Paper Details

@InProceedings{BakkersStiles99,
  title = "{CSP} for {J}ava: {M}ultithreading for {A}ll",
  author= "Bakkers, Andr\`{e} W. P. and Stiles, G. S. and Welch, Peter H. and Hilderink, Gerald H.",
  editor= "Cook, Barry M.",
  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: \"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\'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\'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.