Boost logo

Boost :

From: flameframe_at_[hidden]
Date: 2001-08-13 09:09:10

--- In boost_at_y..., williamkempf_at_h... wrote:

> >
> > Using multiple wait idiom as in Win32 we can easily build a
> mentioned
> > relation.
> Actually, you can't. There's no way for me to prove this, but I
> challenge you to do so and I'm willing to bet I can show race
> conditions with each of your attempts.
> >
> > These lines just are to be written as following.
> >
> > wait mutex and event signaled by other threads when state is
> true
> No, because the Win32 WaitForMultiple*() operations won't gaurantee
> you the order in which the objects are acquired. It's likely that
> the mutex will be acquired first, preventing other threads from
> modifying the state in order to signal the event, so you wind up
> a deadlock caused from a race condition.

Here is the main point! If WaitForMultiple*() function really has
this bug then I agree - deadlock can occur. But I have not heard
about such bug neither from Internet nor in MSDN. You have programmed
with Win32 for a years - so could you please _point_ me (and other
naive programmers) to KB/anywhere article on which your opinion is

It is too serious to just saying that two threads calling the same
WaitForMultiple*() can result to deadlock. A lot of programmers are
using this function(s) to _avoid_ potential deadlocks and will be
very surprised if it introduces one. I am really doubt that you are
right here. At least until I see the proofs.

Best regards,

P.S. And, please, do not redirect me just to "well-known" literature
or to previous mailing in this thread. For the last years I have read
a lot :-) and have followed thread library discussion from the very

Boost list run by bdawes at, gregod at, cpdaniel at, john at