Progress Guarantee for Parallel Programs via Bounded Lock-Freedom

1. Progress Guarantee for Parallel Programs via Bounded Lock-Freedom Erez Petrank – Technion MadanlalMusuvathi- Microsoft BjarneSteensgaard - Microsoft

2. 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, …

3. 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

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

5. 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.

6. Observations • Can progress be guaranteed when using locks ? • No ! • Thread T1 can hold a lock and not be scheduled while T2 waits for the lock.

7. 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;

8. 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.

9. 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.

10. 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

11. Defining Lock-Freedom • 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? • Lock-Freedom • If you schedule enough steps across all threads, one of them will make progress.

12. Defining Lock-Freedom • 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?

13. 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.

14. 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. Problem: nothing “reasonable” would satisfy this def.

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

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

17. 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.

18. 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.

19. 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 1n(a standard trick from complexity and cryptography)

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

21. Services Supporting Lock-Freedom

22. 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.

23. 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.

24. 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.

25. A Service program background Service operation

26. 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. program background

27. Projecting Service Operations program background program Service operations background

28. Lock-Free Program The natural requirement • 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 service’s guarantees depend on its use: bounded concurrency and bounded inputs.

29. A Service Supports Lock-freedom • Let es be a valid execution of service operation sequence. • es 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.

30. The Composition Theorem • Let P be a program and let S be a service. If: • Program P is lock-free. • The service S supports lock-freedom. • 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.

31. 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

32. 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.

33. 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.