Conditions vs Events

[Carl J. Van Arsdall]

Le Monde De Python,

I've been working a lot with python threads from the threading module.
Specifically, when is it better to use a condition object vs an event
object?

It seems to me that, at least superficially, I can just about use these
two mechanisms interchangeably. The only real difference I can see is
that I can call isSet() on an event in the case that an event is
triggered before wait() is called. Are there any differences?

Also, does calling wait reset some type of "notify" in a condition
object like it does in an event object?


Anyhow, thanks for your help!

-carl





--

Carl J. Van Arsdall
(e-mail address removed)
Build and Release
MontaVista Software

 

[Dennis Lee Bieber]

It seems to me that, at least superficially, I can just about use these
two mechanisms interchangeably. The only real difference I can see is
that I can call isSet() on an event in the case that an event is
triggered before wait() is called. Are there any differences?

Events free /all/ waiting threads, period, as long as the event is
"set". If you will, visualize the starting line of a car race (with the
weird rule that cars can start from the pit row rather than being staged
on the starting line).

The "Event" is the green flag. The flag is not "out" and cars wait
at the starting line -- a car in the pit may come out but as soon as it
gets to the staging line it, too, has to wait.

The flag comes "out", and all the cars waiting get to continue --
and, as long as the flag is out, even a car starting in the pit gets to
continue... There is no "wait"

Also, does calling wait reset some type of "notify" in a condition
object like it does in an event object?

"wait()" doesn't do any reset in events... If the event is set, the
wait() is a No-Op.

In comparison -- Conditions require first obtaining the lock, and
the lock is released on wait(); and only then is another thread even
able to obtain the lock and do its own wait(). And the thread that
signals the condition has to, itself, obtain the lock before it can
signal.

The condition "wait" is a sequence similar to:
c.lock.release()
c.event.wait()
c.lock.acquire()

The presence of that acquire() means that even if one uses
"notifyAll", only one thread at a time can continue. The big feature is
that any thread that comes in /after/ the notifyAll ends up having to
wait for the next notify, but all the threads that /had/ been waiting
are allowed to proceed (one at a time).
--