DOC PREVIEW
Stanford CS 295 - Lecture 17

This preview shows page 1-2-3 out of 8 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

5 23 2011 Recall We looked at dynamic race detection Static Race Detection Lecture 17 CS 295 Prof Aiken CS 295 Now we ll look at static race detection Historically much less popular Probably because static tools haven t worked as well Why A much harder problem than many Prof Aiken Lecture 17 CS 295 Lecture 17 The Problem Dynamic Race Detection Eraser A data race occurs when Idea Two threads access a memory location At least one access is a write The accesses are unordered Algorithm As a rule races are bad And common And hard to find Thread 1 x x 1 Thread 2 x x 1 Prof Aiken A shared location must be protected by some lock x I e lock x must be held on every access CS 295 For each shared memory location m record which locks are held on every access of m If no single lock is held on every access report a race on m Lecture 17 Prof Aiken CS 295 Lecture 17 Static Approaches Criteria Many Effective static analysis for race detection Meaning find the many races we believe are in large Java programs Type based Model checking Dataflow systems Identified criteria One thing in common They find relatively few concurrency bugs Why PPrecision i i nott ttoo many ffalse l positives iti Scalability Synchronization idioms Open programs Counterexamples Coarse techniques find a few bugs in 1MLOC Precise techniques not applied to large programs Prof Aiken CS 295 Lecture 17 Prof Aiken CS 295 Lecture 17 1 5 23 2011 The Approach Successive Filtering of Access Pairs Start with a superset of possible races original pairs All read write and write write pairs Successively refine the set reachable pairs Using a series of program analyses Each of which discards some pairs from the set aliasing pairs escaping pairs Final result good set of potential races Not sound Not complete More on this at the end Prof Aiken unlocked pairs CS 295 Lecture 17 Prof Aiken CS 295 Lecture 17 Open Programs Generating a Harness for Method m Analyzing open programs is important 1 Many programs are libraries Developers need to understand behavior w o a client or having to write many clients Standard approach Write a harness manually A harness is the client that exercises the open program Our approach Generate the harness automatically Prof Aiken CS 295 The harness Note Single threaded Prof Aiken 2 For each v assign some concrete object of a compatible type Use new X as needed to create such objects 3 Construct a call to m for each legal combination of arguments chosen from v s Each call in a different thread The v s are shared by all threads Lecture 17 Running Example public class A int f static public void main A a if a new A if a get a get if a inc Create a variable v of each type of an argument result of m Prof Aiken CS 295 Lecture 17 Back to the Story public A f 0 public int get return rd public sync int inc int t rd new A wr 1 A wr 1 return wr t Step 1 Original Pairs private int rd return f private int wr int x f x return x For this talk CS 295 Lecture 17 All pairs of accesses such that One is a write Refer to the same field Ignore arrays Ignore static fields The system does handle both Prof Aiken CS 295 Lecture 17 2 5 23 2011 Example Original Pairs public class A int f static public void main A a if a new A if a get a get if a inc Prof Aiken Example Original Pairs Continued public A f 0 public int get return rd public sync int inc int t rd new A wr 1 A wr 1 return wr t public A 1 f 0 public int get 2 return rd public sync int inc int t rd new A wr 1 A wr 1 return wr t public A f 0 public int get return rd public sync int inc int t rd new A wr 1 A wr 1 return wr t private int rd return f private int wr int x f x return x private int rd return f private int wr int x f x return x private int rd return f private int wr int x f x return x CS 295 Lecture 17 No Checking in Constructors public A f 0 public int get return rd public sync int inc int t rd new A wr 1 A wr 1 return wr t private int rd return f private int wr int x f x return x private int rd return f private int wr int x f x return x 4 5 Prof Aiken CS 295 4 5 Prof Aiken CS 295 Lecture 17 No Checking in Constructors Comments public A 1 f 0 public int get 2 return rd public sync int inc int t rd new A wr 1 A wr 1 return wr t 3 3 Objects being constructed are not shared Programmers do not protect them with locks Races in constructors are relatively rare Without flow sensitivity unprotected accesses in constructors look l k like lik races Our system is flow insensitive Like type based systems Unlike model checking systems Hence we ignore constructors Standard decision in flow insensitive race analysis Lecture 17 Prof Aiken CS 295 Lecture 17 Flow Insensitivity Comments Back to the Story Reachable Pairs Flow insensitivity Step 1 Lexically scoped synchronization Hurts precision synchronized T foo Dominant form in Java No flow sensitivity required Weakens intraprocedural reasoning But helps with scalability Precision loss depends on synchronization idioms used in practice F k j i synchronization h i ti Fork join Programmer may place fork join at arbitrary points Flow sensitivity useful Instead we use annotations Declare threads that cannot execute concurrently on shared data 42 annotations in 1 5MLOC Prof Aiken CS 295 Lecture 17 Access pairs with at least one write of same field Step 2 C Consider id any access pair i a b b To be a race a must be Reachable from a thread spawning site s Without switching threads Where s is reachable from main and similarly for b Prof Aiken CS 295 Lecture 17 3 5 23 2011 A Digression on Context Sensitivity What Does Work It is very important that the reachability computation be context sensitive Object sensitivity Used in subsequent analyses Most notions of context sensitivity don t don t work In the sense of producing poor results Prof Aiken CS 295 Lecture 17 Objects distinguished by call stack at allocation Methods labeled with context of this a new Foo b new Foo bar a bar b Prof Aiken Example Two Object Sensitive Contexts Example Context a public class A int f static public void main A a if a new A a if a get a get if a inc public class A int f static public void main A a if a new A a if a get a get if a inc Prof Aiken …


View Full Document

Stanford CS 295 - Lecture 17

Download Lecture 17
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 17 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 17 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?