Projects

python-csp

Implementation of Communicating Sequential Processes on top of Python.

pycsp

The PyCSP project is an on-going project to bring CSP (Communicating Sequential Processes) to Python. It was started in 2006 and has been updated about every three month. Bug reports and suggestions for new features are most welcome. Example: import sys from pycsp import * @process def ... [More] source(chan_out): for i in range(10): chan_out("Hello world (%d)\n" % (i)) retire(chan_out) @process def sink(chan_in): while True: sys.stdout.write(chan_in()) chan = Channel() Parallel( 5 * source(-chan), 5 * sink(+chan) ) For a short introduction read this. A more complete documentation of all elements can be found here Related publications: Vinter, Brian ; Bjørndalen, John Markus ; Friborg, Rune Møllegaard. PyCSP Revisited. Communicating Process Architectures 2009 : WoTUG-32, Proceedings of the 32st WoTUG Technical Meeting (CPA-09). Eindhoven, The Netherlands. Friborg, Rune Møllegaard ; Bjørndalen, John Markus ; Vinter, Brian. Three Unique Implementations of Processes for PyCSP. Communicating Process Architectures 2009 : WoTUG-32, Proceedings of the 32st WoTUG Technical Meeting (CPA-09). Eindhoven, The Netherlands. Friborg, Rune Møllegaard ; Vinter, Brian. CSPBuilder - CSP based Scientific Workflow Modelling. Communicating Process Architectures 2008 : WoTUG-31, Proceedings of the 31st WoTUG Technical Meeting (CPA-08). York, UK. Bjørndalen, John Markus ; Sampson, Adam T. Process-Oriented Collective Operations. Communicating Process Architectures 2008 : WoTUG-31, Proceedings of the 31st WoTUG Technical Meeting (CPA-08). York, UK. Bjørndalen, John Markus ; Vinter, Brian ; Anshus, Otto. PyCSP - Communicating Sequential Processes for Python. Communicating Process Architectures 2007 : WoTUG-30, Proceedings of the 30st WoTUG Technical Meeting (CPA-07). Surrey, UK. [Less]

ChanL

ChanL is a portable library for easy thread-based synchronous concurrency. ChanL uses channels as primitives for thread communication, and includes a thread pool implementation. It is designed with efficiency, portability, and ease-of-use in mind.

cspbuilder

We introduce a framework for building CSP based applications, targeted for clusters and next generation CPU designs. CPUs are produced with several cores today and every future CPU generation will feature increasingly more cores, resulting in a requirement for concurrency that has not previously ... [More] been called for. The framework is CSP presented as a scientific workflow model, specialized for scientific computing applications. The purpose of the framework is to enable scientists to exploit large parallel computation resources, which has previously been hard due of the difficulty of concurrent programming using threads and locks. The framework is implemented in Python and uses the PyCSP library to handle the execution of CSP networks. Get PyCSP here: http://code.google.com/p/pycsp/ Information on CSP: http://www.wotug.org/csp.shtml [Less]

acpj

The ACP project is an attempt to bring together three ideas into a coherent library for developing concurrent applications in Java. Note that bringing these concepts together enhances the ability of each model to assist the developer in writing concurrent applications, the details of this synergy ... [More] are outlined below. Actors provide lightweight processes in a similar way to Erlang and Scala. Channels provide communication paths connecting Actors. Ports provide the mechanism to control access to channels. With the growing understanding that the next major move in application programming is to take advantage of the new multi-core world we live in where even the most basic computer these days has a multi-core CPU and possibly even a heterogeneous processor environment where the programmer can take advantage of both CPU and GPU. The rise in interest of languages such as Erlang that provides a coherent model for developing safe concurrent software, the addition to the Scala language of an actor model based on Erlang shows how this trend is spreading out in both understanding and implementation. In looking at how processes communicate we know that the use of low-level primitives such as Threads, Semaphores, Locks and Monitors are error-prone and hard to verify. To this end Erlang supports the notion that every actor has a mailbox that other actors can write to and the owning actor can read from. This simple concurrency model is extremely valuable but can be cumbersome in modeling some real-world problems where communication is not point-to-point. In this way the Communicating Sequential Processes (CSP) model is in many ways superior as it provides a formal and concrete formalism with a set of useful abstractions for communication such as the one-to-one, one-to-any, any-to-one and any-to-any channels along with the notion of channel buffering (or not), channel poisoning and more. However, in many implementations of CSP abstract notions into Java (and other languages) tend to focus on the implementation of the channel itself and simply provide methods on the channel to get a reader and/or writer for the processes involved to send and receive messages. The issue is that many systems need additional control over the access to a channel, and while stating that a channel is one-to-one is useful in disallowing multiple processes to write to the same channel we might want to be able to limit the number of messages allowed to be sent or by whom. In the Mach kernel all IPC takes place using Ports, where a Port in this context is akin to a CSP any-to-one buffered channel. The key is that ports, or rather port rights can be passed around a network, so I can send you, via one port, a port right to another port allowing you to now send to or receive from that port. Another key notion in Mach is that one of these port rights is SEND_ONCE which restricts a write port to only ever sending a single message, this is particularly useful in developing callback scenarios. To this end the ACP/J library brings together these three ideas and blends them into a coherent set of abstractions so that the strengths of each can be enhanced by the others. In particular we introduce the notion of Port as the concrete realization of the channel end-point abstraction and provide separate implementations for ReadPort and WritePort, but common capabilities in terms of port rights in terms of providing message limits and ownership of ports. [Less]

luacsp

Hoare's "concurent sequentional processes" in Lua csp.lua Lua CSP Library, cooperative threading made with Lua coroutines test_csp_neqsqueak.lua Newsqueak code from Rob Pike's lecture translated to Lua test_csp_wires.lua Labview-like dataflow in Lua

taskgraph

taskgraph is a Java framework for concurrent programming intended to provide fast and scalable performance, with client code that is understandable, predictable and deterministic. To that end, taskgraph uses a technique similar to UNIX pipelined processes, Communicating Sequential Processes ... [More] (CSP), and Kahn Process Networks (PN), for which we use the term dataflow. In taskgraph, processes are Java modules, called tasks, implemented as classes. Like CSP and PN, tasks communicate through channels forming directed graphs. And like UNIX pipes, channels are buffered and have blocking read and write calls. Check out the Terminology page for terms that may have a particular meaning within this project. For a critique of the Multi-Threading Model, see: The Problem with Threads, by Edward A. Lee For a critique of Java Threads, see: Java's Insecure Parallelism, by Per Brinch Hansen Project Status 10/03/09 The SDK Release 1.0 is now available. It includes: The API binaries Supporting libraries Javadoc files The API Java sources Sample programs Java 1.6 or later is required to build and run the framework. [Less]