Thank you for your interest!
Vicente J. Botet Escriba
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? Thanks for the details. Could you check directly on windows?
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.
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. No. It is not worth if you have tested with 1.54. But version 1.48 is a very old version. 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.) No, it can return either because notified or timeout. A spurious notification is one that doesn't satisfy the predicate you expect after wait. This could be because another thread has changed in the mean time
Le 11/09/14 18:17, Steve Clark a écrit : the condition.
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. Both wait and timed_wait can have associated spurious notifications.
Perhaps you meant that timed_wait() returns true for notification or spurious, and false for timeout or spurious.
No. When the timed_wait returns false, the condition has not been notified, so there is no possible spurious notification in this case ;-)
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? If there is a timeout, this gives you an indication that maybe there is no thread that will notify you, protecting you blocking forever. 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. Agreed. Could you check directly on windows?
Another possibility could be to use the chrono interface to see if the
bug is around the date-time interface.
#include
I've been suspicious that timed_wait() isn't actually waiting at all - just doing something like yield(). Yes, the date on your traces indicates that the timeout has not been reached at all, and that the notifications are done every second, as expected. The problem been the erroneous timeouts.
now is 2014-Sep-09 20:48:12.183781 now is 2014-Sep-09 20:48:12.215471 now is 2014-Sep-09 20:48:13.216511 now is 2014-Sep-09 20:48:14.216805 now is 2014-Sep-09 20:48:15.217191 now is 2014-Sep-09 20:48:16.217453 now is 2014-Sep-09 20:48:17.217685 now is 2014-Sep-09 20:48:18.217291
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.
Sorry, I don't understand what you mean. Could you rephrase? Best, Vicente