Previous column

Next column

---

The Imperion Threading System Douglas Lyon, Fairfield University, Fairfield, USA

COLUMN PDF Version

When you come to
a fork in the road...
Take it.
- Yogi Berr

Abstract

This paper describes the use of the command, facade and decorator design patterns to alter the interface and add new responsibilities to threads. Termed Project Imperion, the threads are developed with the same design patterns as previously reported for Imperion GUI components [Lyon 2004b]. The benefits of Imperion threading include: simplifying code, easing maintenance, separation of thread management logic from the business logic and improved reliability.

Our experience shows that threads are often run more than once. They are frequently stopped and then restarted. However, the present mechanisms for doing this are both low-level and exception-prone. Imperion threads have built-in support for iteration. They support killing and restarting threads by introducing a new class called the RunJob. The RunJob tracks the number of times it has been run, and can be set to run only so many times before it dies. It can be set to start automatically, or be set to wait until explicitly started (or restarted).

The Imperion threading system is a more reliable threading system than the normal java.lang.Thread. Imperion removes dangerous methods and guards’ inputs in order to avoid exceptions. For example, the daemon property can only be set during construction, priorities are guarded for correctness and restarting is safe. This avoids a fruitful source of complex run-time errors that have been bugging both novice and seasoned programmers since the release of JDK 1.0.

Project Imperion was named for the Latin root, imperium, which means the power to command. Like the Intel use of the word CELERON, the on suffix was added to give the word a high-tech look (like electron, proton or muon). It was first conceived at the skunk works of DocJava, Inc., in the late 1990’s.

1 THE CURRENT THREAD MODEL

There are two ways to make a new thread. Either by subclassing the Thread class, or by passing an instance of a class that implements the Runnable interface as a parameter to a thread class constructor. Invoking the start() method causes a thread to move into the ready state. Threads in the ready state are queued for execution but are not running.

Threads have a property, called the Daemon. The term daemon (old English spelling of demon) is a term in the operating systems field. Some have said that it stands for “Disk And Execution MONitor”. A daemon is a task or a thread that remains idle until an event occurs. Daemon tasks are often left idle on an operating system. For example, MacOS X typically has 41 daemon tasks sitting idle. In comparison, it is not uncommon for RedHat Linux to have over 100 idle tasks.

Java can start threads or tasks. To start tasks, it is typical to use platform dependent (i.e., non-portable) code. In Java a daemon thread has special meaning. This meaning comes from the Sun API. In Java, the daemon thread dies when all non-daemon threads die. Before it dies, a daemon is said to be lurking. To put it another way, when only daemons remain in a program, the program exits. For example, a print spool daemon will wake when it sees a file in its spool directory, it then wakes up and prints the file. The print daemon goes back to sleep after all the files in its spool directory are printed. Typically Unix systems run daemon tasks in order to handle requests for services. They are typically started by single task (called inetd). Examples of elements started by inetd (or on RedHat Linux, /etc/xinetd.d) include, echo, a daemon that responds to a ping. There are day daemons, time daemons, login daemons, printing daemons, garbage collector daemons, etc.

Any thread may be set to be a daemon thread by using the setDaemon(true) invocation. However, this can cause an IllegalStateException if the thread is currently alive. Thus, the time-window to safely set the daemon property lies between the construction of and the starting of a thread. The following example prints out a threads’ string representation, its name, and its daemon state:

To run an instance of the TestThread, you must make an instance of the TestThreadand start it.

The following will be printed every 10 seconds at the console:

Line 9 puts the thread to sleep for 10,000 milliseconds (10 seconds). Thread.sleeptakes a long integer because 32 bits does not have enough range to represent long time periods. For example, there are 2^{log2(1000*60*60*24)}= 2²⁶ milliseconds in a day. A signed 32-bit integer overflows in 2³¹-1 milliseconds, (3.5 weeks). A long, 64-bit integer will overflow in 292.4 billion years. The Suns’ corona will have engulfed the Earth in only 10 billion years (by which time, even online journals will be out of print) [Lyon 1999]. Working in milliseconds is counter-intuitive for most people and ignores the nanosecond resolution available in modern high performance operating systems and CPUs. To address this concern, a double precision float is use to represent the time, in seconds, for Imperion threads. This is translated into the Thread.sleep method, which still takes time in milliseconds, at present. There is already a proposal on the table for high-resolution clocks for real-time threads, available at http://www.rtsj.org/. Even so, the present use of a double precision number to represent time does not add any precision to the sleep method, at the moment. The Thread.sleep method can throw an InterruptedException if the thread is interrupted while it is sleeping. Otherwise it will exit normally.

Killing a thread is problematic. The stop, resume and suspend methods have become deprecated because they are considered unsafe. Suspend is inherently deadlock-prone and stopping a thread can cause instance corruption by releasing all the locks on the resources needed by the thread operation. Since the state of the resources cannot be predicted, program execution can’t reliably proceed. The run-time errors that may result can manifest themselves at any time in the future. To more deeply understand why this is true, we need to examine the life cycle of a thread, as shown in Figure 1.

Figure 1. The Life Cycle of a Thread

Figure 1 shows that when the run method returns, the thread becomes dead. Thus, if we kill a thread while it is running, we cannot be assured that it is finished with whatever it is doing. If the thread is blocked when we kill it, it may be waiting for a resource to become available, and it will continue processing when it wakes up. For example, suppose my interest computation is held up because someone is making a transaction with an ATM. If I interrupt the interest computation with an asynchronous stop invocation, then the interest could be lost.

To see how deeply the thread life cycle is embedded in the language, we need look no further than the implementation of the thread life-cycle methods. A blocked thread can be restarted by invoking the notify method. The notify method is defined in the Object class. The notify method is used to notify an object of a change in condition. The methods wait, notify and notifyAll are methods defined in the Object class. The wait method causes the thread of execution to block execution until its notify method is invoked by another thread. The wait method can take three forms:

To more deeply understand why it is so important to allow threads to die only when their run methods end, we must see how race conditions between threads can occur. Race conditions occur when two or more threads try to access the same memory at the same time. In order to make code thread-safe, we have to ensure that certain operations happen all at once (these are known as atomic operations). To create atomic operations, we use the synchronized keyword.

The synchronized keyword may be applied to any reference data-type. For example, suppose there are several threads that are trying to perform an output operation to the PrintStream instance contained in the System class (i.e., System.out). If the threads all output to System.out asynchronously with respect to one-another, then they will tend to over-write one another, intermixing each-others’ output. The solution is to place a lock on the System.out resource using synchronized. The code will have the form:

As another example, suppose that we are programming a banking system. When someone adds money to the bank, we execute:

The lock implements a form of mutex (mutual exclusion). Should the resource that is locked become unavailable (or blocked) it then becomes a single-point of failure. Imagine if such a single point of failure existed in a mission-critical sub-system (like the communications port between the tail-section and cockpit of an air frame). All threads that depended on the correct operation of the port would become deadlocked. The deadlock condition occurs when two or more threads are unable to make progress, due to a dependency on an unavailable resource. This could easily happen if a thread is suspended in the middle of executing on a synchronized resource. If deadlock occurs in a mission critical system, it might result in a mission failure.

To implement atomic execution on a block of code, consider making the entire method synchronized. For example:

Line number 5 is used to give other threads a chance to run. During the execution of the run method, no other threads may execute.

It is also possible to synchronize on the current instance. For example:

Synchronizing on the current instance is considered less clear than synchronizing at the method level [Campione and Walrath].

2 IMPERION THREADS

This section presents an approach to running threads by creating a new, more feature-rich and more reliable thread container, called the RunJob. A RunJob instance contains an instance of a thread. The RunJob contains enough information to start and stop the thread, and to have the thread run any number of times, with a given delay between executions. A RunJob has an implementation of a run method and so knows how to run itself. Thus making use of the command design pattern. The command design pattern places an instance of a command into an instance of another class and calls the issuer. For example, a button can have the role of the issuer, holding a reference to an instance of a command.

The RunJob uses the façade design pattern since it provides a simpler interface to the Thread class. It also uses the decorator design pattern in that it is adding responsibilities to the Thread class. Since the RunJob makes use of both design patterns, we have named it the decorator-façade pattern.

The Imperion RunJob has an overloaded constructor. The most general one follows:

An instance of the RunJob runs every so many seconds. If wait is true then the RunJob will not start unless the start method is invoked, otherwise the RunJob starts right away. If the count is present, then the job only executes count times. The isDaemon method marks this RunJob as either a daemon RunJob or a user RunJob. The Java Virtual Machine exits when the only RunJobs running are all daemon RunJobs and all the threads are daemon threads. Stopping the job yields CPU resources to other threads. The RunJob property can only be set at construction time and is immutable during the life of the RunJob. This avoids a source of run-time exceptions.

We define the RunJob class as one that contains a CommandThread instance. It works by implementing the Runnable interface in a callback mechanism and invokes the run method in the RunJob at given intervals. The run method is left undefined and this causes the RunJob class to be abstract. The following example prints the date and time every two seconds:

The following example will wait for the start method to be invoked before starting the RunJob. It will then run every 1.5 seconds:

The following example starts the RunJob right away, then stops and restarts the job. It will only run 5 times before the job dies, even if the job is restarted. Thus, the RunJob instance tracks the number of times it has been run.

The astute reader will notice that anonymous inner classes are used to define the RunJob. This is deliberate. Anonymous inner class bodies are generally kept short, to improve readability (and to help to separate the thread logic from the business logic). Also, the anonymous RunJob classes promote the isomorphic mapping between instances of the RunJob and instances of a thread. Having one instance of a class that implements runnable for each instance of a thread is a well-known strategy for creating threads that have their own instance variable. In comparison, having a single runnable instance passed to multiple threads can allow all the threads to freely manipulate variables in the runnable instances, leading to potential inconsistencies [Sandén 2004].

To better understand the rationale for the Imperion threading system, it is necessary to understand the history of the thread and some of the shortcomings that it has. In the standard method of using a thread a deadlock-prone method for suspending and resuming a thread can easily be implemented with code in the following format:

Thus, it was typical to suspend and restart threads before the resume and suspend methods became deprecated. The Sun suggested alternative is to use code of the form:

It is up to the programmer to add the following code to the "run loop":

I take issue with this approach. First, the programmer has to remember to do something (which means that there will be occasions when the programmer forgets to do something). Second, the rationale may be clear to the author of the code, but not to the maintainer of the code (who may remove the synchronized invocation and find that no harm was done, this time). Finally, there is an additional cost of synchronization that is imposed by such an implementation. The synchronization is required in order to avoid race conditions.

The RunJob, as implemented in Imperion, treats a stop invocation as non-urgent. The containing thread is always allowed to finish its present command before a flag is checked and the thread stops, leaving instances in known states. Further, the start method makes a new thread instance, reusing the old implementation for the thread command, but resetting the state to the old state (i.e., it tracks the number of times the old thread was run, stores its priority, name, daemon property, etc). As a result we are encumbered with the overhead of making a new instance and setting it to the old thread member variable. This trades the overhead of synchronization for the overhead of creating a new thread. The question of which takes longer really depends on how much work is being done in the synchronized method. The overhead for making a new instance of a thread should at least be a fixed one.

3 WHAT’S THE ASSOCIATION BETWEEN THE RUNJOB AND THE THREAD?

There is a composition association between the RunJob and the Thread classes. That is, the RunJob uses a Thread to run the contained command.

Using the Facade design pattern we are able to map several common components to take advantage of the Runnable interface, as shown in Figure 1.

Figure 2. The RunJob Associations

At the heart of the RunJob is the innerCommandThread class that invokes the call-back run method in the Job class:

Invoking a wait (or sleep) method inside of a synchronized block is likely to result in a deadlock that can come from holding the lock for an indefinite period of time on some resource. The synchronized blocks of an Imperion thread will always be inside of the primary iteration block, whose end task is to run a non-synchronized sleep. This should help to avoid some deadlocks.

4 WHY USE COMPOSITION RATHER THAN EXTENSION?

Several of the methods in the Thread class can throw exceptions if they are misused. Overriding these methods is not an option, as several are declared as final. Further, the RunJob adds new responsibilities that the Thread class was never designed for (i.e., being restartable, being able to track the number of times the run method is invoked, etc.).

More insidious is the need to materially alter the interface of the Thread class in order to hide some of the methods. It is a syntax error for a sub-class to make the visibility of shadowed methods more restrictive. Finally, there is no good way to un-deprecate a method, like the stop method in the Thread class, except by re-implementing it in the containing class.

Threading logic is often added on an as-needed basis. In fact, the RunJob is really just a collection of handy thread features that enable the command and control of a thread. Is adding another class for wrappering a thread invocation really needed?

In my view there are compelling reasons to hide the complexity of thread logic needed to stop and start threads while maintaining some semblance of state, and to make the thread logic as easy as possible for the programmer to maintain. For instance, the following RunColorButton class automatically changes its background color in order to alert the user of its importance:

The above code automatically handles the starting and stopping of the background color change, by reusing the logic in the RunJob class. If this complexity were not hidden from view, the code would more than double in size. Even worse, it would contain code that was practically duplicated in other classes.

Figure 3 The flashing color panel

The code for implementing the color panel follows:

The color panel shows that the buttons not only stop and start their own colors from changing, but that of the containing panel as well. The RunJob simplifies the use of threading and its ease of use actually encourages the use of threading.

5 CONCLUSION

The use of the command and facade design patterns to simplify thread usage is not new [Lyon 2004]. However, the combination of the facade and command patterns, along with the goals of improved reliability and ease of use are new. The danger of run-time exceptions is greatly reduced with the Imperion threading system. This is due, in part, to the guarding of the input. For example, it causes a run-time exception to alter the daemon parameter after starting a thread. As a result, the daemon parameter can only be set in the constructor of a RunJob, thus eliminating a source of a run-time exception. Also guarded is the input to the priority setting method. RunJob thread properties can fall out of sync with one another if the security manager blocks the setting of a property.

A grouping of a thread logic framework into the RunJob factory methods improves maintainability and readability. The use of the anonymous inner classes promotes short method bodies (since people don’t generally like to see long anonymous inner classes). The short method bodies, in turn, promote method forwarding to business logic (improving code reuse and promoting the separation of thread code and business logic).

One of the drawbacks of the Imperion system is that the RunJobs map their actions to only a single listener (themselves). This would seem, on the surface, to be a big limitation. For example, what if many instances are interested in the thread’s execution? I suggest that if this occurs, a new class is needed with a new responsibility that involves the observer-observable design pattern.

Having instances listen to their own event is an easy limitation to live with. In fact, I contend that this is preferable, as it limits inter-object associations, which is, in my view, a primary metric of object-oriented complexity.

The Imperion project is an open-source project freely available at http://www.docjava.com.

REFERENCES

[Camp1996] Campione and Walrath, The Java Tutorial, Addison Wesley, 1996.

[Lyon 1997] Douglas A. Lyon and H. Rao, Java Digital Signal Processing, M&T Press, 1997. Available from http://www.docjava.com.

[Lyon 2004] Douglas A. Lyon, Java for Programmers, Prentice Hall, 2004. Available from http://www.docjava.com.

[Lyon 2004b] Douglas A. Lyon, “Project Imperion: New Semantics, Facade and Command Design Patterns for Swing”, in Journal of Object Technology, Publication Pending.

[Sand 2004] Bo Sandén, “Coping with Java Threads”, in IEEE Computer, April 2004, V. 37, N. 4, pp. 20-27

Appendix A. – The Java Doc

What follows is the javadoc for the RunJob:

About the author

After receiving his Ph.D. from Rensselaer Polytechnic Institute, Dr. Lyon worked at AT&T Bell Laboratories. He has also worked for the Jet Propulsion Laboratory at the California Institute of Technology. He is currently the Chairman of the Computer Engineering Department at Fairfield University, a senior member of the IEEE and President of DocJava, Inc., a consulting firm in Connecticut. E-mail Dr. Lyon at Lyon@DocJava.com. His website is http://www.DocJava.com.

Cite this column as follows: Douglas Lyon: “The Imperion Threading System”, in Journal of Object Technology, vol. 3, no. 7, July-August 2004, pp. 57-70. http://www.jot.fm/issues/issue_2004_07/column5