From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=hzio=FZ=efficios.com=odion@sourceware.org>
Received: from smtpout.efficios.com (unknown [IPv6:2607:5300:203:b2ee::31e5])
	by sourceware.org (Postfix) with ESMTPS id EFC973858D1E
	for <libc-help@sourceware.org>; Wed, 11 Oct 2023 18:30:37 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EFC973858D1E
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=efficios.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=efficios.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com;
	s=smtpout1; t=1697049037;
	bh=SrVcoMeMRKw6InI2biRUr1nwfLybzF8cAyV07v2zx+U=;
	h=From:To:Subject:CC:Date:From;
	b=QDMVPEuuFHvKgNfrlUydnilhRNukliBdnq2nEdDmE3jAR85WvsaRkLP6B1Kb2+pJc
	 lqZVKAdm9BBgQ+5iFwmMI2SftZ2qXtqs90Yv+9KwbV/7GgPLqvviuwk79j5xl1J9n2
	 CLOLINqIRGKh4FtEOc1lOO5D8uM0uuwtdHL8vfWrOzm7S1Ja9HtBkiWoNUN2wkNN0U
	 fJNfJH2pgUstfYmWtMFBXIMmbgaffd3ve1C2Bm1RuhW60/7SsEEQUYHEquWr7GE5WC
	 XWqrp9ToLBGDZnSyuNNbV0Jl+iIo+RLNhE50BxsnXZGExHj/1sd3TEAvYX125famVq
	 i/lObs2/T6icA==
Received: from localhost (modemcable094.169-200-24.mc.videotron.ca [24.200.169.94])
	by smtpout.efficios.com (Postfix) with ESMTPSA id 4S5LtP3bt0z1XGk;
	Wed, 11 Oct 2023 14:30:37 -0400 (EDT)
From: Olivier Dion <odion@efficios.com>
To: libc-help@sourceware.org
Subject: Dead code in pthread_cond_wait() for spin-wait
Organization: EfficiOS
CC: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date: Wed, 11 Oct 2023 14:30:37 -0400
Message-ID: <87a5spvwoi.fsf@laura>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: <libc-help.sourceware.org>

Hi,

Commit ed19993b5b0d05d62cc883571519a67dae481a14 from 2016 introduce "a
new implementation of condition variables".  This new implementation
seems to introduce a spin-wait fast-path to avoid taking the underlying
futex when doing a pthread_cond_wait().

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) {
             [...]
           }
   [...]
 }

it seems to me that the try-spinning portion is dead code in
pthread_cond_wait_common(). I was wondering why this was the case?

I also think that there would maybe some interest in using the Userspace
RCU wait algorithm [0] for this.

 [0] https://github.com/urcu/userspace-rcu/blob/master/src/urcu-wait.h

Thanks,

Olivier

-- 
Olivier Dion
EfficiOS Inc.
https://www.efficios.com