|
Boost : |
From: Robin Boerdijk (robin_boerdijk_at_[hidden])
Date: 2006-01-14 03:02:49
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk