The transactional memory system described herein may implement parallel co-transactions that access a shared memory such that at most one of the co-transactions in a set will succeed and all others will fail (e.g., be aborted). Co-transactions may improve the performance of programs that use transactional memory by attempting to perform the same high-level operation using multiple algorithmic approaches, transactional memory implementations and/or speculation options in parallel, and allowing only the first to complete to commit its results. If none of the co-transactions succeeds, one or more may be retried, possibly using a different approach and/or transactional memory implementation. The at-most-one property may be managed through the use of a shared “done” flag. Conflicts between co-transactions in a set and accesses made by transactions or activities outside the set may be managed using lazy write ownership acquisition and/or a priority-based approach. Each co-transaction may execute on a different processor resource.
Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A method, comprising: using a computer to perform: initiating concurrent execution of two or more different code sequences, each of which is executable to perform a respective task as an atomic transaction, wherein each of the atomic transactions is a transaction in a set of co-transactions, wherein at most one of the atomic transactions in the set of co-transactions is to be allowed to succeed and commit its results, and wherein each of the two or more code sequences comprises one or more memory access operations to locations in a shared memory that is accessible to a plurality of concurrently executing transactions; committing results of at most one of the atomic transactions being performed by the two or more code sequences; and aborting all of the atomic transactions being performed by the two or more code sequences other than the at most one of the atomic transactions for which results are committed, wherein aborted ones of the atomic transactions in the set of co-transactions are not subsequently retried if results of one of the atomic transactions being performed by the two or more code sequences have been committed.
The system runs multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. This approach is for improving performance by trying different algorithms or methods in parallel.
2. The method of claim 1 , wherein the respective tasks to be performed by all of the two or more code sequences as atomic transactions have the same objective.
The method described in claim 1 runs multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. All the co-transactions being executed concurrently aim to achieve the same objective or final result, just by using different approaches. This approach is for improving performance by trying different algorithms or methods in parallel, all targeting the same final outcome.
3. The method of claim 1 , wherein at least two of the atomic transactions employ different transactional memory implementations or different speculation options.
The method described in claim 1 runs multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. At least two of these co-transactions use different methods for managing transactional memory (like different libraries or locking strategies) or different speculation approaches (optimistic vs. pessimistic locking).
4. The method of claim 1 , further comprising: in response to none of the transactions committing their results, initiating a retry of the execution of at least one of the two or more code sequences.
The method described in claim 1 runs multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. If none of the co-transactions successfully commit their results, the system retries at least one of them.
5. The method of claim 1 , wherein said committing comprises setting a value of a shared indicator that is accessible to all of the two or more code sequences to indicate that the at most one of the atomic transactions has committed its results; and wherein said aborting is performed in response to detecting that the shared indicator was set to indicate that the at most one of the atomic transactions has committed its results.
The method described in claim 1 runs multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. To signal that a co-transaction has committed, the system sets a shared flag that all co-transactions can see. The other co-transactions monitor this flag and abort themselves if they detect that it has been set.
6. The method of claim 1 , wherein executing the two or more code sequences comprises locally buffering any write access operations in the respective atomic transactions that target locations in the shared memory without modifying the targeted locations in the shared memory; and wherein said committing comprises modifying the locations targeted in the shared memory to reflect the locally buffered write access operations performed by the at most one of the two or more code sequences.
The method described in claim 1 runs multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. While running, each co-transaction saves its write operations in a temporary, local buffer. Only when a co-transaction commits, its buffered writes are actually applied to the shared memory.
7. The method of claim 1 , further comprising: a conflict detection mechanism determining whether there are any conflicts between the two or more code sequences and one or more concurrently executing transactions other than the atomic transactions being performed by the two or more code sequences.
The method described in claim 1 runs multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. A conflict detection mechanism checks for conflicts between the running co-transactions and other normal transactions that might be accessing the same shared memory.
8. The method of claim 1 , wherein said initiating comprises initiating execution of each of the two or mode code sequences on a different processor resource.
The method described in claim 1 runs multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. Each of these co-transactions runs on a different processor core or resource.
9. A system comprising: one or more processors; and a memory coupled to the one or more processors and storing program instructions executable by the one or more processors to cause the one or more processors to perform: initiating concurrent execution of two or more different code sequences, each of which is executable to perform a respective task as an atomic transaction, wherein each of the atomic transactions is a transaction in a set of co-transactions, wherein at most one of the atomic transactions in the set of co-transactions is to be allowed to succeed and commit its results, and wherein each of the two or more code sequences comprises one or more memory access operations to locations in a shared memory that is accessible to a plurality of concurrently executing transactions; committing results of at most one of the atomic transactions being performed by the two or more code sequences; and aborting all of the atomic transactions being performed by the two or more code sequences other than the at most one of the atomic transactions for which results are committed, wherein aborted ones of the atomic transactions in the set of co-transactions are not subsequently retried if results of one of the atomic transactions being performed by the two or more code sequences have been committed.
The system includes processors and memory to run multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. This approach is for improving performance by trying different algorithms or methods in parallel.
10. The system of claim 9 , wherein at least two of the atomic transactions employ different transactional memory implementations or different speculation options.
The system described in claim 9 includes processors and memory to run multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. At least two of these co-transactions use different methods for managing transactional memory (like different libraries or locking strategies) or different speculation approaches (optimistic vs. pessimistic locking).
11. The system of claim 9 , wherein the program instructions are further executable by the one or more processors to cause the one or more processors to perform: in response to none of the transactions committing their results, initiating a retry of the execution of at least one of the two or more code sequences.
The system described in claim 9 includes processors and memory to run multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. If none of the co-transactions successfully commit their results, the system retries at least one of them.
12. The system of claim 9 , wherein said committing comprises setting a value of a shared indicator that is accessible to all of the two or more code sequences to indicate that the at most one of the atomic transactions has committed its results; and wherein said aborting is performed in response to detecting that the shared indicator was set to indicate that the at most one of the atomic transactions has committed its results.
The system described in claim 9 includes processors and memory to run multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. To signal that a co-transaction has committed, the system sets a shared flag that all co-transactions can see. The other co-transactions monitor this flag and abort themselves if they detect that it has been set.
13. The system of claim 9 , memory access operations to locations in a shared memory that is accessible to a plurality of concurrently executing transactions; committing results of at most one of the atomic transactions being performed by the two or more code sequences; and aborting all of the atomic transactions being performed by the two or more code sequences other than the at most one of the atomic transactions for which results are committed, wherein aborted ones of the atomic transactions in the set of co-transactions are not subsequently retried if results of one of the atomic transactions being performed by the two or more code sequences have been committed.
The system includes processors and memory to run multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. This approach is for improving performance by trying different algorithms or methods in parallel.
14. The system of claim 9 , wherein the program instructions are further executable by the one or more processors to cause the one or more processors to perform: determining whether there are any conflicts between the two or more code sequences and one or more concurrently executing transactions other than the atomic transactions being performed by the two or more code sequences.
The system described in claim 9 includes processors and memory to run multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. The system detects conflicts between the running co-transactions and other normal transactions accessing the shared memory.
15. The system of claim 9 , wherein said initiating comprises initiating execution of each of the two or more code sequences on a different processor resource.
This invention relates to distributed computing systems and addresses the problem of efficiently executing multiple code sequences in parallel. The system comprises a controller and at least two processor resources. The controller is configured to receive a plurality of code sequences. It then initiates execution of these code sequences. Specifically, the initiation involves assigning each of the two or more code sequences to a different processor resource for execution. This ensures that different parts of the overall computation can run concurrently on separate hardware, thereby improving performance and throughput. The system is designed to manage the distribution and execution of these code sequences across available processing power.
16. A computer readable storage medium storing program instructions computer-executable to perform: initiating concurrent execution of two or more different code sequences, each of which is executable to perform a respective task as an atomic transaction, wherein each of the atomic transactions is a transaction in a set of co-transactions, wherein at most one of the atomic transactions in the set of co-transactions is to be allowed to succeed and commit its results, and wherein each of the two or more code sequences comprises one or more transactions has committed its results.
A storage medium contains instructions to run multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again.
17. The storage medium of claim 16 , wherein at least two of the atomic transactions employ different transactional memory implementations or different speculation options.
The storage medium from claim 16 contains instructions to run multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. At least two of these co-transactions use different methods for managing transactional memory (like different libraries or locking strategies) or different speculation approaches (optimistic vs. pessimistic locking).
18. The storage medium of claim 16 , wherein the program instructions are further computer-executable to perform: in response to none of the transactions committing their results, initiating a retry of the execution of at least one of the two or more code sequences.
The storage medium from claim 16 contains instructions to run multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. If none of the co-transactions successfully commit their results, the system retries at least one of them.
19. The storage medium of claim 16 , wherein said committing comprises setting a value of a shared indicator that is accessible to all of the two or more code sequences to indicate that the at most one of the atomic transactions has committed its results; and wherein said aborting is performed in response to detecting that the shared indicator was set to indicate that the at most one of the atomic wherein executing the two or more code sequences comprises locally buffering any write access operations in the respective atomic transactions that target locations in the shared memory without modifying the targeted locations in the shared memory; and wherein said committing comprises modifying the locations targeted in the shared memory to reflect the locally buffered write access operations performed by the at most one of the two or more code sequences.
The storage medium from claim 16 contains instructions to run multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. The instructions make each co-transaction save its write operations in a temporary, local buffer. Only when a co-transaction commits, its buffered writes are actually applied to the shared memory.
20. The storage medium of claim 16 , wherein executing the two or more code sequences comprises locally buffering any write access operations in the respective atomic transactions that target locations in the shared memory without modifying the targeted locations in the shared memory; and wherein said committing comprises modifying the locations targeted in the shared memory to reflect the locally buffered write access operations performed by the at most one of the two or more code sequences.
The storage medium from claim 16 contains instructions to run multiple versions of the same task (co-transactions) at the same time. Each version is treated as an atomic transaction, meaning it either completely succeeds or completely fails. The goal is to have only one version succeed and commit its changes to shared memory, while all the other versions are aborted. Aborted transactions are not retried again. The instructions make each co-transaction save its write operations in a temporary, local buffer. Only when a co-transaction commits, its buffered writes are actually applied to the shared memory.
Cooperative Patent Classification codes for this invention. Click any code to explore related patents in that topic.
March 31, 2010
June 11, 2013
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.