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

[Andrei Alexandrescu]

On 5/30/12 9:56 AM, deadalnix wrote:
> 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.

Must've been another poster. Anyhow, in TDPL's design only synchronized 
classes can be used with the synchronized statement.

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

I'm celebrating day 2 of having no idea what a liquid lock is.

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

... which can be used with synchronized classes.


Andrei