02152  Concurrent Systems - CP Lab 1: Dynamic Java Thread Creation/Cancellation
Technical University of Denmark DTU
02152 Concurrent Systems        Fall 2008
CP Lab 1: Dynamic Java Thread Creation/Cancellation
Home Plan Material  

Purpose

To experiment with Java's mechanims for dynamically starting and terminating threads in connection with a rudimentary multi-threaded window application.

Time and Place

Assistance for this programming lab will be available in the E-databar, Building 341, rooms 003+015, Thursday, September 4, 15.00-17.00.

Preparations

You should consult [Proc 4] and perhaps [Andrews 5.4.1] to see how to create Java threads.

Instructions:

The objective of this lab is to control a number of tasks that each write in a textfield of a window.

  1. Make a new subdirectory for the exercise and fetch the files TaskControl.java and TaskDisplay.java.
  2. Compile and run TaskControl.java and observe that the program does not react to key-presses like 'h' while running a Task.
  3. Now modify TaskControl.java such that typing the command t starts a Task-thread that writes in the first field. How does the system react now? What happens if t is pressed while a Task-thread is running?

  4. Make sure that only one Task-thread is active at a time. Also, when terminating the program using command x, the termination of this thread must be awaited (with t.join()) before closing the window. To determine whether a thread t is active, t.isAlive() should be used.

    Notice that a thread that has terminated cannot be restarted. Instead a new thread object must be created.

  5. Now, by pressing t, is must be possible dynamically to start concurrent threads each writing in a separate textfield. If all fields are occupied, an error message should be issued. At exit, all active threads must terminate before closing the window.

    Hint: Use an array of Thread (or Task) to keep track of the threads.

  6. Add the possibility of terminating an active Task by pressing 0, 1, ... etc. Try first to use t.stop() to stop a thread t.
  7. In general, it is more safe to cancel threads by letting them terminate themselves. A thread t may be urged to terminate itself by calling t.interrupt() which will set an interrupt flag associated with the thread. Now, the next call of a blocking operation in t (in this case sleep) will throw an InterruptedException (and clear the interrupt flag). Change the program such that the tasks terminate themselves and let them show with "|" where they were terminated.
  8. Modify the Task to consume CPU-cycles (see code). You may have to adjust the delay-factor of the inner loop in order to obtain a suitable speed.

     
    Since sleep is no longer called, the InterruptedException will not be thrown. Instead, the task may use the boolean function interrupted() to test (and clear) the value of the interrupt flag where appropriate. Cancel the thread by this means.

Enjoy!

Caveat:

This purpose of this lab is to illustrate the possibility of off-loading GUI-activity to threads. Using the older AWT-GUI framework, this can be done with only minor modifications of the of the code. The reason is that the AWT-framework uses the underlying, native window components which are (assumed to be) thread-safe. This implies that concurrent threads may call update functions in the window components without risking them to be rendered inconsistently or breaking down (eg the window "freezing").

However, in the newer Swing-library, the window components are implemented all in Java, and for efficiency reasons the Swing components are not thread-safe. That means that only the event-dispatcher thread should call Swing components. By calling appropriate operations other threads may register their updates within the event queue for subsequent processing by the event-dispatcher thread.

For details of using Swing from separate threads, see the articles:

http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html
http://java.sun.com/products/jfc/tsc/articles/threads/threads2.html
http://java.sun.com/products/jfc/tsc/articles/threads/threads3.html

PS. The same considerations apply to Windows Forms under .NET. See eg:

http://msdn2.microsoft.com/en-us/library/ms171728.aspx

Hans Henrik Løvengreen, Sep 1, 2008