commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "P.H.Welch" <>
Subject Re: [lang] Concurrency utils for JDK 1.5+ version
Date Sun, 25 Jan 2009 16:33:03 GMT

Hi Russel,

> At the heart of all the problems is shared memory.  Perhaps it is worth
> challenging the use of shared memory models for application programming;
> perhaps it is worth building new APIs that avoid shared memory in order
> to make application that exploit parallelism easier for the average
> programmer to write.
> I am here thinking about CSP-based models:  separate processes each with
> their own memory and communicating via message passing.


CSP also gives us easy ways of synchronising access to shared resources,
including passive shared memory, without using locks.  Channel
communication is only one form of higher-level concept built from
the abstract concept of CSP events.  Another is phased access, like
time-division multiplexing ... but with the phases marked by barrier
events (multiway syncs) that all processes engaged in the phased
access have in their alphabets.

> Erlang has shown that parallel applications can be written that do not
> suffer unexpected deadlock and livelock.  Also it shows that you can
> build an efficient process-based system on a shared memory
> multi-threaded system -- not surprising really.

I should hope so!!  There's (2+) decades of experience reflecting this,
backed up by parallel design rules with formal proofs of good behaviour
... for example, all those industrial Transputer-based projects using
occam ... and now, occam-pi (= occam2 + pi-calculus dynamics):                 (millions of processes)   (CPA09, Nov, Eindhoven)

> So rather than trying to tinker round the edges of JSR166, JSR166y,
> java.util.concurrent, might it be better to create a whole new API to
> allow much easier programming of parallel applications.  This could be
> done as a JSR or just done as an Apache project.
> A lot of the ground work on CSP and Java has already been done by Peter
> Welch and his group at University of Kent.

:)  See:



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message