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

[Dmitry Olshansky]

On 31.05.2012 20:54, Regan Heath wrote:

>> No way! I live in world where victim's hand is cut off as a punishment
>> for mutating a lock after creation ;)
>
> This is related to the "liquid lock" problem raised/mentioned elsewhere
> in the thread. If the reference you lock can change, then one
> thread/iteration may lock one instance, the lock instance mutates, and a
> 2nd thread/iteration locks the new instance and both execute more or
> less in parallel over code which was supposed to be serialized. It's not
> a problem if the lock object is the object being mutated/used by the
> code, but it is a problem if the lock object is protecting other shared
> objects. It's not something I have ever bumped into myself, because the
> bulk of my locking experience is in C/C++ and I use a locking primitive
> which is initialised once and never mutates.
>

Yup, C/C++, locking only special OS provided stuff, it's my background 
exactly.

>>> You *never* want the ordering to change.
>>>
>>> But I think we can probably work that out. What about comparing handles
>>> of the mutexes? So you sort based on some property __mutex_id() which
>>> must return a unique size_t that can be used to always define an
>>> ordering of locking mutexes? Most mutexes are allocated by the OS, and
>>> so their handles won't be affected by a moving GC, so you likely will
>>> use the handle value.
>>>
>>
>> This could work. In fact I imagined comparing handles ...
>> As with math at large you may either project (biject) your domain to a
>> well-known one (like numbers, mutex_id in your case) and work with it
>> or define all relevant properties for whatever your values in this
>> domain are (providing custom ordering for user defined types).
>
> This ordering idea is present in TDPL.. have you both read the link
> Andrei posted?
> http://goo.gl/ZhPM2
> (see 13.15)
>
>

Yes, in fact I was going by TDPL. I just propose to extend it to 
entities other then class instances ( more specifically only those with 
__lock/__unlock ).

-- 
Dmitry Olshansky