Memory Model Safety of Programs

Sebastian Burckhardt Madanlal Musuvathi

Microsoft ResearchEC^2, July 7, 2008

2

Motivation: Memory Model Vulnerabilities

Programmers do not always follow strict locking discipline in performance-critical code◦ Ad-hoc synchronization with normal loads and stores or

interlocked operations is faster

Such code can break on relaxed memory models◦ Most multicore machines are not sequentially consistent◦ Both compilers and actual hardware can contribute to effect

(we focus on hardware effects here)

Vulnerabilities are hard to find, reproduce, and analyze◦ May require specific hardware configuration and schedule

3

C# Example(found in production-level code)

volatile bool isIdling; volatile bool hasWork;

//Consumer thread void BlockOnIdle(){ lock (condVariable){ isIdling = true; if (!hasWork) Monitor.Wait(condVariable); isIdling = false; } }

//Producer thread void NotifyPotentialWork(){ hasWork = true; if (isIdling) lock (condVariable) { Monitor.Pulse(condVariable); } }

4

Key pieces of code on previous slide:

On x86, hardware may perform store late Bug: Producer thread does not notice waiting Consumer,

does not send signal

Store ii, 1

Example: Store Buffer Vulnerability

Store ii, 1

volatile int ii = 0;volatile int hw = 0;

Load hw, 0

Load ii, 1

Store hw, 1

Consumer Producer

0

Abstract View of Memory Models

5

Given a program P, a memory model Y defines the subset TP,Y T of traces corresponding to some (partial or complete) execution of P on Y.

TP, SCTTP, Y

SC (sequential consistency)Is strongest memory model

More executions may be possible on a relaxed memory model Y

5

Memory Model Safety

Observation: Programmer writes code for SC◦ Resorts to {fences, volatiles, interlocked operations} to

maintain SC behavior where needed◦ If program P exhibits non-SC behavior,

it is most likely a bug

Definition: A program P is Y-safe if TP,SC = TP,Y

6

7

Goal & Position

Goal: Find efficient methods to verify / falsify memory model safety of programs.

Position: Memory models should be formulated in a manner that facilitates this goal.

It helps if a memory model Y …• … guarantees that data-race-free programs are

Y-safe (but what about racy ones?)• … guarantees borderline executions (to be

defined next).

8

Borderline Executions

Def.: A borderline execution for P, Y is an execution in TP,SC with a successor in TP,Y - TP,SC

TP,Y

TP,SC

Successor traces are traces with one more instruction.

Example: TSO Borderline Execution

9

2.1 Store hw, 11.1 Store ii, 1

1.2 Load hw, 0

2.1 Store hw, 1

2.2 Load ii, 0

1.1 Store ii, 1

1.2 Load hw, 0

2.1 Store hw, 1

2.2 Load ii, 1

1.1 Store ii, 1

1.2 Load hw, 0

TP, SC

TP, TSO

Successor traces are traces with one more instruction.

10

Borderline Executions

Def.: A borderline execution for P, Y is an execution in TP,SC with a successor in TP,Y - TP,SC

Def.: A memory model Y guarantees borderline executions if the following property is true:

A program P is Y-safe if and only if it has no borderline executions.

TP,Y

TP,SC

11

Borderline Executions

Def.: A borderline execution for P, Y is an execution in TP,SC with a successor in TP,Y - TP,SC

Def.: A memory model Y guarantees borderline executions if the following property is true:

A program P is Y-safe if and only if it has no borderline executions.

TP,Y

TP,SCWe can verify / falsify this as a safety property of sequentially

consistent executions!

12

When does a Memory ModelGuarantee Borderline Executions?

Simplest case: If each trace TP,Y has a predecessor in TP,Y , we can use simple induction (because empty trace is in TP,SC ).

This is true for TSO, and we show in [CAV08] paper how to exploit this to build a borderline monitor.

TP,YTP,SC

13

How May a Memory Model Fail toGuarantee Borderline Executions?

Sometimes, traces have no predecessors(i.e. we can not take away any one instruction).

Example program:

some memory models may allow this “circular” trace:

// Thread 1 // Thread 2

if (y = 1) if (x = 1) x = 1; y = 1;

Load y, 1

Store x, 1 Store y, 1

Load x, 1

14

Conclusions / Future Work

With increasing use of multicores and little programmer regard for race-freedom, we expect more programs to exhibit failures caused by the memory model.

Borderline executions provide a practical way to verify / falsify memory model safety for a general class of memory models

Future work: how to deal with ◦ Memory models without borderline executions◦ Memory models defined by compiler optimizations