Lecture 13 Concurring Concurrently CS 201 j Engineering

Lecture 13: Concurring Concurrently CS 201 j: Engineering Software University Virginia 17 Octoberof 2002 Computer Science CS 201 J Fall 2002 David Evans http: //www. cs. virginia. edu/~evans

Menu • Subtyping Rules Review – Overriding and Overloading • Concurrency 17 October 2002 CS 201 J Fall 2002 2

Substitution Principle … (in client code) Mystery. Type 1 mt 1; Mystery. Type 2 mt 2; Mystery. Type 3 mt 3; … (anything could be here) mt 1 = mt 2. m (mt 3); If the Java compiler is happy with this code, which of these are guaranteed to be true: a. The apparent type of mt 2 is Mystery. Type 2 b. At the last statement, the actual type of mt 2 is Mystery. Type 2 c. Mystery. Type 2 has a method named m d. The Mystery. Type 2. m method takes a parameter of type Mystery. Type 3 e. The Mystery. Type 2. m method returns a subtype of Mystery. Type 1 f. After the last statement, the actual type of mt 1 is Mystery. Type 1 17 October 2002 CS 201 J Fall 2002 3

… (in client code) Mystery. Type 1 mt 1; Mystery. Type 2 mt 2; Mystery. Type 3 mt 3; … (anything could be here) mt 1 = mt 2. m (mt 3); If the Java compiler is happy with this code, which of these are guaranteed to be true: a. The apparent type of mt 2 is Mystery. Type 2 TRUE: the apparent type is obvious from the declaration. b. At the last statement, the actual type of mt 2 is Mystery. Type 2 FALSE: we only know the actual type <= Mystery. Type 2 c. Mystery. Type 2 has a method named m TRUE d. The Mystery. Type 2. m method takes a parameter of type Mystery. Type 3 FALSE: we only know it takes a parameter >= Mystery. Type 3 e. The Mystery. Type 2. m method returns a subtype of Mystery. Type 1 TRUE: the assignment type checking depends on this f. After the last statement, the actual type of mt 1 is Mystery. Type 1 FALSE: we only know that the actual type <= Mystery. Type 1 17 October 2002 CS 201 J Fall 2002 4

Subtyping Rules class A { public RA m (PA p) ; } … (in client code) Mystery. Type 1 mt 1; Mystery. Type 2 mt 2; Mystery. Type 3 mt 3; … mt 1 = mt 2. m (mt 3); If A is Mystery. Type 2, what do we know about RA and PA? RA must be a subtype of Mystery. Type 1: RA <= Mystery. Type 1 Mystery. Type 3 must be a subtype of PA: PA >= Mystery. Type 3 17 October 2002 CS 201 J Fall 2002 5

Subtyping Rules … (in client code) class A { Mystery. Type 1 mt 1; public RA m (PA p) ; Mystery. Type 2 mt 2; } Mystery. Type 3 mt 3; class B extends A { … public RB m (PB a); mt 1 = mt 2. m (mt 3); } If B <= A, what do we know about RB and PB? RB must be a subtype of RA: RB <= RA PA must be a subtype of PB: PB >= PA 17 October 2002 CS 201 J Fall 2002 6

Substitution Principle … (in client code) class A { Mystery. Type 1 mt 1; public RA m (PA p) ; Mystery. Type 2 mt 2; } Mystery. Type 3 mt 3; class B extends A { … public RB m (PB a); mt 1 = mt 2. m (mt 3); } Substitution Principle: Parameters PB >= PA Preconditions pre_A pre_B Result Postconditions 17 October 2002 RB <= RA post_B post_A CS 201 J Fall 2002 7

Substitution Principle / Eiffel … (in client code) class A { Mystery. Type 1 mt 1; public RA m (PA p) ; Mystery. Type 2 mt 2; } Mystery. Type 3 mt 3; class B extends A { … public RB m (PB a); mt 1 = mt 2. m (mt 3); } Substitution Principle Eiffel Parameters PB >= PA PB <= PA Preconditions pre_A pre_B pre_A Result RB <= RA Postconditions post_B post_A 17 October 2002 CS 201 J Fall 2002 8

Overloading and Overriding • Overriding: replacing a supertype’s method in a subtype – Dynamic dispatch finds method of actual type • Overloading: providing two methods with the same name but different parameter types – Statically select most specific matching method of apparent type 17 October 2002 CS 201 J Fall 2002 9

Overloading Example public class Overloaded extends Object { public int try. Me (Object o) { return 17; } public int try. Me (String s) { return 23; } } public boolean equals (String s) { return true; public boolean equals (Object) } is inherited from Object 17 October 2002 CS 201 J Fall 2002 10

public class Overloaded { public int try. Me (Object o) { return 17; } public int try. Me (String s) { return 23; static public void main (String args[]) { } Overloaded over = new Overloaded (); public boolean equals (String s) { System. err. println (over. try. Me (over)); return true; System. err. println (over. try. Me (new String ("test"))); } } Overloading Object obj = new String ("test"); System. err. println (over. try. Me (obj)); System. err. println (over. equals (new String ("test"))); System. err. println (over. equals (obj)); Object obj 2 = over; System. err. println (obj 2. equals (new String ("test"))); } 17 October 2002 CS 201 J Fall 2002 17 23 17 true false 11

Overkill • Overloading and overriding together can be overwhelming! • Avoid overloading whenever possible: names are cheap and plentiful • One place you can’t easily avoid it: constructors (they all have to have the same name) 17 October 2002 CS 201 J Fall 2002 12

My Favorite C++ Program #include<stdio. h> (On notes, for experts only) class A { public: void other () { printf("is an empty func in An"); }; virtual void other (class A *a) { printf("In An"); } }; class B: public A { public: void other (class B *b) { printf("In Bn"); } }; class C: public A { public: void other (class C *c) { printf("In Cn"); } }; void main(void) { A a; B b; C c; A *a. Ptr = &a; B *b. Ptr = &b; C *c. Ptr = &c; a. Ptr = b. Ptr; a. Ptr->other(b. Ptr); b. Ptr->other(); } 17 October 2002 CS 201 J Fall 2002 13

Concurrency 17 October 2002 CS 201 J Fall 2002 14

Our computer can only do one instruction at a time, why would we want to program pretending it can do many things at once? 17 October 2002 CS 201 J Fall 2002 15

Concurrent Programming • Some problems are clearer to program concurrently: – Modularity • Don’t have to explicitly interleave code for different abstractions (especially: user interfaces) • High-level interactions – synchronization, communication – Modeling • Closer map to real world problems: things in the real world aren’t sequential 17 October 2002 CS 201 J Fall 2002 16

Concurrency in Java public class Thread implements Runnable { // OVERVIEW: A thread is a thread of execution in a program. // The Java Virtual Machine allows an application to have // multiple threads of execution running concurrently. public Thread (Runnable target) // Creates a new Thread object that will run the target. public void start () // Starts a new thread of execution. … many other methods } 17 October 2002 CS 201 J Fall 2002 17

Making a Thread public class Thread implements Runnable { public Thread (Runnable target) public void start () … many other methods } // from PS 5 Grid class: public void start. Objects() // EFFECTS: Start all object threads. { Enumeration els = simobjects. elements (); while (els. has. More. Elements ()) { Sim. Object current = (Sim. Object) els. next. Element (); Thread sim. Object. Thread = new Thread (current); sim. Object. Thread. start (); } What do you know about Sim. Object type? } 17 October 2002 CS 201 J Fall 2002 18

Runnable public interface Runnable { public void run() When an object implementing interface Runnable is used to create a thread, starting the thread causes the object's run method to be called in that separately executing thread. The general contract of the method run is that it may take any action whatsoever. } So, to be a subtype of Runnable, Sim. Object must have a method void run () with no preconditions and any postconditions it wants. 17 October 2002 CS 201 J Fall 2002 19

Making a Runnable abstract public class Sim. Object implements Runnable { … public void run () // EFFECTS: Executes one turn by calling the // execute. Turn method, and sleeps for a time // and repeats. { while (true) { execute. Turn (); delay (TURN_DELAY + random. next. Int(TURN_RANDOM)); } } 17 October 2002 CS 201 J Fall 2002 20

Actually… abstract public class Sim. Object implements Runnable { … public void run () // REQUIRES: this has been initialized //@also_requires is. Initialized // EFFECTS: Executes one turn by calling the // execute. Turn method, and sleeps for a time // and repeats. { We are violating the substitution principle! … Sim. Object. run() has a stronger precondition } than Runnable. run(). 17 October 2002 CS 201 J Fall 2002 21

Concurrency • Making a concurrent Java program is easy: Make a subtype R of Runnable new Thread (new R ()). start () • Making a concurrent Java program that behaves correctly is really, really hard! 17 October 2002 CS 201 J Fall 2002 22

Scheduling Meetings • Alice wants to schedule a meeting with Bob and Colleen Bob “When can you meet Friday? ” Alice “When can you meet Friday? ” Colleen “ 11 am or 3 pm” “ 9 am or 11 am” Reserves 11 am for meeting 17 October 2002 Picks meeting time “Let’s meet at 11 am” CS 201 J Fall 2002 Reserves 11 am for meeting 23

Partial Ordering of Events • Sequential programs give use a total ordering of events: everything happens in a determined order • Concurrency gives us a partial ordering of events: we know some things happen before other things, but not total order Alice asks to schedule meeting before Bob replies Alice asks to schedule meeting before Colleen replies Bob and Colleen both reply before Alice picks meeting time before Bob reserves time on calendar 17 October 2002 CS 201 J Fall 2002 24

Race Condition Bob Doug “When can you meet Friday? ” Alice “When can you meet Friday? ” Colleen “ 9, 11 am or 3 pm” “ 9 am or 11 am” “ 9, 11 am or 3 pm” “Let’s meet at 11 am” Reserves 11 am for Doug “Let’s meet at 11 am” Picks meeting time “Let’s meet at 11 am” “I’m busy then…” 17 October 2002 CS 201 J Fall 2002 25

Preventing Race Conditions • Use locks to impose ordering constraints • After responding to Alice, Bob reserves all the times in his response until he hears back (and then frees the other times) 17 October 2002 CS 201 J Fall 2002 26

Locking Doug “When can you meet Friday? ” Bob “When can you meet Friday? ” Alice “When can you meet Friday? ” Colleen “ 9, 11 am or 3 pm” “ 9 am or 11 am” Locks calendar “ 3 pm” “Let’s meet at 11 am” Picks meeting time “Let’s meet at 11 am” “Let’s meet at 3” 17 October 2002 CS 201 J Fall 2002 27

Doug “When can Bob you meet Friday? ” “When can you meet Friday? ” Can’t schedule meeting, no response from Bob 17 October 2002 Deadlocks Alice “When can you meet Friday? ” Colleen “When can you meet Friday? ” Locks calendar for Doug, can’t respond to Alice “ 9, 11 am or 3 pm” Locks calendar for Alice, can’t respond to Doug CS 201 J Fall 2002 Can’t schedule meeting, no response from Colleen 28

Why are threads hard? • Too few ordering constraints: race conditions • Too many ordering constraints: deadlocks • Hard/impossible to reason modularly – If an object is accessible to multiple threads, need to think about what any of those threads could do at any time! • Testing is even more impossible than it is for sequential code – Even if you test all the inputs, don’t know it will work if threads run in different order 17 October 2002 CS 201 J Fall 2002 29

Charge • Computers are single-threaded machines that provide their owner the illusion of multiple threads. • Brains are multi-threaded machines that provide their owner with the illusion of a single thread. • Practice with races/deadlocks on Tuesday, no class on Thursday • Return exams 17 October 2002 CS 201 J Fall 2002 30