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

Alex Rønne Petersen alex at lycus.org
Wed May 30 09:23:43 PDT 2012


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.

>
>
> Andrei
>

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


More information about the Digitalmars-d mailing list