On Thu, 31 May 2012 10:49:52 -0400, Dmitry Olshansky
<dmitry.o...@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
