Boost logo

Boost :

From: Carl Daniel (cpdaniel_at_[hidden])
Date: 2001-10-12 09:58:04

----- Original Message -----
From: <helmut.zeisel_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, October 11, 2001 11:39 PM
Subject: [boost] Re: Boost threads library, waiting on multiple conditions

> --- In boost_at_y..., mf_dylan_at_y... wrote:
> > One thing though, how would I go about waiting on multiple
> > conditions? This is actually the norm in much of my multi-thread
> > work...most of the time is spending waiting on various threads and
> > conditions, usually one of them is a "shutdown" event, another is a
> > checking for work to do etc. etc.
> >
> I do not understand completely:
> When you do the same work on every condition,
> why do you use different conditions?
> When you do different work on each condition,
> why don't you use for every condition
> a specfic worker thread that waits for only one condition?

Conservation of worker threads (which translates to a decrease in working set and a decrease in context switches).
Since Win32 lets one wait on (at least) 64 objects simultaneously, it's frequently more efficient to use one (or a few
threads) to service a large number of events. WaitForMultipleObjects also lets the caller specify whether to wait for
any of the objects or to wait until all are signaled simultaneously. The latter behavior is rarely used, but difficult
to simulate when not available. In the former case, the value returned from the call indicates which object was

For example, a single call to MsgWaitForMultipleObjectEx can simultaneously wait for:
- Windows messages
- Timeout
- APCs
- 60+ other objects (threads, events, mutexes, etc).

Without a similar capability, there are Windows applications which will never use boost::threads that otherwise would.


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