Windows event objects still considered harmful?
Hi, I don't agree with the rationale for excluding a Windows event object-like construct from the Boost thread package. The rationale justifies the exclusion based on the "Concurrent Programming Concepts" paper by Per Brich Hansen in which event variables are dismissed as unsafe. The fundamental problem of event variables according to Hansen's paper is that, "if the sender causes [signals] the event before the receiver waits for it, the receiver will remain delayed until the next event is caused [signalled]". However, Windows event objects don't work like this. From the API specification: "When the state of an auto-reset event object is signaled, it remains signaled until a single waiting thread is released; the system then automatically resets the state to nonsignaled. If no threads are waiting, the event object's state remains signaled." In other words, the receiver will _not_ remain delayed if the sender signals the event before the receiver waits for it. Based on this observation, I think the reference to Hansen's paper should be removed from the rationale. It does not apply to Windows event objects and I had to spend $10 to download the paper from the ACM website and find this out. Furthermore, according to the rationale, "Experienced programmers using the Windows platform today report that event variables are a continuing source of errors". Are there any links to documents that describe these problems? Are these problems perhaps related to the PulseEvent() method, which does cause the behaviour Hansen described but has been deprecated (the API documentation states "This function is unreliable and should not be used. It exists mainly for backward compatibility"). In short, are Windows event objects still considered harmful? Thanks, Robin Boerdijk __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
At 01:02 2006-01-14, Robin Boerdijk wrote:
Hi,
I don't agree with the rationale for excluding a Windows event object-like construct from the Boost thread package. The rationale justifies the exclusion based on the "Concurrent Programming Concepts" paper by Per Brich Hansen in which event variables are dismissed as unsafe. The fundamental problem of event variables according to Hansen's paper is that,
"if the sender causes [signals] the event before the receiver waits for it, the receiver will remain delayed until the next event is caused [signalled]".
However, Windows event objects don't work like this. From the API specification:
"When the state of an auto-reset event object is signaled, it remains signaled until a single waiting thread is released; the system then automatically resets the state to nonsignaled. If no threads are waiting, the event object's state remains signaled."
In other words, the receiver will _not_ remain delayed if the sender signals the event before the receiver waits for it.
I think this the a case of usurping names of things that had definitions and changing them (MS in this case) and event _used to be_ (well back in the '70s when Brinch was at Caltech and we were down in OC writing real-time systems for minicomputers) a semaphore that released ALL waiting entities (I guess MS calls them pulse events now). They aren't dangerous at all, you simply have to KNOW what you're playing with. There are many different policies (in the Alexandrescu terminology) one can have regarding semaphores, IMO these are only a couple of them. Unfortunatly, since I've gotten out of the architecture/design of OSs people seem to have started assigning names (not always ensuring consistancy) to some of these flavors (as we called them) of semaphore.
Based on this observation, I think the reference to Hansen's paper should be removed from the rationale. It does not apply to Windows event objects and I had to spend $10 to download the paper from the ACM website and find this out.
Furthermore, according to the rationale, "Experienced programmers using the Windows platform today report that event variables are a continuing source of errors". Are there any links to documents that describe these problems? Are these problems perhaps related to the PulseEvent() method, which does cause the behaviour Hansen described but has been deprecated (the API documentation states "This function is unreliable and should not be used. It exists mainly for backward compatibility").
In short, are Windows event objects still considered harmful?
personally I don't regard _any_ of the semaphores as "harmful" provided the user understands what s/he is using.
Thanks,
Robin Boerdijk
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Robin Boerdijk wrote:
"if the sender causes [signals] the event before the receiver waits for it, the receiver will remain delayed until the next event is caused [signalled]".
But I struck this exact problem the other day with boost threads condition variables. Both notify_one() & notify_all() have no effect if there are no threads waiting: http://boost.org/doc/html/condition.html - Chris Byrne
Robin Boerdijk wrote:
"if the sender causes [signals] the event before the receiver waits
for
it, the receiver will remain delayed until the next event is caused [signalled]".
But I struck this exact problem the other day with boost threads condition variables. Both notify_one() & notify_all() have no effect if there are no threads waiting:
This is getting a bit off-topic, but to get a Windows style auto-reset events you need a mutex, a condition variable and a boolean flag. It would look something like this: signal event: lock mutex set boolean flag notify condition variable unlock mutex wait for event: lock mutex while not boolean flag set wait for condition variable reset boolean flag unlock mutex This is a Windows style auto-reset event. My original question was (and still is), what is wrong with this? Robin Boerdijk __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
participants (3)
-
Chris Byrne -
Robin Boerdijk -
Victor A. Wagner Jr.