Re: [Boost-users] Thread events

From: Johan 't Hart (jopie64_at_[hidden])
Date: 2005-09-08 14:06:12

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_at_[hidden]>
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!