[dmd-concurrency] CSP: Communicating sequential processes

[Robert Jacques]

On Wed, 20 Jan 2010 12:05:27 -0500, Michel Fortin  
<michel.fortin at michelf.com> wrote:
> Le 2010-01-20 à 10:57, Robert Jacques a écrit :
>
>>>> 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?
>
> A const function only makes the "this" reference const. Accessing the  
> same objects through other references (such as a global or an argument)  
> could cause non-const functions to be called on that same object, which  
> could require a write lock even when calling a const function.
>
> Pure functions are safe of course, but that's too restricting to be  
> really useful.

Good point. Although, I'm tempted to say that any const function that  
results in mutation is a program logic error and therefore a deadlock may  
actually be desired behavior. Anyways, I thought of something else which  
throws a spanner into the work. Lock-regions, i.e. ownership regions,  
could protect multiple objects and the entire region would never be  
entirely const. So definitely no-go as a default. Still might a good  
option to have if we can find a good recursive CREW lock.