Re: [boost] [thread] Resource usage in Win32 version of condition class

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-01-03 02:38:37

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