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.