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): http://www.occam-pi.org/ http://www.cosmos-research.org/ (millions of processes) http://www.cs.york.ac.uk/CPA08/programme.html (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: http://www.cs.kent.ac.uk/projects/ofa/jcsp/ Cheers, Peter. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
