Re: Thread library and Win32

From: williamkempf_at_[hidden]
Date: 2001-10-29 14:39:00

--- In boost_at_y..., "Anson Tsao" <ansont_at_m...> wrote:
> Perhaps it makes sense to treat WAIT_ABANDONED the same as
> WAIT_OBJECT_0, in that case the assertions should reflect that. I 
did
> not use the term 'runtime condition' properly in this context, my
> concern is whether WAIT_ABANDONED is something that should never 
occur
> thus an assertion, or whether it is a valid runtime error that 
needs to
> be handled.

Well, there are two ways to get an abandoned mutex.  One is to forget 
to unlock the mutex before the thread completes, which should not be 
possible to do in Boost.Threads because of the forced usage of the 
Scoped Lock pattern.  The other is for a mutex to be locked by a 
thread when someone calls TerminateThread on it.  We all know the 
dangers of TerminateThread and I'd hate to try and cater to it to 
this extent.

Above and beyond all of this, there's a school of thought that says 
the MS concept of abandoned mutexes is flawed any way.  The only 
thing that happens with abandoned mutexes is that any thread that 
tries to lock the mutex once it's been abandoned returns the 
WAIT_ABANDONED result, but there's nothing you can do with this 
result.  There's no way to recover from this "error".  So it's really 
just taking error handling a step too far.  In fact, this is why most 
(all?) other platforms have no concept of abandoned mutexes and will 
instead deadlock in the cases where MS returns WAIT_ABANDONED.

Do you have any specific thoughts on any of this?  If not, I'm 
inclined to leave the assert as it is, or possibly to create an 
artificial deadlock if WAIT_ABANDONED is returned.

Bill Kempf