Thread events

Just another documentation item, if you have a subscription to C/C++ Users Journal there was an introduction a few years ago by Bill Kempf that had more tutorial examples on the use of condition variables. I'm including a link to the introduction but you will need a subscription to read the entire article. http://www.cuj.com/documents/s=9765/cuj0205kempf/ Jason

You want either, http://www.boost.org/doc/html/barrier.html Or, http://www.boost.org/doc/html/condition.html Based on what you are trying to do.

And of course reading the FAQ, which points you to the rational for not having events... http://www.boost.org/doc/html/threads/rationale.html#threads.rationale.event...

-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

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" <oleg.smolsky@pacific-simulators.co.nz> Newsgroups: gmane.comp.lib.boost.user Sent: Thursday, September 08, 2005 6:24 AM Subject: Re: Thread events

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!

Johan 't Hart schrieb:

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?

I recommend getting a book on pthreads (Posix Threads). E.g. "Programming with POSIX Threads" David. R. Butenhof. You will understand then why the sole combination of mutex and condition valiables will solve (almost) every MT need. I said almost because there is on some platforms (Win32) an inherent inability to cancel out of blocking IO calls. However the clever guys that ported pthreads to Win32 solved a lot of these problems. You might also look into my thread_alert submission which is in the boost file vault. It does address this later issue to some degree. Regards, Roland