analysis of software artifacts - spring 2006 1 survey of race condition analysis techniques team...

Analysis of Software Artifacts -

Spring 2006

1

Survey of Race Condition Analysis Techniques

Team Extremely Awesome

Nels Beckman

Project Presentation

17-654: Analysis of Software Artifacts


Spring 2006

2

A Goal-Based Literature Search

• This semester we explored many fundamental style of software analysis.

• How might each one be applied to the same goal?• (Finding race conditions)

• Purpose:• Analyze strengths of different analysis

styles normalized to one defect type.• See how you might decide amongst

different techniques on a real project.


Spring 2006

3

What is a Race Condition?

• One Definition:• “A race occurs when two threads can

access (read or write) a data variable simultaneously and at least one of the two accesses is a write.” (Henzinger 04)

• Note:• Locks not specifically mentioned.


Spring 2006

4

Why Race Conditions?

• Race conditions are insidious bugs:• Can corrupt memory.• Often not detected until later in execution.• Appearance is non-deterministic.• Difficult to reason about the interaction of

multiple threads.• My intuition?

• It should be relatively easy to ensure that I am at least locking properly.


Spring 2006

5

But First: Locking Discipline

• Mutual Exclusion Locking Discipline• A programing discipline that will ensure an

absence of race conditions.• Requires a lock be held on every access to

a shared variable.• Not the only way to achieve freedom

from races!• See example, next slide.

• Some tools check MLD, not race safety.


Spring 2006

6

Example: (Yu '05)

t u vt:Fork(u)

t:Lock(a)t:Write(x)t:Unlock(a)

u:Lock(a)u:Write(x)u:Unlock(a)

v:Lock(a)v:Write(x)v:Unlock(a)

t:Join(u)t:Write(x)t:Fork(v)


t:Join(v)


Spring 2006

7

Four Broad Analysis Types

• Type-Based Race Prevention• Languages that cannot express “racy”

programs.• Dynamic Race Detectors

• Using instrumented code to detect races.• Model-Checkers

• Searching for reachable race states.• Flow-Based Race Detectors

• Of the style seen in this course.


Spring 2006

8

Dimensions of Comparison

• Ease of Use• Annotations

• What is the associated burden with annotating the code?• Expression

• Does tools restrict my ability to say what I want?• Scalability

• Could this tool legitamately claim to work on a large code base?

• Soundness• What level of assurance is provided?

• Precision• Can I have confidence in the results?


Spring 2006

9

Type-Based Race Prevention

• Goal:• To prevent race conditions using the

language itself.• Method:

• Encode locking discipline into language.• Relate shared state and the locks that

protect them.• Use typing annotations.• Recall ownership types; this will seem

familiar.


Spring 2006

10

Example: Race-Free Cyclone

• To give a better feel, let's look at Cyclone.• Other type-based systems are very similar.


Spring 2006

11


• Things we want to express:• “This lock protects this variable.”

int*l p1 = new 42;int*loc p2 = new 43;


Spring 2006

12




Declares a variable of type “an integer protected by the lock named l.”


Spring 2006

13




(loc is a special lock name. It means this variable is never shared.)


Spring 2006

14


• Things we want to express:• “This is a new lock.”

let lk<l> = newlock();


Spring 2006

15




Variable name


Spring 2006

16




Lock type name


Spring 2006

17


• Things we want to express:• “This function should only be called when in

posession of this lock.”

void inc<l:LU>(int*l p;{l}) { // blah blah}


Spring 2006

18




void inc<l:LU>(int*l p;{l}) { // blah blah}This can be ignored for now...


Spring 2006

19




void inc<l:LU>(int*l p;{l}) { // blah blah}When passed an int whose protection lock is l...


Spring 2006

20




void inc<l:LU>(int*l p;{l}) { // blah blah}The caller must already possess lock l...


Spring 2006

21

Example: Race-Free Cyclonevoid inc<l:LU>(int*l p;{l}) { *p = *p + 1;}void inc2<l:LU>(lock_t<l> plk, int*l p;{}) { sync(plk) { inc(p); }}void f(;{}) { let lk<l> = newlock(); int*l p1 = new 42; int*loc p2 = new 43; spawn(g);

inc2(lk, p1);inc2(nonlock, p2);

}


Spring 2006

22

Example: Race-Free Cyclonevoid inc<l:LU>(int*l p;{l}) { *p = *p + 1;}void inc2<l:LU>(lock_t<l> plk, int*l p;{}) { sync(plk) { inc(p); }}void f(;{}) { let lk<l> = newlock(); int*l p1 = new 42; int*loc p2 = new 43; spawn(g);


}

It would be a type error to call inc without possessing the lock for the first argument.


Spring 2006

23

Example: Race-Free Cyclonevoid inc<l:LU>(int*l p;{}) { *p = *p + 1;}void inc2<l:LU>(lock_t<l> plk, int*l p;{}) { sync(plk) { inc(p); }}void f(;{}) { let lk<l> = newlock(); int*l p1 = new 42; int*loc p2 = new 43; spawn(g);


}

Imagine if the effects clause were empty...


Spring 2006

24

Example: Race-Free Cyclonevoid inc<l:LU>(int*l p;{}) { *p = *p + 1;}void inc2<l:LU>(lock_t<l> plk, int*l p;{}) { sync(plk) { inc(p); }}void f(;{}) { let lk<l> = newlock(); int*l p1 = new 42; int*loc p2 = new 43; spawn(g);


}

A dereference would also signal a compiler error, since it is unprotected.


Spring 2006

25


• Positives:• Soundness

• Programs are race-free by construction.• Familiarity

• Languages are usually based on well-known languages.• Locking discipline is a very common paradigm.

• Relatively Expressive• These type systems have been integrated with

polymorphism, object migration.• Classes can be parameterized by different locks

• Types Can Often be Inferred• Intra-procedural (thanks to effects clauses)


Spring 2006

26


• Negatives:• Restrictive:

• Not all race-free programs are legal.• e.g. Object initialization, other forms of

syncrhonization (fork/join, etc.).• Annotation Burden:

• Lots of annotations to write, even for non-shared data.

• Especially to make more complicate features, like polymorphism, work.

• Another Language


Spring 2006

27


• Open Research Questions:• Reduce Restrictions as Much as Possible

• Initialization phase• Subclassing without run-time checks in OO• Encoding of thread starts and stops• Remove annotations for non-threaded code


Spring 2006

28


• Open Research Questions:• Personally, sceptical that inference can

improve a whole lot. • Programmer intent still must be specified

somehow in locking discipline.• But escape analysis could infer thread-locals.


Spring 2006

29

Dynamic Race Detectors

• Find race conditions by:• Instrumenting the source code.• Running lockset and happens-before

analyses.• Lockset has no false-negatives.• Happens-before has no false positives.

• Instrumented source code will be represented by us.• We see all (inside the program)!


Spring 2006

30

Lockset Analysis

• Imagine we’re watching the program execute…

...marbury = 5;madison = 5;makeStuffHappen();...


Spring 2006

31

Lockset Analysis

• Whenever a lock is acquired, add that to the set of “held locks.”

...roe = 5;wade = 5;synchronize(my_object) {...

Held

Locks:my_objec

t(0x34EFF

0)


Spring 2006

32

Lockset Analysis

• Likewise, remove locks when they are released.

...brown = 43;board = “yes”;} // end synch...

Held

Locks:


Spring 2006

33

Lockset Analysis

• The first time a variable is accessed, set its “candidate set” to be the set of held locks.

...rob_frost = false;...

Held

Locks:lock1

(0xFFFF01)

lock2(0xFFFF08)

Candidate

Set:rob_fros

t

(0xFFFF01)

(0xFFFF08)


Spring 2006

34

Lockset Analysis

• The next time that variable is accessed, take the intersection of the candidate set and the set of currently held locks…

...if(!rob_frost) {...

Held

Locks:lock1

(0xABFF44)

Candidate

Set:rob_fros

t

(0xFFFF01)

(0xFFFF08)

∩


Spring 2006

35

Lockset Analysis

• If the intersection is empty, flag a potential race condition!

...if(!rob_frost) {...

Held

Locks:lock1

(0xABFF44)

Candidate

Set:rob_fros

t

(0xFFFF01)

(0xFFFF08)

∩


Spring 2006

36

Happens-Before Analysis

• More complicated.• Intuition:

• Certain operations define an ordering between operations of threads.

• Establish thread counters to create a partial ordering.

• When a variable access occurs that can’t establish itself as being ‘after’ the previous one, we have detected an actual race.


Spring 2006

37

Happens-Before on our Example

t ut:Fork(u)




1

21


Spring 2006

38


t ut:Fork(u)




1

21

Clock value.


Spring 2006

39


t ut:Fork(u)




1

21

Each variable stores the thread clock value for the most recent access of each thread.

x:u-1t-2


Spring 2006

40


t ut:Fork(u)




1

21

Also, threads learn about and store the clock values of other threads through synchronization activities.

x:u-1t-2

t:self-2u-1


Spring 2006

41


t ut:Fork(u)



1

2

1

If u were to go off, incrementing its count and accessing variables, t would find out after the join.

x:u-32t-2

t:self-2u-32

…

32


Spring 2006

42



When an access does occur, it is a requirement that: for each previous thread access of x: t’s knowledge of that thread’s time ≤ x’s knowledge of that thread’s time

x:u-32t-2

t:self-2u-32

t


Spring 2006

43

So, combining the two…

• Modern dynamic race detectors use both techniques.• Lockset analysis will detect any violation of

locking discipline.• This means we will get plenty of false positives

when strict locking discipline is not followed.• Simple requires less memory and fewer cycles.


Spring 2006

44


• Modern dynamic race detectors use both techniques.• Happens-Before will report actual race

conditions that were detected.• Extremely path sensitive.• No false positives!• False negatives can be a problem.• High memory and CPU overhead.

• As we have seen, happens-before does not merely enforce locking discipline.• Works when threads are ‘ordered.’


Spring 2006

45


• Performance-wise:• Use lockset, then switch to happens-before

for variables where a race is detected.• Of course this is dynamic! No guarantee or

reoccurrence!• Similarly, modify detection granularity at

runtime.


Spring 2006

46

Future Research

• Use static tools to limit search space• We can soundly approximate every location

where race might occur.• Performance improvements

• Could be used for in-field monitoring.• Improve chances of HB hitting?


Spring 2006

47

Model-Checking for Race Conditons

• The Art of Model Checking• Develop a model of your software system

that can be completely explored to find reachable error states


Spring 2006

48


• Normally, scope of model determines whether or not model checking is feasible.• Detailed model – Model checking takes

longer.• Simple model – Must be detailed enough to

capture principles of interest.


Spring 2006

49


• Model-checking concurrent programs is quite a challenge• Take a large state space• Add all possible thread interleavings• Result – Very large state space

• Details of specific models would be too muc to go into


Spring 2006

50


• Strategies:• Persistent Sets

• Eliminate pointless thread interleavings• Sometimes known as partial order reduction

• Contexts• Represent every other thread with one abstract

state machine.• Like CEGAR, only refine as much as needed.


Spring 2006

51


• Ease of use?• Annotations

• None• Expression

• Some tools use model-checking to implement lockset which does not allow much expression.

• Others allow us to find actual race conditions!• Scalability

• A Question Mark: Is the state space small enough?

• Previous tools using partial order reduction have been used on large software, not for races


Spring 2006

52


• Soundness?• Yes, model-checking in this manner is

sound, as long as it terminates.• Precision?

• Depends on how your model is used.• In one model lockset analysis is used. Tends to

be imprecise.• Another model directly searches for “racy”

states, which makes it very precise, but it doesn't yet work in the presence of aliasing.


Spring 2006

53

Good 'ole Flow-Based Analysis

• Has been approached in a few ways• Engineering Approach

• Sacrifice Soundness• Increase Precision as Much as Possible• Rank Results• Use Heuristics and Good Judgement• Think of PREfix or Coverity

• Rely on Alias Analysis• Rely on Programmer Annotations


Spring 2006

54

Good 'ole Flow-Based Analysis

• Engineering Approach:• Start with interprocedural lockset analysis• Make simple improvements:

• “use statistical analysis to computer the probability that s ... similar to known locks.”

• “realize that the first, last or only shared data in a critical section are special.”

• “if the number of distinct entry locksets in a function exceeds a fixed limit we skip the function”

• (Engler ’03)


Spring 2006

55

Many Benefits

• Ease of Use?• Annotations

• None or a constant number that give immidiate precision improvements.

• Expression• Non-lock based idioms are 'hard-coded' by

heuristics.• Scalability

• More than any other.• Linux, FreeBSD, Commercial OS• 1.8MLOC in 2-14 minutes


Spring 2006

56

Many Benefits

• Soundness?• Not sound in a few specific ways.• Ability to detect some false negative.

• Precision?• Fewer false positives than traditional

lockset tools. • ~6 when run on Linux 2.5.• 10s, 100s, 1000s in other static tools on

smaller applications.


Spring 2006

57

Other Flow-Based Tools

• Some Rely on Alias Analysis• Limited by Current State-of-the-Art• Still Many False Positives• May not Scale

• Some Rely on Programmer Annotations to distinguish all the hard cases• May impose programmer burden


Spring 2006

58

So, Let’s Do a Final Comparison…


Spring 2006

59

Annotations

• Type-Based Systems• Annotations are a major limiting factor.

They can be inferred, but they must be understood by the programmer.

• Dynamic Tools• Unnecessary

• Model-Checking• Unnecessary

• Flow-Based Analysis• Necessary in some form or another


Spring 2006

60

Expression

• Type-Based Systems• Limited to strict locking discipline.

• Dynamic Tools• Thanks to combination of lockset and happens-

before, relative freedom.

• Model-Checking• Can allow great expression (Depends on

technology).

• Flow-Based Analysis• Expression can be traded for soundness or

annotations.


Spring 2006

61

Scalability

• Type-Based Systems• Scalability Limited by Annotations

• Dynamic Tools• Getting better, but performance still a major

issue (1-3x mem. Usage, 1.5x CPU usage)• Model-Checking

• Not extremely scalable. Depends highly on number of processes.

• Flow-Based Analysis• Has shown the best scalability.


Spring 2006

62

Soundness

• Type-Based Systems• Sound

• Dynamic Tools• Fundamentally unsound; but lockset will

catch most possible races in execution.• Model-Checking

• Also sound. May not terminate.• Flow-Based Analysis

• Different techniques trade soundness for precision.


Spring 2006

63

Precision

• Type-Based Systems• Low precision. Strict MLD.

• Dynamic Tools• Better precision.

• Model-Checking• Can be very high. Not complete

(undecidability of reachability).• Flow-Based Analysis

• High precision using an engineering approach.


Spring 2006

64

Questions

analysis of software artifacts - spring 2006 1 survey of race condition analysis techniques team...

Documents

racefree cyclone things

new lock

newlock slide

joinv slide

race conditions purpose

absence of race conditions

dynamic race detectors

reachable race states