From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-10-20 18:36:39
--- Alexander Terekhov <terekhov_at_[hidden]> wrote:
> Real mutexes are designed for memory sharing, not isolation.
> "Some have complained that POSIX mutexes don't allow a locking thread
> to detect that the previous owner terminated "abnormally"... that's
> because it wouldn't do any good to know without isolation between
> the entities involved. With IPC mechanisms it makes sense to know,
> because you can do something about it."
> "Counting semaphores are well matched to dealing with
> producer/consumer problems, including those that might exist
> between threads of different processes, or between a signal handler
> and a thread. In the former case, there may be LITTLE OR NO MEMORY
> shared by the processes; in the latter case, one is not
> communicating between co-equal threads, but between a thread and an
> interrupt-like entity. It is for these reasons that IEEE Std
> 1003.1-2001 allows semaphores to be used by threads."
That is right and interestingly enough Win32 doesn't have
WAIT_ABANDONED state for semaphors or any other synch.
object but mutex.
Actually Win32 makes it even more confusing.
In the WAIT_ABANDONED state, the mutex is set to nonsignaled
but the ownership is granted. Isn't it weird!
However this thread is about mutexes on Win32 and
under this OS, WAIT_ABANDONED is a valid state
that needs to be handled.
In the current boost::mutex implementation
the return code is ignored (in non-debug version),
so that if the mutex owner is terminated,
a waiting thread will get the ownership as if
nothing happened. It is dead wrong.
In general WAIT_ABANODONED is not a good thing,
the data could have been partially modified
and the application should take appropriate actions.
That's said, in certain cases (like read-only protection)
even if a mutex is abandoned, the application can
still continue to work normally.
BTW: What happens with POSIX mutexes when the owner is terminated?
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk