Thank you for your interest!
Vicente J. Botet Escriba
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