Thanks for your replies.
To me boost::condition looks very much like the old event variable, except
that it works together with a mutex. I am now wondering why you should lock
a mutex before waiting for the condition? Is there a rationale about this?
Johan
----- Original Message -----
From: "Oleg Smolsky"
Hello Johan,
Johan 't Hart wrote on 8/09/2005 at 11:04 a.m.:
I'm quite a newbie in the boost world, and I read the documentation about boost::threads. Inthere I read that events were not included in boost because they were too error-phrone. That made me wonder how to do multithreading without events, for example, how do you make a thread wait for something to do without events? Well, I don't know if it's at all possible to implement a powerful (or flexible) multi-threaded project using just conditions.
I use sockets and select() instead of WaitForMultipleObjects(). IE select() is the cross-platform multiplexor that you can use for threading and network events. That's the "worker thread" side.
As for the "user code" side, you can implement a simple event that can be signalled and waited upon using conditions. IE it's common to have event.Wait() and event.Signal(), which are very very basic but cross-platform: - you can use boost conditions - or you can use WaitForSingleObject() on win32 and pthread condition on unix. AFAIK that's what boost does.
Best regards, Oleg.
-- Mijn Postvak In wordt beschermd door SPAMfighter 11666 spam-mails zijn er tot op heden geblokkeerd. Download de gratis www.SPAMfighter.com vandaag nog!