On Thu, 31 May 2012 12:54:07 -0400, Regan Heath <re...@netmail.co.nz>
wrote:
On Thu, 31 May 2012 16:23:29 +0100, Dmitry Olshansky
<dmitry.o...@gmail.com> wrote:
On 31.05.2012 19:11, Steven Schveighoffer wrote:
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);
}
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.
Well, I thought the original proposal was to use the opCmp of the *data*,
i.e. the object being protected. At least that's what it seems like from
the example.
Apologies if this was not the case.
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)
No, I haven't read it yet. I did review an early version of TDPL, but I
have not re-read the released version (though I do have a copy). Whether
it was in there or not, it's been a while :)
-Steve
