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

[deadalnix]

Le 30/05/2012 17:46, Andrei Alexandrescu a écrit :
> On 5/30/12 2:34 AM, deadalnix wrote:
>> Le 29/05/2012 23:33, Andrei Alexandrescu a écrit :
>>> On 5/29/12 1:37 AM, deadalnix wrote:
>>>> I would say that breaking things here, with the right deprecation
>>>> process, is the way to go.
>>>
>>> So what should we use for mutex-based synchronization if we deprecate
>>> synchronized classes?
>>>
>>> Andrei
>>
>> I think something similar to range design here is the way to go.
>>
>> It is easy to define something like
>>
>> template isLockable(T) {
>> enum isLockable = isShared!T && is(typeof(T.init.lock())) &&
>> is(typeof(T.init.release()));
>> }
>>
>> And allow locking only if(isLockable!Type) .
>>
>> Now we can create SyncObject or any structure we want. The point is that
>> we lock explicit stuff.
>
> But in this design anyone can lock such an object, which was something
> you advocated against.
>
> Andrei

I was advocating on being able to lock ANY object, which is out of control.

Such an object is known to be lockable, and most object will not be. It 
will avoid liquid lock, because most thing will not be lockable.

Combined with encapsulation capabilities that D already have, exposing 
the lock to the entire worlds is easy. It will avoid unexpected lock 
from 3rd party code, which is a source of tedious deadlock.

It also open door for locking on struct, that is easily embeded in a 
class as value (so constructed and destructed with the class).

The fact that anyone or not can lock/unlock a mutex is a encapsulation 
problem and we already have solution in D for that.