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

[Alex Rønne Petersen]

On 30-05-2012 18:42, Iain Buclaw wrote:
> 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

I use it in my source base currently to implement weak references.

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