From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by sourceware.org (Postfix) with ESMTPS id 923033858D20 for ; Thu, 14 Dec 2023 22:23:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 923033858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=twrodgers.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=twrodgers.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 923033858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::134 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702592604; cv=none; b=LKrVgL/3Fu0FfYz8DJ1xbeC8F+VGAK6NgHfOSnwbQro7Xo7BhaPj16QCn026LT97Ar7vJJrmzVtBhhwMVCZGumpYsnEFNmI42PW5usxXdiugpctFaTwDkqtqnL5KHcorOorRJFAHbKa80Td8Jwp8gDmKi13guEPCB+Q7hl4I/k4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702592604; c=relaxed/simple; bh=b2tIaEz0qMw9FpsB1vVvXE+gRCMoYeWc19d/X/YNWjk=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=UKwu4K+Tu2t5O/6NkHvZI9xHW/kSy+iR/3W/RDCRgDSCoreUKbPfGzB5vU1G+kIy3jAVxry9YPr1KRmOC3qcaxhgSKHAj5tA5RB7fhcjoRWXcKm3Yv6utUdn6RPSy33O7ysPWRj0brzSr2shk7c8xqsvHiGiCI3ENNH9Wffoeh4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-50e1b82f949so996412e87.2 for ; Thu, 14 Dec 2023 14:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twrodgers-com.20230601.gappssmtp.com; s=20230601; t=1702592600; x=1703197400; 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=kKTn9PLhTl4L6Jk+xikl19AIALEfFtESQKT/sptQBUM=; b=l7XLZ8wgXf7cdBcpbq5cbvAeQL4rEH1HkgQ6NqnGcYVk8r5MawF3Z3boSREDxjfLuC 4584AAIxNapiPfjxqVxQ0VMCCrqUrH0kmTGVPKAB5xrG1279rnzrB/3Nf1gJRERKu/wW WWaB51lU+9acTBSLEBPJy6X/xuyq2Pmv8RmNDhsvi2xHLm1JdHwgobc8Wd7Ih9YJ/47M Z/x34Jc5AWhN14D2tAKcHgGSorVOUHkqAK1b9RZwlT9zXp3jl94YKIIws+5bYojuLWw3 S7cZ7z07BBTOTN+toi60FK3o9B7/DAVj2HwwgDyk1V7z9WF/+Y+i4bs8lUaD6W/NMlBW ZbuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702592600; x=1703197400; 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=kKTn9PLhTl4L6Jk+xikl19AIALEfFtESQKT/sptQBUM=; b=umsrBu5P0JIXvNWcVQPGyceHV8yYw6Zuw8hfmQtVeItl8xKCK0BFnpCllnmaN99aiF uia6Wxp3r/DBVv6mN1I3BgQpQvNiJzXobIbeR1Lsgadu1jpoyhW9j8HYOTRkNWvuDWaM A63eSAKcMssmFTuDyaQ3yAv4uUTxxLr4JyPtpc5S04i15jOz6M1CoycLHZ+d72ogmwOH Eaws3YlXMq36OtByX7xABoO/IayOONpq6Swf7hrctfvoAZ9pQO0pyQc4MNVUzO6dgx2a 4ZShw4hYTeFSHVEycePbIENmAtA0VJT1L2ee0RDczaoEC1tqaaFAcI/VisjiN6nHljOX FuhA== X-Gm-Message-State: AOJu0YzNq0LmehoEUTCog+ChMVlqkzS+cMMRQx/yON9xxsEYt5hunp9u RWOR+k1KxqnccCK28q385CWS38ZIML/q8IkBYMhrrg== X-Google-Smtp-Source: AGHT+IFHi69Wo5DMFBqNs6p5XoIwVuUHiUOjTuMPez4LKVSQaaW9RetTh788puCm/x6qsEFlRzbP2gMVuHjMwKeNgiQ= X-Received: by 2002:a05:6512:3d18:b0:50e:16c8:aba5 with SMTP id d24-20020a0565123d1800b0050e16c8aba5mr1211902lfv.44.1702592599880; Thu, 14 Dec 2023 14:23:19 -0800 (PST) MIME-Version: 1.0 References: <88357210-2f36-4711-1b2b-0b4185810e7c@thatsmathematics.com> In-Reply-To: From: Thomas Rodgers Date: Thu, 14 Dec 2023 14:23:08 -0800 Message-ID: Subject: Re: [PATCH 1/2] libstdc++: Atomic wait/notify ABI stabilization To: Jonathan Wakely Cc: Jonathan Wakely , Nate Eldredge , gcc-patches , "libstdc++" Content-Type: multipart/alternative; boundary="0000000000001d0b44060c7fbb4f" X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,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: --0000000000001d0b44060c7fbb4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I need to look at this a bit more (and not on my phone, at lunch). Ultimately, C++26 expects to add predicate waits and returning a =E2=80=98tri-state=E2=80=99 result isn=E2=80=99t something that=E2=80=99s b= een considered or likely to be approved. On Mon, Dec 11, 2023 at 12:18=E2=80=AFPM Jonathan Wakely wrote: > 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 =3D __val;` inside the l= oop >> 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 =3D __val; >> __detail::__wait_impl(__wait_addr, &__args); >> __val =3D __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 =3D=3D 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 >> >> --0000000000001d0b44060c7fbb4f--