Re: [boost] [thread] Timed waits in Boost.Thread potentially fundamentally broken on Windows (possibly rest of Boost too)

Subject: Re: [boost] [thread] Timed waits in Boost.Thread potentially fundamentally broken on Windows (possibly rest of Boost too)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-01-23 08:23:48

On 23 Jan 2015 at 15:35, Andrey Semashev wrote:

> > Option 2: We loop waiting until steady_clock (really
> > QueryPerformanceCounter under Boost) shows the requested timeout has
> > passed. Problem: This wastes battery power and generates needless
> > wakeups. A more intelligent implementation would ask Windows for the
> > thread quanta and transform timeouts to match the Vista kernel
> > scheduler in combination with always using deadline scheduling, but
> > this would slow down the timed waits implementation.
> 
> That is a missed notification waiting to happen.

For reference for those pondering this option, there is no 
possibility of missed notifications on Windows as unless you use 
PulseEvent() (we don't), it can't happen on the win32 threading 
model.

There is also an option 2a and 2b here: (a) loop the wait and (b) use 
deadline timer scheduling instead of timeouts. Note we already do the 
latter for larger timeouts, but it is currently not being adjusted 
for NT kernel quanta since Vista.

> > Option 3: We adjust Boost.Thread to return timeouts when Windows
> > returns a timed out status code, even if the actual time waited is
> > considerably lower than the time requested. Problem: some code
> > written for POSIX where when you ask for a timeout you always get it
> > may misbehave in this situation.
> 
> That is simply incorrect. Why would you indicate a timeout when none occurred? 
> This will surely break some timed code.

Some would say that if Windows claims a timeout, we should return a 
timeout. I suspect this is what the Dinkumware STL will do, and for 
compatibility we may wish to match that.

> The standard description is pretty clear: return cv_status::timeout only when 
> the timeout has expired, otherwise return cv_status::no_timeout. Boost.Thread 
> should follow this.

This is the current behaviour. However, and it is a big however, the 
semantics are subtly different. On POSIX you either get your wait as 
long as you asked or a spurious wakeup. On Windows you are ordinarily 
getting a wait between nothing and an arbitrary higher amount than 
requested. This is a "spurious wakeup on steroids".

The key point here is that Windows spurious wakeups are occuring 
*much* more frequently than on POSIX. This has implications for 
battery life and plenty more.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/