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

Steven Schveighoffer schveiguy at yahoo.com
Thu May 31 08:11:07 PDT 2012


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

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.

-Steve


More information about the Digitalmars-d mailing list