From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35542 invoked by alias); 7 Jul 2015 15:49:42 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 34853 invoked by uid 48); 7 Jul 2015 15:49:34 -0000 From: "mac at mcrowe dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/41861] [DR 887][C++0x] does not use monotonic_clock Date: Tue, 07 Jul 2015 15:49:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 4.4.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mac at mcrowe dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-07/txt/msg00550.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861 --- Comment #9 from Mike Crowe --- It seems that there's been lots of talk about this but no firm solution. Here's some interesting links: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2999.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4486.html (search for "887") https://www.redhat.com/archives/posix-c++-wg/2009-July/msg00002.html (search for "887") https://github.com/cplusplus/LWG/blob/master/xml/issue0887.xml To me they seem to boil down to three points of view: 1. The current implementation of converting all other clocks to the system_clock is acceptable behaviour. Unfortunately this is racey when the system clock is changed and could cause the caller to wait for far longer than requested. 2. Implementers should add an extra constructor parameter (or perhaps template parameter) to condition_variable to allow the master clock for the condition_variable to be configured. All clocks would then be converted to this clock. This would allow the client code to express its intent but it seems ugly to require platform-specific code to make the standard behaviour actually work. 3. condition_variable should support wait_until using at least steady_clock (CLOCK_MONOTONIC) and system_clock (CLOCK_REALTIME.) Relative wait operations should use steady_clock. User-defined clocks should probably convert to steady_clock. I believe that only option 3 makes any sense but this requires an equivalent to pthread_cond_timedwait that supports specifying the clock. The glibc implementation of such a function would be straightforward.