From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15546 invoked by alias); 7 Jan 2018 20:55:53 -0000 Mailing-List: contact libstdc++-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libstdc++-owner@gcc.gnu.org Received: (qmail 15411 invoked by uid 89); 7 Jan 2018 20:55:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-27.6 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=risks X-Spam-User: qpsmtpd, 2 recipients X-HELO: relay.appriver.com Received: from relay101a.appriver.com (HELO relay.appriver.com) (207.97.230.14) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 07 Jan 2018 20:55:51 +0000 X-Note: This Email was scanned by AppRiver SecureTide X-Note-AR-ScanTimeLocal: 01/07/2018 3:53:48 PM X-Note: SecureTide Build: 12/19/2017 1:37:44 PM UTC (2.6.27.2) X-Note: Filtered by 10.238.11.161 X-Note-AR-Scan: None - PIPE Received: by relay.appriver.com (CommuniGate Pro PIPE 6.1.7) with PIPE id 273613008; Sun, 07 Jan 2018 15:53:48 -0500 Received: from [213.210.30.29] (HELO elite.brightsign) by relay.appriver.com (CommuniGate Pro SMTP 6.1.7) with ESMTPS id 273612986; Sun, 07 Jan 2018 15:53:48 -0500 Received: from chuckie.brightsign ([fd44:d8b8:cab5:cb01::19] helo=chuckie) by elite.brightsign with esmtp (Exim 4.89) (envelope-from ) id 1eYHyr-0008uy-LO; Sun, 07 Jan 2018 20:55:45 +0000 Received: from mac by chuckie with local (Exim 4.89) (envelope-from ) id 1eYHyr-0003RK-Kn; Sun, 07 Jan 2018 20:55:45 +0000 From: Mike Crowe To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Cc: Mike Crowe Subject: [PATCH 4/5] libstdc++ atomic_futex: Use std::chrono::steady_clock as reference clock Date: Sun, 07 Jan 2018 20:55:00 -0000 Message-Id: <20180107205532.13138-5-mac@mcrowe.com> In-Reply-To: <20180107205532.13138-1-mac@mcrowe.com> References: <20180107205532.13138-1-mac@mcrowe.com> X-Note: This Email was scanned by AppRiver SecureTide X-Note-AR-ScanTimeLocal: 01/07/2018 3:53:48 PM X-Note: SecureTide Build: 12/19/2017 1:37:44 PM UTC (2.6.27.2) X-Note: Filtered by 10.238.11.161 X-Policy: brightsign.biz X-Primary: brightsign.biz@brightsign.biz X-Virus-Scan: V- X-Note: ICH-CT/SI:0-0/SG:1 1/1/0001 12:00:00 AM X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-43/SG:1 1/7/2018 3:53:04 PM X-GBUdb-Analysis: 0, 213.210.30.29, Ugly c=0.476605 p=-0.960784 Source Normal X-Signature-Violations: 0-0-0-6198-c X-Note: Spam Tests Failed: X-Country-Path: ->->United Kingdom->United States X-Note-Sending-IP: 213.210.30.29 X-Note-Reverse-DNS: elite.brightsigndigital.co.uk X-Note-Return-Path: mcrowe@brightsign.biz X-Note: User Rule Hits: X-Note: Global Rule Hits: G293 G294 G295 G296 G300 G301 G433 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00034.txt.bz2 The user-visible effect of this change is that std::future::wait_for now uses std::chrono::steady_clock to determine the timeout. This makes it immune to changes made to the system clock. It also means that anyone using their own clock types with std::future::wait_until will have the timeout converted to std::chrono::steady_clock rather than std::chrono::system_clock. Now that use of both std::chrono::steady_clock and std::chrono::system_clock are correctly supported for the wait timeout, I believe that std::chrono::steady_clock is a better choice for the reference clock that all other clocks are converted to since it is guaranteed to advance steadily. The previous behaviour of converting to std::chrono::system_clock risks timeouts changing dramatically when the system clock is changed. --- libstdc++-v3/include/bits/atomic_futex.h | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/libstdc++-v3/include/bits/atomic_futex.h b/libstdc++-v3/include/bits/atomic_futex.h index 78f39fb4048..7dff848d8ad 100644 --- a/libstdc++-v3/include/bits/atomic_futex.h +++ b/libstdc++-v3/include/bits/atomic_futex.h @@ -71,7 +71,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION template class __atomic_futex_unsigned : __atomic_futex_unsigned_base { - typedef chrono::system_clock __clock_t; + typedef chrono::steady_clock __clock_t; // This must be lock-free and at offset 0. atomic _M_data; @@ -169,7 +169,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION unsigned _M_load_and_test_until_impl(unsigned __assumed, unsigned __operand, bool __equal, memory_order __mo, - const chrono::time_point<__clock_t, _Dur>& __atime) + const chrono::time_point& __atime) { auto __s = chrono::time_point_cast(__atime); auto __ns = chrono::duration_cast(__atime - __s); @@ -229,7 +229,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION _M_load_when_equal_until(unsigned __val, memory_order __mo, const chrono::time_point<_Clock, _Duration>& __atime) { - // DR 887 - Sync unknown clock to known clock. const typename _Clock::time_point __c_entry = _Clock::now(); const __clock_t::time_point __s_entry = __clock_t::now(); const auto __delta = __atime - __c_entry; @@ -241,7 +240,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION template _GLIBCXX_ALWAYS_INLINE bool _M_load_when_equal_until(unsigned __val, memory_order __mo, - const chrono::time_point<__clock_t, _Duration>& __atime) + const chrono::time_point& __atime) { unsigned __i = _M_load(__mo); if ((__i & ~_Waiter_bit) == __val) -- 2.11.0