[dmd-concurrency] CSP: Communicating sequential processes

[Robert Jacques]

On Wed, 20 Jan 2010 02:07:53 -0500, Sean Kelly <sean at invisibleduck.org>  
wrote:
> On Jan 19, 2010, at 10:00 PM, Robert Jacques wrote:
>
>> Communicating sequential processes and pi calculus are one of the other  
>> major schools of message passing. There's been some interest in it, so  
>> I'm digging out and summarizing some old notes of mine. I view  
>> implementing CSP as a good use case for D's message passing  
>> architecture; i.e. one should be able to write a CSP library and have  
>> it compose gracefully with other concurrent libraries. Most of the  
>> active research in this area is being done by the University of Kent  
>> (http://www.cs.kent.ac.uk/projects/ofa/kroc/).
>
> Thanks for all the info!

Your welcome. I hope it helps.

>> An aside: I ran across CREW (Concurrent read, exclusive write) locks  
>> again while making this. These have always seemed perfect for D as it  
>> has both const and shared/synchronized method modifiers. I don't think  
>> there's any blockers for implementing this, so should I file a bugzilla  
>> enhancement request, so it gets onto the big long todo list?
>
> Is what you want in core.sync.rwmutex?  You can use it as:
>
> synchronized( mut.reader ) {}
> synchronized( mut.writer ) {}
>
> It doesn't currently allow upgrading read locks to write locks, though I  
> think this wouldn't be difficult to add.  More importantly I suppose is  
> that acquiring a concurrent read lock may be more expensive than you'd  
> expect, so you really only want to use a ReadWriteMutex if the read  
> operations take a reasonable amount of time to complete.

Sort of; I was thinking about implicit use and not explicit use; i.e.  
const functions would take a reader lock and non-const function would take  
a writer lock. Generally, I've heard reports that CREW locks give big  
performance boosts in certain domains (game programming, for instance),  
but I don't know exactly the real performance trade-off compare to normal  
locks under low contention. Still, it would be nice to be able to replace  
an object's mutex with a rwmutex and have it work right.