Transactional memory compatibility management

#Sometimes a computational problem can be divided into pieces in a way that allows a system to work on more than one piece at a time. For example, concurrent computing simultaneously carries out multiple computing tasks, such as multiple threads or multiple processes. Similarly, parallel computing systems carry out multiple instructions simultaneously. Parallel computing may be viewed as an example of concurrent computing, and the distinction between them is not critical here.

#Various tools and techniques are used to coordinate the pieces of a divided computational problem. In particular, transactional memory may be used to control access to shared memory. Transactional memory supports a way to abstractly express what memory operations operate with a transactional behavior. In some transactional memory implementations, code in a transaction executes a series of reads and writes to shared memory which appear from outside the transaction to happen atomically. That is, either all of the code in a transaction completes (transaction succeeded), or else work done by the code before the transaction fails is undone, so the view from outside the transaction is that none of the code completed (transaction failed).

#In some situations, code is initially designed and written to run on a transactional memory system, while in other situations the possibility of running particular code on a transactional memory implementation arises after that code has already been designed and written. Some code is also less amenable to transactional execution than other code. For example, it may be difficult or impossible to undo work done by code that transmits data over a network or code that changes the state of a peripheral device.

#A more particular description will be given with reference to the attached drawings. These drawings only illustrate selected aspects and thus do not fully determine coverage or scope.

#FIG. 1 is a block diagram illustrating a computer system having a runtime environment, a transactional memory implementation, source code, corresponding intermediate language code, and other items in an operating environment, and also illustrating configured storage medium embodiments;

#FIG. 2 is a block diagram further illustrating intermediate language code and associated transactional memory compatibilities;

#Overview

#With the increased use of concurrent programming and multi-core processors, transactional memory is gaining traction as a means of mitigating shared memory synchronization problems. Programmers are writing programs with fine-grained parallel execution contexts. When managing access to shared state, however, lock-based methods are difficult to get correct and do not compose over multiple modules. Transactional memory offers an implicit fine-grained alternative to explicit lock-based synchronization, thereby providing programmers with an easy-to-use programming model. Transactional memory implementations may allow programmers to express synchronization and to manage failures with greater reliability, scalability and ease of use than lock-based alternatives.

#In some views, transactional memory systems guarantee to a programmer the properties of atomicity, consistency and isolation. Atomicity refers to the ability of the transactional memory system to make it appear that either all the operations in a transaction were executed, or none were. A transactional memory system may provide strong atomicity or weak atomicity, for example. Strong atomicity guarantees atomicity and isolation between transactions and non-transactional code by making all non-transactional work access memory as if it were in a transaction, while weak atomicity guarantees atomicity and isolation between transactions. In one view, consistency refers to the fact that transactions appear to operate against a consistent snapshot of memory, where no other thread is writing to any of the shared memory locations. Consistency may also mean that when code is updating multiple transactional resources (tables, tables and indices, files and databases, etc.), all of the updates made within a single transaction are made available at the same time, as part of the committing action; in some views, this is isolation, not consistency. Some argue that consistency doesn't pertain to transactional memory, but is instead the job of the application, arguing that in databases consistency is guaranteed through a constraint system which is not available to the transactional memory programmer. Isolation may also refer to the fact that the effect of memory writes made by a transaction are not visible to other transactions until the writes are committed. Regardless of variations in terminology, it is generally agreed that the transaction system makes it appear that these updates occurred all at once. Any other transaction attempting to read two objects in memory at the same time these objects are being committed will not see one object updated and one that has not yet been updated.