unexpected interference can lead to why is it hard cont d
play

Unexpected interference can lead to Why is it hard? (Contd) - PowerPoint PPT Presentation

What is concurrency? Concurrent programs CISC422/853: Formal Methods consist of units (typically called threads, or processes) that on a multi-processor machine: could be executed by different in Software Engineering: processors at the


  1. What is concurrency? � Concurrent programs… CISC422/853: Formal Methods consist of units (typically called threads, or processes) that ° on a multi-processor machine: could be executed by different in Software Engineering: processors at the same time Computer-Aided Verification ° on a single-processor machine: could be executed by different schedules in different interleavings ° communicate through q shared memory or message passing Topic 1: A few words about concurrency � Demos: (2 threads, 1 shared object) garden1.java garden1.java [Kramer, McGee: “Concurrency: State Models and Juergen Dingel Java Programs” http://www.doc.ic.ac.uk/~jnm/book/] (2 threads, no shared variables) demo1.c Jan, 2009 demo1.c demo2.c (2 threads, 1 shared variable) demo2.c 1 2 CISC422/853, Winter 2009 CISC422/853, Winter 2009 What is concurrency? (Cont’d) Why is it hard? � Concurrent programs � Sequential programs special case of concurrent ones typically require • Every concurrent program can be made to execute sequentially without much effort ° synchronization though, e.g., q locks: e.g., one per object; only held by ≤ 1 processes ° tradeoff: amount of parallelism ⇔ risk of interference q semaphores: natural number n together with two atomic operations: ° ideally: program exhibits a maximal degree of concurrency, i.e., P(n): if n>0, then n:=n-1; else suspend calling process ⋅ contains a minimal amount of synchronization ⋅ V(n): if some process p suspended on n, then resume p; else n:=n+1 � Consequences: q monitors: abstract data type representing a shared resource ⋅ private monitor variables, monitor operations, condition variables • Harder to write: When adding a line of code to ° to prevent interference on shared data through race conditions ° a sequential program, programmer must be aware of what � Demo q has happened up until that point, and q will happen after that point garden2.java ° a concurrent program, programmer must also be aware of what (2 threads, 1 shared and synchronized object) garden2.java q may have or may not have happened concurrently ⇒ harder to get code to work correctly 3 4 CISC422/853, Winter 2009 CISC422/853, Winter 2009

  2. Unexpected interference can lead to Why is it hard? (Cont’d) surprising results � Consequences (Cont’d) � Consider the following concurrent program with shared variable x: • Harder to debug: ° When program doesn’t work may be difficult to reproduce error N := 5; x := 0; N := 5; x := 0; • Harder to test: for (i=0; i<N; i++) { for (j=0;j<N; j++) { for (i=0; i<N; i++) { for (j=0;j<N; j++) { ° Impossible to test program comprehensively with respect to all x := x+1; x := x+1; possible schedulings x := x+1; x := x+1; } } • Harder to reason about: } } ° unexpected interference can lead to surprising results � What are the values that x can have upon termination? “I’ve come across many teams whose application worked fine even • When assignments are atomic: ? “I’ve come across many teams whose application worked fine even under heavy and extended stress testing, and ran perfectly at under heavy and extended stress testing, and ran perfectly at • When assignments are not atomic: ? many customer sites, until the day that a customer actually had a many customer sites, until the day that a customer actually had a � What if N = 1000? N =10 8 ? real multiprocessor machine and then deeply mysterious races real multiprocessor machine and then deeply mysterious races and corruptions started to manifest intermittently. ” � Could you devise a comprehensive test that shows this? and corruptions started to manifest intermittently. ” [H. Sutter. “The free lunch is over: A fundamental turn to concurrency in software”. Dr. Dobb's Journal, 30(3), March 2005] 5 6 CISC422/853, Winter 2009 CISC422/853, Winter 2009 Testing Doesn’t Always Cut It But Wait, It Can Be Even Worse! int x, y, tmp; � Will the call p(x,y) always � Ideally: statements in a program are executed int x, y, tmp; … … succeed? in the order in which they appear in the text thread swap() { thread swap() { x = 1; x = 1; tmp = x; � Can’t exhaustively test for tmp = x; � However: this is disallows many performance- y = 2; y = 2; x = y; x = y; z = x+y; these kinds of race enhancing compiler optimizations (to, e.g., y = tmp; z = x+y; y = tmp; … } … } conditions, because take advantage of parallelism, multi-level � not enough control over caches, optimistic execution) proc p(int i, j) { proc p(int i, j) { // pre: i+j is odd relative execution speeds on // pre: i+j is odd � Next best thing: sequential consistency … ... … ... multi-processor machines } x = 1; • “every read of a variable will ‘see’ the most recent } x = 1; � not enough control over y = 2; write in execution order to that variable by any y = 2; thread main() { scheduling policy on single- thread main() { z = x+y; processor” z = x+y; x=1; y=2; processor machines // x,y not x=1; y=2; run swap(); • allows, e.g., “semantics-preserving” reordering run swap(); // aliases � combinatorial explosion … … run swap(); run swap(); � Ok for sequential programming, but still too p(x, y); p(x, y); } restrictive for concurrent programming } 7 8 CISC422/853, Winter 2009 CISC422/853, Winter 2009

  3. But Wait, It Can Be Even Worse! But Wait, It Can Be Even Worse! (Cont’d) (Cont’d) � Wanted: Balance desires of program developer (ease � In summary: JMM allows some surprising manipulations of program development) with desires of compiler public class PossibleReordering { public class PossibleReordering { writer (optimization possibilities) static int x = 0, y = 0; static int x = 0, y = 0; static int a = 0, b = 0; static int a = 0, b = 0; � Enter: the Java Memory Model (JMM) public static void main(String[] args) throws InterruptedException { public static void main(String[] args) throws InterruptedException { Thread one = new Thread(new Runnable() { • Specifies minimal guarantees that JVM must make about Thread one = new Thread(new Runnable() { public void run() { • What will this public void run() { when the effect of an action A of thread T1 are visible to a = 1; x = b ; a = 1; x = b ; program output? action B of thread T2 } } • Is this the only • A in T1 visible to B in T2 iff A in T1 “happens before” B in T2 }; }; output it can Thread two = new Thread(new Runnable() { Thread two = new Thread(new Runnable() { Definition: A in T1 happens before B in T2 if Definition: A in T1 happens before B in T2 if produce? public void run() { public void run() { ° T1 == T2 and A comes before B b = 1; y = a ; • How do you test for ° T1 == T2 and A comes before B b = 1; y = a ; } } this? ° A == T.start() and B is an action in T ° A == T.start() and B is an action in T }; }; ° … ° … one.start(); two.start(); one.start(); two.start(); ° (A in T1 happens before C in T3) and (C in T3 happens before Demo: Reorder.java one.join(); other.join(); System. out .println("( " + x + "," + y + ")"); ° (A in T1 happens before C in T3) and (C in T3 happens before one.join(); other.join(); System. out .println("( " + x + "," + y + ")"); } B in T2) } B in T2) } 9 10 CISC422/853, Winter 2009 CISC422/853, Winter 2009 } But Wait, It Can Be Even Worse! Why use concurrency? (Cont’d) � In summary: � Performance gain: • JMM allows some surprising manipulations • ideally, speed up factor equal to number of processors � Ease of programming: • Synchronization statements allow programmer to ° restrict the “happens before” partial order, and thus to • concurrency is a real-world phenomenon prevent certain, unwanted compiler manipulations to occur • many programming problems are inherently concurrent and can be solved more naturally using concurrency: � By the way: ° E.g., embedded systems, reactive systems • reading up on, experimenting with, and summarizing the JMM would make a nice project And we have seen last time, an embedded system may be controlling the brakes in your car tomorrow… 11 12 CISC422/853, Winter 2009 CISC422/853, Winter 2009

  4. Model checking � Model checking helps us out here: • Exhaustive enumeration of all possible executions/schedules of a concurrent program • Check that all of them are ok ⇒ complete confidence (when exploration was exhaustive) 13 CISC422/853, Winter 2009

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend