Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-08 06:02:35

> ross.s_at_i... (Ross Smith) wrote:
> > I've given up on the whole CV-vs-event mess; to be perfectly honest,
> > I've come to the conclusion that most people have been brainwashed by
> > the "Unix is always right and Windows is always wrong" school of
> > thought, and aren't prepared to discuss the matter rationally.

could you please show me some events based code which would be
functionally equivalent with respect to some "monitor" with one
(or several) internal conditions (CVs) to wait for? we could
then discuss the matter rationally.

> Microsoft have introduced monitors (i.e. like condition variables) in
> .NET. Maybe they have been brainwashed too? :-)

AFAICT (based on the preliminary docu available on the MS web site)
they have simply copied java monitors (and added some "extensions";
e.g. tryenter methods).

also, based on the their choice for signaling methods names
(Pulse/PulseAll) it seems that they are using old events/PulseEvent
API (instead of some new "CV" synchronization object); something

(Louis Thomas <lthomas_at_[hidden]> wrote)

>> given:
>> ex_mutex - mutex
>> cond - autoreset event
>> nWaiters - int
>> wait(timeout) {
>> nWaiters++
>> bTimedOut=SignalAndWait(ex_mutex, cond, timeout)
>> lock ex_mutex
>> nWaiters--
>> return bTimedOut
>> }
>> signal(bAll) {
>> do (bAll?nWaiters:1 times) {
>> PulseEvent(cond)
>> }
>> }

that does not work under windows debugger(s) or when
programs suspend threads "manually" (w/o debugger).

"PulseEvent() may fail to release a thread waiting on an event
 object while the application is running in a debug environment.
 This is true regardless of whether or not the code is compiled
 with debug information. This is also regardless of whether the
 debuggee is executed by the "go" command or by being "single


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