Peng Liu and Charles Zhang Prism Research Group Department of Computer Science and Engineering Hong Kong University of Science and Technology 1.

Slides:



Advertisements
Similar presentations
Dataflow Analysis for Datarace-Free Programs (ESOP 11) Arnab De Joint work with Deepak DSouza and Rupesh Nasre Indian Institute of Science, Bangalore.
Advertisements

Bounded Model Checking of Concurrent Data Types on Relaxed Memory Models: A Case Study Sebastian Burckhardt Rajeev Alur Milo M. K. Martin Department of.
Applications of Synchronization Coverage A.Bron,E.Farchi, Y.Magid,Y.Nir,S.Ur Tehila Mayzels 1.
Greta YorshEran YahavMartin Vechev IBM Research. { ……………… …… …………………. ……………………. ………………………… } T1() Challenge: Correct and Efficient Synchronization { ……………………………
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Effective Static Deadlock Detection
1 Chao Wang, Yu Yang*, Aarti Gupta, and Ganesh Gopalakrishnan* NEC Laboratories America, Princeton, NJ * University of Utah, Salt Lake City, UT Dynamic.
Principles of Engineering System Design Dr T Asokan
An Case for an Interleaving Constrained Shared-Memory Multi-Processor Jie Yu and Satish Narayanasamy University of Michigan.
Based on: Petri Nets and Industrial Applications: A Tutorial
A Randomized Dynamic Program Analysis for Detecting Real Deadlocks Koushik Sen CS 265.
Ensuring Operating System Kernel Integrity with OSck By Owen S. Hofmann Alan M. Dunn Sangman Kim Indrajit Roy Emmett Witchel Kent State University College.
Model Checker In-The-Loop Flavio Lerda, Edmund M. Clarke Computer Science Department Jim Kapinski, Bruce H. Krogh Electrical & Computer Engineering MURI.
Guoliang Jin, Linhai Song, Wei Zhang, Shan Lu, and Ben Liblit University of Wisconsin–Madison Automated Atomicity- Violation Fixing.
Enforcing Sequential Consistency in SPMD Programs with Arrays Wei Chen Arvind Krishnamurthy Katherine Yelick.
Troubleshooting SDN Control Software with Minimal Causal Sequences COLIN SCOTT, ANDREAS WUNDSAM, BARATH RAGHAVANAUROJIT PANDA, ANDREW OR, JEFFERSON LAI,EUGENE.
/ PSWLAB Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs By Cormac Flanagan, Stephen N. Freund 24 th April, 2008 Hong,Shin.
7th Biennial Ptolemy Miniconference Berkeley, CA February 13, 2007 Causality Interfaces for Actor Networks Ye Zhou and Edward A. Lee University of California,
CP — Concurrent Programming 12. Petri Nets Prof. O. Nierstrasz Wintersemester 2005 / 2006.
12/07/2007Jiacun Wang1 SE-561 Math Foundations Petri Nets - II Dr. Jiacun Wang Department of Software Engineering Monmouth University.
1 ACID Properties of Transactions Chapter Transactions Many enterprises use databases to store information about their state –e.g., Balances of.
1 Sharing Objects – Ch. 3 Visibility What is the source of the issue? Volatile Dekker’s algorithm Publication and Escape Thread Confinement Immutability.
Problem Statement Give a formal Problem statement showing the input / output; objective (e.g. minimizing computational cost or other relevant metrics)
Formal Verification of SpecC Programs using Predicate Abstraction Himanshu Jain Daniel Kroening Edmund Clarke Carnegie Mellon University.
SE-565 Software System Requirements More UML Diagrams.
Learning From Mistakes—A Comprehensive Study on Real World Concurrency Bug Characteristics Shan Lu, Soyeon Park, Eunsoo Seo and Yuanyuan Zhou Appeared.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
Exceptions and Mistakes CSE788 John Eisenlohr. Big Question How can we improve the quality of concurrent software?
Verification technique on SA applications using Incremental Model Checking 컴퓨터학과 신영주.
1 Testing Concurrent Programs Why Test?  Eliminate bugs?  Software Engineering vs Computer Science perspectives What properties are we testing for? 
© 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 1 Concurrency in Programming Languages Matthew J. Sottile Timothy G. Mattson Craig.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Threads and Processes.
Lifecycle Verification of the NASA Ames K9 Rover Executive Dimitra Giannakopoulou Mike Lowry Corina Păsăreanu Rich Washington.
50.003: Elements of Software Construction Week 8 Composing Thread-safe Objects.
Pallavi Joshi* Mayur Naik † Koushik Sen* David Gay ‡ *UC Berkeley † Intel Labs Berkeley ‡ Google Inc.
6.852: Distributed Algorithms Spring, 2008 Class 13.
ICS 313: Programming Language Theory Chapter 13: Concurrency.
Xusheng Xiao North Carolina State University CSC 720 Project Presentation 1.
Consider the program fragment below left. Assume that the program containing this fragment executes t1() and t2() on separate threads running on separate.
Modelling by Petri nets
Modeling Mobile-Agent-based Collaborative Processing in Sensor Networks Using Generalized Stochastic Petri Nets Hongtao Du, Hairong Qi, Gregory Peterson.
CSCI1600: Embedded and Real Time Software Lecture 11: Modeling IV: Concurrency Steven Reiss, Fall 2015.
Effective Static Deadlock Detection Mayur Naik* Chang-Seo Park +, Koushik Sen +, David Gay* *Intel Research, Berkeley + UC Berkeley.
Theory-Aided Model Checking of Concurrent Transition Systems Guy Katz, Clark Barrett, David Harel New York University Weizmann Institute of Science.
Grigore Rosu Founder, President and CEO Professor of Computer Science, University of Illinois
Effective Static Deadlock Detection Mayur Naik (Intel Research) Chang-Seo Park and Koushik Sen (UC Berkeley) David Gay (Intel Research)
Capturing Requirements. Questions to Ask about Requirements 1)Are the requirements correct? 2)Consistent? 3)Unambiguous? 4)Complete? 5)Feasible? 6)Relevant?
Agenda  Quick Review  Finish Introduction  Java Threads.
Reachability Testing of Concurrent Programs1 Reachability Testing of Concurrent Programs Richard Carver, GMU Yu Lei, UTA.
Concurrent Programming Acknowledgements: Some slides adapted from David Evans, U. Virginia.
Synchronization Questions answered in this lecture: Why is synchronization necessary? What are race conditions, critical sections, and atomic operations?
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini VIII. Specifications (II)
Advantages of FSM Their simplicity make it easy for inexperienced developers to implement with little to no extra knowledge (low entry level)
CPE555A: Real-Time Embedded Systems
Threads Cannot Be Implemented As a Library
runtime verification Brief Overview Grigore Rosu
Java Programming: Guided Learning with Early Objects
Amir Kamil and Katherine Yelick
Threads and Memory Models Hal Perkins Autumn 2011
Department of Computer Science University of California, Santa Barbara
Implementing synchronization
More on Thread Safety CSE451 Andrew Whitaker.
Threads and Memory Models Hal Perkins Autumn 2009
EE 4xx: Computer Architecture and Performance Programming
Deadlock Detection for Distributed Process Networks
Amir Kamil and Katherine Yelick
Foundations and Definitions
Department of Computer Science University of California, Santa Barbara
COT 5611 Operating Systems Design Principles Spring 2014
Petri Nets Laurie Frazier.
Presentation transcript:

Peng Liu and Charles Zhang Prism Research Group Department of Computer Science and Engineering Hong Kong University of Science and Technology 1

Motivation An Atomicity Violation (AV) in StringBuffer. The accesses, assumed to be atomic, are interleaved non-serializably by a remote access. run(){ // s1.append(s2): synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 1 2

Motivation An Atomicity Violation (AV) in StringBuffer. The accesses, assumed to be atomic, are interleaved non-serializably by a remote access. run(){ // s1.append(s2): synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 1 3

Motivation An Atomicity Violation (AV) in StringBuffer. The accesses, assumed to be atomic, are interleaved non-serializably by a remote access. run(){ // s1.append(s2): synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 1 4

Motivation An Atomicity Violation (AV) in StringBuffer. The accesses, assumed to be atomic, are interleaved non-serializably by a remote access. run(){ // s1.append(s2): synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 1 5

Motivation An Atomicity Violation (AV) in StringBuffer. The accesses, assumed to be atomic, are interleaved non-serializably by a remote access. run(){ // s1.append(s2): synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } run(){ s2.delete(0, s2.length()); } Thread 1 Thread 2 6

Motivation An Atomicity Violation (AV) in JDK StringBuffer. The accesses, assumed to be atomic, are interleaved non-serializably by a remote access. run(){ // s1.append(s2): synchronized(s1) { a int len = s2.length(); b s2.getChars(0, len, s1…); } run(){ r s2.delete(0, s2.length()); } Thread 1 Thread 2 7

Motivation Common approach of Fixing the Atomicity Violation Synchronize the atomicity sequence (from a to b) and the remote access (r) with locks. run(){ // s1.append(s2): synchronized(s1) { + lockM.lock(); a int len = s2.length(); b s2.getChars(0, len, s1…); + lockM.unlock(); } run(){ + lockM.lock(); r s2.delete(0, s2.length()); + lockM.unlock(); } Thread 1 Thread 2 8

Motivation Problems with Fixing the Violations 9

Motivation Problems with Fixing the Violations 10

Motivation Introduce New Deadlocks AV (a,b,r) and the original lock oL protecting some irrelevant vars. Thread 1 Thread 2 a oL.lock(); … oL.unlock(); b oL.lock();... r... oL.unlock(); 11

Motivation Introduce New Deadlocks AV (a,b,r) and the original lock oL protecting some irrelevant vars. Thread 1 Thread 2 a oL.lock(); … oL.unlock(); b oL.lock();... r... oL.unlock(); 12

Motivation Introduce New Deadlocks AV (a,b,r) and the original lock oL protecting some irrelevant vars. Thread 1 Thread 2 a oL.lock(); … oL.unlock(); b oL.lock();... r... oL.unlock(); 13

Motivation Introduce New Deadlocks AV (a,b,r) and the original lock oL protecting some irrelevant vars. Thread 1 Thread 2 a oL.lock(); … oL.unlock(); b oL.lock();... r... oL.unlock(); + L.lock(); + L.unlock(); + L.lock(); + L.unlock(); 14

Motivation Introduce New Deadlocks AV (a,b,r) and the original lock oL protecting some irrelevant vars. Thread 1 Thread 2 a oL.lock(); … oL.unlock(); b oL.lock();... r... oL.unlock(); + L.lock(); + L.unlock(); + L.lock(); + L.unlock(); 15

Motivation Problems with Fixing the Violations 16

Motivation Sacrifice the Concurrency Greatly Two overlapping Avs: (a,b,r) and (a’b,r’). Thread 1 Thread 3 a b a b Thread 2 r’ a’ … r … b’ 17

Motivation Sacrifice the Concurrency Greatly Two overlapping Avs: (a,b,r) and (a’b,r’). Thread 1 Thread 3 a b a b Thread 2 r’ a’ … r … b’ 18

Motivation Sacrifice the Concurrency Greatly Two overlapping Avs: (a,b,r) and (a’b,r’). Thread 1 Thread 3 a b a b Thread 2 r’ a’ … r … b’ 19

Motivation Sacrifice the Concurrency Greatly Two overlapping Avs: (a,b,r) and (a’b,r’). Thread 1 Thread 3 a b a b Thread 2 r’ a’ … r … b’ 20

Motivation Sacrifice the Concurrency Greatly Two overlapping Avs: (a,b,r) and (a’b,r’). Thread 1 Thread 3 a b a b Thread 2 r’ a’ … r … b’ 21

Motivation Sacrifice the Concurrency Greatly Two overlapping Avs: (a,b,r) and (a’b,r’). Thread 1 Thread 3 a b a b Thread 2 r’ a’ … r … b’ 22

Motivation Sacrifice the Concurrency Greatly Two overlapping Avs: (a,b,r) and (a’b,r’). Thread 1 Thread 3 +L.lock(); a b +L.unlock(); Thread 2 +L.lock(); r’ +L.unlock(); +L.lock(); a’ … r … b’ +L.unlock(); 23

Motivation Our Guarantee 24

Motivation Our Guarantee 25

Motivation Our Approach 26

Motivation Our Approach Bug report: …… 27

Motivation Our Approach 28

Motivation Our Approach Constraints: no two pandas on the single-plank bridge simultaneously. Solver: control theory. 29

Motivation Rationale Performance – Loose constraints – Concurrency-preserving solver. Safety – Handle deadlocks with solver 30

thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 run(){ s2.delete(0, s2.length()); } thread1.join(); thread2.join(); 31

Abstract graphical and mathematical model. Places (circles) Transitions (horizontal bars) Arcs between them 32

Abstract graphical and mathematical model. Places (circles) Transitions (horizontal bars) Arcs between them 33

Abstract graphical and mathematical model. Places (circles) Transitions (horizontal bars) Arcs between them 34

Abstract graphical and mathematical model. Places (circles) Transitions (horizontal bars) Arcs between them 35

Abstract graphical and mathematical model. Places contain tokens Transitions, when triggered, move tokens Arcs (the weights) determine how many to move. 1 by default. 36

Abstract graphical and mathematical model. Places contain tokens Transitions, when triggered, move tokens Arcs (the weights) determine how many to move. 1 by default. 37

Abstract graphical and mathematical model. Places contain tokens Transitions, when triggered, move tokens Arcs (the weights) instruct how many to remove or give. 1 by default. 38

Abstract graphical and mathematical model. A transition can be triggered only if the input place contains enough tokens. 39

Statements -> places. Control flows-> transitions Branch 40

Statements -> places. Control flows-> transitions Branch 41

Statements -> places. Control flows-> transitions Branch 42

Statements -> places. Control flows-> transitions Branch 43

Statements -> places. Control flows-> transitions Branch 44

Statements -> places. Control flows-> transitions Loop 45

Statements -> places. Control flows-> transitions Loop 46

Statements -> places. Control flows-> transitions Loop 47

Statements -> places. Start/Join/Control flows-> transitions Threading 48

Statements -> places. Start/Join/Control flows-> transitions Threading 49

Statements -> places. Start/Join/Control flows-> transitions Threading 50

Statements -> places. Lock/Unlock/Control flows-> transitions Locking 51

Statements -> places. Lock/Unlock/Control flows-> transitions Locking 52

Statements -> places. Lock/Unlock/Control flows-> transitions Locking 53

Mathematical form. 54 T1T2 P1 P20 P301 D = Structure Matrix (initial) Token Distribution Vector U 0 = P11 P20 P30 P1 T1T2 P2 P3 1

thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 run(){ s2.delete(0, s2.length()); } thread1.join(); thread2.join(); 55 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7

thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 run(){ s2.delete(0, s2.length()); } thread1.join(); thread2.join(); 56 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P7 P8 P9 T6 T7 P6

thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 run(){ s2.delete(0, s2.length()); } thread1.join(); thread2.join(); 57 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P7 P8 P9 T6 T7 P6

thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 run(){ s2.delete(0, s2.length()); } thread1.join(); thread2.join(); 58 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7

thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } } Thread 2 run(){ s2.delete(0, s2.length()); } thread1.join(); thread2.join(); 59 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7

thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } } Thread 2 run(){ s2.delete(0, s2.length()); } thread1.join(); thread2.join(); 60 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7

thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 run(){ s2.delete(0, s2.length()); } thread1.join(); thread2.join(); P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7

thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 run(){ s2.delete(0, s2.length()); } thread1.join(); thread2.join(); 62 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7

thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 run(){ s2.delete(0, s2.length()); } thread1.join(); thread2.join(); 63 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7

64 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7 Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 Inter-thread constraint: U(P3) + U(P7) <=1 run(){ s2.delete(0, s2.length()); }

65 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7 thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 thread1.join(); thread2.join(); run(){ s2.delete(0, s2.length()); }

66 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7 Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 Inter-thread constraint: U(P4) + U(P7) <=1 run(){ s2.delete(0, s2.length()); }

67 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7 thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 thread1.join(); thread2.join(); run(){ s2.delete(0, s2.length()); }

68 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7 thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 thread1.join(); thread2.join(); run(){ s2.delete(0, s2.length()); }

69 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7 thread1.start(); thread2.start(); Thread 1 run(){ synchronized(s1) { int len = s2.length(); s2.getChars(0, len, s1…); } Thread 2 thread1.join(); thread2.join(); run(){ s2.delete(0, s2.length()); }

70 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7 Intra-thread constraint: thread-representing token stays in P3, or P4, but not both at any time. U(P3) + U(P4) <=1

71 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7 Inter-thread: U(P3) + U(P7) <=1 U(P4) + U(P7) <=1 Intra-thread: U(P3) + U(P4) <=1 Equivalent form: U(P3) + U(P4) + U(P7) <=1

Supervision Based on Place Invariants (SBPI) Input: constraints, e.g., U(P3) + U(P4) + U(P7) <=1 Output: augmentation to PN to satisfy the constraints. Output augmentation: New control places with tokens Arcs connecting them to the original PN. Mathematic form.

Output augmentation in its math form: New control places with tokens Arcs connecting them to the original PN. Output of our example: New place M. M has one token (U 0 M = 1 ). Connecting to T2, T6, from T4, T7. D M = T1T2T3T4T5T6T7 M0010 1

Output augmentation in its math form: New control places with tokens Arcs connecting them to the original PN. Output of our example: New place M. M has one token (U 0 M = 1 ). Connecting to T2, T6, from T4, T7. D M = T1T2T3T4T5T6T7 M0010 1

Output: New place M, with one token. Connecting to T2, T6, from T4, T7. M 75 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7

Wang’s deadlock avoidance (SBPI) [POPL’09] Reuse. Part program. Deadlocks introduced by our fix.

Control place -> lock (static field). Arc to (from) a transition -> locking operation at the control flow (between a pair of statements). Injected locking operations should not affect other control flows (sharing common statements).

M 78 P1 T1 P2 T2 P3 T3 P4 T4 P5 L T5 P6 P7 P8 P9 T6 T7 Thread 1 synchronized(s1) { +lockM.lock(); int len = s2.length(); s2.getChars(0, len, s1…); +lockM.unlock(); } Thread 2 +lockM.lock(); s2.delete(0, s2.length()); +lockM.unlock();

Evaluation Benchmarks: OpenJMS, messaging service implementation. Derby, Apache’s database system. Jigsaw, W3C’s webserver platform. Violation detection: Pecan [ISSTA ‘11] Evaluated properties: Performance of patched code Safety

Evaluation Benchmarks: OpenJMS, messaging service implementation. Derby, Apache’s database system. Jigsaw, W3C’s webserver platform. Violation detection: Pecan [ISSTA ‘11] Evaluated properties: Performance of patched code Safety

Evaluation (performance) Compared to the state of the art fixes, 1.Axis-noDA is 7% faster 2.Axis-DA is only 3% slower. (It has strong safety guarantee.) OpenJMSJigsaw Derby

Evaluation (safety) 1.No deadlocks are identified for Axis-DA. 2.Frequent deadlocks for other fixes, including Axis-noDA and AFix. Patched programT=2T=4T=8T=12 OpenJMSAxis-noDA0027 AFix0025 JigsawAxis-noDA20 AFix20 DerbyAxis-noDA00011 AFix0007

Conclusion A formal violation-fixing approach with strong guarantees on Performance. Sacrifice the concurrency minimally. Safety. No deadlocks are introduced. Implementation & Evaluation Compared to the state of the art, Axis-noDA is 7% faster. Axis-DA (with strong safety guarantee) is merely 3% slower.