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

[Alex Rønne Petersen]

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

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org