Groovy Parallel Patterns (gpp)
copyright 2015 Jon Kerridge Edinburgh Napier University
contact j dot kerridge at napier dot ac dot uk
This library creates a number of re-usable parallel design patterns based on the use of Communicating Process Architectures (CPA).
Typically, CPA use communications concepts as described by Hoare in his 1978 ACM Paper entitled Communicating Sequential Processes (CSP). The great advantage of this theory is that we are able to build parallel system about which we can reason and more specifically can analyse a processes network for deadlock and livelock freedom BEFORE it is executed. In addition, we can refine one parallel solution into another one and then reason that the behaviour of both designs is the same.
This project uses the JVM based Groovy scripting language and builds upon the JCSP Library developed by the University of Kent together with some additional Groovy helper Classes described in my books Using Concurrency and Parallelism Effectively (parts 1 and 2), available for free download from bookboon.com. A search for 'bookboon kerridge' is by far the quickest way of locating the source texts.
The example source code is available from https://bitbucket.org/jkerridge/ucape-examples
The goal is to create a number of basic processes that can be used to implement typical components of a parallel system. These are then combined into Parallel Design Patterns that create commonly used solution architectures.
The underlying processes can be used either in multi-core solutions or on clusters with no change to the process and pattern definitions. All that is required is that the patterns are invoked in a different manner depending on the architecture used for deployment. All the processes have been designed to terminate cleanly at the end of execution so that computing resources can be cleanly recovered and thus reused without any special intervention.
The hope is that programmers will then be able to use the supplied processes to build yet further application networks.
The design goal has been to construct data objects that contain no parallel content at all and that are solely derived from the needs of the application.
The programmer can use the the patterns with no underlying understanding of, nor the need to program any communication between any of the processes. The only concern of the programmer is to create the required communication channels for the resulting process network. This can be easily achieved by creating a diagram of the network and transforming that into the required code.