Re: [pure-lang-users] ANN: Pure 0.6 released

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> Please give us something more disciplined than (p)threads, which are
> nothing but an invitation to make a mess of a concurrent program.

When I talk about pthreads an OpenMP, that's just the implementation. 
The concurrency model presented to the Pure programmer will be something 
entirely different. I'm not going to repeat the mistakes I did with Q. ;-)

> (This assumes that you have already introduced state; threads are fine
> without mutable state.)  I'd prefer fork/join/pipe semantics like Unix
> processes myself, since they are already known to distribute well over
> multiple cores and multiple machines, but I can live with any reasonable
> discipline.

So far, I've been looking at the following models which are known to 
work well in FPLs: Linda (or rather a variation called "concurrent tree 
bags" being used in Aardappel), Erlang-style message passing (but 
without the copying, which will need some special provisions in order to 
get safe but lockless reference counting) and concurrent futures a la 
Alice ML. The latter is especially attractive because it unifies 
concurrency and the lazy futures which Pure already has, but it lacks 
the message passing aspect.

I think that a combination of concurrent futures with message passing 
would be nice to have, and this should be pretty close to the 
fork/join/pipe model you have in mind.

This will still require some kind of synchronization for the impure 
stuff in the library (references, sentries and direct C pointer 
manipulation, as well as eval/str), but this can be handled behind the 
scenes. In any case I want to make sure that purely functional code will 
never need any kind of mutex locking. Lockless synchronization might 
also work for some of the impure features. Of course, the message 
passing channels themselves also need some kind of protection, but if 
possible I will also use a lockfree data structure there.

I'm open to suggestions, so if you know about any other concurrency 
models and/or implementation tricks that might be interesting in this 
context, please let me know.

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag