Locking Made Easy

Antić, Jelena; Chatzopoulos, Georgios; Guerraoui, Rachid; Trigonakis, Vasileios

doi:10.1145/2988336.2988357

Cited by 7 publications

(12 citation statements)

References 42 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The authors designed a synchronization framework that dynamically switches between five different spin‐lock implementations with the objective of maximizing an application performance metric. GLS (Generic Locking Service) 18 is an adaptive scheme that automatically selects the lock algorithm depending on the workload features. With low contention, GLS uses a simple spin‐lock scheme, while with high contention it switches to queue‐based locks or, under high system load, to sleeping locks.…”

Section: Related Workmentioning

confidence: 99%

Mutable locks: Combining the best of spin and sleep locks

Marotta

Tiriticco

Sanzo

et al. 2020

Concurrency and Computation

View full text Add to dashboard Cite

In this article, we present mutable locks, a synchronization construct with the same semantic of traditional locks (such as spin locks or sleep locks), but with a self-tuned optimized trade-off between responsiveness and CPU-time usage during threads' wait phases. Mutable locks tackle the need for efficient synchronization supports in the era of multicore machines, where the run-time performance should be optimized while reducing resource usage. This goal should be achieved with no intervention by the programmers. Our proposal is intended for exploitation in generic concurrent applications, where scarce or no knowledge is available about the underlying software/hardware stack and the workload. This is an adverse scenario for static choices between spinning and sleeping, which is tackled by our mutable locks thanks to their hybrid waiting phase and self-tuning capabilities.

show abstract

Section: Related Workmentioning

confidence: 99%

Mutable locks: Combining the best of spin and sleep locks

Marotta

Tiriticco

Sanzo

et al. 2020

Concurrency and Computation

View full text Add to dashboard Cite

show abstract

“…This category includes lock algorithms implementing mechanisms that detect situations in which a lock needs to adapt itself, for example to cope with changing levels of contention (i.e., how many threads concurrently attempt to acquire a lock), or to avoid lock-related pathological behaviors (e.g., preemption of the lock holder to execute a thread waiting for the lock). This category includes MCS-TimePub 4 [46], GLS [9], SANL [98], LC [52], AHMCS 5 [21] and so-called Malthusian algorithms like Malth_Spin and Malth_STP 6 [30].…”

Section: Categorizing Lock Algorithmsmentioning

confidence: 99%

“…Immediate parking. With immediate parking 8 , a thread waiting for an already held lock immediately blocks until the thread gets a chance to obtain the lock 9 . This waiting policy requires kernel support (via the futex syscall on Linux) to inform the scheduler that the thread is waiting for a lock, so that it does not try to schedule the thread until the lock is made available.…”

Section: Categorizing Lock Algorithmsmentioning

confidence: 99%

“…Besides, some techniques enhancing lock algorithms (e.g., lazy lock allocation [55], biased locking [33]) can be beneficial to adapt a given lock that is not initially the best for a given workload. Finally, for applications where the access pattern of a lock varies during the workload, adaptive lock algorithm such as GLK [9] can be used.…”

Section: Lock Propertiesmentioning

confidence: 99%

“…The design and implementation of the LiTL lock library borrows code and ideas from previous open-source toolkits that provide application developers with a set of optimized implementations for some of the most-established lock algorithms: Concurrency Kit [4], liblock [61][62][63], libslock [27] and lockin [9,36]. All of these toolkits require potentially tedious source code modifications in the target applications, even in the case of algorithms that have been specifically designed to lower this burden [10,83,93].…”

Section: Lock Algorithm Implementationsmentioning

confidence: 99%

See 2 more Smart Citations

Lock–Unlock

Guerraoui

Guiroux

Lachaize

et al. 2018

ACM Trans. Comput. Syst.

Self Cite

View full text Add to dashboard Cite

A plethora of optimized mutex lock algorithms have been designed over the past 25 years to mitigate performance bottlenecks related to critical sections and locks. Unfortunately, there is currently no broad study of the behavior of these optimized lock algorithms on realistic applications that consider different performance metrics, such as energy efficiency and tail latency. In this article, we perform a thorough and practical analysis of synchronization, with the goal of providing software developers with enough information to design fast, scalable, and energy-efficient synchronization in their systems. First, we perform a performance study of 28 state-of-the-art mutex lock algorithms, on 40 applications, on four different multicore machines. We consider not only throughput (traditionally the main performance metric) but also energy efficiency and tail latency, which are becoming increasingly important. Second, we present an in-depth analysis in which we summarize our findings for all the studied applications. In particular, we describe nine different lock-related performance bottlenecks, and we propose six guidelines helping software developers with their choice of a lock algorithm according to the different lock properties and the application characteristics. From our detailed analysis, we make several observations regarding locking algorithms and application behaviors, several of which have not been previously discovered: (i) applications stress not only the lock–unlock interface but also the full locking API (e.g., trylocks, condition variables); (ii) the memory footprint of a lock can directly affect the application performance; (iii) for many applications, the interaction between locks and scheduling is an important application performance factor; (vi) lock tail latencies may or may not affect application tail latency; (v) no single lock is systematically the best; (vi) choosing the best lock is difficult; and (vii) energy efficiency and throughput go hand in hand in the context of lock algorithms. These findings highlight that locking involves more considerations than the simple lock/unlock interface and call for further research on designing low-memory footprint adaptive locks that fully and efficiently support the full lock interface, and consider all performance metrics.

show abstract

TWA – Ticket Locks Augmented with a Waiting Array

Dice

Kogan

2019

Lecture Notes in Computer Science

View full text Add to dashboard Cite

TWA avoids the complexity and extra accesses incurred by scalable queue-based locks, such as MCS the handover path, providing performance above or beyond that of MCS at high contention.Relative to MCS we also incur fewer coherence misses during handover. Under contention, MCS will generally induce a coherence miss fetching the owner node's Next field, and another miss to set the flag field in the successor's node, whereas our approach causes only one miss in the critical handover path.we observe in passing and without further comment ... * favor; at the expense of * avoid dilemma * MCS : Each arriving thread uses an atomic instruction to append a "node" (representing that thread) to tail of a chain of waiting threads, forming an explicit queue, and then busy waits on a field within that node. * MCS : node is proxy for thread * MCS : chain ; explicit queue of nodes where node represents waiting thread. * MCS is usually considered as an alternative to ticket locks. * succession : handoff vs handover * QoI = Quality-of-implementation issue * SPARC oddities : no 64-bit SWAP; no FAA; emulate all with CAS; MOESI * Claim : performance TWA » Max(MCS, TKT) * TWA unlock path is slightly longer than TKT, but handoff is accomplished first/early. * Ambient; native; free-range; * Supports our claim ... * models; reflects; mirrors; * Waiting threads interfere with handover * wrap around; rollover; overflow; aliasing; ABA; rollover recurrence could result in progress failure and hang waiting thread fails to exii long-term waiting mode missed wakeup -LT thread fails to observe change in WA[x] * Optimization : really "cycle shaving" * Influence of API design on lock : @ pass/convey from lock-to-unlock : pass/convey May need to add extra field in lock body to pass That field may induce additional coherence traffic @ scoped locking; lexically balanced -allows on-stack queue nodes @ express as closure : like java synchronized block * Inter-lock hash collisions vs intra-lock collisions * Ticket locks made less repulsive * overall path length increases; but critical path decreases * Cycle shaving game * Ticket Locks are context-free locks. * latency withing contended CS implies scalability ! * Readers are not simply passive observers ; Quantum : readers change state * Not strictly deterministic; reliable performance * Collision : false notification * point-to-point 1:1 vs one-to-many communcation * Amenable to MONITOR-MWAIT * Wait-away; wait-aside * dissipate central contention * TKTWA5 : invisible readers/waiters TKTWA7 : visible readers/waiters * Analogy : bakery/deli with TicketAllocator and NowServing Crowd/mob around NowServing impedes handover MCS is a true queue -line TWA : assign waiting place based on ticket Move to counter when turn is near * Waiting Array values are hints -advisory Can not reason directly about tranfer of ownership from absence or presence of values on the waiting array. Only changes. Waiting thread must always consult ground truth in "grant" field. * Ticket lock field names Ticket-Grant; Head-Tail; Request-...

show abstract

Locking Made Easy

Cited by 7 publications

References 42 publications

Mutable locks: Combining the best of spin and sleep locks

Mutable locks: Combining the best of spin and sleep locks

Lock–Unlock

TWA – Ticket Locks Augmented with a Waiting Array

Contact Info

Product

Resources

About