db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"
%T CSP for Java: Multithreading for All db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"
%A Andr\[`e] W. P. Bakkers, G. S. Stiles, Peter H. Welch, Gerald H. Hilderink db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"
%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.