(I'm not that familiair with news servers, so this post might appear for the second time. I hope to get an answer though) Hello, 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? I don't know how to implement that with just mutexes. Can someone help me? Thanks in advance. Johan 't Hart -- -- Mijn Postvak In wordt beschermd door SPAMfighter 11622 spam-mails zijn er tot op heden geblokkeerd. Download de gratis www.SPAMfighter.com vandaag nog!
Johan 't Hart wrote:
(I'm not that familiair with news servers, so this post might appear for the second time. I hope to get an answer though)
Hello,
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? I don't know how to implement that with just mutexes.
Can someone help me?
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
Rene Rivera wrote:
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... Hmmm, it appears that the titles of the first two items in the Rationale have been chopped: * Rationale for the Creation of * Rationale for the Low Level Primitives Supported in Something to do with the port to Boost.Book perhaps? Regards, Angus
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
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.
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!
The mutex is used to keep the "state" of what you are waiting to happen from being changed in the window of time between your test of it and your thread actually being placed on the wait queue of the condition primitive. Otherwise you could get: Thread A tests the "state" and gets a false result. Thread B changes the "state" to true and then wakes all the waiters on the queue. Thread A is added to the wait queue. Which would potentially leave Thread A waiting forever for something that has already occurred. On 8 Sep 2005, at 12:06 PM, Johan 't Hart wrote:
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"
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!
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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
participants (8)
-
Angus Leeming
-
Christian Henning
-
Jason Stewart
-
Johan 't Hart
-
Oleg Smolsky
-
Rene Rivera
-
Roland Schwarz
-
Thomas Costa