db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
@InProceedings{BakkersStiles99,
  title =        "{CSP} for {J}ava: {M}ultithreading for {A}ll",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  author=        "Bakkers,  Andr\`{e} W. P. and Stiles,  G. S. and Welch, Peter H. and Hilderink,  Gerald H.",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  editor=        "Cook,  Barry M.",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  pages =        "277--279",
  booktitle=     "{P}roceedings of {W}o{TUG}-22: {A}rchitectures, {L}anguages and {T}echniques for {C}oncurrent {S}ystems",
  isbn=          "90 5199 480 X",
  year=          "1999",
  month=         "mar",
  abstract=      "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: \&amp;quot;Liveness considerations in concurrent
     software development introduce context dependencies that can
     make the construction of reusable components harder than in
     strictly sequential settings.\&amp;quot; Two approaches he
     suggests for design sound tedious and perhaps risky:
     \&amp;quot;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...\&amp;quot;
     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
     \&amp;quot;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\'t necessary for
     strictly GUI work, such as updating component
     properties\&amp;quot; [2]. Oaks and Wong [3], also
     associated with Sun, are more positive, but note that
     \&amp;quot;Deadlock between threads competing for the same
     set of locks is the hardest problem to solve in any threaded
     program. It\'s a hard enough problem, in fact, that we will
     not solve it or even attempt to solve it.\&amp;quot; Later
     they state \&amp;quot;Nonetheless, a close examination of
     the source code is the only option presently available to
     determine if deadlock is a possibility...\&amp;quot; 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."
}