Re: [boost] Windows event objects still considered harmful?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-01-17 21:09:31

"Robin Boerdijk" <robin_boerdijk_at_[hidden]> wrote in message 
news:20060112151043.59600.qmail_at_web33201.mail.mud.yahoo.com...
> 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.

That discussion was four or five years ago so my memory may be faulty, but 
isn't the real problem that if no threads are available (because events are 
happening faster than they can be disposed of) then events will be silently 
dropped?

IIRC, Brich Hansen argued that threading primatives should work correctly 
regardless of the relative speed of each tread, and that was why the docs 
referenced him.

> 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?

Some of the war stories appeared in list discussions, so you might check the 
archives. Seems to me the topic also came up over a beer with some Microsoft 
VC++ folks in Redmond in 2001 after Bill Kempf presented Boost.Threads to 
the C++ committee, and they had also seen the 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?

To rehabilitate them you would need to show not only that they aren't 
harmful, but that they are somehow better that the alternatives, that they 
have POSIX threads equivalents, that threading experts endorse them, etc., 
etc. Threading is such a minefield that many people are very reluctant to 
accept features just because programmers claim to have used them 
successfully. Programmers claimed goto's were fine, too,  but they 
eventually fell into disfavor.

--Beman