Dear all,
CC: Stephan @ Microsoft - Stephan I'd love to know what the MSVC STL
does below so we have the option of matching your behaviour.
During investigating this bug report for Boost.Thread
(https://svn.boost.org/trac/boost/ticket/9856) I have discovered a
very worrying situation: it would appear that potentially all timed
waits in Boost.Thread, and potentially in other parts of Boost, are
broken on Windows Vista and later and have been for some years.
The problem is in correct handling of timeouts. If one does this:
mutex mtx;
condition_variable cond;
unique_lock<mutex> lk(mtx);
assert(cv_status::timeout == cond.wait_for(lk, chrono::seconds(1)));
... one would reasonably expect occasional failures on POSIX due to
spurious wakeups. It turns out that this also spuriously fails on
Windows, which is a surprise probably to many as Windows hides signal
handling (actually APCs) inside its Win32 APIs and automatically
restarts the operation after interruption. There is, therefore, the
potential that quite a lot of code written to use Boost.Thread on
Windows makes the hard assumption that the assert above will never
fail.
The reason why Windows spuriously fails above isn't due to spurious
wakeups, it is in fact due to changes in the Vista kernel scheduler
as documented at
https://technet.microsoft.com/en-us/magazine/2007.02.vistakernel.aspx.
In essence, if you now ask Windows to go sleep for X milliseconds,
Windows Vista onwards will in fact sleep for anywhere between zero
and X+N milliseconds where N is some arbitrarily long value. In other
words, timeouts in Windows are purely advisory, and are freely
ignored by the Windows kernel from Vista onwards. You can test this
for yourself using this little program which reduces the #9856 bug
report to its Win32 API essentials:
#include
#include
#include <chrono>
int main(void)
{
ULONG ulDelay_ms = 20;
HANDLE hSemaphoreDelay = CreateSemaphore(NULL, 0, 1, NULL);
for (size_t n = 0; n < 50; n++)
{
while (1) {
auto begin = std::chrono::high_resolution_clock::now();
ULONG hr = WaitForSingleObject(hSemaphoreDelay, ulDelay_ms);
auto end = std::chrono::high_resolution_clock::now();
auto diff = end - begin;
if (hr == WAIT_ABANDONED)
printf("Wait Abandoned ");
else if (hr == WAIT_TIMEOUT)
printf("Timed out ");
else
printf("Signaled ");
DWORD lTDelta =
std::chrono::duration_caststd::chrono::milliseconds(diff).count();
printf("Target Wait Interval: %u Real Wait Interval: %u
(%u)\n", ulDelay_ms, lTDelta, diff.count());
if (lTDelta >= ulDelay_ms) break;
}
printf("\n");
}
CloseHandle(hSemaphoreDelay);
return 0;
}
As you'll see, actual time waited is anywhere between zero and 20 + N
milliseconds where actual time waited is sometimes a whole integer
multiple of the Windows kernel granularity (15 ms) or some fraction
of that granularity. Most of the time he tries to hit what you asked
for, but you get no guarantees.
More detail about how and why Windows Vista onwards does this can be
found at
http://forum.sysinternals.com/bug-in-waitable-timers_topic16229.html.
This raises the question about what to do with Boost.Thread. We have
the following options:
Option 1: Timed waits are allowed to spuriously fail by the standard,
so we mark this as wontfix and move on. Anyone using the predicate
timed waits has never seen a problem here anyway.
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.
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.
Boost commmunity, I turn it over to you for advice!
Niall
--
ned Productions Limited Consulting
http://www.nedproductions.biz/
http://ie.linkedin.com/in/nialldouglas/
