Component-Based Software Engineering

1. Component-Based Software Engineering More stuff on Threads Paul Krause

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

3. 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

4. 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

5. 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!

6. 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

7. 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

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

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

10. 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

11. 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!"); • }

12. 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

13. 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

14. 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(); }

15. 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

16. An example run run-single: Waiting Contributing: current amount: 20 Waiting Contributing: current amount: 40 Waiting Contributing: current amount: 60 Waiting Contributing: current amount: 80 Waiting Contributing: current amount: 100 Thank you! Contributing: current amount: 120

17. 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

18. Pausing execution • Maintain 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

19. 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

20. 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?

21. 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?

22. 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();

23. 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(); }

24. 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

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

26. 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();

27. 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"); }

28. 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

29. 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); }

30. 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

31. 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

32. 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

33. 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

34. 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)

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

36. 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()

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