Don G wrote:

I may be worried over something inconsequential, but the condition class creates three kernel objects per instance.

There is quite a lot of archived discussion available about this topic. There is agreement, that on windows this is the only reliable way of doing it. Beneath the boost list you might also google for "condition win32".

Granted, one would have to instantiate hundreds of these objects to notice a problem, but STL collections make such things trivial. For example, in a previous job one of our teams created a large, in-memory database that had a mutex/condvar on lots of objects. I guess that I am concerned by the non-portable "cost of use" equation (say vs. pthreads). One could write code that was perfectly reasonable on Unix and quite terrible on Windows.

I suspose any correctly implemented pthread condition on win32 will exhibit comparable behaviour.

Some years ago I also implemented a condvar on Win32, but the technique I used required only one event per thread (a CondVar was nothing more than a list of stack structures guarded by the associated mutex).

As far as I understood the main issue that it is not possible to implement a condition on win32 with a single event is that it is not possible to awake a single thread _and_ awake all threads. You can't achive both available semantics with an event alone.

In the FWIW category, I could see no benefit (and lots of pain) binding the condvar to the mutex at the time of wait(), so in my implementation a condvar was permantently bound to its mutex (as in "condvar::condvar(mutex & m)"). I have yet to find a case where the posix-style, free association was needed.

You would need this e.g. in implementing the "monitor pattern". Having this dynamic binding allows for binding a single mutex to more than a mutex at a time. As opposed to conditions your construct also would create a condition with "state". This is not a condition anymore. I suspect, you are looking for a different kind of synchronization primitives, are you? Roland