[dmd-concurrency] CSP: Communicating sequential processes

[Robert Jacques]

On Wed, 20 Jan 2010 10:48:57 -0500, Robert Jacques <sandford at jhu.edu>  
wrote:

> 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.

But, since the reader lock would only be called from const functions,  
there would never be a situation where you'd want to upgrade a reader lock  
to a writer lock. The only issue would be writer locks trying to take a  
reader or a second writer lock. Or am I missing something?