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. | ||
