[dmd-concurrency] CSP: Communicating sequential processes

[Robert Jacques]

On Wed, 20 Jan 2010 07:14:44 -0500, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> Le 2010-01-20 à 2:53, Robert Jacques a écrit :
>
>> 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.
>
> I think read/write lock usage should only be used explicitly.
>
> That's because you can never upgrade "safely" from a read lock to a  
> write lock, or to be precise there is always a risk that you must  
> release your read lock before upgrading. Two threads could acquire a  
> read lock and then both might want to upgrade to a write lock, which  
> can't be satisfied without one of them dropping its read lock first.
>
> If the read lock drops because you call another function that wants a  
> write lock, this could be trouble. Upgrades work well when there is only  
> one thread requesting upgrades. Otherwise the upgrade must be seen as a  
> drop-read-lock then acquire-write-lock non-atomic operation.
>

Ah, the composability problem. Thanks for explaining.