From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by sourceware.org (Postfix) with ESMTPS id 774863858CDA; Mon, 11 Dec 2023 20:18:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 774863858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 774863858CDA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::334 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702325906; cv=none; b=JyonXeUTnpmYXGdBcf/08nbTQQ/nqnEGjKx/imTIdsmg1dpBoAjuK0siENzQ2cBhbxfA6RRe/al7oupNSNrtw8OqA5lQvCjvJbC8HyXXTV97utRWuChmel5r0pc8QKw0cN8F8E8HjilhBvlNExCaYcG04Ommwu8yvbn1uzKw3+A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702325906; c=relaxed/simple; bh=OjQB927hfvwXdSGI+oL5BeyVRQ5ghxYG1EblhU5ftDk=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=ri4R/lrGCx4XoXaU48qOhO9hDBLVh+LejXjD6zqzcxFi4woFIXuQN8wHjAFDLm3uyMJ3lWBoHqR8i4fBNNeQl/yxHLSz463tDsqRIxkCsP+PkXp0q2cRDamu+SO+Xee/oenVv39SXby+btOygWP+GccIdRZ9etcwlLW/ZF1ENIw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-40c2c5a8150so45536405e9.2; Mon, 11 Dec 2023 12:18:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702325894; x=1702930694; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=R3k6JFEFkveXmmwNTxxR07RiZhF3dZbOwOu+kbhYkH8=; b=OqGDn/50CU14wWWhk1rHskxcTrLbTKd1I3I9+WtleO5eVpS3gANi3HbYE4qaeRdhGw ITPB9v5VIBzVMFFoZxovhXmiwydiCUM8+dEEdL7YnQcmi4BUg2VhBBC2lRhngoPWMFUr dQXALNXDXcsC0W+DDQEeSNZMmY00gOfwOkAcS55FkcFSrAxRqG7KcQkNp6f42q94DQ/g 8ru7VNvYICmT+fRC1nxJT7Xc9sxveOEm0o4IqM471M+aRiotmwy56a7LKFiYIC63wJh5 KoTdbCX4BlGpekxbd9IYomDGpzUBAzs8d0qWw7DejOqXmUJZjG8Pt/HKwLeQfkGKHp3k uHzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702325894; x=1702930694; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R3k6JFEFkveXmmwNTxxR07RiZhF3dZbOwOu+kbhYkH8=; b=nmoF6qDh0/lOKfPzSY8l/DQJR5M12IpxzjA4UHgtYWggsoMPDmPmGGvOB/K4fTlEzP IOnZ1i4/MOeuRYBYlUsG+eIKj0wIxfIR8CgUDl9BkbZxIYGaLSXYYxlnuzwIbEmyIHd+ HEsYoCUS85zmPAnwmMNvkfne0rIqd2lVdj0z8UcFUK/E6s1T77MGADI6yNmALkzCRttQ 7BtuSSevNlThkzyHvmdUa2WyFHfah+FWm0AtpJ+h0Nosgk/AQWm7Bt4+zfopIYnMbA5A MRcbc9w8R1PULP/90CJzz/vKOczvu5KUqLM8W7WwNn9Z6XYptz4U7ufJgUHVIodR4tho kfSQ== X-Gm-Message-State: AOJu0YyIiSXwMYVLfkZbbnhKuFqTYPNEPFovOvrGMxSDWbw9o7UHGK3q U0ehHxAP70TB37FTRB1xucV6x4wiloALlkZ6WIA= X-Google-Smtp-Source: AGHT+IEUU0jxOqNiOdNinOUyBI5HxkN5wMtsDmSr7/tRAHdumLGyxVe2rAM4IpCwc4stk3mfew5WOLWs/sJbWv3U/Os= X-Received: by 2002:a1c:721a:0:b0:40c:25c7:b32d with SMTP id n26-20020a1c721a000000b0040c25c7b32dmr2660439wmc.136.1702325893967; Mon, 11 Dec 2023 12:18:13 -0800 (PST) MIME-Version: 1.0 References: <88357210-2f36-4711-1b2b-0b4185810e7c@thatsmathematics.com> In-Reply-To: From: Jonathan Wakely Date: Mon, 11 Dec 2023 20:18:01 +0000 Message-ID: Subject: Re: [PATCH 1/2] libstdc++: Atomic wait/notify ABI stabilization To: Nate Eldredge Cc: Jonathan Wakely , gcc-patches , "libstdc++" , Thomas Rodgers Content-Type: multipart/alternative; boundary="00000000000033b78f060c41a2ca" X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: --00000000000033b78f060c41a2ca Content-Type: text/plain; charset="UTF-8" CCing Tom's current address, as he's not @redhat.com now. On Mon, 11 Dec 2023, 19:24 Nate Eldredge, wrote: > On Mon, 11 Dec 2023, Nate Eldredge wrote: > > > To fix, we need something like `__args._M_old = __val;` inside the loop > in > > __atomic_wait_address(), so that we always wait on the exact value that > the > > predicate __pred() rejected. Again, there are similar instances in > > atomic_timed_wait.h. > > Thinking through this, there's another problem. The main loop in > __atomic_wait_address() would then be: > > while (!__pred(__val)) > { > __args._M_old = __val; > __detail::__wait_impl(__wait_addr, &__args); > __val = __vfn(); > } > > The idea being that we only call __wait_impl to wait on a value that the > predicate said was unacceptable. But looking for instance at its caller > __atomic_semaphore::_M_acquire() in bits/semaphore_base.h, the predicate > passed in is _S_do_try_acquire(), whose code is: > > _S_do_try_acquire(__detail::__platform_wait_t* __counter, > __detail::__platform_wait_t __old) noexcept > { > if (__old == 0) > return false; > > return __atomic_impl::compare_exchange_strong(__counter, > __old, __old - 1, > memory_order::acquire, > > memory_order::relaxed); > } > > It returns false if the value passed in was unacceptable (i.e. zero), *or* > if it was nonzero (let's say 1) but the compare_exchange failed because > another thread swooped in and modified the semaphore counter. In that > latter case, __atomic_wait_address() would pass 1 to __wait_impl(), which > is likewise bad. If the counter is externally changed back to 1 just > before we call __platform_wait (that's the futex call), we would go to > sleep waiting on a semaphore that is already available: deadlock. > > I guess there's a couple ways to fix it. > > You could have the "predicate" callback instead return a tri-state value: > "all done, stop waiting" (like current true), "value passed is not > acceptable" (like current false), and "value was acceptable but something > else went wrong". Only the second case should result in calling > __wait_impl(). In the third case, __atomic_wait_address() should > just reload the value (using __vfn()) and loop again. > > Or, make the callback __pred() a pure predicate that only tests its input > value for acceptability, without any other side effects. Then have > __atomic_wait_address() simply return as soon as __pred(__val) returns > true. It would be up to the caller to actually decrement the semaphore or > whatever, and to call __atomic_wait_address() again if this fails. In > that case, __atomic_wait_address should probably return the final value > that was read, so the caller can immediately do something like a > compare-exchange using it, and not have to do an additional load and > predicate test. > > Or, make __pred() a pure predicate as before, and give > __atomic_wait_address yet one more callback function argument, call it > __taker(), whose job is to acquire the semaphore etc, and have > __atomic_wait_address call it after __pred(__val) returns true. > > -- > Nate Eldredge > nate@thatsmathematics.com > > --00000000000033b78f060c41a2ca--