1,721,136 research outputs found
Life of occam-Pi
Full text linkThis paper considers some questions prompted by a brief review of the history of computing. Why is programming so hard? Why is concurrency considered an “advanced” subject? What’s the matter with Objects? Where did all the Maths go? In searching for answers, the paper looks at some concerns over fundamental ideas within object orientation (as represented by modern programming languages), before focussing on the concurrency model of communicating processes and its particular expression in the occam family of languages. In that focus, it looks at the history of occam, its underlying philosophy (Ockham’s Razor), its semantic foundation on Hoare’s CSP, its principles of process oriented design and its development over almost three decades into occam-? (which blends in the concurrency dynamics of Milner’s ?-calculus). Also presented will be an urgent need for rationalisation – occam-? is an experiment that has demonstrated significant results, but now needs time to be spent on careful review and implementing the conclusions of that review. Finally, the future is considered. In particular, is there a future
Java Threads in the Light of occam/CSP
Full text linkJava 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
Formal Analysis of Concurrent Java Systems
Full text linkJava threads are synchronised through primitives based upon monitor concepts developed in the early 1970s. The semantics of Java's primitives have only been presented in natural language ? this paper remedies this with a simple and formal CSP model. In view of the dif?culties encountered in reasoning about any non-trivial interactions between Java threads, being able to perform that reasoning in a formal context (where careless errors can be highlighted by mechanical checks) should be a considerable con?dence boost. Further, automated model-checking tools can be used to root out dangerous states (such as deadlock and livelock), ?nd overlooked race hazards and prove equivalence between algorithms (e.g. between optimised and unoptimised
versions). A case study using the CSP model to prove the correctness of the JCSP and CTJ channel implementations (which are built using standard Java monitor synchronisation)
is presented. In addition, the JCSP mechanism for ALTing (i.e. waiting for and, then, choosing between multiple events) is veri?ed. Given the history of erroneous implementations of this key primitive, this is a considerable relief
Cluster Computing and JCSP Networking
Full text linkHoare's algebra of Communicating Sequential Processes (CSP) enables a view of systems as layered networks of concurrent components, generating and responding to events communicated to each other through channels, barriers and other formally defined synchronisation primitives. The resulting image and discipline is close to hardware design and correspondingly easy to visualise, reason about, compose and scale. JCSP is a library of Java packages providing an (occam) extended version of this model that may be used alongside, or as a replacement for, the very different threads-and-monitors concurrency mechanisms built into Java. The current release (JCSP 1.0) supports concurrency within a single Java Virtual Machine (which may be multi-processor). This paper reports early experiments with JCSP.net, an extension of JCSP for the dynamic construction of CSP networks across distributed environments. The aims of JCSP.net are to simplify the construction and programming of dynamically distributed and parallel systems. It provides high-level support for CSP architectures, unifying concurrency logic within and between processors. The experiments are on some classical HPC problems, an area of work for which JCSP.net was not primarily designed. However, low overheads in the supporting infrastructure were a primary consideration - along with an intuitive and high-level distributed programming model (based on CSP). Results reported show JCSP holding up well against - and often exceeding - the performance obtained from existing tools such as mpiJava and IBM's TSpaces. The experimental platform was a cluster of 16 dual-processor PIII Linux machines. It is expected that future optimisations in the pipeline for the JCSP.net infrastructure will improve the results presented here. JCSP and JCSP.net were developed at the University of Kent
Using Java for Parallel Computing: JCSP versus CTJ
Full text linkJava provides support for concurrent and parallel programming through threads, monitors and its socket and Remote Method Invocation (RMI) classes. However, there have been many concerns expressed about the way in which this support is provided, e.g., [1][2], citing problems such as improper implementation of monitors and difficulty of programming with threads. Hoare’s Communicating Sequential Processes (CSP) [3][4][5] model fully specifies thread synchronization and is based on processes, compositions, and channel communication. It provides a mathematical notation for describing patterns of communication using algebraic expressions and contains formal proofs for analyzing, verifying and eliminating undesirable conditions, such as race hazards, deadlocks, livelock, and starvation. Two independent research efforts provide a CSP based process-oriented design pattern for concurrency implemented in Java: Communicating Sequential Processes for Java (JCSP) [6] and Communication Threads in Java (CTJ) [7]. In this paper, we compare these two packages, looking at the philosophy behind their development,
their similarities, their differences, their performance, and their use
- …
