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


  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: link
Be 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).