Component-Based Software Engineering More stuff on Threads Paul Krause

Lecture 7 - Contents Basics of threads and synchronization Waiting - releasing locks Collection Plate example Choices when pausing execution Ice Cream Example Notify versus NotifyAll

Quick Reminder User requests document is printed and saved Word processor spools print job Word processor starts saving to hard drive User requests document is printed and saved

A Better Solution Thread starts spooling print job User requests document is printed and saved Spawn threads to print and save Main thread waits until other threads are complete User gets control ready for next operation Thread starts saving document to hard drive

Basic concepts Synchronization enables a Java object to be locked for exclusive use by a thread A locked object is inaccessible to any thread other than the one that locked it So long as the other threads honour this Each object can keep track of the other threads that want exclusive access to it How to keep threads fighting over limited toys!

Waiting This is not just a matter of notifying the JVM it can (but doesn’t have to!) provide resource to other threads As with Thread.yield or Thread.sleep Calling myObject.wait will release myObject’s lock Waiting is the process of getting (completely) out of the way when you can’t be productive

CollectionPlate example Minister passes around a collection plate He waits until the collection has exceeded a certain amount While he is waiting, other people can modify the state of the collection plate By adding money to it Once the total collected exceeds a certain amount, the Minister takes back the plate

Structure of Minister Class public class Minister { private CollectionPlate collectionPlate = new CollectionPlate(); … private class CollectionAcceptor extends Thread { … } private class CollectionChecker extends Thread { }

CollectionPlate We will lock the instance of CollectionPlate whenever we access or modify its state private class CollectionPlate { int amount = 0; }

main method Start off a thread that is going to monitor the state of the collectionPlate minister.new CollectionChecker().start(); Within the run method of the CollectionChecker, we Obtain the lock on collectionPlate If the amount on the collectionPlate is less than 100 we temporarily release the lock until we are notified by another thread of a change

CollectionChecker’s run() synchronized (collectionPlate) { while (collectionPlate.amount < 100) { try { System.out.println("Waiting"); collectionPlate.wait(); } catch (InterruptedException ie) { ie.printStackTrace(); // getting past the while statement means that the // contribution goal has been met System.out.println("Thank you!");

More detail The CollectionChecker must have the lock for collectionPlate before it calls wait() on it The CollectionChecker cannot proceed if there is less than 100 units on the plate So theCollectionChecker waits by releasing the lock on the collectionPlate and waiting until another thread notifies it of a change in state to the latter If the amount is still < 100 it waits some more. Otherwise it says “Thank you” and terminates

What happens during a wait In the “Minister” case, several threads have been started up that can accept contributions: for (int i = 0; i < 6; i++ ) { minister.new CollectionAcceptor(20).start(); } In turn, each will claim the lock on the collectionPlate, add $20 and then notify the ministrr when it has finished

CollectionAcceptor’s run() synchronized (collectionPlate) { int amount = collectionPlate.amount + contribution; String msg = "Contributing: current amount: " + amount; System.out.println(msg); collectionPlate.amount = amount; collectionPlate.notify(); }

The result In turn (why?) each instance of CollectionAcceptor obtains the lock on collectionPlate $20 is then added to the collectionPlate and the waiting class is notified when the lock is released again The CollectionAcceptor (“minister”) can resume execution and check the contents of the collectionPlate

An example run run-single: Waiting Contributing: current amount: 20 Thank you! Contributing: current amount: 120

In General If myObject.wait() is called by threadA, then: threadA temporarily releases the lock on myObject Execution of threadA is suspended threadA registers its interest in being notified after another thread has modified myObject Once notified, threadA can resume execution having recovered the lock on myObject It is the designer’s responsibility to ensure waiting objects are notified

Pausing execution Maintain current locks Release current locks Waiting for some event to occur, before completing the process of accessing or modifying a resource Release current locks Having completed business with a resource, this pause means the thread has finished its work for now

Other fun things with threads! Yielding “Politely offering up your place the the queue” Does not release locks Blocking A thread will block while it is waiting for a lock The JVM will automatically tranisition it to Runnable when the lock becomes available Sleeping Waits at least as long as the specified time

Ice-cream man example We create a number of Children as customers of an IceCream man Each Child has an IceCreamDish that should be filled completely before the IceCream man serves another customer In the the application, the instance of IceCreamMan is declared static to ensure there is only one instance (is there another way of doing this?) The IceCreamMan’s thread is set as a “daemon” thread - So?

Basic outline Start the IceCreamMan on a new thread Start three instances of Child, each on their own thread Each child will obtain a dish of ice cream and eat it Once all three children have eaten their ice cream, the main thread prints out a message and terminates What about iceCreamMan?

Starting the iceCreamMan Remember iceCreamMan = new IceCreamMan() is a static property of Chil\ Hence (as far as Children are concerned) there is only one iceCreamMan In the main method: iceCreamMan.setDaemon(true); iceCreamMan.start();

Getting the children going String[] names = {"Ricardo", "Paolo", "Maria"}; Thread[] children = new Thread[names.length]; // create some child objects // create a thread for each child // get the Child threads started int counter = -1; for (String name : names) { Child child = new Child(name); children[++counter] = new Thread(child); children[counter].start(); }

What’s the iceCreamMan doing? The iceCreamMan has a list of IceCreamDishes: private List<IceCreamDish> dishes = new ArrayList<IceCreamDish> (); If the list is not empty, he serves some ice cream, otherwise he sleeps for a bit to give the children a chance to add dishes

iceCreamMan.run() public void run() { while (true) { if (!dishes.isEmpty()) { serveIceCream(); } else { try { sleep(1000); catch(InterruptedException ie) { ie.printStackTrace();

The story so far The iceCreamMan is waiting for some dishes to fill Three children have been started, so what are they doing? Child.run() // add myDish to iceCreamMan.dishes iceCreamMan.requestIceCream(myDish); // now try to eat myDish of ice cream eatIceCream();

Eating iceCream public void eatIceCream() { synchronized(myDish) { while (myDish.readyToEat == false) { try { System.out.println(name + msg); myDish.wait(); } catch (InterruptedException ie) { ie.printStackTrace(); myDish.readyToEat = false; System.out.println(name + " yum");

So? The Child “owns” the lock on its iceCreamDish If the iceCreamDish is not ready to eat, the Child releases the lock and waits to be notified when it is full Note the use of a “while” loop, and not an “if” statement. It is possible that the Child thread could wake up before it is notified. By using a while loop, the guard will be checked again if such a “spurious wake up” occurs

IceCreamMan.serveIceCream private void serveIceCream() { // get an ice cream dish IceCreamDish currentDish = dishes.get(0); synchronized (currentDish) { currentDish.readyToEat = true; // notify the dish's owner that the dish is ready currentDish.notify(); } // remove the dish from the queue of dishes dishes.remove(currentDish);

Note Correct functioning requires both the writer of Child and the writer of IceCreamMan to synchronise on IceCreamDishes. There is nothing here that forces a Child to synchronize. But if she doesn’t, then she may get a half-full or even empty IceCreamDish

notify() vs. notifyAll() In the previous examples, we only had one thread waiting for the lock on an object at a time We used notify() to inform the JVM that when lock was available and the waiting thread could resume In general, there could be several threads waiting notifyAll() might be more appropriate

More in wait() Following a wait(myObject) invocation: The current thread is blocked Unless the current thread has been interrupted, in which case the method exits throwing an InterruptedException. The thread is placed in an internal “wait set” associated with myObject The lock on myObject is released But all other locks are retained

notify() Following a myObject.notify() invocation: If one exists, then an arbitrarily chosen thread T is removed from the wait set associated with myObject T must re-obtain the lock on myObject It will be blocked until it does so T will then resume from the point of its wait

myObject.notifyAll() All threads in the wait set for myObject are removed But they must wait in turn for the synchronization lock on myObject So they will continue one at a time (at least until each respective thread releases the lock)

NotifyVersusNotifyAll.java We will run the program first using notify() in the main method and then again using notifyAll()

Usage guidelines Only use notify() if you are sure that the thread that will be notified will be able to use the notification Note that in general you will not know which thread will be notified by the JVM If multiple threads are waiting on one event, but with different conditions to meet, then best to use notifyAll()

Simple example Producer thread Consumer Thread 1 Consumer Thread 2 synchronized(lock) { value = Math.random(); lock.notifyAll(); } Consumer Thread 1 While (value < 0.5) { lock.wait(); } Consumer Thread 2 While (value >= 0.5) { lock.wait(); }