Re: [Boost-users] [Thread] thousands of spurious wakeups from timed_wait() per second

Subject: Re: [Boost-users] [Thread] thousands of spurious wakeups from timed_wait() per second
From: Steve Clark (steven.clark_at_[hidden])
Date: 2014-09-11 12:17:33

Thank you for your interest!

Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:

> Le 10/09/14 04:38, Steven Clark a écrit :
> Which platforms are you testing?

In the original post, I erred in some details regarding platforms.  I am 
currently testing on two virtual machines, both Virtual Box running Ubuntu 
Linux (64-bit), and hosted on two different computers running Windows.

* One is running Linux 3.13.0, Ubuntu 14.04.1, and Boost 1.54.
* The other runs Linux 3.2.0, Ubuntu 12.04.5, and Boost 1.46.
* My intended target is an Intel arm i.MX27 running Linux x.y.z and Boost 
1.48.
I have not run my tests on the intended target yet.  I can move to a 
different version of Boost if necessary but it's a nuisance.  Is this the 
platform information you wanted?

> Could you test with the develop branch?

That would be a nuisance.  Have there been relevant changes since Boost 
1.54?  It is much more recent than what I mentioned in the original post.  I 
will try the development branch if you're sure it is worthwhile.

> > I'm also having trouble with the return value of timed_wait().
> > The documentation carefully states that timed_wait() returns "false if
> > the call is returning because the time specified by abs_time was 
reached,
> > true otherwise".  This seems to mean that spurious wakeups return true
> > -- and if you think about it, the return value is useless if spurious
> > wakeups could return false.  You'd have to add your own check for 
timeout.
> the function return true if there were a notify on this condition. This 
> doesn't mean that another thread has not already changed the result of 
> the predicate.
> the function return false when there were no notify before the timeout 
> was reached.

Let me restate what I think you said, which is also what I've observed so 
far.  Timed_wait() can return for three reasons: notification, timeout, or 
spurious.  It returns true on notification, and false on timeout or 
spurious.  (This is contrary to the documentation, which appears to be 
carefully written.)

I find it hard to believe that normal wait() cannot tell the difference 
between spurious and notification, yet timed_wait() can.  Granted, I don't 
understand the issues that lead to spurious wakeups.

Perhaps you meant that timed_wait() returns true for notification or 
spurious, and false for timeout or spurious.  That makes no sense to me 
either - there's no point in timed_wait() having a return value.  What 
decision can the caller reliably make on the basis of such a return value?

Thank you for running my test on a Mac.  Your output is what I expected to 
see.

I converted the test program to make pthread calls instead of Boost.  It 
works perfectly, just like your Mac run.  This is unsatisfactory because 
eventually I want the same code to run on Windows.

I've been suspicious that timed_wait() isn't actually waiting at all - just 
doing something like yield().  When I added a check for the current time vs. 
the timeout deadline into my test program, the number of spurious wakeups 
dropped almost to half, suggesting to me that the 
boost::posix_time::microsec_clock::local_time() call almost doubles the time 
it takes to run through the inner loop.

Are there any compiler flags that direct how Boost implements its thread 
functions?  I think I ran across something once, something like 
BOOST_POSIX_THREADS, but I haven't found it and I have no idea what the 
alternative to pthreads might be.

> Best,
> Vicente

Merci,
Steve