MemoryModelSensitive Data Race Analysis - PowerPoint PPT Presentation

1 / 24
About This Presentation
Title:

MemoryModelSensitive Data Race Analysis

Description:

Memory Consistency Models ... Control flow interwoven with memory consistency requirements ... Constraints of Sequential Consistency. legalSC ops order ... – PowerPoint PPT presentation

Number of Views:31
Avg rating:3.0/5.0
Slides: 25
Provided by: rast3
Category:

less

Transcript and Presenter's Notes

Title: MemoryModelSensitive Data Race Analysis


1
Memory-Model-Sensitive Data Race Analysis
  • Jason Yue Yang
  • Microsoft Corporation
  • Ganesh Gopalakrishnan, Gary Lindstrom
  • University of Utah

2
Shared-Memory Systems
A hardware perspective
Multiprocessor architectures - increasingly
parallel
  • Multithreaded software - popular, BUT hard to
    analyze
  • Thread libraries e.g., P-thread, Win32, Solaris
  • Language level support of threads e.g., Java

3
Memory Consistency Models
Defines the legal orderings of memory operations
that can be perceived at the user level
  • Many have been developed
  • Sequential Consistency (SC)
  • Coherence
  • Parallel Random Access Memory (PRAM)
  • Causal Consistency
  • Processor Consistency (PC)
  • Release Consistency
  • Location Consistency
  • The Intel Itanim Memory Model
  • Java Memory Model (JMM)
  • and more!

4
Sequential Consistency
  • Requirements
  • Exists a common total order
  • Respects program order
  • Read sees the latest write

Example
Initially, x y 0. Finally, can r1 r2
1? Thread 1 Thread
2
r1 x y 1
r2 y x 1
Under Sequential Consistency No Under many weak
models Yes
5
Concurrency-Related Properties
  • Trace validity
  • Whether a certain set of outcome is legal
  • Atomicity
  • Whether a block of code is executed atomically
  • Race Freedom
  • Whether the program is free of data-race

6
What Is a Data-Race?
  • Informally conflicting and concurrent accesses

Is this program race-free?
Initially, x y 0.
Are these two instructions conflicting and
concurrent?
Thread 1 r1 x if (r1 gt 0) y 1
Thread 2 r2 y if (r2 gt 0) x 1
  • Control flow interwoven with memory consistency
    requirements
  • Hence, the answer depends on the memory model
  • - Under SC, this program is race-free
  • - Under a weaker model, this program might
    contain races

7
A Subtle Variation
Is this program race-free?
Initially, x y 0.
Thread 1 r1 x if (r1 gt 0) y 1
Thread 2 r2 y if (r2 gt 0) x 1
This small change introduces a race-condition,
even under SC executions
8
Observations
  • Properties satisfied under one memory model may
    be broken under another
  • Thread semantics must be taken into account in
    addition to program semantics
  • Informal intuitions may lead to inaccurate
    results
  • Correctness properties need to be formalized
  • Thread interleaving can be counter-intuitive
  • Need an automatic tool with exhaustive coverage

9
Methodology
Test Program
ProgramThread Semantics e.g., SC, Itanium,
JMM
SAT
Solver CLP SAT QBF
Constraints
Correctness Properties e.g., race, atomicity
UNSAT
(1) Define both intra-thread and inter-thread
semantics as constraints

(2) Model correctness properties as additional
constraints
(3) Reduce a verification problem to a
constraint satisfaction problem and solve it
automatically

10
Formalizing SC Executions
  • SC is most commonly assumed in SW development
  • Critical in defining race conditions in the newly
    proposed Java Memory Model
  • Apply happens-before order for acquire/release
    semantics

11
The Source Language
  • Java-like (simplified but non-trivial)
  • Local and global variables
  • Computations
  • Control branches
  • Monitor-like mutual exclusion
  • Instruction types
  • Read e.g., r x
  • Write e.g., x 1 or x r
  • Control e.g., if (r0)
  • Computation e.g., r1 r2 1
  • Lock e.g., Lock m
  • Unlock e.g., Unlock m

12
Specification Techniques
(1) Apply declarative specifications - Easy to
understand, flexible (2) Make the rules higher
order - pass down the order relation
through all the rules - Compositional, reusable,
scalable, easy to compare (3) Make all rules
explicit - Executable using a constraint-programm
ing system
13
Constraints of Sequential Consistency
(ops is the execution trace order is the
ordering relation)
  • legalSC ops order
  • requireWeakTotalOrder ops order ?
  • requireTransitiveOrder ops order ?
  • requireAsymmetricOrder ops order ?
  • requireProgramOrder ops order ?
  • requireReadValue ops order ?
  • requireComputation ops order ?
  • requireMutualExclusion ops order

Common total order
Respects program order
Read sees latest write
Program semantics
Lock/unlock semantics
requireWeakTotalOrder ops order ? ? i, j ? ops.
(fb i ? fb j ? id i ? id j) ? (order i j ??
order j i)
order is repeatedly refined
Hidden rules are explicit
14
Constraints for Control Flow
  • Treat control operations similar to memory
    operations
  • Imagine assigns and uses of control
    variables
  • Add an auxiliary control variable ck for each
    branch statement k, and convert the if-statement
    to an auxiliary assign of ck
  • E.g. if(r1gt0) becomes c1r1gt0
  • Every op k has a path predicate ctrExpr
  • K is a use of those control variables in ctrExpr
  • k is feasible if ctrExpr evaluates to ture
  • Feasibility of ops are checked when setting the
    rules

15
Read Value Rules
  • Consistent values across reads and writes
  • Intuitively, a read should see the latest write
  • Local data/control flow can be treated similar to
    global reads
  • Global Reads forall r x, exists a latest write
    on x
  • Local Reads forall x r, exists a latest write
    on r
  • Control Reads forall op that depends on c,
    exists a most recent write on c
  • requireReadValue ops order
  • globalReadValue ops order ?
  • localReadValue ops order ?
  • controlReadValue ops order

16
Computation Rules
  • Program semantics
  • Not directly related to memory ordering, but
    needed for analyzing real code
  • Two types
  • Local variable computation r1 r2 1
  • Control evaluation c1 r1 gt 0
  • Predicate eval follows standard program semantics
  • requireComputation ops order ? i ? ops.
  • (isControl i ? data i eval (ctrExpr i)) ?
  • (isCmp i ? data i eval (cmpExpr i))

17
Constraints of Race Conditions
  • detectDataRace ops ? ? scOrder, hbOrder.
  • legalSC ops scOrder ?
  • requireHbOrder ops hbOrder scOrder ?
  • mapConstraints ops hbOrder scOrder ?
  • existDataRace ops hbOrder
  • requireHbOrder ops hbOrder scOrder ?
  • requireProgramOrder ops hbOrder ?
  • requireSyncOrder ops hbOrder scOrder ?
  • requireTransitiveOrder ops hbOrder
  • existDataRace ops hbOrder ? ? i, j ? ops.
  • conflictingAccess i j ?
  • (hbOrder i j) ? (hbOrder j i)

Under SC execution
Respects happens-before
Mutually consistent
Exists data-race
Conflicting
Concurrent
18
Making It Executable
  • Encode the test case as a Constraint Logic
  • Program (CLP) that interprets executions and
    checks
  • conformance with the rules
  • Implementation in FD-Prolog is straightforward
  • Universal quantification handled via enumeration
  • Existential quantification handled via
    backtracking
  • Built-in constraint solver from FD-Prolog
  • - Logical variables
  • - Finite-domain (FD) variables

19
How to Encode the Ordering Relation?
The Method
  • Given a test program with N operations, use a 2D
    precedence matrix with N2 constraint variables
  • Interpret the symbolic execution, impose
    constraints to the 2D matrix
  • When interpretation finishes, x values reveal
    latitude in weak order
  • When an x changes to a 1, an attempt to set it to
    0 later triggers backtracking

20
Example of Prolog Implementation
Formal Specification (e.g., requireWeakTotalOrder)
requireWeakTotalOrder ops order ? ? i, j ? ops.
(fb i ? fb j ? id i ? id j) ? (order i j ??
order j i)
SICStus Prolog Code
requireWeakTotalOrder(Ops,Order,FbList)-
forEachElem(Ops,Order,FbList,doWeakTotalOrder). e
lemProg(doWeakTotalOrder,Ops,Order,FbList,I,J)-
const(feasible,Feasible), length(Ops,N),
matrix_elem(Order,N,I,J,Oij),
matrix_elem(Order,N,J,I,Oji),
nth(I,FbList,Fi), nth(J,FbList,Fj),
(Fi Feasible /\ Fj Feasible)
/\ I \ J) gt (Oij \/ Oji).
21
Interactive and Incremental Analysis
Test Program
Execution (ops)
Initially, x y 0.
Tinit Thread 1 Thread 2 (1)
wr(x,0) (3) rd(x,r1) (6)
rd(y,r2) (2) wr(y,0) (4)
ctr(c1,r1gt0) (7) ctr(c2,r2gt0)
(5) wr(y,1,c1) (8)
wr(x,1,c2)
Thread 1 r1 x if (r1 gt 0) y 1
Thread 2 r2 y if (r2 gt 0) x 1
1 2 3 4 5 6 7 8
1
0 1 1 1 1 1 1 1 0 0 1 1 1 1 1 1 0
0 0 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0
0 0 0 0 0 0 0 0 1 1 1 0 1 1 0 0 1
1 1 0 0 1 0 0 1 1 1 0 0 0
2
3
Possible interleaving 1 2 6 7 8 3 4 5 Data-race
operations 3 and 8
The adjacency matrix
4
5
6
7
8
22
Summary
Existing Approaches
  • Scalable, but not formal
  • Based on simplifying assumptions
  • Or formal, but not executable
  • Paper-and-pencil approach is error-prone

Our Approach
  • Formal and executable (although not quite as
    scalable)
  • Allows rigorous analysis of a program pattern
    under
  • an exact memory model
  • Generic
  • Not limited to specific synchronization
    mechanism
  • Can define concurrency properties under other
    memory models

23
Rigorous Concurrency Analysis
More Exhaustive
More Scalable
Inter-thread
Intra-thread
Intra-procedural
Inter-procedural
Memory-model sensitive
Memory-model insensitive
24
Thank You !
Papers and prototype tools are available
at http//www.cs.utah.edu/yyang/research.html
Write a Comment
User Comments (0)
About PowerShow.com