Progress Guarantee for Parallel Programs via Bounded Lock-Freedom Erez Petrank – Technion Madanlal Musuvathi- Microsoft Bjarne Steensgaard - Microsoft

Advances in Parallel Programming Attempts to simplify – Automatic parallelization, easy models (transactional memories), new languages, platforms, tools for debugging, … Develop our understanding – Define good and bad properties of parallel systems and parallel runs (deadlocks, data races, lock-freedom), logics for arguing about parallel runs, verification methods, compositionality, …

A Progress Guarantee Intuitively: “ No matter which interleaving is scheduled, my program will make progress. ” “Progress” is something the developer defines. – Specific lines of code

Progress Guarantees Lock-Freedom If you schedule enough steps across all threads, one of them will make progress. Lock-Freedom If you schedule enough steps across all threads, one of them will make progress. Great guarantee, but difficult to achieve. Somewhat weak. Wait-Freedom If you schedule enough steps of any thread, it will make progress. Wait-Freedom If you schedule enough steps of any thread, it will make progress. Obstruction-Freedom If you let any thread run alone for enough steps, it will make progress. Obstruction-Freedom If you let any thread run alone for enough steps, it will make progress.

Concentrate on Lock-Freedom Realistic (though difficult): Various algorithms appear in the literature: data structures (stack, queue, hashing, skiplist, etc.), Michael’s allocator, garbage collectors, etc. Advantages: Worst-case responsiveness, scalability, no deadlocks, no livelocks, added robustness to threads fail-stop. Lock-Freedom If you schedule enough steps across all threads, one of them will make progress. Lock-Freedom If you schedule enough steps across all threads, one of them will make progress.

Observations Can progress be guaranteed when using locks ? – No ! – Thread T 1 can hold a lock and not be scheduled while T 2 waits for the lock.

Observations Can progress be guaranteed when using locks ? – No ! Is progress guaranteed when we do not employ locks? – No ! – Computation can be blocked by fine-grained synchronization. While ( ! CAS(addr,0,1) ) ; Work on shared space; *addr = 0; While ( ! CAS(addr,0,1) ) ; Work on shared space; *addr = 0;

Observations Can progress be guaranteed when using locks ? – No ! Is progress guaranteed when we do not employ locks? – No ! Can we determine if a given program has a progress guarantee? – No ! – We cannot generally decide which paths of the computation are reachable.

Observations Can progress be guaranteed when using locks ? – No ! Is progress guaranteed when we do not employ locks? – No ! Can we determine if a given program has a progress guarantee? – No ! Thus, even if we do not employ locks, it is necessary to argue that the program makes progress.

Agenda Progress guarantees & lock-freedom intro  Motivate and define bounded lock-freedom ( Formalize using LTL & Model Checking ) Motivate and define system support for lock-freedom (composability) Conclusion Lock-freedom supporting garbage collection

Definition:  execution π,  a bound k, such that  point in the execution, if the threads run k steps, one of them will make progress. – Rigorous, – but provides a intangible guarantee: when will progress be made? In 10 steps? Or 100,000,000? Defining Lock-Freedom Lock-Freedom If you schedule enough steps across all threads, one of them will make progress. Lock-Freedom If you schedule enough steps across all threads, one of them will make progress.

Defining Lock-Freedom Lock-Freedom If you schedule enough steps across all threads, one of them will make progress. Lock-Freedom If you schedule enough steps across all threads, one of them will make progress. My program is certified to make progress. Do you really need to know when?

Defining Lock-Freedom A more tangible guarantee:  a bound k, such that  execution π, and  point in the execution, if the threads run k steps, one of them will make progress. – Bounded lock-freedom: allows quantifying the guarantee. – Important whenever the bound needs be specified. – Not so easy… Lock-Freedom If you schedule enough steps across all threads, one of them will make progress. Lock-Freedom If you schedule enough steps across all threads, one of them will make progress.

Defining Lock-Freedom A more tangible guarantee:  a bound k, such that  execution π, and  point in the execution, if the threads run k steps, one of them will make progress. – Bounded lock-freedom: allows quantifying the guarantee. – Important whenever the bound needs be specified. Lock-Freedom If you schedule enough steps across all threads, one of them will make progress. Lock-Freedom If you schedule enough steps across all threads, one of them will make progress. Problem: nothing “reasonable” would satisfy this def.

Problem with First Attempt A running thread Progress points in the execution Current execution position k threads

Problem with First Attempt k threads Naïve solution: let k depend on the num of threads.

Bounded Lock-Freedom Pitfalls Consider:  τ,  k, such that  execution π that does not run more than τ threads, and  point in the execution, if the threads run k steps, one of them will make progress. Problem: everything lock-free is bounded lock-free. – Let your algorithm run. If it fails to make progress on time, invoke a few more threads to increase τ, and buy more time until progress is required. Solution: let k depend on the input.

Bounded Lock-Freedom Definition A program is bounded lock-free if  n  k such that,  input x of length n,  execution of the program on the input x, and  possible point in the execution, if the threads run k steps, one of them will make progress.

Bounded Lock-Freedom Definition On inputs of length n, my program makes progress within 2n steps! No other program can do that! What if the system does not have a natural input ? Create a “complexity” input 1 n (a standard trick from complexity and cryptography) What if the system does not have a natural input ? Create a “complexity” input 1 n (a standard trick from complexity and cryptography)

Formalization and Model Checking Formalization using Linear Temporal Logic. Model checking for an implementation of a lock-free stack implementation. See Paper…

Services Supporting Lock- Freedom

Consider system services: event counters, memory management, micro-code interpreters, caching, paging, etc. Normally, designs of lock-free algorithms assume that the underlying system operations do not foil lock-freedom.

Can We Trust Services to Support Lock-Freedom ? Valois’ lock-free linked-list algorithm has a well known C++ implementation, which uses the C++ new operation. A hardware problem: lock Free algorithms typically use CAS or LL/S, but LL/SC implementations are typically weak: spurious failures are permitted.

Can We Trust Services to Support Lock-Freedom ? Background threads may also cause difficulties ! – Consider an event counter with create(); inc(); dec(); zero(); – If one thread fails to update the counter, another must succeed  lock-freedom. – But, if a background thread presents statistics graphically, and may reset its value, then the program may not make progress. Conclusion: system support matters.

A Service background program Service operation

A Service We’d like to separate the discussion: – Show that a program is lock-free – Show that a system supports lock-freedom And then compose – Composition theorem: any execution of a lock-free program on a lock-free supporting service is lock-free. background program

Projecting Service Operations background program background Service operations program

Lock-Free Program A program is lock free if: – It is lock-free when service operations are executed in a single step. – Service calls are valid (for the service). –  n  τ(n), such that on inputs of length n, the program: does not simultaneously run more than τ (n) threads. Calls the service operations with inputs of length ≤ n. The natural requirement The service’s guarantees depend on its use: bounded concurrency and bounded inputs.

A Service Supports Lock-freedom Let e s be a valid execution of service operation sequence. e s is k-bounded lock-free if at any point in the execution, after the projected service operations run k steps jointly, one of the threads will finish an operation. A service supports lock-freedom if  n  τ  k, such that if inputs to operations never exceed n, and number of simultaneous concurrent threads never exceeds τ, then the projected service execution is k-bounded lock-free.

The Composition Theorem Let P be a program and let S be a service. If: 1.Program P is lock-free. 2.The service S supports lock-freedom. 3.The program P does not communicate with the service except via the service operations, Then the joint execution of the program P using the service S is lock-free.

Related Work [Herlihy91] presented wait- and lock-freedom Vast literature on designing lock-free algorithms (see [ The Art of Multiprocessor Programming, Herlihy & Shavit 2008 ]. Formal definitions (unbounded LF) [ Dongol, ICFEM’06 ]. First (and only) automatic verification of lock-free data structures [Gotsman et al. POPL’09] Various lock-free garbage collectors – First one by Herlihy & Moss – Moving lock-free collectors by Pizlo-Petrank-Steensgaard PLDI’08

Conclusion We’ve introduced, motivated, and formally defined bounded lock-freedom. The formal definition was used with Chess to model- check a lock-free stack implementation. Real-world examples motivate system support for lock-freedom. Defining system support for lock-freedom: a framework and a composability theorem.

Open Problems Classify the guarantees provided by known lock-free algorithms. Lower bounds for interesting tasks. Dealing with weak memory models. More model checking and verification of (bounded) lock-free algorithms.