Boost logo

Boost :

From: Scott McCaskill (scott_at_[hidden])
Date: 2001-08-13 12:25:45


> [code snipped]
>
> OK, but why is this better than the event-based solution? IOW what is the
> rationale for the added complexity?
>

That's a different question. I don't have a lot of experience with events
and WFMO, but I can see one possible advantage of CVs over WFMO. WFMO can
only tell you one of two things (depending on how it's used) about which of
the objects in question became signaled:

1) one particular object became signaled, the others may or may not have
become signalled;

2) all of the objects became signaled

In the case where the predicate consists of multiple parts (analogous to
waiting for more than one object in WFMO), using CVs I can find out as much
info as I want about which part(s) of the predicate became true, whereas
with WFMO I have only the two options above. Granted, you could achieve the
same results by using more than just WFMO, but then the solution would be
more complex than CVs, not less. So for the particular example you gave, I
suppose one could argue that the CV solution is more complex (slightly), but
in general my impression so far is that CVs offer a much more general
solution (and--_IMO_--are not hard to use).

As I said, I don't have a lot of experience with events, but maybe someone
who does can show me the most elegant way to do the equivalent of the
following using events:

mutex m;
condition cv;
volatile bool a = false, b = false, c = false;

void threadfunc()
{
    mutex::scoped_lock lock( m );
    while ( !( a || b || c ) )
        cv.wait( lock );
    if ( a )
        do_something_a();
    if ( b )
        do_something_b();
    if ( c )
        do_something_c();
}

void notifyThread( bool _a, bool _b, bool _c )
{
    { mutex::scoped_lock lock( m ); a = _a; b = _b; c = _c; }
    cv.notify_one();
}


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk