Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'd like to see some valid examples of needing to let a thread enter a locked, non-re entrant mutex, then destroying the mutex (which supposedly terminates the thread).

I can't think of any good reason to do this. I can't remember precisely what we were arguing about earlier today, but my colleague insists such techniques are needed for "point-of-no-return" problems (again, forgive me, but I forgot the example he gave me).

share|improve this question
What is the intended state of the other threads after mutex destruction ? –  NWS Jul 24 '12 at 8:43
Dead. Terminated. Kaput. No-more. Gone. Having ceased to be. Ex-threads. –  Frob Jul 24 '12 at 10:32
Threadless... ? –  jflood.net Jul 24 '12 at 10:58
A thread enters a mutex and is supposed to terminate when said mutex is destroyed. That is to say, since no platform actually terminates threads in mutexes that have been destroyed, we'd have our own mutex implementation that does this. –  Frob Jul 24 '12 at 11:10

2 Answers 2

up vote 5 down vote accepted

I suppose you could make an argument that a mutex that protects a resource should be destroyed and any waiting threads killed if something happens to the resource (e.g. threads waiting to write to a device which goes off-line). Or possibly in a hard-real-time environment where any tasks which haven't completed during their quantum have to be force-exited. Kind of a stretch, though, I don't see this being a general-purpose solution.

share|improve this answer
This is probably what the example was. In the former case, an atom would work just as well: When they wake up, they check the atom and branch accordingly (not to mention giving any stack objects a chance to cleanup). In the latter case, where the threads themselves are the hazards, that would make sense -- but not something I can see any benefit to implementing in userland (which I think was the argued purpose). –  Frob Jul 24 '12 at 14:35
How about a situation where code discovers that a service running on some other threads is no longer required. Setting a flag to tell the other thread to terminate at its next opportunity might be insufficient if the thread is waiting for an event which will never occur. Asynchronously invalidating the object upon which the other thread would wait, if allowed, would avoid that issue. –  supercat Aug 22 at 18:53

I think you are using your mutex as a semaphore to signal that the threads all need to shutdown. This could be useful if any one (or subset) of the threads is capable of detecting conditions that require all the other threads to stop. This would also require all the threads to routinely access this mutex & a parent thread wait for them all to terminate before terminating itself or restarting the threads.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.