From: Ward Willats <musl@wardco.com>
To: musl@lists.openwall.com
Subject: std::condition_variable::wait_for() breakage when system_clock changes C++11 MIPS
Date: Tue, 2 Aug 2016 16:33:29 -0700 [thread overview]
Message-ID: <3008FD15-1C92-4870-9CD9-BC8B694ACCD0@wardco.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]
Hello.
This may be a little too C++ for this list, but I wasn't sure where to turn. Also, I thought I should at least document it for the Google, and see if you folks think I should take this problem elsewhere, or, perhaps more likely, if I have made some stupid error (!)
We are running a C++ 11 app on a MIPS-based Linux/OpenWRT platform and linking against MUSCL 1.1.12 and libstdc++ v3. On cold boot, our system clock is often some random time in the future until ntpd or other software corrects it. This led to odd behavior and this experiment:
If I use the busybox "date --set" to move our system's clock 24 hours into the future, and then call:
std::condition_variable::wait_for() with the pre-canned std::chrono::duration, std::chrono::milliseconds( 120000 ), as a 2 minute wait timeout AND then...
...set the clock BACK 24 hours to the correct/current time with ntpd, wait_for() doesn't return after 2 minutes (assuming no notify() of course). (Presumably, wait_for() is using system_clock, and not steady_clock, and will fire in 24 hours + 2 minutes -- but I haven't waited to find out.)
However, if I repeat this experiment and call std::condition_variable::wait_until() with a timeout time_point calculated as std::chrono::steady_clock::now() + std::chrono::milliseconds( 120000 ), which neatly binds a steady_clock ref into the time_point, it does indeed fire in 2 minutes after the clock is set back, as expected.
In short, the std::condition_variable API that takes a std::chrono:duration does not work, but the one that takes a std::chrono::time_point does.
This is strange to me since sites like cppreference.com <http://cppreference.com/> indicate that both methods use a steady_clock to calculate duration AND imply that wait_for() may even implemented internally in terms of wait_until(). However, in this implementation, both of these assertions seem incorrect. Anyway, it seems like a bug.
Personally, I am fine, as I can implement a wrapper that does our wait_for() in terms of wait_until(), but it took a few days of chasing through our code to pin this down, so figured I share and maybe save someone some pain.
-- Ward
[-- Attachment #2: Type: text/html, Size: 3067 bytes --]
next reply other threads:[~2016-08-02 23:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-02 23:33 Ward Willats [this message]
2016-08-02 23:40 ` Patrick Oppenlander
2016-08-03 11:27 ` Szabolcs Nagy
2016-08-03 17:29 ` Ward Willats
2016-08-04 3:47 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3008FD15-1C92-4870-9CD9-BC8B694ACCD0@wardco.com \
--to=musl@wardco.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).