1. Racing toward disaster...

2. Today in history Last time: Dijkstra’s algorithm (off the cuff) This time: Principle o’ the day Timer threads Design exercise, reprise The joy of race conditions

3. Principle o’ the day Commit early for ease of coding; commit late for flexibility Commit early == make fixed decision at compile time Commit late == make few/no decision at compile time; allow program to make final decisions at runtime

4. History of commitment Bad old days of FORTRAN (ssss... it hurts us my precious) Had to commit to data size and layout at compile time All arrays were declared w/ fixed length No dynamic memory allocation Somewhat better in C Dynamic mem allocation 1/2 part of language Still handled through library Language support primitive (at best) C++/Java/Scheme/etc. support dyn mem fully

5. History of commitment FORTRAN/C/Pascal: commit to specific function calls at compile time (early binding) Hard to have data-dependent functions Scheme/LISP a little better: funcs are 1st class data themselves, so can be synthesized and passed around Java/C++/other OO langs: method binding is late Name has many interpretations Actual method call decided at runtime Makes functions data dependent (polymorphism)

6. History of commitment FORTRAN (pre-90): data types fixed by compiler designer No support for programmer-defined data types C/Pascal/C++/Java: data types fixed at compile time Object o=new String(“...”); commits to a single data type (String) But what if that isn’t flexible enough? E.g., need a Parser object that is document- specific Don’t know which Parser to new at compile time

7. Timer threads

8. Single thread solution public void doYourThing(long period) { assert period>0; while (!_toStop) { long last=System.currentTimeMillis(); // do inner loop stuff long delta=System.currentTimeMillis()-last; try { Thread.sleep(period-delta); } catch (InterruptedException ex) { // do something with this }

9. Analysis of single-thread Tricky to handle “roll-over” What if “inner loop stuff” takes more than one period? System.currentTimeMillis() has some overhead Requires a trap to kernel space Small beans if period is long Hard to align w/ other threads Multiple timers running simultaneously Interface to GUI etc...

10. Multi-thread approaches In general, want a multi-thread model “timer thread”: only job is to keep time beat “worker threads”: respond to timer, do something at each beat Can have many worker threads for one timer Possibilities: java.util.Timer javax.swing.Timer roll your own...

11. Timers behind the scenes Need 2 things: Time base: way to delay for p time units Communication: way to make some other thread do something

12. Timers behind the scenes Time base: Thread.sleep(p) Object.wait(p) Essentially: Go to sleep now; wake up in p ms Both subject to InterruptedException Have to run in try/catch block wait requires that you “own the object’s monitor” Technically, you wait on a specific object Have to synchronize w.r.t. that object before you can call wait() sleep() does this implicitly for you

13. Thread communication Timer thread can now while (!_toStop) { try { this.wait(period); } catch (InterruptedException ex) {} } But what does it do next? How does it tell other threads to do something?

14. Thread communication Opposite of wait() is notify()/notifyAll() Picks one/all threads that are waiting on an object Breaks them out of any wait() they’re in They go back into normal thread schedule Like wait(), call notify() on a specific object Again, have to “own monitor for object” before can call notify() on it Essentially the “observable/observer” design pattern for multi-threaded apps

15. Thread communication public Object sharedObject=new Object(); // in “worker” thread while (!done) { synchronized (sharedObject) { try { sharedObject.wait(); // indefinite wait } catch (InterruptedException ex) { // do something } // do main stuff of loop }

16. Thread communication // in “timer” thread while (!_toStop) { synchronized (this) { try { this.wait(period); } catch (InterruptedException ex) { // do something with exception } synchronized (sharedObject) { sharedObject.notifyAll(); }