Roadmap

1. Introduction Concurrent Programming Communication and Synchronization Completing the Java Model Overview of the RTSJ Memory Management Clocks and Time Scheduling and Schedulable Objects Asynchronous Events and Handlers Real-Time Threads Asynchronous Transfer of Control Resource Control Schedulability Analysis Conclusions Roadmap

2. Completing The Java Model Lecture aims: • To introduce thread priorities and thread scheduling • To show how threads delay themselves • To illustrate how threads can be grouped together • To consider interaction with processes outside the VM • To summarises the strengths and weaknesses of Java model • To introduce Bloch’s safety levels

3. Thread Priorities I • Although priorities can be given to Java threads, they are only used as a guide to the underlying scheduler when allocating resources • An application, once running, can explicitly give up the processor resource by calling the yield method • yield places the thread to the back of the run queue for its priority level

4. Thread Priorities II package java.lang; public class Threadextends Object implements Runnable { // constants publicstaticfinalint MAX_PRIORITY = 10; publicstaticfinalint MIN_PRIORITY = 1; publicstaticfinalint NORM_PRIORITY = 5; // methods publicfinalintgetPriority(); publicfinal voidsetPriority(int newPriority); publicstaticvoidyield(); ... }

5. Warning • From a real-time perspective, Java’s scheduling and priority models are weak; in particular: • no guarantee is given that the highest priority runnable thread is always executing • equal priority threads may or may not be time sliced • where native threads are used, different Java priorities may be mapped to the same operating system priority

6. Delaying Threads: Clocks • Java supports the notion of a wall clock • java.lang.System.currentTimeMillis returns the number of milliseconds since 1/1/1970 GMT and is used by used by java.util.Date (see also java.util.Calendar) • However, a thread can only be delayed from executing by calling the sleep methods in the Thread class • sleep provides a relative delay (sleep from now for X milliseconds, y nano seconds), rather than sleep until 15th December 2003

7. Delaying a Thread public class Threadextends Object implements Runnable { ... publicstaticvoidsleep(long ms) throws InterruptedException; publicstaticvoidsleep(long ms, int nanoseconds) throws InterruptedException; ... }

8. Thread executing Sleep Granularity Local drift Granularity difference between clock and sleep time Time specified by program Thread runnable here but not executing Interrupts disabled Time

9. Drift • The time over-run associated with both relative and absolute delays is called the local drift and it it cannot be eliminated • It is possible, with absolute delays, to eliminate the cumulative drift that could arise if local drifts were allowed to superimpose while(true) { // do action every 1 second sleep(1000) }

10. Absolute Delays I • Consider an embedded system where the software controller needs to invoke two actions • The causes the environment to prepare for the second action • The second action must occur a specified period (say 10 seconds) after the first action has been initiated • Simply sleeping for 10 seconds after a call to the first action will not achieve the desired effect for two reasons • The first action may take some time to execute. If it took 1 second then a sleep of 10 would be a total delay of 11 seconds • The thread could be pre-empted after the first action and not execute again for several seconds • This makes it extremely difficult to determine how long the relative delay should be

11. Absolute Delays II { static long start; static void action1() {...}; static void action2() {...}; try { start = System.currentTimeMillis(); action1(); Thread.sleep( 10000 - (System.currentTimeMillis() - start)); } catch (InterruptedException ie) {...}; action2(); } What is wrong with this approach?

12. Timeout on Waiting I • In many situations, a thread can wait for an arbitrary long period time within synchronized code for an associated notify (or notifyAll) call • There are occasions when the absence of the call, within a specified period of time, requires that the thread take some alternative action • Java provides two methods for this situation both of which allows the wait method call to timeout • In one case, the timeout is expressed in milliseconds; in the other case, milliseconds and nanoseconds can be specified

13. Timeout on Waiting II • There are two important points to note about this timeout facility • As withsleep, the timeout is a relative time and not an absolute time • It is not possible to know for certain if the thread has been woken by the timeout expiring or by a notify • There is no return value from the wait method and no timeout exception is thrown

14. Timeouts on Waiting public class TimeoutException extends Exception {}; public class TimedWait { public static void wait(Object lock, long millis) throws InterruptedException, TimeoutException { // assumes the lock is held by the caller long start = System.currentTimeMillis(); lock.wait(millis); if(System.currentTimeMillis() >= start + millis) throw new TimeoutException(); } } What is wrong with this approach?

15. Thread Groups I • Thread groups allow collections of threads to be grouped together and manipulated as a group rather than as individuals • They also provide a means of restricting who does what to which thread • Every thread in Java is a member of a thread group • There is a default group associated with the main program, and hence unless otherwise specified, all created threads are placed in this group

16. Thread Groups II public class ThreadGroup { public ThreadGroup(String name); // Creates a new thread group. public ThreadGroup(ThreadGroup parent, String name); // Creates a new group with the // specified parent. . . . public final voidinterrupt(); // Interrupt all threads in the group. publicvoiduncaughtException(Thread t, Throwable e); // Called if a thread in the group // terminates due to an uncaught exception. }

17. Thread Groups III • Hierarchies of thread groups to be created • Thread groups seem to have fallen from favour in recent years • The deprecation of many of its methods means that there is little use for it • However, the interrupt mechanisms is a useful way of interacting with a group of threads • Also, the uncaughtException method is the only hook that Java 1.4 provides for recovering when a thread terminates unexpectedly

18. Processes • Threads execute within the same virtual address space and, therefore, have access to shared memory. • The Java languages acknowledges that the Java program might not be the only activity on the hosting computer and that it will executing under control of an operating system • Java, therefore, allows the programmer to create and interact with other processes under that host system • Java defines two classes to aid this interaction: • java.lang.Process • java.lang.Runtime • (look them up on the web and in the book)

19. Strengths of the Java Concurrency Model • The main strength is that it is simple and it is supported directly by the language • This enables many of the errors that potentially occur with attempting to use an operating system interface for concurrency do not exists in Java • The language syntax and strong type checking gives some protection • E.g., it is not possible to forget to end a synchronized block • Portability of programs is enhanced because the concurrency model that the programmer uses is the same irrespective of on which OS the program finally executes

20. Weaknesses I • Lack of support for condition variable • Poor support for absolute time and time-outs on waiting • No preference given to threads continuing after a notify over threads waiting to gain access to the monitor lock for the first time • Poor support for priorities Note Java 1.5 concurrency utilities will provide some help here

21. Weaknesses II • Synchronized code should be kept as short as possible • Nested monitor calls • should be avoided because the outer lock is not released when the inner monitor waits (to release the lock causes other problems) • can lead to deadlock occurring • It is not always obvious when a nested monitor call is being made: • methods in a class not labelled as synchronized can still contain a synchronized statement; • methods in a class not labelled as synchronized can be overridden with a synchronized method; method calls which start off as being unsynchronized may be used with a synchronized subclass • methods called via interfaces cannot be labelled as synchronized

22. Bloch’s Thread Safety Levels I • Immutable • Objects are constant and cannot be changed • Thread-safe • Objects are mutable but they can be used safely in a concurrent environment as the methods are synchronized • Conditionally thread-safe • Objects either have methods which are thread-safe, or have methods which are called in sequence with the lock held by the caller

23. Bloch’s Thread Safety Levels II • Thread compatible • Instances of the class provide no synchronization • However, instances of the class can be safely used in a concurrent environment, if the caller provides the synchronization by surrounding each method (or sequence of method calls) with the appropriate lock • Thread-hostile • Instances of the class should not be used in a concurrent environment even if the caller provides external synchronization • Typically a thread hostile class is accessing static data or the external environment

24. Summary I • Threads can have priorities but support is weak • Threads can delay themselves by using the sleep methods which only supports relative time periods (intervals); it is not possible to accurately sleep until an absolute time • Time-outs of waiting for events is supported via the wait methods but it is not easy to determine whether the timeout has expired or the event has occurred • Threads can be grouped together via the ThreadGroup class • Hierarchies of groups can be formed and it is possible to interrupt the whole group

25. Summary II • Interaction with processes outside the virtual machine via the Processes and RunTime classes • The Java model has both strengths and weaknesses • Bloch’s has defined thread safety levels

26. Further Reading and Exercises • Find out what Java 1.5 has done to the Thread class to help with the “uncaught exception” problem • Find out about the Processes and Runtime classes • Do the The Santa Claus Problem Exercise

27. Introduction Concurrent Programming Communication and Synchronization Completing the Java Model Overview of the RTSJ Memory Management Clocks and Time Scheduling and Schedulable Objects Asynchronous Events and Handlers Real-Time Threads Asynchronous Transfer of Control Resource Control Schedulability Analysis Conclusions Roadmap Now finished our overview of Java’s concurrency model. See book for examples of it in use.