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-FreedomLock-Freedom

If you schedule enough steps across all threads, one of them will make progress.

Defining Lock-FreedomLock-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-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 executionCurrent 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.