JCSP
 | The topic of this article may not meet Wikipedia's general notability guideline. (November 2014) |
JCSP is an implementation of communicating sequential processes (CSP) for the programming language Java.[1]
Although CSP is a mathematical system, JCSP does not require in-depth mathematical skill, allowing instead that programmers can achieve well-behaved software by following simple rules.
Overview
[edit]There are four ways in which multi-threaded programs can fail untestably:[1]
- Race conditions – shared variables may have indeterminate state because several threads access them concurrently without sufficient locking
- Deadlock – two or more threads reach a stalemate when they try to acquire locks or other resources in a conflicting way
- Livelock – similar to deadlock but resulting in endless waste of CPU time
- Starvation – one or more threads do no work, compromising the intended outcome of the software algorithms
Generally, it is not possible to prove the absence of these four hazards merely by rigorous testing. Although rigorous testing is necessary, it is not sufficient. Instead it is necessary to have a design that can demonstrate these four hazards don't exist. CSP allows this to be done using mathematics and JCSP allows it to be done pragmatically in Java programs.
The benefit of the basis in mathematics is that stronger guarantees of correct behaviour can be produced than would be possible with conventional ad hoc development. Fortunately, JCSP does not force its users to adopt a mathematical approach themselves, but allows them to benefit from the mathematics that underpins the library.
Note that the CSP term process is used essentially as a synonym for thread in Java parlance; a process in CSP is a lightweight unit of execution that interacts with the outside world via events and is an active component that encapsulates the data structures on which it operates.
Because the encapsulation of data is per-thread (per process in CSP parlance), there is typically no reliance on sharing data between threads. Instead, the coupling between threads happens via well-defined communication points and rendezvous. The benefit is that each thread can broadly be considered to be a "single-threaded" entity during its design, sparing the developer from the uncertainties of whether and where to use Java's synchronized keyword, and at the same time guaranteeing freedom from race conditions. JCSP provides for clear principles for designing the inter-thread communication in a way that is provably free from deadlock.
There is a clear similarity between some classes in the standard Java API (java.util.concurrent) and some in JCSP. JCSP's channel classes are similar to the BlockingQueue. There is one important difference: JCSP also provides an Alternative class to allow selection between inputs; this capability is absent from the standard Java API. Alternation is one of the core concepts that CSP uses to model events in the real world.
Alternative was proven to operate correctly by exhaustive mathematical analysis of its state space, guaranteeing it can never in itself cause a deadlock.[2] As such, it epitomises the dependability of JCSP from its mathematical basis.
Networking Layer
[edit]Because Transmission Control Protocol (TCP) sockets can be constructed to behave as blocking channels in the CSP sense, it is possible to distribute JCSP processes across multiple computers. This is achieved using the JCSP Net extension that provides channels with CSP semantics using TCP. Because CSP is compositional, it does not matter in behaviour terms whether processes are co-located or distributed. The only difference is in the relative performance. So it is possible, for example, to develop an application on a single server then compare multi-processor version of the same application with the aim of optimising the performance.
Other versions
[edit]Robot edition
[edit]JCSP re is a highly reduced version of the JCSP packages developed around 2008 at the Napier University Edinburgh by Professor Jon Kerridge, Alex Panayotopoulos and Patrick Lismore. Research into JCSP for robotics environments and JCSP for mobile environments is an active area of research at Napier University Edinburgh. The working implementation of 'JCSP re' allows the development of the same concurrent software for robots. Specifically, the robots targeted for this research were the Lego Mindstorms NXTs because they can run the popular LeJOS NXJ virtual machine that executes Java source code.[3]
Using JCSP from other languages
[edit]JCSP is essentially a pure-Java API (although a research alternative exists that uses the C-CSP extension to the JVM). As such, it is in principle eminently suitable for concurrency in Scala and Groovy applications as well as Java ones.
JCSP can therefore provide an alternative to Scala's actor model. JCSP uses synchronised communication and actors use buffered (asynchronous) communication, each of which have their advantages in certain circumstances. JCSP allows its channels to be buffered so can easily emulate the actor model; the converse is not true.
See also
[edit]- Communicating sequential processes, the mathematics underlying JCSP
References
[edit]- ^ a b Belapurkar, Abhijit (21 June 2005). "CSP for Java programmers". IBM DeveloperWorks. Retrieved 2007-04-20.
- ^ Welch, Peter; Martin, Jeremy (2000). Formal Analysis of Concurrent Java Systems. Communicating Process Architectures 2000 (Report).
- ^ Jon Kerridge; Alex Panayotopoulos; Patrick Lismore (2008). "JCSPre: the Robot Edition to Control LEGO NXT Robots". Concurrent Systems Engineering Series Volume 66: Communicating Process Architectures 2008. IOS Press Books: 255–270. doi:10.3233/978-1-58603-907-3-255. Archived from the original on 2010-04-18.
{{cite journal}}: CS1 maint: bot: original URL status unknown (link)
External links
[edit]- JCSP project at the University of Kent
- JCSP re[permanent dead link] early beta release