Wait for multiple boost::condition(s)

I am about to port some Windows code which does a lot of WaitForMultipleObjects(), waiting for several signals at a time. I was wondering if there was some way to wait for multiple boost::condition(s) at the same time. Thanks, Steve

Sorry, at the moment there isn't. Mike "Steve Hartmann" <SHartmann@verityinst.com> wrote in message news:14A95978D8D7E64682CE342DC4CBE56005E584@VERITYMAIL.veritynt.com... I am about to port some Windows code which does a lot of WaitForMultipleObjects(), waiting for several signals at a time. I was wondering if there was some way to wait for multiple boost::condition(s) at the same time. Thanks, Steve _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Steve Hartmann wrote:
I am about to port some Windows code which does a lot of WaitForMultipleObjects(), waiting for several signals at a time. I was wondering if there was some way to wait for multiple boost::condition(s) at the same time.
I arrived at the very same question some time ago. Since then I had to learn, that waiting for a condition and waiting for multiple objects are not as closely related at it might seem at first glance. A condition does not carry state, while the handle you are waiting for does. A condition simply signals that a state change has appeared. Specifically a state change of a ceratin (group of) variable(s) that is (are) protected by a mutex. What you rather would need to have, is that a certain condition be signalled when an operating system supplied handle changes state. I ended having created a small class "wfmo" with the condition to be signalled as a member. The class has meber functions to add operating system handles, and creates a thread internally that blocks on WaitForMultipleObjects. On return it signals the condition. This is working. However I think it does address the problem only in a pragmatic way. (And I am afraid the runtime overhead due to the additional thread might be not negligible in some cases.) To do away with the additional thread you would need to modify the condition.wait() to accept the handles of the objects you are waiting for. Internally the wait currently uses WaitForSingleObject. It would be a simple task to replace them by WaitForMultipleObjects. But: You need to supply operating system handles then! And this breaks portability. The real problem is: Boost currently does not have a low level IO concept, that defines its own IO handles and the like. Altough this topic has been repeadetly discussed on the list there still has been no proposal (at least formally) that addresses theses issues. Yes there have been proposals about networking and the like but not about general (low level) IO. (On top of which I think, networking should be built.) Nevertheless, if you like I can send you my wmfo.hpp for study. Roland
participants (3)
-
Michael Glassford
-
Roland Schwarz
-
Steve Hartmann