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

[Steven Schveighoffer]

On Thu, 31 May 2012 12:54:07 -0400, Regan Heath <regan at netmail.co.nz>  
wrote:

> On Thu, 31 May 2012 16:23:29 +0100, Dmitry Olshansky  
> <dmitry.olsh at gmail.com> wrote:
>
>> On 31.05.2012 19:11, Steven Schveighoffer wrote:
>>> On Thu, 31 May 2012 10:49:52 -0400, Dmitry Olshansky
>>> <dmitry.olsh at gmail.com> wrote:
>>>> OK let me land you a hand here. My proposal, that I think fits your
>>>> ideas quite favorably.
>>>
>>> [snip]
>>>
>>>> Does it makes sense?
>>>
>>> Everything but the ordering. I like the idea of ordering the locks  
>>> based
>>> on an intrinsic value, but opCmp isn't it. Objects can mutate, and  
>>> opCmp
>>> may produce different results. Imagine:
>>>
>>> synchronized(a, b) // at this point a < b
>>> {
>>> a.makeGreaterThan(b);
>>> assert(a > b);
>>> }
>>>
>>
>> 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.

Well, I thought the original proposal was to use the opCmp of the *data*,  
i.e. the object being protected.  At least that's what it seems like from  
the example.

Apologies if this was not the case.

>>> 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)

No, I haven't read it yet.  I did review an early version of TDPL, but I  
have not re-read the released version (though I do have a copy).  Whether  
it was in there or not, it's been a while :)

-Steve