From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89197 invoked by alias); 20 Jul 2018 10:53:43 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 89179 invoked by uid 89); 20 Jul 2018 10:53:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=waking, 2018-07-06, HTo:U*mac, wakeup X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Jul 2018 10:53:41 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3707281A4EA6; Fri, 20 Jul 2018 10:53:39 +0000 (UTC) Received: from localhost (unknown [10.33.36.108]) by smtp.corp.redhat.com (Postfix) with ESMTP id E02711C5B4; Fri, 20 Jul 2018 10:53:38 +0000 (UTC) Date: Fri, 20 Jul 2018 10:53:00 -0000 From: Jonathan Wakely To: Mike Crowe Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH 1/2] condition_variable: Report early wakeup of wait_until as no_timeout Message-ID: <20180720105338.GQ14057@redhat.com> References: <20180710100929.32704-1-mac@mcrowe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180710100929.32704-1-mac@mcrowe.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.2 (2017-12-15) X-SW-Source: 2018-07/txt/msg01162.txt.bz2 On 10/07/18 11:09 +0100, Mike Crowe wrote: >As currently implemented, condition_variable always ultimately waits >against std::chrono::system_clock. This clock can be changed in arbitrary >ways by the user which may result in us waking up too early or too late >when measured against the caller-supplied clock. > >We can't (yet) do much about waking up too late[1], but >if we wake up too early we must return cv_status::no_timeout to indicate a >spurious wakeup rather than incorrectly returning cv_status::timeout. The patch looks good, thanks. Can we come up with a test for this, using a user-defined clock that jumps back? >[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861 >--- > libstdc++-v3/ChangeLog | 5 +++++ > libstdc++-v3/include/std/condition_variable | 8 +++++++- > 2 files changed, 12 insertions(+), 1 deletion(-) > >diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog >index cceef0271ae..ea7875ace9f 100644 >--- a/libstdc++-v3/ChangeLog >+++ b/libstdc++-v3/ChangeLog >@@ -1,3 +1,8 @@ >+2018-07-09 Mike Crowe >+ * include/std/condition_variable (wait_until): Only report timeout >+ if we really have timed out when measured against the >+ caller-supplied clock. >+ > 2018-07-06 François Dumont > > * include/debug/functions.h (__gnu_debug::__check_string): Move... >diff --git a/libstdc++-v3/include/std/condition_variable b/libstdc++-v3/include/std/condition_variable >index 84863a162d6..a2d146a9b09 100644 >--- a/libstdc++-v3/include/std/condition_variable >+++ b/libstdc++-v3/include/std/condition_variable >@@ -116,7 +116,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > const auto __delta = __atime - __c_entry; > const auto __s_atime = __s_entry + __delta; > >- return __wait_until_impl(__lock, __s_atime); >+ // We might get a timeout when measured against __clock_t but >+ // we need to check against the caller-supplied clock to tell >+ // whether we should return a timeout. >+ if (__wait_until_impl(__lock, __s_atime) == cv_status::timeout) >+ return _Clock::now() < __atime ? cv_status::no_timeout : cv_status::timeout; >+ else >+ return cv_status::no_timeout; > } > > template >-- >2.11.0 > >BrightSign considers your privacy to be very important. The emails you send to us will be protected and secured. Furthermore, we will only use your email and contact information for the reasons you sent them to us and for tracking how effectively we respond to your requests.