[ace-users] Condition Variables vs. Events
Luetjens, D.
this question does not really belong to this list, but it arose to me while
browsing the ACE source.
I was wandering what the difference of using ConditionVariables against
Events are, or better when to use which type of synchronsiation mechanism.
From the waiters point of view I'm interested to wait until something of
interest happens. This can be acomplished by using a condition or event to
wait for.
From the sender point of view I want to have the ability to signal only one
Thread or all Threads. This can be done with
Condition.Signal/Condition.Broadcast or Manual/Automatic Events.
The only real difference I see, is that with Manual Reset Events the Event
has to be cleared manually from the last Thread waiting for that event vs.
the Condition.Broadcast, where this is solved by the condition variable
itself.
While browsing the net I found a text explaining, that condition variables
often come with a predicate like this:
Waiter:
> mutex.lock;
> while (!predicate())
> condition.wait(&mutex);
> mutex.unlock();
Sender:
> mutex.lock();
> predicate.set();
> condition.broadcast();
> mutex.unlock();
The predicate is useful if one thread decides to stop the processing of the
condition by resetting the predicate(). But this is nothing special to
condition variables. This can also be done with events.
Thanks for the enlightenment
Dirk
Douglas C. Schmidt
>> this question does not really belong to this list, but it arose to me while
>> browsing the ACE source.
>>
>> I was wandering what the difference of using ConditionVariables against
>> Events are, or better when to use which type of synchronsiation mechanism.
Here's a discussion of this taken from a draft of our upcoming book on
ACE:
Events are similar to condition variables in the sense that a thread
can use them to inform another thread when a certain event occurs.
Similarly, threads can wait on an event to be signaled about the
occurrence of certain activities. Events can be set, reset, or pulsed
automatically or manually, which allows users to control the number of
threads woken up by the signaling operations. These different
signaling mechanisms allow an event to memorize its states or to
indicate a state transition. In contrast to condition variables,
events can therefore be used to solve the ``lost wakeup'' problems.
Events are often implemented using sleep locks. They are therefore
more expensive than mutexes, but provide better control over thread
scheduling. However, condition variables enable threads to wait for
an arbitrary condition expressions involving shared data, whereas
events provide a simpler notification mechanism. Thus, condition
variables are often more useful for complex coordination activities.
>> While browsing the net I found a text explaining, that condition variables
>> often come with a predicate like this:
>>
>> Waiter:
>> > mutex.lock;
>> > while (!predicate())
>> > condition.wait(&mutex);
>> > mutex.unlock();
>>
>> Sender:
>> > mutex.lock();
>> > predicate.set();
>> > condition.broadcast();
>> > mutex.unlock();
>>
>> The predicate is useful if one thread decides to stop the processing of the
>> condition by resetting the predicate(). But this is nothing special to
>> condition variables. This can also be done with events.
No, that's not really true since you can't ensure the same semantics
with events due to race conditions between signaling an event and
checking the predicate. Please see the paper at
http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
for a much more in-depth implementation-oriented analysis of the
differences.
Thanks,
Doug
--
Dr. Douglas C. Schmidt, Associate Professor TEL: (949) 824-1901
Dept of Electrical & Computer Engineering FAX: (949) 824-2321
616E Engineering Tower WEB: www.ece.uci.edu/~schmidt/
University of California, Irvine, 92697-2625 NET: sch...@uci.edu
TERE...@de.ibm.com
"Douglas C. Schmidt" <sch...@cs.wustl.edu> wrote:
[...]
> >> The predicate is useful if one thread decides to stop the processing
of the
> >> condition by resetting the predicate(). But this is nothing special to
> >> condition variables. This can also be done with events.
>
> No, that's not really true since you can't ensure the same semantics
> with events due to race conditions between signaling an event and
> checking the predicate. Please see the paper at
>
> http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
>
> for a much more in-depth implementation-oriented analysis of the
> differences.
fyi.. [http://groups.google.com/groups?as_umsgid=3AEAC433...@web.de]:
[...]
Louis Thomas <lth...@arbitrade.com> wrote:
>Subject: RE: Win32 Conditions
[...]
>Schmidt & Pyarali list many of these in their
>paper "Strategies for Implementing POSIX Condition Variables on Win32"
>[http://www.cs.wustl.edu/~schmidt/win32-cv-1.html], and, as they indicate,
>none of them are correct.
^^^^^^^^^^^^^^^^^^^^^^^^
>However, there is one that they did not mention
>that is interesting because it is correct. Here it is in pseudocode form:
>---------- Algorithm 1 ----------
>given:
>ex_mutex - mutex
>cond - autoreset event
>nWaiters - int
>
>wait(timeout) {
> nWaiters++
> bTimedOut=SignalAndWait(ex_mutex, cond, timeout)
> lock ex_mutex
> nWaiters--
> return bTimedOut
>}
>
>signal(bAll) {
> do (bAll?nWaiters:1 times) {
> PulseEvent(cond)
> }
>}
>---------- ---------- ----------
>This pseudocode assumes that ex_mutex is always held by the thread calling
>signal, but is easily corrected by adding a CritSec or mutex to protect
>nWaiters. I think that this algorithm meets all the requirements specified
>by PThreads. There is no signal stealing, double broadcast deadlocks, or
>spurious wake ups. (There may be spurious PulseEvents but they do not
cause
>wake ups.) It has the nice property that it requires the same number of
>sync
>objects as the Unix version. However, it has one major drawback that is
not
>even mentioned in the PThread spec. In Win32, a thread that is in the
>'suspended' state is not in the 'waiting' state. This means that if a
>thread
>is waiting on an auto-reset event but is suspended when the PulseEvent
>occurs, it will miss the notification because it was not really waiting on
>the event. Debuggers suspend and resume threads all the time. This means
>that single stepping a program while a signal occurs can very easily cause
>any number of wake ups to be missed and deadlock to occur. Because of this
>problem, this implementation is basically unusable. PThreads does not even
>say whether or not threads can be suspended, let alone how this should
>affect threads waiting on a condition.
.
.
.
regards,
alexander.