Java threads in the light of occam/CSP

Java provides support for parallel computing through a model that is built into the language itself. However, the designers of Java chose to be fairly conservative and settled for the concepts of threads and monitors. Monitors were developed by Tony Hoare (and others) in the early 1970s as a structured way of using semaphores to control access to shared resources. Hoare moved away from this, in the late 1970s, to develop the theory of Communicating Sequential Processes (CSP). One reason was that the semantics of monitors are not WYSIWYG, so that designing robust parallel algorithms at this level is seriously hard. This tutorial will look at how this impacts on threaded applications written in Java. Fortunately, it is possible to introduce the CSP model into Java through sets of classes implemented on top of its monitor support. By restricting interaction between active Java objects to CSP synchronisation primitives, Java thread semantics become compositional and systems with arbitrary levels of complexity become possible. Multi-threadedWeb applets and distributed applications become simpler to design and implement, race hazards never occur, difficulties such as starvation, deadlock and livelock are easier to confront and overcome; and performance is no worse than that obtained from directly using the raw monitor primitives. The advantages of teaching parallelism in Java purely through the CSP class librarieswill be discussed. These libraries were developed jointly at Kent and Oxford Universities in the U.K. and the University of Twente in the Netherlands. This paper was developed from material first presented at the Java Threads Workshop [1]. It presents the basic threads model of Java, discusses why they may be a good thing but why they need special care in their management, runs through the monitor mechanisms provided in Java for their control and points out weaknesses in that control. Finally, the CSP primitives are introduced and the case for ignoring the monitor methods presented. This work is one of the foundation stones of the JavaPP project [2], which spun out from the above workshop. The other founding stones [3, 4, 5, 6] were first presented at the WoTUG-20 conference last year.