Transactional Memory: Glimmer of a Theory

Guerraoui, Rachid; Kapalka, Michal

doi:10.1007/978-3-642-02658-4_1

Cited by 6 publications

(3 citation statements)

References 48 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In this section, we show that giving HyTM the ability to run and commit transactions in parallel brings considerable instrumentation costs. We focus on a natural progress condition called progressiveness [17][18][19] that allows a transaction to abort only if it experiences a readwrite or write-write conflict with a concurrent transaction: Definition 4 (Progressiveness). Transactions T i and T j conflict in an execution E on a t-object X if X ∈ Dset(T i ) ∩ Dset(T j ) and X ∈ Wset(T i ) ∪ Wset(T j ).…”

Section: Providing Concurrency In Hytmmentioning

confidence: 99%

“…First, transactions that do not conflict are expected to run concurrently, regardless of their types (software or hardware). This property is referred to as progressiveness [19] and is believed to allow for increased parallelism. Second, in addition to exchanging the values of transactional objects, hardware transactions usually employ code instrumentation techniques.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Inherent Limitations of Hybrid Transactional Memory

Alistarh

Kopinsky²,

Kuznetsov

et al. 2015

Lecture Notes in Computer Science

View full text Add to dashboard Cite

International audienceSeveralHybridTransactionalMemory(HyTM)schemeshave recently been proposed to complement the fast, but best-effort nature of Hardware Transactional Memory (HTM) with a slow, reliable software backup. However, the costs of providing concurrency between hardware and software transactions in HyTM are still not well understood.In this paper, we propose a general model for HyTM implementations, which captures the ability of hardware transactions to buffer memory accesses. The model allows us to formally quantify and analyze the amount of overhead (instrumentation) caused by the potential presence of software transactions. We prove that (1) it is impossible to build a strictly serializable HyTM implementation that has both uninstrumented reads and writes, even for very weak progress guarantees, and (2) the instrumentation cost incurred by a hardware transaction in any progressive opaque HyTM is linear in the size of the transaction’s data set. We further describe two implementations which exhibit optimal instrumentation costs for two different progress conditions. In sum, this paper proposes the first formal HyTM model and captures for the first time the trade-off between the degree of hardware-software TM concurrency and the amount of instrumentation overhead

show abstract

Section: Providing Concurrency In Hytmmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Inherent Limitations of Hybrid Transactional Memory

Alistarh

Kopinsky²,

Kuznetsov

et al. 2015

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…On the other hand, consider the schedule σ of (LL, set) in Figure 2(a). Clearly, σ is serializable and is accepted by most (progressive [14]) TM-based implementations since there is no read-write conflict. However, we prove that σ is not accepted by any implementation in P. Our proof technique is interesting in its own right: we show that if there exists any implementation in P that accepts σ, it must also accept the schedule σ depicted in Figure 2(b).…”

Section: On the Incomparability Of Synchronization Techniquesmentioning

confidence: 99%

Optimism for Boosting Concurrency

Gramoli,

Kuznetsov,

Ravi

2012

Preprint

View full text Add to dashboard Cite

Modern concurrent programming benefits from a large variety of synchronization techniques. These include conventional pessimistic locking, as well as optimistic techniques based on conditional synchronization primitives or transactional memory. Yet, it is unclear which of these approaches better leverage the concurrency inherent to multi-cores.In this paper, we compare the level of concurrency one can obtain by converting a sequential program into a concurrent one using optimistic or pessimistic techniques. To establish fair comparison of such implementations, we introduce a new correctness criterion for concurrent programs, defined independently of the synchronization techniques they use.We treat a program's concurrency as its ability to accept a concurrent schedule, a metric inspired by the theories of both databases and transactional memory. We show that pessimistic locking can provide strictly higher concurrency than transactions for some applications whereas transactions can provide strictly higher concurrency than pessimistic locks for others. Finally, we show that combining the benefits of the two synchronization techniques can provide strictly more concurrency than any of them individually. We propose a list-based set algorithm that is optimal in the sense that it accepts all correct concurrent schedules. As we show via experimentation, the optimality in terms of concurrency is reflected by scalability gains.

show abstract