Java Threads and higher level constructs for doing concurrent programming

Background How to create/run threads interrupt(), join() Thread priorities/states Synchronized blocks of code wait(),notify()/notifyAll

 Like several concurrent subprograms running within the same address space.  Within a program, individual threads are explicitly “spawned” and give the appearance of simultaneously running sequences of commands.  On a single processor machine, the simultaneous running is an illusion – cpu is time splicing.  Differ from separate processes in that each process runs in its own address space – threads are a lightweight shared memory model

 Single-user programs/clients  continuously responsive user interfaces  e.g., accept input when event handler is busy  Do not block on time-consuming i/o or socket operations  e.g., make help menu accessible during time- consuming database operation, etc.  Speed up tasks when multiple processors available  Model multiple clients on single platform  Servers  Allows multiple clients to connect without “busy signal”

 User clicks GUI button to download web page (occurs in separate thread so GUI isn’t “frozen”)  Massive numerical problems split among processors  assumes each thread runs on separate processor; not necessarily the case  Server spawns thread for each client connection and main thread goes back to accept()  User clicks button which begins time- consuming database lookup. Client can accept more input while lookup is taking place.

 Imagine a GUI program that performs a time- consuming task in the event handler How can the GUI remain responsive?  If we do task in a separate thread and sleep it periodically, user interface thread will appear “live”.  See FrameThread.java and FrameNoThread.java

 Extend Thread. Specifically...  Create a class that extends Thread and place the work that the Thread will carry out in the run() method (ie override the run method).  Create an object from your Thread class.  Call the start() method on the Thread object.  The new Thread then enters the runnable state (it may or may not run immediately depending on resources/priority).

 Implement Runnable. Specifically...  Create a class that implements the Runnable interface. Place all of the work that the Thread will perform in the run() method.  Create an object from your Runnable class.  Create a Thread object and pass the Runnable object to the constructor.  Call the start() method on Thread object.  See simple examples under basic directory.

Class ThreadExample{ public static void main(String[] args){ System.out.println(“Main thread started”); MyFirstThread t = new MyFirstThread(); t.start(); System.out.println(“main thread continuing”); } Class MyFirstThread extends Thread{ void run(){ System.out.println(“in new thread …”); }

class ThreadTest{ public static void main(String[] args){ System.out.println(“main thread started …”); MyRunnableObj r = new MyRunnableObj(); Thread t = new Thread(r); t.start(); System.out.println(“Main thread continuing”); } Class MyRunnableObj implements Runnable{ public void run(){ System.out.println(“new thread started …”); }

Common these days, like with other libraries, to use anonymous inner classes for simple threads Thread t = new Thread(new Runnable(){ public void run(){ //do work here } }); This provides a few advantages: -Reduces proliferation of small, simple classes -Allows t access to instance variables of outer class -Puts code definition close to where object is created.

 Main thread continues  New threads execute the run method and die when they are finished  If any thread calls System.exit(0), it will kill all threads.  Think of each run() as its own main  Program does not exit until all non-daemon threads die.

 Four states a Thread can be in:  New  When you create with new operator but haven’t run yet.  Runnable  When you invoke start() method. Note that Thread is not necessarily running, could be waiting.  Blocked  When sleep() is called  Blocking operation such as input/output  wait() is called by the Thread object  Thread tries to obtain a lock on a locked object

 Dead  Dies a natural death because the run method exits normally  Dies abruptly after an uncaught exception terminates the run method  As of 1.5 Java supports a getState() method in the Thread class that reports one of these states.

 The execution of multiple threads on a single CPU is called scheduling.  The Java runtime supports a very simple, deterministic scheduling algorithm known as fixed priority scheduling.  Thread.setPriority(int newPriority)  Value must be between MIN_PRIORITY and MAX_PRIORITY  NORM_PRIORITY is normal value

 When multiple threads are ready to be executed, the thread with the highest priority is chosen for execution.  Only when that thread stops, or is suspended for some reason, will a lower priority thread start executing.  Scheduling of the CPU is fully preemptive. If a thread with a higher priority than the currently executing thread needs to execute, the higher priority thread is immediately scheduled.

 The Java runtime will not preempt the currently running thread for another thread of the same priority. In other words, the Java runtime does not time-slice. However, the system implementation of threads underlying the Java Thread class may support time-slicing. Do not write code that relies on time-slicing.  In addition, a given thread may, at any time, give up its right to execute by calling the yield method. Threads can only yield the CPU to other threads of the same priority--attempts to yield to a lower priority thread are ignored.  static void Thread.yield()

 When all the runnable threads in the system have the same priority, the scheduler chooses the next thread to run in a simple, non- preemptive, round-robin scheduling order.

Atomic processes, sharing resources, synchronization/coordination, avoiding deadlock

 Any time a writeable variable is visible to more than one thread, potential problems exist.  Simple example: two clients try to purchase item at same time.  Order or execution unpredictable  If (itemsLeft > itemsRequested) not reliable!  Must create “thread-safe” programs  More on this later …

 Everything in either Object or Thread class  Two classes of methods:  Those defined in Object  wait(), notify(), notifyAll()  Those defined in Thread class  join(), sleep(), interrupt(), isAlive(), yield(), etc.  All involve situations where threads communicate with each other in some way.  Will discuss later …

 It is best to learn how these methods work with a few canonical examples  First is the following scenario  A client issues a command that requires a time consuming operation – in this case we can imagine it to be reading a lot of data from an input stream  The UI should not block during this operation. Other things can be done that are useful. Thus, we place the operation in a thread.  However, certain commands require this read operation to be complete before they can sensibly be executed.  How do we say “block this command until the other thread is finished”?  Study ExJoin.java in class notes … it uses Thread.join() to handle this situation.

 In the next example we imagine a thread that is launched into a time consuming operation – in this case an expensive calculation in a large loop.  The main thread remains responsive to the GUI and reports on progress of the worker thread. As this progress is monitored, the client may wish to terminate the worker thread.  How can this be done?  We use the following Thread methods to carry this out:  void interrupt(): sends an interrupt request to thread  boolean isInterrupted(): tests weather the thread is interrupted  static Thread currentThread(): returns object represent this Thread.

 Thread.interrupt() is an important method. It supersedes stop() and suspend(), which are now deprecated.  The idea with interrupt() is that one thread notifies another thread that it might be time to stop, but leaves it up to the thread itself to decide.  How does a thread know that it has been interrupted?  By calling isInterruped() or, if the thread is blocking  An InterruptedException is thrown

 The next and probably most important topic is atomicity – how to ensure that one thread completes an entire sequence of instructions without being preempted by another thread.  Note that instructions are not lines of Java code – one line can be made up of several instructions, possibly many more  The motivation is simple – if one thread takes on action best on a test condition, but another thread begins to execute and halts the original thread, the condition may no longer be true by the time the initial thread recommences execution.  How do we “lock” threads out of a piece of code until one thread is finished executing?

 One thread is called the Producer. Producer shoves consecutive integers into a Cubbyhole object as fast as it can.  Other thread is called Consumer. Consumer grabs from the Cubbyhole object as fast as it can.  Consumer would like to grab once for each put by the Producer, but what if one goes faster than the other?  We want to block Consumer from consuming until Producer has finished producing.  Likewise, we want to block Producer from producing again until Consumer has conumed.

public class CubbyHole{ private int contents; public synchronized int get() { return contents; } public synchronized void put(int value) { contents = value; }

public class Producer extends Thread { private CubbyHole cubbyhole; private int number; public Producer(CubbyHole c, int number) { cubbyhole = c; this.number = number; } public void run() { for (int i = 0; i < 10; i++) { cubbyhole.put(i); System.out.println("Producer #" + this.number + " put: " + i); try { sleep((int)(Math.random() * 100)); } catch (InterruptedException e) { } }}}

public class Consumer extends Thread { private CubbyHole cubbyhole; private int number; public Consumer(CubbyHole c, int number) { cubbyhole = c; this.number = number; } public void run() { int value = 0; for (int i = 0; i < 10; i++) { value = cubbyhole.get(); System.out.println("Consumer #" + this.number + " got: " + value); }}}

 Note that these classes of themselves do not preclude a race condition.  This is done by shychronizing access to the Cubbyhole object.  We want to guarantee that the Consumer thread can’t get until the Producer has produced.  Need to study wait() and notify() methods.

 void wait(): relinquishes the object lock without exiting the object method – ie if the thread can only proceed within object method once another thread has changed the object’s state. Can only be called if the calling thread already possesses the lock – otherwise, an IllegalMonitorStateException is thrown. The lock is given to the next waiting thread, or chosen randomly if more than one thread is waiting on the same object’s lock.  void notify()/notifyAll(): a thread cannot pull itself out of the wait() state, but requires another thread to call notify/notifyAll to allow it to reclaim the lock and continue.

 This topic confuses many beginning Java programmers  Two forms:  synchronized(objReference){ …}//synchronize a block  synchronized void methodName(){…}//synch a method  Former is more general, but causes confusion. Best to use simple form whenever possible.  Second form is equivalent to:  synchronized(this) for entire method body  Recently java has added a java.util.concurrent.locks package, which contains much of the same functionality but perhaps packaged in a more friendly way. We will go over these briefly as the last step in this lecture.

 Fairly straightforward rules:  When a given thread is executing a synchronized method in an object, no other thread can execute an other synchronized method on the SAME OBJECT!  We say that the first thread obtains a lock on the object and doesn’t release it until it finishes the synched method  Beware that only code which tries to obtain a lock on the object will have to wait. For example, if a thread wishes to call a non-synched method in the object, it will not be blocked.

 Remember the following rules:  When a thread encounters a synchronized block of code, it attempts to obtain a lock on the object that is being synchronized upon.  Consider the first thread in a program that encounters the lock. Since it is the first thread, it will successfully obtain the lock.  Now consider a second thread that encounters any synchronized block of code that synchronzies on the same object.

 This second thread will attempt to obtain the lock on objReference.  It will fail to obtain the lock unless the first thread has released it. This means that the first thread must have finished its synchronized block of code.  If the second thread cannot obtain the lock, it must wait until the first thread releases it.

 Must use the opposite route that put the Thread into the blocked state  If put to sleep, specified time interval must elapse.  If waiting for i/o operation, operation must have finished.  If the thread called wait(), then another thread must call notify/notifyAll.  If waiting for a lock, then owning thread must have relinquished the lock.

public class CubbyHole { private int contents; private boolean available = false; public synchronized int get() { while (available == false) { try { wait(); } catch (InterruptedException e) { } } available = false; notifyAll(); return contents; }

public synchronized void put(int value) { while (available == true) { try { wait(); } catch (InterruptedException e) { } } contents = value; available = true; notifyAll(); }

 This time we have a queue of specified length containing String messages.  Two Consumer and one Producer thread run simultaneously.  The Producer adds messages to the queue up to the maximum queue size, then waits for the Consumer to remove one before proceeding.  The Consumer removes messages from the queue unless none are present, in which case it waits for the Producer to add one.  Note that this concept of a blocking queue mimics a very common model where a resource may not be available and polling is inelegant and inefficient. notify() replaces polling with a pushback model.

 The term “race condition” is used to describe a situation where the correctness of multi- threaded code depends on an ordering of operations that is not guaranteed in any execution.  If one thread “races” ahead of another, the code could fail to give correct results.  A very nice example is the concept of a Bank with clients simultaneously moving money within and between accounts.

 An Account object allows clients to withdraw, deposit, and see the balance of a single account.  One thread, the Saver, deposits money.  Another thread, the Spender, withdraws money.  In this example, if there are insufficient funds to allow a specified withdrawal, then, rather than block, an Exception is thrown.  Study the example and see what can go wrong..

 In this more realistic example many Account objects are created and threads are create to transfer money between them in different random ways.  If the code is correct, the total amount of money should not change – it is just moved around but never withdrawn.  However, this requires proper atomicity of the transfer method. This example shows what can go wrong and how to fix it.