From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cygnus.enyo.de (cygnus.enyo.de [79.140.189.114]) by sourceware.org (Postfix) with ESMTPS id 3AA933858C3A; Thu, 12 Oct 2023 16:40:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3AA933858C3A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de Received: from [172.17.203.2] (port=60377 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1qqyjB-00BuLY-PN; Thu, 12 Oct 2023 16:40:01 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.96) (envelope-from ) id 1qqyjB-0002MS-2A; Thu, 12 Oct 2023 18:40:01 +0200 From: Florian Weimer To: Olivier Dion Cc: libc-help@sourceware.org, libc-alpha@sourceware.org, Mathieu Desnoyers , Adhemerval Zanella Netto , "carlos@redhat.com" Subject: Re: Dead code in pthread_cond_wait() for spin-wait References: <87a5spvwoi.fsf@laura> <87ttqvvo7k.fsf@laura> Date: Thu, 12 Oct 2023 18:40:01 +0200 In-Reply-To: <87ttqvvo7k.fsf@laura> (Olivier Dion's message of "Thu, 12 Oct 2023 11:45:51 -0400") Message-ID: <87mswnn6am.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Olivier Dion: > On Wed, 11 Oct 2023, Adhemerval Zanella Netto wrote: >> On 11/10/23 15:30, Olivier Dion via Libc-help wrote: > > [...] > >>> However, looking at the following snippet in nptl/pthread_cond_wait.c: >>> >>> static __always_inline int >>> __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, >>> clockid_t clockid, const struct __timespec64 *abstime) >>> { >>> const int maxspin = 0; >>> [...] >>> /* Spin-wait first. [...] */ >>> unsigned int spin = maxspin; >>> while (signals == 0 && spin > 0) { >>> [...] >>> } >>> [...] >>> } >>> >> >> Afaik it was added a placeholder for future extension, so fell free to >> send a patch to delete it. > > [...] > > What about making it work instead? Would this be something to consider? > IMHO it would be worth it. Having a fast-path that spins instead of > taking the futex directly can greatly impact performance in some cases. Changes to the condvar code are very difficult for us. There's an open bug with patches that have been under review for years: pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing