synchronized (this[.classinfo]) in druntime and phobos

[deadalnix]

Le 01/06/2012 14:52, Alex Rønne Petersen a écrit :
> On 01-06-2012 14:26, deadalnix wrote:
>> Le 31/05/2012 20:17, Andrei Alexandrescu a écrit :
>>> On 5/31/12 5:19 AM, deadalnix wrote:
>>>> The solution consisting in passing a delegate as parameter or as
>>>> template is superior, because it is now clear who is in charge of the
>>>> synchronization, reducing greatly chances of deadlock.
>>>
>>> It can also be a lot clunkier for certain abstractions. Say I want a
>>> ProducerConsumerQueue. It's much more convenient to simply make it a
>>> synchronized class with the classic primitives, instead of primitives
>>> that accept delegates etc.
>>>
>>> Nevertheless I think there's merit in this idea. One thing to point out
>>> is that the idiom can easily be done today with a regular class holding
>>> a synchronized class private member.
>>>
>>> So we got everything we need.
>>>
>>>
>>> Andrei
>>
>> I was thinking about that. Here is what I ended up to think is the best
>> solution :
>>
>> synchronized classes exists. By default, they can't be use as parameter
>> for synchronized(something) .
>>
>> synchronized(something) will be valid is something provide
>> opSynchronized(scope delegate void()) or something similar. Think
>> opApply here. The synchronized statement is rewritten in a call to that
>> delegate.
>>
>> Here are the benefit of such an approach :
>> 1/ Lock and unlock are not exposed. You can only use them by pair.
>> 2/ You cannot lock on any object, so you avoid most liquid locks and
>> don't waste memory.
>> 3/ synchronized classes ensure that a class can be shared and it
>> internal are protected from concurrent access.
>> 4/ It is not possible possible by default to lock on synchronized
>> classes's instances. It grant better control over the lock and it is now
>> clear which piece of code is responsible of it.
>> 5/ The design allow the programmer to grant the permission to lock on
>> synchronized classes's instances if he/she want to.
>> 6/ It is now possible to synchronize on a broader range of user defined
>> stuffs.
>>
>> The main drawback is the same as opApply : return (and break/continue
>> but it is less relevant for opSynchronized). Solution to this problem
>> have been proposed in the past using compiler and stack magic.
>>
>> It open door for stuff like :
>> ReadWriteLock rw;
>> synchronized(rw.read) {
>>
>> }
>>
>> synchronized(rw.write) {
>>
>> }
>>
>> And many types of lock : spin lock, interprocesses locks, semaphores, .
>> .. . And all can be used with the synchronized syntax, and without
>> exposing locking and unlocking primitives.
>>
>> What do people think ?
>
> Your idea is great, but it has one (or arguably many) fundamental flaw,
> the same one that opApply does: The delegate's type is fixed. That is,
> you can't call opSynchronized() in a pure function, for example (same
> goes for nothrow, @safe, ...).
>

I was also thinking about passing the delegate as template parameter but 
wanted to keep design proposal consistent with what already exists. It 
solve some issues.

Maybe opApply have to be modified that way, or, better, both could work.

Anyway, some issue are known and have to be fixed with opApply, and the 
same issue are present here.I did mention that in my proposal. Still, I 
think it is better to have consistent mecanisms in the language, and it 
is no more work to fix that for opApply than to fix that for both 
opApply and opSynchronized .