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

[Regan Heath]

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.

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


R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/