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