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

[Iain Buclaw]

On 30 May 2012 17:23, Alex Rønne Petersen <alex at lycus.org> wrote:
> On 30-05-2012 18:14, Andrei Alexandrescu wrote:
>>
>> 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?
>
>
> Generally in two ways:
>
> 1) synchronized (obj)
> 2) obj.__monitor
>
> (1) accesses it in order to actually do locking, but if obj is an
> instantiation of a class that uses the this reference internally for
> locking, you end up with potential deadlocks. Therefore, you can say that
> obj's mutex is exposed. This isn't necessarily bad, because if obj does
> *not* use its this reference for synchronized statements, nothing will blow
> up. This is why the OP was about banning synchronized (this).
>
> (2) is an undocumented feature of the language that druntime (and maybe some
> phobos code) makes use of to create/alter/delete monitors.
>

I'm pretty certain the use of .__monitor is stricted only to:
object_.d - The frontend implementation which contains the underlying
functions that are invoked when you synchronise(obj).
monitor_.d - The backend implementation which contains the platform
separated bits.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';