Amalgamated Lock-Elision

Abstract

Hardware lock-elision (HLE) introduces concurrency into legacy lockbased code by optimistically executing critical sections in a fast-path as hardware transactions. Its main limitation is that in case of repeated aborts, it reverts to a fallback-path that acquires a serial lock. This fallback-path lacks hardwaresoftware concurrency, because all fast-path hardware transactions abort and wait for the completion of the fallback. Software lock elision has no such limitation, but the overheads incurred are simply too high. We propose amalgamated lock-elision (ALE), a novel lock-elision algorithm that provides hardware-software concurrency and efficiency: the fallback-path executes concurrently with fast-path hardware transactions, while the common-path fast-path reads incur no overheads and proceed without any instrumentation. The key idea in ALE is to use a sequence of fine-grained locks in the fallback-path to detect conflicts with the fast-path, and at the same time reduce the costs of these locks by executing the fallback-path as a series segments, where each segment is a dynamic length short hardware transaction. We implemented ALE into GCC and tested the new system on Intel Haswell 16-way chip that provides hardware transactions. We benchmarked linked-lists, hash-tables and red-black trees, as well as converting KyotoCacheDB to use ALE in GCC, and all show that ALE significantly outperforms HLE.

A Template for Implementing Fast Lock-free Trees Using HTM

“…First, they provide pointers to an SCX-record while its SCX is in progress (so it can be helped). Second, they act as locks that grant exclusive access to an SCX O , and allow an invocation of SCX O to determine whether any user-defined fields 1 Private variable for process p: attempts p , tagseq p 2 SCX(V , R, f ld, new ) by process p 3 onAbort:…”

“…Case 2: Suppose processes take only finitely many steps in transactions. Then, processes take only finitely many steps in SCX 1 . It follows that, after some time t ′ , no process takes a step in SCX 1 .…”

“…Moreover, if wraparound is still a concern, one can replace the freezing CAS steps in SCX O with double-wide CAS instructions (available on most modern systems) which atomically operate on 128-bits. 1 Private variable for process p: tseq p 2 SCX 4 (V , R, f ld, new ) by process p 3 Let infoF ields be a pointer to a table in p's private memory containing, 4 for each r in V , the value of r .info read by p's last LLX(r ) 5 Let old be the value for f ld returned by p's last LLX(r ) 6 Begin hardware transaction Let infoF ields be a pointer to a table in p's private memory containing, 4 for each r in V , the value of r .info read by p's last LLX(r ) 5 Let old be the value for f ld returned by p's last LLX(r ) 6 Begin hardware transaction by our transformations). Consequently, p will fail to freeze r , and S will perform an explicit abort and return False, so it will not reach line 16, which contradicts our assumption (so this case is impossible).…”

“…Updates are performed on keys drawn uniformly randomly from a fixed key range [0, K). RQs are performed on ranges [lo, lo + s) where lo is uniformly random in [0, K) and s is chosen, according to a probability distribution described below, from [1,1000] for the BST and [1,10000] for the (a, b)-tree. (We found that nodes in the (a, b)-tree contained approximately 10 keys, on average, so the respective maximum values of s for the BST and (a, b)-tree resulted in range queries returning keys from approximately the same number of nodes in both data structures.)…”

“…Different options for concurrency have recently begun to be explored in the context of TLE. Refined TLE [14] and Amalgamated TLE [1] both improve the concurrency of TLE when a process is on the fallback path by allowing HTM transactions to run concurrently with a single process on the fallback path. Both of these approaches still serialize processes on the fallback path.…”