Progress Guarantee for Parallel Programs via Bounded Lock-Freedom

Erez Petrank – TechnionMadanlal 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-FreedomIf you schedule enough steps across all threads, one of them will make progress.

Great guarantee, but difficult to

achieve.

Somewhat weak.

Wait-FreedomIf you schedule enough steps of any thread, it will make progress.

Obstruction-FreedomIf 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-FreedomIf you schedule enough steps across all threads, one of them will make progress.

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.

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;

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-FreedomIf you schedule enough steps across all threads, one of them will make progress.

Defining Lock-Freedom

Lock-FreedomIf 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-FreedomIf 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-FreedomIf 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 1n (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

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

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.