events & cv's papers
Saul
I've seen a couple of times posts (at this newsgroup) along the lines:
"The use of events (As opposed to condition variables) for
synchronization of threads is hard to use correctly"
It was also noted that the comparison of events & cv's was studied in
the 1970's.
Where did these studies appear?
Thanks
Saul
Joe Seigh
I'm not aware of any paper on this but the first statement is basically
just an opinion.
It may be in some cases they are confusing the lossy unix signaling mechanism
for events. In that case, of course. Nobody is going to argue that the
unix signaling mechanism isn't problematic.
Events are a lower level synchronization primitive than condition variables.
As such you do have a little more work to do when using these than when using
a higher level construct, but that's true when using any low level vs. high
level construct.
The flip side is that while CV's may be more "powerful", they're also more
restrictive on what you can use in your solution set. So it's a trade off.
So while it's nice to use these high level contructs when they fit your
problem set, it's also nice to have the lower level contructs when you
need them, especially to construct other high level constructs that don't
suck too badly in performance.
Joe Seigh
David Butenhof
> Saul wrote:
>>
>> I've seen a couple of times posts (at this newsgroup) along the lines:
>> "The use of events (As opposed to condition variables) for
>> synchronization of threads is hard to use correctly"
>> It was also noted that the comparison of events & cv's was studied in
>> the 1970's.
>> Where did these studies appear?
>
> I'm not aware of any paper on this but the first statement is basically
> just an opinion.
All statements are opinions.
As for papers, you'd have to do a search. I don't have any references
handy, and I have neither the time nor the inclination to do the search.
> It may be in some cases they are confusing the lossy unix signaling
> mechanism for events. In that case, of course. Nobody is going to argue
> that the unix signaling mechanism isn't problematic.
Huh?
> Events are a lower level synchronization primitive than condition
> variables. As such you do have a little more work to do when using these
> than when using a higher level construct, but that's true when using any
> low level vs. high level construct.
No, events are HIGHER level than condition variables. Condition variables
are "mechanism"; events introduce POLICY as well as mechanism. In effect,
(though there are plenty of implementation shortcuts), in comparison to
condition variables events add both the SYNCHRONIZATION and PREDICATE in
addition to the coordinated blocking mechanism.
> The flip side is that while CV's may be more "powerful", they're also more
> restrictive on what you can use in your solution set. So it's a trade
> off.
Condition variables are only restrictive in that they were designed to
coordinate with a mutex and application predicate. Events are far more
restrictive. Certainly neither is appropriate for all possible
circumstances, but it's easier to adapt the behavior of a condition
variable because there's no inherent policy.
> So while it's nice to use these high level contructs when they fit your
> problem set, it's also nice to have the lower level contructs when you
> need them, especially to construct other high level constructs that don't
> suck too badly in performance.
Though there are few problem sets that truly fit the "event" model, you're
certainly correct that it doesn't hurt to have them... as long as there's
also a more general lower level mechanism like the condition variable. ;-)
/------------------[ David.B...@compaq.com ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/
Alexander Terekhov
Here is a few links that perhaps might help..
http://www.acm.org/classics/feb96
http://www.acm.org/pubs/citations/journals/surveys/1973-5-4/p223-hansen
ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/SRC-020.pdf
http://sources.redhat.com/cgi-bin/cvsweb.cgi/pthreads/condvar.c?cvsroot=pthreads-win32
http://groups.google.com/groups?as_umsgid=3AEAC433...@web.de
(implementing POSIX-CV under windows; problem of
SignalAndWait/PulseEvent
and MS-thread model with respect to suspended thread state)
http://www.opengroup.org/austin
(POSIX Draft 7 (Proposed Final Text) Specifications):
"Much experience with semaphores shows that there are two
distinct uses of synchronization: locking, which is typically
of short duration; and waiting, which is typically of long or
unbounded duration. These distinct usages map directly onto
mutexes and condition variables, respectively."
"Mutexes and condition variables have been effectively used with
and without priority inheritance, priority ceiling, and other
attributes to synchronize threads that share memory. The
efficiency of their implementation is comparable to or better
than that of other synchronization primitives that are sometimes
harder to use (for example, binary semaphores[1]). Furthermore,
there is at least one known implementation of Ada tasking that
uses these primitives.
Mutexes and condition variables together constitute an
appropriate, sufficient, and complete set of inter-thread[2]
synchronization primitives."
[1] MS:auto-reset event/counting semaphore with value/count
initially set to 0 or 1 and that never become "> 1";
[2] share process memory/address space; or inter-process
synchronization (PROCESS_SHARED mutexes/cvs) for
processes that share some memory (memory that can be
mapped concurrently into the address space of more
than one process).
regards,
alexander.