On 31.05.2012 19:11, Steven Schveighoffer wrote:
On Thu, 31 May 2012 10:49:52 -0400, Dmitry Olshansky
<[email protected]> 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 ;)
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).
--
Dmitry Olshansky
