From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25048 invoked by alias); 10 Apr 2015 09:56:23 -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 25030 invoked by uid 89); 10 Apr 2015 09:56:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 10 Apr 2015 09:56:21 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3A9uKdZ006586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 10 Apr 2015 05:56:20 -0400 Received: from [10.36.7.15] (vpn1-7-15.ams2.redhat.com [10.36.7.15]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3A9uIFR015671; Fri, 10 Apr 2015 05:56:18 -0400 Subject: Re: [patch] Fix shared_timed_mutex::try_lock_until() et al From: Torvald Riegel To: Jonathan Wakely Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org In-Reply-To: <20150410083757.GV9755@redhat.com> References: <20150407142830.GG9755@redhat.com> <1428512373.924.26.camel@triegel.csb> <20150408191159.GQ9755@redhat.com> <20150408193808.GR9755@redhat.com> <1428624966.924.32.camel@triegel.csb> <20150410083757.GV9755@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 10 Apr 2015 09:56:00 -0000 Message-ID: <1428659777.2909.1.camel@triegel.csb> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00442.txt.bz2 On Fri, 2015-04-10 at 09:37 +0100, Jonathan Wakely wrote: > On 10/04/15 02:16 +0200, Torvald Riegel wrote: > >On Wed, 2015-04-08 at 20:38 +0100, Jonathan Wakely wrote: > >> On 08/04/15 20:11 +0100, Jonathan Wakely wrote: > >> >We can get rid of the _Mutex type then, and just use std::mutex, > >> >and that also means we can provide the timed locking functions > >> >even when !defined(_GTHREAD_USE_MUTEX_TIMEDLOCK). > >> > > >> >And so maybe we should use this fallback implementation instead of > >> the > >> >pthread_rwlock_t one when !defined(_GTHREAD_USE_MUTEX_TIMEDLOCK), > >> >so that they have a complete std::shared_timed_mutex (this applies > >> >to at least Darwin, not sure which other targets). > >> > >> Here's a further patch to do that (which really needs to go into > >> 5.0 too, so we don't switch Darwin to the new pthread_rwlock_t > >> version and then have to swtich it back again in 6.0). > > > >I understand why a mutex with timeouts isn't required anymore, but > >why do you now add it to the USE_PTHREAD_RWLOCK_T condition? If > >pthread_rwlock_t is available, why would we need a normal mutex with > >timeouts? > > Darwin and HPUX support pthread_rwlock_t but not the timed lock > functions, see https://gcc.gnu.org/PR64847 and (part of) > https://gcc.gnu.org/PR64368 which were "fixed" by > https://gcc.gnu.org/r220161 which just disables the timed lock > functions on those targets, using #if _GTHREAD_USE_MUTEX_TIMEDLOCK. > > That means Darwin and HPUX have an incomplete shared_timed_mutex that > doesn't support the timed functions (i.e. what might get added to > C++17 as std::shared_mutex). > > The patch below gives Darwin and HPUX a fully conforming (albeit > slower) shared_timed_mutex, by ensuring we don't use pthread_rwlock_t > for targets that can't use timed functions with pthread_rwlock_t. > > If std::shared_mutex is added to the standard we could use > pthread_rwlock_t for that even on Darwin and HPUX, because it provides > everything needed for a non-timed std::shared_mutex. Ah, right. I was confused by the name, thinking those targets don't support pthread_mutex_timedlock, not pthread_rwlock_timedrdlock etc.