Motivation Transactional memory

atomicity between 2 parallel transactions conflict

in concurrent programming, synchronization required when parallel threads attempt access shared resource. low level thread synchronization constructs such locks pessimistic , prohibit threads outside critical section making changes. process of applying , releasing locks functions additional overhead in workloads little conflict among threads. transactional memory provides optimistic concurrency control allowing threads run in parallel minimal interference. goal of transactional memory systems transparently support regions of code marked transactions enforcing atomicity, consistency , isolation.

a transaction collection of operations can execute , commit changes long conflict not present. when conflict detected, transaction revert initial state (prior changes) , rerun until conflicts removed. before successful commit, outcome of operation purely speculative inside transaction. in contrast lock-based synchronization operations serialized prevent data corruption, transactions allow additional parallelism long few operations attempt modify shared resource. since programmer not responsible explicitly identifying locks or order in acquired, programs utilize transactional memory cannot produce deadlock.

with these constructs in place, transactional memory provides high level programming abstraction allowing programmers enclose methods within transactional blocks. correct implementations ensure data cannot shared between threads without going through transaction , produce serializable outcome. example, code can written as:

in code, block defined transaction guaranteed atomicity, consistency , isolation underlying transactional memory implementation , transparent programmer. variables within transaction protected external conflicts, ensuring either correct amount transferred or no action taken @ all. note concurrency related bugs still possible in programs use large number of transactions, in software implementations library provided language unable enforce correct use. bugs introduced through transactions can difficult debug since breakpoints cannot placed within transaction.

transactional memory limited in requires shared-memory abstraction. although transactional memory programs cannot produce deadlock, programs may still suffer livelock or resource starvation. example, longer transactions may repeatedly revert in response multiple smaller transactions, wasting both time , energy.