public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "aaron at aarongraham dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/41861] [C++0x] <condition_variable> does not use monotonic_clock Date: Tue, 10 Nov 2009 04:38:00 -0000 [thread overview] Message-ID: <20091110043804.14281.qmail@sourceware.org> (raw) In-Reply-To: <bug-41861-12114@http.gcc.gnu.org/bugzilla/> ------- Comment #6 from aaron at aarongraham dot com 2009-11-10 04:38 ------- So it appears that the problem is gthreads. The monotonic_clock support is purely superficial in gcc until gthreads supports such a concept. Developers will need to create their own clock and modify the standard library headers to use it should they require a reasonable level of reliability in the face of a possibly-changing system clock. But I think the Howard/Detlef debate is a separate issue. I believe they have determined that a condition_variable (and mutex) must continue to use a specific clock once the object is created, and to sync all given time points to that clock, and are arguing over whether or not that is implementable. No big deal. I just don't believe there is any particular requirement that it be the system_clock (and, if there were, I would think that to be a big mistake). In almost every project I've worked on, our purposes would be much better served if a monotonic_clock were used instead. Rarely do we care what the epoch is. What we do care about is timer reliability even when NTP (or some other mechanism) is changing the clock. But that's just my experience. Thanks for looking into this. I'm hoping for a resolution that doesn't make <condition_variable> and <mutex> all but useless as provided by the standard library sans modification. The boost team has already made some egregious mistakes in this area. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861
next prev parent reply other threads:[~2009-11-10 4:38 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-10-28 23:46 [Bug libstdc++/41861] New: " atgraham at gmail dot com 2009-10-29 0:31 ` [Bug libstdc++/41861] " paolo dot carlini at oracle dot com 2009-11-03 11:22 ` [Bug libstdc++/41861] [C++0x] " paolo dot carlini at oracle dot com 2009-11-03 13:58 ` cfairles at gcc dot gnu dot org 2009-11-03 15:27 ` cfairles at gcc dot gnu dot org 2009-11-03 15:37 ` paolo dot carlini at oracle dot com 2009-11-10 4:38 ` aaron at aarongraham dot com [this message] 2010-02-04 18:02 ` paolo dot carlini at oracle dot com 2010-02-05 12:53 ` [Bug libstdc++/41861] [DR 887][C++0x] " paolo dot carlini at oracle dot com 2010-02-05 12:53 ` [Bug libstdc++/41861] [C++0x] " paolo dot carlini at oracle dot com
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=20091110043804.14281.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).