Boost logo

Boost :

Subject: Re: [boost] [thread] Timed waits in Boost.Thread potentially fundamentally broken on Windows (possibly rest of Boost too)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-01-23 10:30:41


On Friday 23 January 2015 14:12:19 Niall Douglas wrote:
> On 23 Jan 2015 at 16:46, Andrey Semashev wrote:
> > >
> > > 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.
> >
> > We're not mimicking OS behavior in Boost.Thread - that's the point of it
> > being a portability layer.
>
> The Dinkumware STL behaviour is not OS behaviour. It's one of the big
> three STLs.

What I'm saying is that Boost.Thread should implement the standard interface,
not something else's. If Windows reports a timeout when it didn't actually
happen (i.e. it has not been reached yet), Boost.Thread should not report the
timeout to users. If this is what actually happens, and Dinkumware STL does
that then there is a bug in Dinkumware STL, and we should not copy it.

> > If Windows is not well suited for it then oh well... MS should fix
> > Windows then to be more efficient.
>
> Vista made these changes to scheduling for efficiency purposes. I
> suspect Boost.Thread was written for an XP or earlier target.

I'm confused. Boost.Thread always implemented the standard behavior, with
possibility of spurious wakeups. Windows before Vista did not exhibit spurious
wakeups (which was ok) and since Vista it started doing this, and this
improved efficiency (I assume, the estimate of the improvement had included
the negative effect on the applications dealing with the wakeups).
Boost.Thread is still behaving correctly wrt the standard. So, why would you
want to change Boost.Thread and conceal spurious wakeups, making it less
efficient? I'll reiterate that any current use of cv must deal with spurious
wakeups already.

> > > > 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".
> >
> > I don't see the difference. On POSIX, you're not guaranteed to be woken up
> > exactly at the timeout either. And spurious wakeups can potentially happen
> > as often as one can emit signals to the process. Granted, that usually
> > doesn't happen that often, but conceptually this is not different from
> > Windows.
>
> My reading of
> http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_cond_
> timedwait.html says that the timed wait may not return timed out if
> abstime has not passed. Unfortunately abstime is measured against the
> system clock which may arbitrarily move around, but that's the POSIX
> definition.

Note that this means that a wait is allowed to return either before or after
the timeout. So this is basically what I said.

> > So we're talking about efficiency, not correctness as you originally
> > stated?
> Let's call it correctness of expectation of behaviour by the
> community. It's why I'm asking for advice here instead of
> unilaterally deciding on my own. None of the three options isn't
> without unhelpful consequence.
>
> For example, would the community be happy if on Windows timed waits
> always were at least the timeout interval requested? In other words,
> we guarantee that timeout intervals requested are honoured?

My opinion is that there is no point in that since any current use of a cv
must involve a loop and a condition anyway (or wait with a condition). Trying
to deal with spurious wakeups in the cv implementation is just a waste of
resources.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk