1 / 33

Progress Guarantee for Parallel Programs via Bounded Lock-Freedom

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

desma
Download Presentation

Progress Guarantee for Parallel Programs via Bounded Lock-Freedom

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related