1. Multithreading

2. RHS – SWC 2 What is a thread Inside a single process, multiple threads can be executing concurrently A thread is the execution of (part of) the program code, running independently of other threads Threads can share data, but local data can also belong to a specific thread

3. RHS – SWC 3 What is a thread Do threads really run in parallel? Depends on your system… At any time, there can be as many threads running as there are CPUs in your system If more threads are running, the operating system will use time-slicing

4. RHS – SWC 4 What is a thread If only one CPU is available, and 10 threads are running, each thread is only truly running 10 % of the time OS manages threads using time slices –Threads are queued up –Each thread gets to run in a time-slice –It is then suspended, and put back in queue

5. RHS – SWC 5 What is a thread Why use threads at all…? It is sometimes unacceptable if a long operation blocks the application Think about an Internet browser; while one page is loading, you can still load other pages, scroll a page, etc. Using threads does not as such reduce the computation effort

6. RHS – SWC 6 Using threads Simple use of threads follows a few steps: First, implement a class which implements the Runnable interface: public interface Runnable { void run(); }

7. RHS – SWC 7 Using threads Next, put the code which needs to run in a a separate thread into the run method: public class MyTask implements Runnable { public void run() { // Code for task here... }

8. RHS – SWC 8 Using threads When the code is to be executed, create an object of your class, and a Thread object taking your object as input Finally, start the thread Runnable r = new MyTask(); Thread t = new Thread(r); t.start();

9. RHS – SWC 9 Using threads Simple use of threads is thus not in itself particularly complicated When the started task ends, the thread itself is terminated What if we need to stop a thread, before the task has ended (or task is ”infinite”)…?

10. RHS – SWC 10 Using threads public void run() { while (true) { if (theQueue.isEmpty()) sleep(100); else processElement(theQueue.pop()); }

11. RHS – SWC 11 Using threads We cannot directly stop a thread, but we can ask it to stop itself… Call the method interrupt on the thread object The thread itself can check for interruption by calling Thread.interrupted

12. RHS – SWC 12 Using threads public void run() { while (!Thread.interrupted()) { if (theQueue.isEmpty()) sleep(100); else processElement(theQueue.pop()); }

13. RHS – SWC 13 Using threads But…what if the thread is sleeping? If interrupt is called on a sleeping thread, an InterruptedException is thrown in the thread We must catch this exception in run

14. RHS – SWC 14 Using threads public void run() { try { while (!Thread.interrupted()) { if (theQueue.isEmpty()) sleep(100); else processElement(theQueue.pop()); } catch (InterruptedExeption ex) {...} // Code for cleaning up, if needed }

15. RHS – SWC 15 Using threads Can a thread refuse to terminate…? Yes, but why should it… Calling interrupt on a thread is a signal to –Stop what you are doing –Clean up after yourself –Terminate completely We assume that threads are always willing to cooperate

16. RHS – SWC 16 Using threads DEMO ThreadExample

17. RHS – SWC 17 Exercises On a railway through a mountain area, it was at some point only possible to build a tunnel with room for one track (see drawing below). This poses a problem when a train wants to pass through the tunnel – how can it be sure that no train is coming from the opposite direction at the same time? Devise a way for making sure that only one train uses the tunnel at any time. This problem is from the pre-radio era, so no solution involving remote communication is legal Make sure to take note of any assumptions you make when designing your solution Tunnel

18. RHS – SWC 18 Race conditions As long as threads only access their own local data (data created in their own thread), things are pretty easy If threads try to access (and change) shared data, things get complicated So-called race conditions can occur

19. RHS – SWC 19 Race conditions public void deposit(int amount) { int newBalance = balance + amount; balance = newBalance; } public void withdraw(int amount) { int newBalance = balance - amount; balance = newBalance; } balance = 1000 // Called on sepa- // rate threads deposit(100); withdraw(100); newBalance(d) = 1100 newBalance(w) = 900 balance = 900; balance = 1100;

20. RHS – SWC 20 Race conditions A very nasty property of race conditions is that they only occur sometimes… Allocation of time slices to threads is not deterministic – depends on total state of the system Code running correctly on one system may run incorrectly on another system

21. RHS – SWC 21 Race conditions Maybe this will help: public void deposit(int amount) { balance = balance + amount; } Unfortunately not – interruption is at lower level, so statement is not ”atomic”

22. RHS – SWC 22 Syncronised object access We must somehow prevent threads from simultaneous access to shared objects This is done by using a Lock object The Lock type is actually an interface – most commonly used implementation is the ReentrantLock class

23. RHS – SWC 23 Syncronised object access public class BankAccount { private Lock balanceLock; private int balance; public BankAccount() { balance = 0; balanceLock = new ReentrantLock(); }

24. RHS – SWC 24 Syncronised object access public void deposit(int amount) { balanceLock.lock(); balance = balance + amount; balanceLock.unlock(); } public void withdraw(int amount) { balanceLock.lock(); balance = balance - amount; balanceLock.unlock(); } This is almost – but not quite – good enough…

25. RHS – SWC 25 Syncronised object access If a thread calls lock on the Lock object, the thread owns the lock, until it calls unlock on the Lock object Any other thread calling lock on the Lock object will be suspended, until the lock becomes available What if the thread holding the lock never calls unlock …?

26. RHS – SWC 26 Syncronised object access public void aMethod() { aLock.lock(); // Code accessing a shared // resource aLock.unlock(); } What if this code throws an exception…?

27. RHS – SWC 27 Syncronised object access We must be sure that the thread holding the lock will call unlock Otherwise, we could have a deadlock We can ensure the call by using a finally clause

28. RHS – SWC 28 Syncronised object access public void aMethod() { aLock.lock(); try { // Code accessing a shared // ressource } finally { aLock.unlock(); } ALWAYS executed!

29. RHS – SWC 29 Exercises Review: R19.5, R19.7, R19.8 Programming: P19.1, P19.2, P19.3

30. RHS – SWC 30 Preventing deadlocks Using locks ensures that shared data remains consistent, even in a multi- threaded scenario However, using locks may lead to other problems, typically a deadlock A deadlock occurs when two threads wait for each other to release locks

31. RHS – SWC 31 Preventing deadlocks I have lock A, but I’m waiting for lock B… I have lock B, but I’m waiting for lock A…

32. RHS – SWC 32 Preventing deadlocks Safe A Safe B Key A Key B

33. RHS – SWC 33 Preventing deadlocks public void withdraw(int amount) { balanceLock.lock(); try { while (balance < amount) // Wait for balance to increase } finally { balanceLock.unlock(); } But now it is impossible to deposit money…

34. RHS – SWC 34 Preventing deadlocks One solution is to use a so-called condition object Enables a thread to release a lock temporarily, thereby allowing other threads to obtain it A condition object is always related to a lock object

35. RHS – SWC 35 Preventing deadlocks I’m waiting for condition A to be fulfilled… OK, I’ll tell you when it might be fulfilled

36. RHS – SWC 36 Preventing deadlocks public class BankAccount { private Lock balanceLock; private Condition sufficientFundsCondition; private int balance; public BankAccount() { balance = 0; balanceLock = new ReentrantLock(); sufficientFundsCondition = balanceLock.newCondition(); }

37. RHS – SWC 37 Preventing deadlocks public void withdraw(int amount) { balanceLock.lock(); try { while (balance < amount) sufficientFundsConditions.await(); } finally { balanceLock.unlock(); } Not sleeping, but waiting…

38. RHS – SWC 38 Preventing deadlocks public void deposit(int amount) { balanceLock.lock(); try {... sufficientFundsConditions.signalAll(); } finally { balanceLock.unlock(); } Tell threads waiting on this condition, that the condition might have changed

39. RHS – SWC 39 Preventing deadlocks Notice that this is a coordinated effort between deposit and withdraw We must have control over all pieces of code trying to access a shared object Common errors: –Calling await without calling signalAll –Calling signalAll without locking the lock

40. RHS – SWC 40 Multithreading – final remarks Working with multi- threading is difficult! Hard to get an overview of all possible scenarios and consequences Errors may only show up occasionally

41. RHS – SWC 41 Multithreading – final remarks Debugging a multi- threaded program can be a true nightmare… The debugging process itself may change the behavior of the program Timing changes when debugging

42. RHS – SWC 42 Multithreading – final remarks Use multithreading only if you really need to! Typical example: GUI application with lengthy operations Makes GUI responsive when lengthy operations are executing

43. RHS – SWC 43 Multithreading – final remarks Making a program multi- threaded does not make it faster as such Amount of computation does not become smaller Multi-core CPUs make things a bit more compli- cated…

44. RHS – SWC 44 Exercises Review: R19.9, R19.10 Programming: P19.6