Paper Details

%T CSP for Java: Multithreading for All
%A André W. P. Bakkers, G. S. Stiles, Peter H. Welch, Gerald H. Hilderink
%E Barry M. Cook
%B Proceedings of WoTUG\-22: Architectures, Languages and Techniques for Concurrent Systems
%X Many internet, real\-time and embedded applications are most
   naturally designed using concurrency. Unfortunately, the
   design of concurrent (multithreaded) programs has the
   reputation of being extremely difficult and dangerous, due
   to the possibility of deadlock, livelock, race hazards, or
   starvation \- phenomena not encountered in single\-threaded
   programs. Lea [1] emphasizes concern for the apparent
   difficulty: "Liveness considerations in concurrent
   software development introduce context dependencies that can
   make the construction of reusable components harder than in
   strictly sequential settings." Two approaches he
   suggests for design sound tedious and perhaps risky:
   "Top\-down (safety first): Initially design methods
   and classes assuming full synchronization (when applicable),
   and then remove unnecessary synchronization as needed to
   obtain liveness and efficiency...Bottom up (liveness first):
   Initially design methods and classes without concern for
   synchronization policies, then add them via composites,
   subclassing, and related layering techniques..."
   Both suggest lengthy sessions of patching and testing until
   the application appears to work as desired. Even those
   intimately connected with Java seem reluctant to employ more
   than a single thread. The Swing documentation states
   "If you can get away with it, avoid using threads.
   Threads can be difficult to use, and they make programs
   harder to debug. In general, they just aren\\[rs]t necessary
   for strictly GUI work, such as updating component
   properties" [2]. Oaks and Wong [3], also associated
   with Sun, are more positive, but note that
   "Deadlock between threads competing for the same
   set of locks is the hardest problem to solve in any threaded
   program. It\\[rs]s a hard enough problem, in fact, that we
   will not solve it or even attempt to solve it."
   Later they state "Nonetheless, a close examination
   of the source code is the only option presently available to
   determine if deadlock is a possibility..." and add
   that no tools exist for detecting deadlock in Java
   programs. We feel, however, based on fifteen years of
   experience, that concurrent approaches are the best way to
   design most programs. Done properly (e.g., using CSP [4])
   this results in better understanding of the problem and the
   solution, and leads to much cleaner implementations. A
   tremendous amount of work has been done on and with CSP in
   recent years, and the present state of the language and the
   tools offers the Java programmer excellent facilities for
   the design and analysis of multithreaded programs.
   Furthermore, Java designs based on CSP class libraries can
   now be verified against formal specifications and checked
   for deadlock and livelock with CASE tools \- prior to
   implementation. We present the CSP model (processes,
   channels, events, networks) and its binding into (100% Pure)
   Java through the CSP class libraries developed at Kent [5]
   and Twente [6]. We describe some of the tools associated
   with CSP (e.g., FDR [7]) and demonstrate, in several
   practical applications, their use for checking
   specifications and proving the absence of deadlock. We
   emphasize that CSP concepts are easy to understand and apply
   and that the engineering benefits they confer on system
   design and implementation are significant for both
   real\-time and non\-real\-time multithreaded systems.

If you have any comments on this database, including inaccuracies, requests to remove or add information, or suggestions for improvement, the WoTUG web team are happy to hear of them. We will do our best to resolve problems to everyone's satisfaction.

Copyright for the papers presented in this database normally resides with the authors; please contact them directly for more information. Addresses are normally presented in the full paper.