Atomicity: A powerful concept for analyzing concurrent software Shaz Qadeer Microsoft Research.

Slides:



Advertisements
Similar presentations
Summarizing Procedures in Concurrent Programs Shaz Qadeer Sriram K. Rajamani Jakob Rehof Microsoft Research.
Advertisements

Zing: Exploiting Program Structure for Model Checking Concurrent Software Tony Andrews Shaz Qadeer Sriram K. Rajamani Jakob Rehof Microsoft Research Yichen.
QED: A Simplifier for Concurrent Programs Shaz Qadeer Microsoft Research Joint work with Tayfun ElmasAli SezginSerdar Tasiran.
The complexity of predicting atomicity violations Azadeh Farzan Univ of Toronto P. Madhusudan Univ of Illinois at Urbana Champaign.
Reduction, abstraction, and atomicity: How much can we prove about concurrent programs using them? Serdar Tasiran Koç University Istanbul, Turkey Tayfun.
Goldilocks: Efficiently Computing the Happens-Before Relation Using Locksets Tayfun Elmas 1, Shaz Qadeer 2, Serdar Tasiran 1 1 Koç University, İstanbul,
Verification of Multithreaded Object- Oriented Programs with Invariants Bart Jacobs, K. Rustan M. Leino, Wolfram Schulte.
Chapter 6: Process Synchronization
1 Concurrency Specification. 2 Outline 4 Issues in concurrent systems 4 Programming language support for concurrency 4 Concurrency analysis - A specification.
Part IV: Exploiting Purity for Atomicity. Busy Acquire atomic void busy_acquire() { while (true) { if (CAS(m,0,1)) break; } } CAS(m,0,1) (fails) (succeeds)
Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs Stephen Freund Williams College Cormac Flanagan University of California, Santa Cruz.
ZING Systematic State Space Exploration of Concurrent Software Jakob Rehof Microsoft Research
Taming Win32 Threads with Static Analysis Jason Yang Program Analysis Group Center for Software Excellence (CSE) Microsoft Corporation.
Types for Atomicity in Multithreaded Software Shaz Qadeer Microsoft Research (Joint work with Cormac Flanagan)
CS444/CS544 Operating Systems Introduction to Synchronization 2/07/2007 Prof. Searleman
Atomicity in Multi-Threaded Programs Prachi Tiwari University of California, Santa Cruz CMPS 203 Programming Languages, Fall 2004.
C. Flanagan1Types for Atomicity Cormac Flanagan UC Santa Cruz Stephen N. Freund Williams College Shaz Qadeer Microsoft Research Analysis of Concurrent.
/ PSWLAB Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs By Cormac Flanagan, Stephen N. Freund 24 th April, 2008 Hong,Shin.
CS 263 Course Project1 Survey: Type Systems for Race Detection and Atomicity Feng Zhou, 12/3/2003.
Summarizing Procedures in Concurrent Programs Shaz Qadeer Sriram K. Rajamani Jakob Rehof Microsoft Research.
CS444/CS544 Operating Systems Synchronization 2/16/2006 Prof. Searleman
Concurrency.
C. FlanaganAtomicity for Reliable Concurrent Software - PLDI'05 Tutorial1 Atomicity for Reliable Concurrent Software Part 3a: Types for Race-Freedom and.
C. FlanaganSAS’04: Type Inference Against Races1 Type Inference Against Races Cormac Flanagan UC Santa Cruz Stephen N. Freund Williams College.
Modular Verification of Multithreaded Software Shaz Qadeer Compaq Systems Research Center Shaz Qadeer Compaq Systems Research Center Joint work with Cormac.
C. FlanaganDynamic Analysis for Atomicity1. C. Flanagan2Dynamic Analysis for Atomicity Atomicity The method inc() is atomic if concurrent threads do not.
Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.
C. Flanagan1Atomicity for Reliable Concurrent Software - PLDI'05 Tutorial Atomicity for Reliable Concurrent Software Joint work with Stephen Freund Shaz.
Runtime Atomicity Analysis of Multi-threaded Programs Focus is on the paper: “Atomizer: A Dynamic Atomicity Checker for Multithreaded Programs” by C. Flanagan.
Types for Atomicity in Multithreaded Software Cormac Flanagan Systems Research Center HP Labs.
Synchronization in Java Fawzi Emad Chau-Wen Tseng Department of Computer Science University of Maryland, College Park.
1 A Modular Checker for Multithreaded Programs Cormac Flanagan HP Systems Research Center Joint work with Shaz Qadeer Sanjit A. Seshia.
Verifying Commit-Atomicity Using Model Checking Cormac Flanagan University of California, Santa Cruz.
Part II: Atomicity for Software Model Checking. Class Account { int balance; static int MIN = 0, MAX = 100; bool synchronized deposit(int n) { int t =
Part 2: Reachability analysis of stack-based systems.
Cormac Flanagan UC Santa Cruz Velodrome: A Sound and Complete Dynamic Atomicity Checker for Multithreaded Programs Jaeheon Yi UC Santa Cruz Stephen Freund.
Synchronization CSCI 444/544 Operating Systems Fall 2008.
/ PSWLAB Eraser: A Dynamic Data Race Detector for Multithreaded Programs By Stefan Savage et al 5 th Mar 2008 presented by Hong,Shin Eraser:
Taming Concurrency: A Program Verification Perspective Shaz Qadeer Microsoft Research.
Cs205: engineering software university of virginia fall 2006 Semantics and Specifying Procedures David Evans
Concurrency Recitation – 2/24 Nisarg Raval Slides by Prof. Landon Cox.
C. FlanaganType Systems for Multithreaded Software1 Cormac Flanagan UC Santa Cruz Stephen N. Freund Williams College Shaz Qadeer Microsoft Research.
Runtime Refinement Checking of Concurrent Data Structures (the VYRD project) Serdar Tasiran Koç University, Istanbul, Turkey Shaz Qadeer Microsoft Research,
Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.
Games Development 2 Concurrent Programming CO3301 Week 9.
Reduction: A powerful technique for analyzing concurrent software Shaz Qadeer Microsoft Research Collaborators: Cormac Flanagan, UC Santa Cruz Stephen.
COMP 111 Threads and concurrency Sept 28, Tufts University Computer Science2 Who is this guy? I am not Prof. Couch Obvious? Sam Guyer New assistant.
Internet Software Development Controlling Threads Paul J Krause.
Context-bounded model checking of concurrent software Shaz Qadeer Microsoft Research Joint work with: Jakob Rehof, Microsoft Research Dinghao Wu, Princeton.
Shared Memory Consistency Models. SMP systems support shared memory abstraction: all processors see the whole memory and can perform memory operations.
Memory Consistency Models. Outline Review of multi-threaded program execution on uniprocessor Need for memory consistency models Sequential consistency.
Bugs (part 1) CPS210 Spring Papers  Bugs as Deviant Behavior: A General Approach to Inferring Errors in System Code  Dawson Engler  Eraser: A.
Effective Static Deadlock Detection Mayur Naik* Chang-Seo Park +, Koushik Sen +, David Gay* *Intel Research, Berkeley + UC Berkeley.
Effective Static Deadlock Detection Mayur Naik (Intel Research) Chang-Seo Park and Koushik Sen (UC Berkeley) David Gay (Intel Research)
/ PSWLAB Thread Modular Model Checking by Cormac Flanagan and Shaz Qadeer (published in Spin’03) Hong,Shin Thread Modular Model.
Multithreaded Programming in Java David Meredith Aalborg University.
CSCI1600: Embedded and Real Time Software Lecture 17: Concurrent Programming Steven Reiss, Fall 2015.
Agenda  Quick Review  Finish Introduction  Java Threads.
1 Announcements HW9: Java Concurrency Due Monday May 9 th Tests in HW Server coming up Check your grades in Rainbow Grades! Homework Server survey:
Healing Data Races On-The-Fly
CSE 120 Principles of Operating
ZING Systematic State Space Exploration of Concurrent Software
Threads and Memory Models Hal Perkins Autumn 2011
Atomicity in Multithreaded Software
Threads and Memory Models Hal Perkins Autumn 2009
CSE 451: Operating Systems Autumn 2003 Lecture 7 Synchronization
CSE 451: Operating Systems Autumn 2005 Lecture 7 Synchronization
CSE 451: Operating Systems Winter 2003 Lecture 7 Synchronization
Lecture 8 Thread Safety.
CSE 332: Concurrency and Locks
Presentation transcript:

Atomicity: A powerful concept for analyzing concurrent software Shaz Qadeer Microsoft Research

Concurrent programs Processor 1 Processor 2                         Thread 1 Thread 2 Thread 3 Thread 4 Operating systems, databases, web servers, browsers, GUIs, web services Modern languages: Java, C# Cost of multiprocessing desktop < $2000

Reliable concurrent software? Correctness problem –does program behaves correctly for all inputs and all interleavings? –very hard to ensure with testing Bugs due to concurrency are insidious –non-deterministic, timing dependent –data corruption, crashes –difficult to detect, reproduce, eliminate

Multithreaded program execution Thread 1... int t1 = hits; hits = t   t2=hitshits=t2+1t1=hitshits=t1+1    hits=0 hits=2  t2=hits hits=t2+1 t1=hitshits=t1+1     hits=0 hits=1   t2=hitshits=t2+1t1=hits hits=t1+1     hits=0 hits=1  Thread 2... int t2 = hits; hits = t

Races in action Power outage in northeastern grid in 2003 Affected millions of people Race in Alarm and Event Processing code “We had in excess of three million online operational hours in which nothing had ever exercised that bug. I'm not sure that more testing would have revealed it.”-- GE Energy's Mike Unum

Race conditions A race condition occurs if two threads access a shared variable at the same time, and at least one of the accesses is a write Thread 1... int t1 = hits; hits = t Thread 2... int t2 = hits; hits = t

Preventing race conditions using locks Lock can be held by at most one thread Race conditions are prevented using locks –associate a lock with each shared variable –acquire lock before accessing variable Thread 1 synchronized(lock) { int t1 = hits; hits = t1 + 1 } Thread 2 synchronized(lock) { int t2 = hits; hits = t2 + 1 }          hits=0 hits=2 acq t1=hits hits=t1+1 rel acq t2=hits hits=t2+2 rel

Race detection Static: –Sterling 93, Aiken-Gay 98, Flanagan-Abadi 99, Flanagan-Freund 00, Boyapati-Rinard 01, von Praun-Gross 01, Boyapati-Lee-Rinard 02, Grossman 03 Dynamic: –Savage et al. 97 (Eraser tool) –Cheng et al. 98 –Choi et al. 02

int balance; Race-free bank account void deposit (int n) { synchronized (this) { balance = balance + n; }

int balance; Race-free bank account void deposit (int n) { synchronized (this) { balance = balance + n; } int read( ) { int r; synchronized (this) { r = balance; } return r; } void withdraw(int n) { int r = read( ); synchronized (this) { balance = r – n; } Race-freedom not sufficient! Thread 1 deposit(10); Thread 2 withdraw(10); balance = 10

int balance; Atomic bank account void deposit (int n) { synchronized (this) { balance = balance + n; } int read( ) { int r; synchronized (this) { r = balance; } return r; } void withdraw(int n) { synchronized (this) { balance = balance – n; }

java.lang.StringBuffer (jdk 1.4) “String buffers are safe for use by multiple threads. The methods are synchronized so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.”

java.lang.StringBuffer is buggy! public final class StringBuffer { private int count; private char[ ] value;. public synchronized StringBuffer append (StringBuffer sb) { if (sb == null) sb = NULL; int len = sb.length( ); int newcount = count + len; if (newcount > value.length) expandCapacity(newcount); sb.getChars(0, len, value, count); //use of stale len !! count = newcount; return this; } public synchronized int length( ) { return count; } public synchronized void getChars(...) {... } }

Atomicity A method is atomic if it seems to execute “in one step” even in presence of concurrently executing threads Common concept –“(strict) serializability” in databases –“linearizability” in concurrent objects –“thread-safe” multithreaded libraries “String buffers are safe for use by multiple threads. …” Fundamental semantic correctness property

Definition of atomicity deposit is atomic if for every non-serialized execution, there is a serialized execution with the same behavior         acq(this)r=balbal=r+nrel(this)xyz  Serialized execution of deposit         acq(this)r=balbal=r+nrel(this)xyz         acq(this)r=balbal=r+nrel(this)xyz  Non-serialized executions of deposit

blue thread holds lock  red thread does not hold lock  operation y does not access balance  operations commute S0S0 S1S1 S2S2 S3S3 S4S4 S7S7 S6S6 S5S5 acq(this)r=balbal=r+nrel(this)xyz S0S0 T1T1 T2T2 T3T3 S4S4 S7S7 T6T6 S5S5 acq(this)r=balbal=r+nrel(this)xyz S0S0 T1T1 S2S2 T3T3 S4S4 S7S7 S6S6 S5S5 yr=balbal=r+nrel(this)xacq(this)z S0S0 T1T1 T2T2 T3T3 S4S4 S7S7 S6S6 S5S5 r=balbal=r+nrel(this)xyz Reduction (Lipton 75) S0S0 S1S1 S2S2 T3T3 S4S4 S7S7 S6S6 S5S5 acq(this)r=balbal=r+nrel(this)yz x blue thread holds lock after acquire  operation x does not modify lock  operations commute

 B : both right + left commutes –variable access holding lock  N : atomic action, non-commuting –access unprotected variable Four atomicities R : right commutes –lock acquire S0S0 S1S1 S2S2 acq(this)x S0S0 T1T1 S2S2 x S7S7 T6T6 S5S5 rel(this)z S7S7 S6S6 S5S5 z  L : left commutes –lock release S2S2 S3S3 S4S4 r=baly S2S2 T3T3 S4S4 y S2S2 T3T3 S4S4 x S2S2 S3S3 S4S4 x

S0S0. S5S5 R* N L*xY... S0S0. S5S5 R* N L* x Y... Sequential composition  Use atomicities to perform reduction  Lipton: sequence (R+B)* ; (N+  ) ; (L+B)* is atomic CCCCCC CCCNNN CCCLLL CNRNRR CNRLBB CNRLB; R ; B ; N ; L ; N N R R ; N ; L ; R ; N ; L ; N C N

int balance; Bank account /*# atomicity N */ void deposit (int x) { acquire(this); int r = balance; balance = r + x; release(this); } /*# atomicity N */ int read( ) { int r; acquire(this); r = balance; release(this); return r; } /*# atomicity N */ void withdraw(int x) { int r = read( ); acquire(this); balance = r – x; release(this); } RBBLRBBL RBLBRBLB NRBLNRBL NN N /*# guarded_by this */

int balance; Bank account /*# atomicity N */ void deposit (int x) { acquire(this); int r = balance; balance = r + x; release(this); } /*# atomicity N */ int read( ) { int r; acquire(this); r = balance; release(this); return r; } /*# atomicity N */ void withdraw(int x) { acquire(this); int r = balance; balance = r – x; release(this); } RBBLRBBL RBLBRBLB RBBLRBBL NNN /*# guarded_by this */

Soundness theorem Suppose a non-serialized execution of a well-typed program reaches state S in which no thread is executing an atomic method Then there is a serialized execution of the program that also reaches S

Atomicity checker for Java Leverage Race Condition Checker to check that protecting lock is held when variables accessed Found several atomicity violations –java.lang.StringBuffer –java.lang.String –java.net.URL

“String buffers are safe for use by multiple threads. The methods are synchronized so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.” “String buffers are atomic”

More work on atomicity checking Dynamic analysis (Wang-Stoller03, Flanagan-Freund 04) Model checking (Robby et al. 04)

So far… Atomicity as a lightweight and checkable specification

Now… Atomicity for precise and efficient analysis of concurrent programs Why is precise analysis of concurrent programs difficult?

The problem Given a concurrent boolean program with assertions, does the program ever go wrong by failing an assertion?  Abstract interpretation Cousot-Cousot 77, Graf-Saidi 97 unbounded data  boolean data

Concurrent boolean program without procedures k = size of CFG of the program n = number of threads Need to analyze all interleavings of various threads –complexity proportional to k n

Concurrent boolean program with procedures Ramalingam 00: The problem is undecidable, even with only two threads –two unbounded stacks –reduction from the undecidable problem “Is the intersection of two context-free languages empty?”

Atomic blocks to the rescue! S0S0. S5S5 R* N L*xY... S0S0. S5S5 R* N L* xY... Other threads need not be scheduled in the middle of an atomic block Lipton: any sequence (R+B)*; (N+  ) ; (L+B)* is an atomic block

First idea Infer maximal atomic blocks

Concurrent boolean program without procedures k = size of CFG of the program n = number of threads a = size of CFG of inferred atomic blocks Need to analyze all interleavings of various threads but only at atomic block boundaries –complexity proportional to (k/a) n

Second idea Summarize inferred atomic blocks Inspired by summarization of procedures in sequential programs

Summarization for sequential programs (Sharir-Pnueli 81, Reps-Horwitz-Sagiv 95) Bebop, ESP, Moped, MC, Prefix, … int x; void incr_by_2() { x++; } void main() { … x = 0; incr_by_2(); … x = 0; incr_by_2(); … x = 1; incr_by_2(); … } x  x’ 0  2 1  3

Assertion checking for sequential programs Given a sequential boolean program with assertions, does the program ever go wrong by failing an assertion? Boolean program with: –g = number of global vars –l = max. number of local vars in any scope –k = size of the CFG of the program Complexity is O( k  2 O(g+l) ), linear in the size of CFG Summarization enables termination in the presence of recursion

Summarization in concurrent programs Unarticulated so far Naïve extension of summaries for sequential programs do not work Call PReturn P

Second idea Summarize inferred atomic blocks Summary of procedure = summary of constituent atomic blocks Often procedure is single atomic block –In Atomizer benchmarks (Flanagan-Freund 04), majority of procedures are atomic

Concurrent boolean program with procedures Ramalingam 00: The problem is undecidable, even with only two threads. Qadeer-Rajamani-Rehof (POPL 04): The problem is decidable, if all recursive procedures are atomic. –For a sequential program, the whole execution is an atomic block –Algorithm behaves exactly like classic interprocedural dataflow analysis (Sharir- Pnueli 81)

Model checker for concurrent software Implementation of atomic block inference and summarization Applications –Concurrent systems code, e.g., device drivers –Web services –Spec# (C# + specifications)

Atomicity as a language primitive First proposed in the 70s –Tony Hoare –David Lomet Hardware implementation –Rajwar-Goodman 02 Software implementation –Herlihy-Luchangco-Moir-Scherer 03 –Harris-Fraser 03 –Welc-Jagannathan-Hosking 04 –MIT (Martin Rinard’s group)

Conclusions Atomicity is a useful concept for analyzing concurrent programs –Lightweight specification –Simplifies formal and informal reasoning –Enables precise and efficient analysis Perhaps the right synchronization primitive for future concurrent languages?