Patent application number | Description | Published |
20090172306 | System and Method for Supporting Phased Transactional Memory Modes - A phased transactional memory (PhTM) may support a plurality of transactional memory implementations, including software, hardware, and hybrid implementations, and may provide mechanisms for dynamically transitioning between transactional memory modes in response to changing workload characteristics; upon discovering that the current mode does not perform well, is not suitable, or does not support functionality required for particular transactions; or according to scheduled phases. A system providing PhTM may be configured to transition from a first transactional memory mode to a second transactional memory mode while ensuring that transactions executing in the first transactional memory mode do not interfere with correct execution of transactions in the second transactional memory mode. The system may be configured to abort transactions in progress or to wait for transactions to complete, be aborted, or reach a safe transition point before transitioning to a new mode, and may use a global mode indicator in coordinating transitions. | 07-02-2009 |
20090282410 | Systems and Methods for Supporting Software Transactional Memory Using Inconsistency-Aware Compilers and Libraries - Systems and methods to reduce overhead associated with read set consistency validation in software transactional memory implementations are disclosed. These systems and methods may employ an inconsistency-aware compiler-library technique, in which an inconsistency-aware compiler communicates to various inconsistency-aware library functions knowledge about whether a given transaction has read consistent values to date. The inconsistency-aware library functions may exploit this information to avoid the need to validate the transaction, or portions thereof. If read set values are known to be consistent prior to the function call, the compiler may pass a parameter value to the function indicating as much. Otherwise, it may pass a value indicating that the read set values may be inconsistent. An inconsistency-aware function may determine that it will not perform a dangerous action, even though its parameters may not be consistent. Otherwise, the inconsistency-aware function may invoke a validation operation, or may perform other error avoidance operations. | 11-12-2009 |
20100332901 | ADVICE-BASED FEEDBACK FOR TRANSACTIONAL EXECUTION - One embodiment provides a system that facilitates the execution of a transaction for a program in a hardware-supported transactional memory system. During operation, the system records a failure state of the transaction during execution of the transaction using hardware transactional memory mechanisms. Next, the system detects a transaction failure associated with the transaction. Finally, the system provides an advice state associated with the recorded failure state to the program to facilitate a response to the transaction failure by the program. | 12-30-2010 |
20100333093 | FACILITATING TRANSACTIONAL EXECUTION THROUGH FEEDBACK ABOUT MISSPECULATION - One embodiment provides a system that facilitates the execution of a transaction for a program in a hardware-supported transactional memory system. During operation, the system records a misspeculation indicator of the transaction during execution of the transaction using hardware transactional memory mechanisms. Next, the system detects a transaction failure associated with the transaction. Finally, the system provides the recorded misspeculation indicator to the program to facilitate a response to the transaction failure by the program. | 12-30-2010 |
20110078385 | System and Method for Performing Visible and Semi-Visible Read Operations In a Software Transactional Memory - The software transactional memory system described herein may implement a revocable mechanism for managing read ownership in a shared memory. In this system, write ownership may be revoked by readers or writers at any time other than when a writer transaction is in a commit state, wherein its write ownership is irrevocable. An ownership record associated with one or more locations in the shared memory may include an indication of whether the memory locations are owned for writing, and an identifier of the latest writer. A read ownership array may record data indicating which, if any, threads currently own the memory locations for reading. The system may provide an efficient read-validation operation, in which a full read-set validation is avoided unless a change in a global read-write conflict counter value indicates a potential conflict. The system may support a wide range of contention management policies, and may provide implicit privatization. | 03-31-2011 |
20110246725 | System and Method for Committing Results of a Software Transaction Using a Hardware Transaction - The system and methods described herein may exploit hardware transactional memory to improve the performance of a software or hybrid transactional memory implementation, even when an entire user transaction cannot be executed within a hardware transaction. The user code of an atomic transaction may be executed within a software transaction, which may collect read and write sets and/or other information about the atomic transaction. A single hardware transaction may be used to commit the atomic transaction by validating the transaction's read set and applying the effects of the user code to memory, reducing the overhead associated with commitment of software transactions. Because the hardware transaction code is carefully controlled, it may be less likely to fail to commit. Various remedial actions may be taken before retrying hardware transactions following some failures. If a transaction exceeds the constraints of the hardware, it may be committed by the software transactional memory alone. | 10-06-2011 |
20110246993 | System and Method for Executing a Transaction Using Parallel Co-Transactions - 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. | 10-06-2011 |
20120005461 | System and Method for Performing Incremental Register Checkpointing in Transactional Memory - Systems and methods described herein for performing incremental register checkpointing may employ a special register to indicate which registers have already been checkpointed. This register may include one bit per register. These systems may also include a special pointer register whose value identifies a location in user memory or in dedicated on-chip storage at which a copy of a register's value should be saved by a checkpointing operation. Only registers modified during speculative execution or execution of a transaction may be checkpointed (e.g., when register modifying instructions are encountered) and subsequently restored (e.g., due to misspeculation or transaction abort), rather than all of the registers of the processor. Each register may be checkpointed at most once for a given speculative episode or atomic transaction. Setting a bit in the special register may prevent checkpointing of the corresponding register. Setting all of the bits in the special register may disable checkpointing. | 01-05-2012 |