From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id C44B73858D1E for ; Wed, 11 Oct 2023 18:57:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C44B73858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-1c87a85332bso1252295ad.2 for ; Wed, 11 Oct 2023 11:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1697050657; x=1697655457; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=mhf2N6WurlJNxiSF5UXD0ImlQgzYbwfxKeQgXAOQ/OQ=; b=sAl/NxqfyXmYOpsnKl9rAh8+vFFrUq8vIyKOQATDnCY7hiPzST/rSREoGcJLzUbOaZ g1rs1yQ67ZPxsyPj8YSmnenlIqx8IKdZPqmB/rozFfp5J49KHCpZ+Ivgw5pojlpEfeY4 Gzj0xDCO9jpWfgVY6GtjJHJX9VF0hMGjxZ3opYI0KjlZCV13X4iuI2BdCuKqaczq83CH 9e22nSiB6yBqnoF0PhrOJorQBSepVvW6qoaT+vnuaSrEqnoQqU3ZeuK9B7OfqC6BAjkK 3gW+JbLm6MOU4dTTPxVXPpXnVXt4cPMGlk+Wt2E8PnRa3Q/z2CDW8BoLsyp6+GfscJds x0sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697050657; x=1697655457; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mhf2N6WurlJNxiSF5UXD0ImlQgzYbwfxKeQgXAOQ/OQ=; b=ox+ODqmL7JZTPg8UNFgdZzeEzym0PFhg9IbrTHVcel5ANc99b4vPEZkuYJ0+C5GY/9 nAQHqnDdbreimZOQBFRXvXZvbuAe4b8ltGWPa6umwfjj3q5E9fDXeRt4MaH6sT0IIY8u tUYGvcVylu0xv8SAzgQxBFIU1De1zYgevHxTfmVlv+Mk8ZtujDZTSrTia7Le2qMTM5FR bofJD/60yc+wa/esu787hWuxtNRkVXv5Id2vhxEFMlVBFSwJYHNTve9vS8FDqG3MznOF H8nN6LTXEVJNc+GtqZ/tptXjeB9F26Kc2jwIRmFHyX/5iRk8F7589BSV64pO0ooG3Phh n5TA== X-Gm-Message-State: AOJu0YzatuCFZcivsI+6Q2e0BhjWU8kjQDVCcRoQ0iwr/7M632tYdzA0 JAMBYtdW3vXpUWlbpN+4yqm32OgBSAhHXFv9++KwuA== X-Google-Smtp-Source: AGHT+IH6XK0u9qKdHT88VRoQ5CGocrPAFSW3fX2SzOYe6l+v20HgwbKKgc1Qwd9GHETURh+Dlm76nw== X-Received: by 2002:a17:902:d2c3:b0:1bf:826:9e30 with SMTP id n3-20020a170902d2c300b001bf08269e30mr27765404plc.16.1697050657650; Wed, 11 Oct 2023 11:57:37 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c2:d09b:642a:4b0f:e5f0:8bf7? ([2804:1b3:a7c2:d09b:642a:4b0f:e5f0:8bf7]) by smtp.gmail.com with ESMTPSA id w12-20020a170902e88c00b001c5f62a639asm172439plg.196.2023.10.11.11.57.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Oct 2023 11:57:37 -0700 (PDT) Message-ID: Date: Wed, 11 Oct 2023 15:57:34 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Dead code in pthread_cond_wait() for spin-wait To: Olivier Dion , libc-help@sourceware.org Cc: Mathieu Desnoyers References: <87a5spvwoi.fsf@laura> Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <87a5spvwoi.fsf@laura> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,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: On 11/10/23 15:30, Olivier Dion via Libc-help wrote: > 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) { > [...] > } > [...] > } > Afaik it was added a placeholder for future extension, so fell free to send a patch to delete it. > 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 >