Re: Removing the assignable requirement from stl list elements
Denise Kleingeist wrote:
{ shouldn't this discussion be taken to comp.programming.threads?
it seems to be going off on a tangent here. please bring it back
to discussing C++. thanks! -mod }
Well, I'll just answer her simple question.
Hello James!
kanze wrote:
Check what? For deadlocks? How? At the very least you'd need
to lock a mutex for this first (otherwise any other thread
might come along and just create the deadlock you are
determining does not exist) which might create the deadlock in
the first place.
How can this lock create a deadlock?
I'm relatively clueless about multi-threading thus I may be utterly
wrong. However, from my limited understanding I don't think I am. Here
is the situation creating a dead-lock:
- There are three mutexes MA, MB, and MC in addition to the
check mutex MM.
- There are two threads TA and TB, each already holding one
mutex: TA holds MA, TB hold MB.
- TA wants to lock MB, currently held by TB, in addition to
MA. To do so, it locks MM and verifies that there is no
potential of a deadlock: TB is not trying to lock MA. Thus, TA
can go ahead and try locking MB on which the thread will block
holding MA and MM waiting for MB to be released. The thread
cannot release MM prior to locking MB because otherwise TB
could have locked MM, checked for no deadlock and locked MA,
creating the very deadlock we want to detect.
It releases MM after having checked for a deadlock, but before
actually locking. And yes, there is a loophole, where the
condition can occur, and won't be detected. You do need some
means of atomically releasing MM and locking MB; that's why some
systems offer deadlock checking as part of the system
implementation of mutex locking. But we're not talking about
something critical to the behavior of the application here;
we're talking about additional error detection. And even if it
isn't perfect, it's better than nothing.
Alternatively, you can only use the MM mutex, plus conditionals,
and reimplement all of the mutex logic yourself within the
protected zone. I've not tried this, but it sounds like a lot
of work, with very slow mutex locking as a result.
- TB wants to lock (the unrelated) MC. To do so, it tries to lock MM
upon which it will block because this lock is held by TA until MB is
locked and MM is released. Since TB hold MB there is an addition
deadlock created which was not present prior to the checking logic.
Probably it is just inexperience with multi-threading but I can't see
off-hand how this deadlock can be prevented. I briefly thought that
adding another mutex locked only while MM is held could help but it
would only shift the problem one step further.
You need a request which would atomically (and inconditionally)
release one mutex, while acquiring (and possibly waiting) for
another one. Which doesn't exist in any system I know of.
--
James Kanze (Gabi Software) email: kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]