Bruce on Threading Terminology

Bruce Eckel posted on Threading Terminology over at artima.com. The beauty of this post is following along with Bruce as he intuitively wrestles with Java 1.5 threads as a service to his Thinking in Java readers. As with most popular blogs, the discussion that follows is interesting. A common thought is that despite the power and clarity of the Java 1.5 threading model, the same pitfalls remain.

Multithreaded Applications: asynchrony - a blessing or curse?

We have the power to create a new thread in our code. We create a thread and send it on a mission. Our new thread is J.E.B. Stuart and his task is to find the Union's flank and then to report immediately. Meanwhile the main thread can continue its march towards Washington. At this point, we have two elements operating asynchronously, but eventually the main thread may have to wait for Stuart's report. At this point the strategy begings to unravel, the main thread has to halt its advance and await notification from Stuart.
The wait proceeds, now the main thread may have to choose between retiring from the field or proceeding on to battle. One problem is that the main thread still has a responsibilty to Stuart. Stuart cannot be left orphaned precariously near the Union's lines. In any case Stuart must be ordered to terminate his patrol.
The essence of multithreaded apps is indepence and asynchrony, yet the reality is that lines of communication must be maintained between threads and protocols must be established to handle the situations that will arise.

Synchrony - the beating heart of time

Many of the elements of a threading service are synchronization objects such as Mutexes, Semaphores, Critical Sections, Signals, Events, and Monitors. With a few simple lines of code, we loose a fury upon the world, and then write reams of code trying to control this bastard child. Ultimately the synchronity of single threadedness is revealed as more powerful than the asynchronous multithread. It is the only way to subdue the creature.

Multiprocess or Multithread

Multithreaded programs have been identfied as more performant and more scalable than their multiprocess counterparts. A good example is process spawning web-servers, such as CGI servers, vs. threaded servers such as Mod Perl. One very brilliant blogger whose URL I cannot recall (I will update this blog when I remember), suggests that multiprocess is far more robust than multithreaded. I especially enjoyed his term for hard-to-find multithreaded bugs - "heisen bugs".
However, if one process is dependent on the state of another process, synchronicity issues will exist. What about multimachine distributed systems and such? Message Queue applications are used to synch up the constituents.

In conclusion - good, bad, indifferent or just reality.

It is goodness that programming languages and platforms continue to put a fine point on thier support for multithreaded programs. Yet multithreaded support needs to exist in the viscera of applications that need threads. It is not a problem for language designers, it is a problem for application designers. It is a problem for very experienced application designers.