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

[Alex Rønne Petersen]

On 30-05-2012 19:19, Andrei Alexandrescu wrote:
> 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.

I have to confess to this as well. I'm starting to suspect that he 
really means deadlock. Searching on Google for "liquid lock mutex" 
literally brings up this very NG thread. :)

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

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