304 results about "Transactional memory" patented technology

A set top box (STB) includes a trusted transactional cache and associated transactional protocol and enables e-commerce transactions to be securely committed to a remote server extremely quickly and with little network overhead. The invention does away with the user concern of whether the transaction was successful. The STB operates equally well on robust private networks as on unpredictable Internet or wireless networks, and avoids upsetting users who would otherwise have to wait in front of a display screen for confirmation of completion of the transaction after a temporary communication failure with the central site. The method may advantageously be used to provide cost-effective micro-payments solutions. The STB may include a dual headed display capability in which data and video maybe be directed to separate displays. The STB may feature an embedded ticket printer, as well as an embedded barcode scanner. This enables non computer literate users to more conveniently track transactions committed via the STB, or to take advantage of promotional coupons. The STB features an embedded hardware true Random Number Generator to produce maximum entropy encryption keys, therefore providing maximum secure and fool-proof means to protect private data using government authorized encryption schemes.

A testing tool automatically records a series of user steps taken during a user session with a transactional server and generates a test for testing the functionality of server. Through a user interface of the testing tool, the user can define verification steps to automatically test for expected server responses during test execution. The testing tool displays the test to the user as a tree having nodes (displayed as icons) which represent steps of the test. Via the user interface, the user can modify node properties and perform other types of tree edit operations to edit the test, without the need to know a scripting or other programming language. When the user selects a node that corresponds to a particular field or other object of the server screen, the testing tool automatically displays the screen with the object highlighted. The testing tool also allows the test author to use a spreadsheet to conveniently specify data sets for running multiple iterations of a test; thus, the user can record a single transaction and then automatically test the transaction with other data sets.

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.

Hardware-based transactional memory mechanisms, such as Speculative Lock Elision (SLE), may allow multiple threads to concurrently execute critical sections protected by the same lock as speculative transactions. Such transactions may abort due to contention or due to misidentification of code as a critical section. In various embodiments, speculative execution mechanisms may be augmented with software and/or hardware contention management mechanisms to reduce abort rates. Speculative execution hardware may send a hardware interrupt signal to notify software components of a speculative execution event (e.g., abort). Software components may respond by implementing concurrency-throttling mechanisms and/or by determining a mode of execution (e.g., speculative, non-speculative) for a given section and communicating that determination to the hardware speculative execution mechanisms, e.g., by writing it into a lock predictor cache. Subsequently, hardware speculative execution mechanisms may determine a preferred mode of execution for the section by reading the corresponding entry from the lock predictor cache.

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.

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.

A computer processing system having memory and processing facilities for processing data with a computer program is a Hybrid Transactional Memory multiprocessor system with modules 1 . . . n coupled to a system physical memory array, I/O devices via a high speed interconnection element. A CPU is integrated as in a multi-chip module with microprocessors which contain or are coupled in the CPU module to an assist thread facility, as well as a memory controller, cache controllers, cache memory, and other components which form part of the CPU which connects to the high speed interconnect which functions under the architecture and operating system to interconnect elements of the computer system with physical memory, various 1/0, devices and the other CPUs of the system. The current hybrid transactional memory elements support for a transactional memory system that has a simple/cost effective hardware design that can deal with limited hardware resources, yet one which has a transactional facility control logic providing for a back up assist thread that can still allow transactions to reference existing libraries and allows programmers to include calls to existing software libraries inside of their transactions, and which will not make a user code use a second lock based solution.

Utilizing a software locking approach to execute a code section, upon failure of a hardware transactional approach, is disclosed. A method is disclosed that includes utilizing a hardware approach to transactional memory to execute a code section relating to memory. Where utilizing the hardware approach fails a threshold in executing the code section, the software approach is instead utilized to execute the code section relating to the memory. The threshold may include the hardware approach aborting execution of the code section a predetermined one or more times. The hardware approach includes starting a transaction inclusive of the code section, conditionally executing the transaction, and upon successfully completing the transaction, committing execution to memory. The software locking approach includes placing a lock on memory, executing the code section, committing execution of the code section to the memory as the code section is executed, and then removing the lock from the memory.

Hardware assisted transactional memory system with open nested transactions. Some embodiments described herein implement a system whereby hardware acceleration of transactions can be accomplished by implementing open nested transaction in hardware which respect software locks such that a top level transaction can be implemented in software, and thus not be limited by hardware constraints typical when using hardware transactional memory systems.

The described embodiments provide a processor (e.g., processor 102) for executing instructions. During execution, the processor starts by transactionally executing instructions from a protected section of program code. The processor then encounters a transactional failure condition while transactionally executing the instructions from the protected section of program code. In response to encountering the transactional failure condition, the processor enters a transactional-scout mode and speculatively executes subsequent instructions in the transactional-scout mode.

A computing system processes memory transactions for parallel processing of multiple threads of execution with millicode assists. The computing system transactional memory support provides a Transaction Table in memory and a method of fast detection of potential conflicts between multiple transactions. Special instructions may mark the boundaries of a transaction and identify memory locations applicable to a transaction. A ‘private to transaction’ (PTRAN) tag, directly addressable as part of the main data storage memory location, enables a quick detection of potential conflicts with other transactions that are concurrently executing on another thread of said computing system. The tag indicates whether (or not) a data entry in memory is part of a speculative memory state of an uncommitted transaction that is currently active in the system. Program millicode provides transactional memory functions including creating and updating transaction tables, committing transactions and controlling the rollback of transactions which fail.

The systems and methods described herein may extend transactional memory implementations to support transaction communicators and/or transaction condition variables for which transaction isolation is relaxed, and through which concurrent transactions can communicate and be synchronized with each other. Transactional accesses to these objects may not be isolated unless called within communicator-isolating transactions. A waiter transaction may invoke a wait method of a transaction condition variable, be added to a wait list for the variable, and be suspended pending notification of a notification event from a notify method of the variable. A notifier transaction may invoke a notify method of the variable, which may remove the waiter from the wait list, schedule the waiter transaction for resumed execution, and notify the waiter of the notification event. A waiter transaction may commit only if the corresponding notifier transaction commits. If the waiter transaction aborts, the notification may be forwarded to another waiter.

The system and methods described herein may reduce read/write fence latencies and cache pressure related to STM metadata accesses. These techniques may leverage locality information (as reflected by the value of a respective locale guard) associated with each of a plurality of data partitions (locales) in a shared memory to elide various operations in transactional read/write fences when transactions access data in locales owned by their threads. The locale state may be disabled, free, exclusive, or shared. For a given memory access operation of an atomic transaction targeting an object in the shared memory, the system may implement the memory access operation using a contention mediation mechanism selected based on the value of the locale guard associated with the locale in which the target object resides. For example, a traditional read/write fence may be employed in some memory access operations, while other access operations may employ an optimized read/write fence.

A system for controlling contention between conflicting transactions in a transactional memory system. During operation, the system receives a request to access a cache line and then determines if the cache line is already in use by an existing transaction in a cache state that is incompatible with the request. If so, the system determines if the request is from a processor which is in a polite mode. If this is true, the system denies the request to access the cache line and continues executing the existing transaction.

In a multi-threaded computer system that uses transactional memory, object fields accessed by only one thread are accessed by regular non-transactional read and write operations. When an object may be visible to more than one thread, access by non-transactional code is prevented and all accesses to the fields of that object are performed using transactional code. In one embodiment, the current visibility of an object is stored in the object itself. This stored visibility can be checked at runtime by code that accesses the object fields or code can be generated to check the visibility prior to access during compilation.

In transactional memory systems, transactional aborts due to conflicts between concurrent threads may cause system performance degradation. A compiler may attempt to minimize runtime abort rates by performing one or more code transformations and/or other optimizations on a transactional memory program in an attempt to minimize one or more store-commit intervals. The compiler may employ store deferral, hoisting of long-latency operations from within a transaction body and/or store-commit interval, speculative hoisting of long-latency operations, and/or redundant store squashing optimizations. The compiler may perform optimizing transformations on source code and/or on any intermediate representation of the source code (e.g., parse trees, un-optimized assembly code, etc.). In some embodiments, the compiler may preemptively avoid naïve target code constructions. The compiler may perform static and/or dynamic analysis of a program in order to determine which, if any, transformations should be applied and/or may dynamically recompile code sections at runtime, based on execution analysis.

Transactional Lock Elision (TLE) may allow multiple threads to concurrently execute critical sections as speculative transactions. Transactions may abort due to various reasons. To avoid starvation, transactions may revert to execution using mutual exclusion when transactional execution fails. Because threads may revert to mutual exclusion in response to the mutual exclusion of other threads, a positive feedback loop may form in times of high congestion, causing a “lemming effect”. To regain the benefits of concurrent transactional execution, the system may allow one or more threads awaiting a given lock to be released from the wait queue and instead attempt transactional execution. A gang release may allow a subset of waiting threads to be released simultaneously. The subset may be chosen dependent on the number of waiting threads, historical abort relationships between threads, analysis of transactions of each thread, sensitivity of each thread to abort, and/or other thread-local or global criteria.

Systems and methods for optimizing code may use transactional memory to optimize one code section by forcing another code section to execute atomically. Application source code may be analyzed to identify instructions in one code section that only need to be executed if there exists the possibility that another code section (e.g., a critical section) could be partially executed or that its results could be affected by interference. In response to identifying such instructions, alternate code may be generated that forces the critical section to be executed as an atomic transaction, e.g., using best-effort hardware transactional memory. This alternate code may replace the original code or may be included in an alternate execution path that can be conditionally selected for execution at runtime. The alternate code may elide the identified instructions (which are rendered unnecessary by the transaction) by removing them, or by including them in the alternate execution path.