On 31.05.2012 20:54, Regan Heath wrote:
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.
Yup, C/C++, locking only special OS provided stuff, it's my background
exactly.
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)
Yes, in fact I was going by TDPL. I just propose to extend it to
entities other then class instances ( more specifically only those with
__lock/__unlock ).
--
Dmitry Olshansky
