G06F9/528

THREAD-SAFE DEVELOPMENT IN A MULTI-THREADED SYSTEM

A method for thread-safe development of a computer program configured for parallel thread execution comprises maintaining a digital record of read or write access to a data object from each of a plurality of sibling threads executing on a computer system. Pursuant to each instance of read or write access from a given sibling thread, an entry comprising an indicator of the access type is added to the digital record. The method further comprises assessing the thread safety of the read or write access corresponding to each entry in the digital record and identifying one or more thread-unsafe instances of read or write access based on the assessment of thread safety.

Speculative bank activate dynamic random access memory (DRAM) scheduler

A system and associated processes may perform a memory access operation that includes receiving a data packet comprising a command of a type of a plurality of types of commands. The processes may include initiating a decoding of a first portion of the command, and automatically speculating as to the type of the command. Based on the speculation as to the type of the command, a bank activate command may be generated before the data packet is entirely decoded or received.

Determining action selection policies of an execution device

Computer-implemented methods, systems, and apparatus, including computer-readable medium, for generating an action selection policy for causing an execution device to complete a task are described. Data representing a task that is divided into a sequence of subtasks are obtained. For a specified subtask except for a first subtask in the sequence of subtasks, a value neural network (VNN) is trained. The VNN receives inputs include reach probabilities of reaching a subtask initial state of the specified subtask, and predicts a reward of the execution device in the subtask initial state of the specified subtask. A strategy neural network (SNN) for a prior subtask that precedes the specified subtask is trained based on the VNN. The SNN receives inputs include a sequence of actions that reach a subtask state of the prior subtask, and predicts an action selection policy of the execution device in the subtask state of the prior subtask.

DETERMINING ACTION SELECTION POLICIES OF AN EXECUTION DEVICE

Computer-implemented methods, systems, and apparatus, including computer-readable medium, for generating an action selection policy for causing an execution device to complete a task are described. Data representing a task that is divided into a sequence of subtasks are obtained. For a specified subtask except for a first subtask in the sequence of subtasks, a value neural network (VNN) is trained. The VNN receives inputs include reach probabilities of reaching a subtask initial state of the specified subtask, and predicts a reward of the execution device in the subtask initial state of the specified subtask. A strategy neural network (SNN) for a prior subtask that precedes the specified subtask is trained based on the VNN. The SNN receives inputs include a sequence of actions that reach a subtask state of the prior subtask, and predicts an action selection policy of the execution device in the subtask state of the prior subtask.

Memory system, operation method thereof, and database system including the memory system
11182300 · 2021-11-23 · ·

A method for operating a multi-transaction memory system, the method includes: storing Logical Block Address (LBA) information changed in response to a request from a host and a transaction identification (ID) of the request into one page of a memory block; and performing a transaction commit in response to a transaction commit request including the transaction ID from the host, wherein the performing of the transaction commit includes: changing a valid block bitmap in a controller of the multi-transaction memory system based on the LBA information.

APPARATUS AND DATA PROCESSING METHOD FOR TRANSACTIONAL MEMORY
20210271485 · 2021-09-02 ·

In an apparatus with transactional memory support circuitry, for a first type of transaction started using a first type of transaction start instruction, commitment of results of instructions executed speculatively following the first type of transaction start instruction are prevented until a transaction end instruction is reached. An abort is triggered when a conflict is detected between an address of a memory access from another thread and the addresses tracked for the transaction. For a second type of transaction started using a second type of transaction start instruction, an address of the read operation is marked as trackable whilst an address of a write operation is omitted from being marked as trackable. This allows an apparatus that supports transactional memory to also be used for multi-word address watching.

Block-based processor core composition register

Systems, apparatuses, and methods related to a block-based processor core composition register are disclosed. In one example of the disclosed technology, a processor can include a plurality of block-based processor cores for executing a program including a plurality of instruction blocks. A respective block-based processor core can include one or more sharable resources and a programmable composition control register. The programmable composition control register can be used to configure which resources of the one or more sharable resources are shared with other processor cores of the plurality of processor cores.

CONTROLLER ADDRESS CONTENTION ASSUMPTION

Embodiments of the present invention are directed to a computer-implemented method for controller address contention assumption. A non-limiting example computer-implemented method includes a shared controller receiving a fetch request for data from a first requesting agent, the receiving via at least one intermediary controller. The shared controller performs an address compare using a memory address of the data. In response to the memory address matching a memory address stored in the shared controller, the shared controller acknowledges the at least one intermediary controller's fetch request, wherein upon acknowledgement, the at least one intermediary controller resets, wherein the acknowledging comprises exchanging tokens by the shared controller and the at least one intermediary controller, wherein the at least one intermediary controller transmits an identity of the first requesting agent and a type of operation associated with the requested data, and wherein the shared controller transmits an acceptance.

Reactive transaction management

Methods, systems, and apparatus, including computer programs encoded on computer storage media, for implementing reactive transaction management. A method includes: receiving, by an application framework, a program that defines a transaction having a plurality of operations to one or more respective transactional resources; generating, by the application framework, a respective sequence of reactive operators for each transactional resource in the transaction; initiating each respective sequence of reactive operators, including: determining, by the application framework using a first thread, that one of the sequences has not completed; in response, relinquishing computing resources of the first thread; receiving an indication that all of the sequences of reactive operators have completed; determining that none of the sequences of reactive operators failed; and in response, committing the operations of the transaction in each of the one or more transactional resources.

Distributed system, computer program product and method

A distributed system is provided that includes member nodes and a leader node. Each member node stores a database and updates the database by performing common ones of a plurality of transactions. The leader node generates a batch, to be executed by each member node, which includes two or more transactions lacking an access conflict from among the plurality of transactions. The leader node includes: a section that generates an access set as a set of database entries to be accessed by each transaction to be executed; a section that generates the batch, based on the access set of each transaction to be executed; and a leader-side section that performs a consensus process for the batch among the leader and member nodes. Each member node includes the database; a member-side section that performs a consensus process for the batch; and a section that performs parallel execution of batch transactions.