Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
start [2010/11/09 15:45] wikiadmin created |
start [2010/11/10 10:51] (current) transactions |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | Welcome to the Transactions page | + | |
+ | |||
+ | ===== Transactional Memory − A Short Introduction ===== | ||
+ | |||
+ | Transactional memory (TM) is a new computation paradigm in which | ||
+ | processes of an application communicate using lightweight, in-memory | ||
+ | transactions. Basically, a process that wants to access a shared data | ||
+ | structure executes some operations on this structure inside a | ||
+ | transaction. When the transaction commits, all these operations appear | ||
+ | as if they took place instantaneously, at some single, unique point in | ||
+ | time. When the transaction aborts, however, all the operations are | ||
+ | roll-backed and their effects are never visible to other transactions. | ||
+ | |||
+ | The TM paradigm is argued to be as easy to use as coarse-grained | ||
+ | locking, and nearly as efficient on multi-core systems as | ||
+ | hand-crafted, fine-grained locking. It is thus not surprising to see a | ||
+ | large body of work dedicated towards implementing the paradigm and | ||
+ | exploring its limitations. | ||
+ | |||
+ | == How Good is a Transactional Memory Implementation? == | ||
+ | |||
+ | We evaluate transactional memory (TM) implementations, both on theoretical and | ||
+ | experimental ground. We ask: | ||
+ | |||
+ | * What are the inherent limitations and trade-offs of transactional memory, | ||
+ | * How expensive are some of the guarantees a TM implementation may provide, and | ||
+ | * Which algorithms/frameworks perform best. |