On the Input Acceptance of Transactional Memory

Abstract

We present the Input Acceptance of Transactional Memory (TM). Despite the large interest for performance of TMs, no existing research work has investigated the impact of solving a conflict that does not need to be solved. Traditional solutions for a TM to be correct is to delay or abort a transaction as soon as it presents a risk to violate consistency. Both alternatives are costly and should be avoided if consistency is actually preserved. To address this problem, we introduce the input acceptance of a TM as its ability to commit transactions, we upper-bound the input acceptance of existing TMs and propose a new TM with higher input acceptance.

Composing Relaxed Transactions

“…Now an add operation, implemented using a classic transaction, is inserting an element somewhere in the middle of the list, while in the meantime another add is modifying the head of the list. In this situation, most implementations would cause one of the transactions to unnecessarily abort in order to avoid the complex detection of cycles in the conflict graph [13] and still guarantee serializability. However, an elastic transaction [16] would consider this to be a false conflict and hence allow both transactions to commit since semantically the execution does not violate atomicity.…”

“…Yet, transactions in their classic form are often considered too restrictive [13]. They tend to reduce concurrency by overconservatively aborting transactions even in executions that would semantically be correct at the application level, should the transactions be actually committed.…”

Democratizing Transactional Programming

“…Clearly, the value of the head → next pointer observed by the transaction (Line 6) is no longer important when the transaction is checking whether the value val corresponds to a value of a node further in the list (Line 7), yet a concurrent modification of head → next can invalidate the transaction when reading next → val ; this is a false-conflict leading to unnecessary aborts. Such unnecessary aborts limit concurrency because they preclude schedules that would be correct, be all the transactions committed [35]. Conversely, the hand-over-hand locking program of Algorithm 3 allows such concurrent update (Line 7) when checking the value (Line 8), starting from the second iteration of the while-loop.…”

Brief announcement

“…A transactional history is valid with respect to synchronization S if it is equivalent to a sequential history and if it does not result from the execution by S of an invalid schedule (with abort events). (This notion generalizes the input acceptance [2] to S.) A lock-based history is valid with respect to synchronization S if it is equivalent to a sequential history and for each object x, no lock (x)i occurs between a lock (x)j and an unlock (x)j where i = i.…”