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

[Dmitry Olshansky]

On 01.06.2012 16:26, deadalnix wrote:
>  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 ?

+1. Works for me.

It refines what I believe the shadow cabinet (loosely: me, you, Alex, 
Regan Heath and Steven) propose.

P.S. Removing monitor from non-synced/shared classes would be good too. 
As a separate matter.

-- 
Dmitry Olshansky