I learned to program Win32 first, so I have an affinity for events (and semaphores) over mutexes and condition variables. However, just about everything I read about condition variables states that they are a superior mechanism over events, often safety is reason cited. What is not explained, or what I do understand anyway, is why. My experience thus far would lead me to believe Win32 events are less error prone than Linux condition variables due to stronger guarantees and post-condition that events offer over condition variables. Win32 events synchronize themselves, you do not have to employ an additional mutex as you do with condition variables, and events are never spuriously awoken as condition variables may be. It is possible to lose the signal with both events and condition variables. If you signal an already signaled event, it does not double-bang. Only one "awakening" occurs (there is a bug in the comport code example on MSDN due to this). With condition variables, if no one is waiting on it when it is signal, the signal is lost. (This was the first bug I wrote using cd''s, I expected the signal to persist until it was waited on). There are solutions for both of these issues, with events you cannot rely on state at the time of the event, you have to check the state at the time of the awakening. e.g. keep reading characters from the comport until there are no more, don''t just read how many were available when the event was signaled. With condition variables, you have to check the condition (the variable that the ‘condition variable’ signals for) prior to waiting (to see if it''s ready now). Events have a couple of configuration options that tailor their behavior for several different uses. When the event auto-resets, it is atomically reset upon a wait and you are guaranteed that one and only one thread will be awoken. Condition variables do not make a ''there can only be one'' guarantee, and all waiting threads may contend for the mutex upon signaling. (This causes thread-thrashing and is problematic on latency sensitive systems and high-capacity servers using thread-pools. I suppose this is a QoI issue, condition variables could be implemented without awakening all the waiting threads for one-shot-signals, but posix does not require this.) If you desire the ‘signal and forget’ behavior of condition variables, there is a PulseEvent Win32 API call that behaves this way (if no threads are waiting on the event, the signal is lost). One functional difference, is that you can call pthread_cond_signal or pthread_cond_broadcast on any condition variable, whereas you must decide at creation whether an event is automatic (auto-reset, behaves like cond signal) or manual (behaves like cond broadcast). The Win32 method is to wait on more than one event if you need this behavior; an automatic event for single-shots, and a manual event for broadcast. That is why I think events are easier to use, and are a superior solution. Why do so many think that condition variables are better?

For one thing: Win32 events aren''t very portable, and do very much influence the structure of the code. This in itself, is reason enough to consider them superior for many people. Events might be better on Windows, in most cases, I''m not sure.

quote:CWizard
For one thing: Win32 events aren''t very portable, and do very much influence the structure of the code. This in itself, is reason enough to consider them superior for many people. Events might be better on Windows, in most cases, I''m not sure.

Aside from waiting on multiple events simutaneously (I have an idea on how to emulate this as well, but no implementation to back it up yet), I have written a wrapper around a condition variable that behaves very much like a Win32 event. I believe you could use two Win32 events (and a mutex) and emulate a condition variable as well.

...

quote:SiCrane
Essentially there are two objections that I remember. Number one is that using events for synchronization somehow depend on knowing the relative speed of the two synchronizing threads/processes. Don''t ask me to explain this one, I was an undergrad when I read it. Number two is that events are error prone because there is no explicit relationship between the event object and the data that it guards, so in large scale designs it is possible to forget to synchronize properly.

Sorry, not very much help, but it should be enough to do a search and find the original paper.

Why would you try to guard data with an event? I think that''s a strawman. "Egads! Booleans are no good for floating-point calculations!"

I did read something about having to know the relative speed of the processes, but no example was given. I was not able to think of an example where condition variables did not also bind the execution times together. I''ll try to track down more information about the relative speed issue.

I prefer the three building blocks of:

- atomic compare/exchange
- counting semaphores
- monitors

You can easily build the others on top of this, if you need them.

I also prefer an OS that has native support for waiting for multiple of these at the same time, select() or poll() style. Thus, there''s something to be said for all of these (except compare/exchange) to be file descriptors. Or, under Windows, HANDLEs and WaitForMultipleObjects().

Btw: that''s one thing Windows NT got right: WaitForMultipleObjects(), and making all the synchronizable primitives except CRITICAL_SECTION be waitable with that same function, including the message queue!

quote:Original post by SiCrane

quote:Original post by Magmai Kai Holmlor
Why would you try to guard data with an event? I think that''s a strawman. "Egads! Booleans are no good for floating-point calculations!"

Because in 1974 there were very few synchronization primitives available. I want to say that the only other proven method was spin-locks, as this was in the days when only load and stores could be considered atomic operations on the processor. Try to keep things in perspective: this is the paper that introduced monitors. Hoare wouldn''t write about mutexes until a year later.

Oh, are these criticisms stale then? It''s very possible Win32 events do not work anything like the events around back then.