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

[Andrei Alexandrescu]

On 5/30/12 9:03 AM, Regan Heath wrote:
> On Wed, 30 May 2012 16:46:54 +0100, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> 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.
>
> I think there is some confusion here as to what the "problem" is and is
> not.
>
> The problem is /not/ that you can lock any object.
> The problem is /not/ that we have synchronized(object) {}
> The problem is /not/ that we have synchronized classes/methods.

Several posts in this thread assert that such are problems.

> The problem /is/ that synchronized classes/methods use a mutex which is
> exposed publicly, and it the same mutex as used by synchronized(object)
> {}. This exposure/re-use makes deadlocks more likely to happen, and
> harder to spot.

This is news to me. How do you publicly access the mutex of a 
synchronized class object?


Andrei