From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id 753F73858D20 for ; Thu, 29 Dec 2022 15:44:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 753F73858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x635.google.com with SMTP id tz12so45807884ejc.9 for ; Thu, 29 Dec 2022 07:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Dim4CZmyC884jhTS26YX1xCfLPs4WoyWSX0HlHDfDxc=; b=baI7tRA70tyBW0Awr5gbQ/rkreNTp6jXSXW6efE8t4Ps0NgPlVatCjktQeH/xFuTLb /934+J0WNUV0k1cwGsn7OSx3HwqEUMd70I2kfvUmTZBRD3vhli8aO0ubvfJ0h3wvGYl7 idL7i6RAZqUyYrZT105GVANjWrK+5eoh9Obczh+1z9K0a6RVd74PZSe3ODE0RxlaIDm6 j904VgmB9TWMz2YvvaDgST8FJu1wsGua7rvMfScsuz87xADfMzeVTC/SrJAec+4Gpn/x OnHY7itD/Rr8aYxLkA4pPKx8gm5N6wcxhR9DM6bDETonT4cznAwHXcR1g/nSwzoqseuc YzUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Dim4CZmyC884jhTS26YX1xCfLPs4WoyWSX0HlHDfDxc=; b=30rmMeczgDg65OG4HsAS82sQ/anhDZ+537S+A0Y+uZKMG97vyzh+6sMf715FGby2Qe 5xhd3zm6L84DUqEbnhNcT0EmbuNKXb4jUayyXNjGa0uvtv1bErNtqAQ1LirqO85fQbjW b473qqufUMZGgTEh4hGcKoX/AD1ZotSrlsdSV59LXTQ/WiCJjLLKIFqTFPBz3O5GMpeB P0uHMckMvOUOIBTDNP6dwk3wO2lxV8nRUGmyuUWp+4hbEUpBKI9ZbgGefplfUtYhjqE7 VSpnSlnGkhDEBGl8Lv9xQ2gl/AwvpOgELCTcmPwfpqbDyqOy5ftKTDEE/SOZBHpnh86n lLpQ== X-Gm-Message-State: AFqh2kp5jCUlegTySAqi9hY87zzSPV7Cqfd80IXl32lXSzkPz3tRLvVQ aaRORFXowq9M/U1JIHdKx7jZRZf29TyQZfMI244= X-Google-Smtp-Source: AMrXdXvztDvKapGddnbBShMmm1oSYWfrdGMFMMJJuPt/HNGN6MJIpscgREbrFYB9wZMgeYGMGZ/k/o9eB5x2eIIWvtU= X-Received: by 2002:a17:906:2896:b0:7ea:5ba6:e773 with SMTP id o22-20020a170906289600b007ea5ba6e773mr2894540ejd.506.1672328683123; Thu, 29 Dec 2022 07:44:43 -0800 (PST) MIME-Version: 1.0 References: <6640F26B-F267-40E0-9223-2F0F45462176@sandoe.co.uk> <05A9C1EF-7EC9-4276-BA11-8922A66B3D3A@sandoe.co.uk> In-Reply-To: <05A9C1EF-7EC9-4276-BA11-8922A66B3D3A@sandoe.co.uk> From: Jonathan Wakely Date: Thu, 29 Dec 2022 15:44:31 +0000 Message-ID: Subject: Re: [RFA] choosing __platform_wait_t on targets without lock-free 64 atomics To: Iain Sandoe Cc: "libstdc++" , Thomas Rodgers Content-Type: multipart/alternative; boundary="0000000000001af9ca05f0f95d2f" X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,HTML_MESSAGE,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: --0000000000001af9ca05f0f95d2f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 29 Dec 2022, 15:30 Iain Sandoe, wrote: > Hi Folks, > > > On 29 Dec 2022, at 12:09, Jonathan Wakely wrote: > > > On Thu, 29 Dec 2022, 11:29 Iain Sandoe, wrote: > > >> The recent addition of the tz handling has pulled in a dependency on > > >> > >> This currently specifies __platform_wait_t as a 64bit quatity on > platforms without _GLIBCXX_HAVE_LINUX_FUTEX. > >> > >> PowerPC does not have a 64b atomic without library support - so that > this causes a bootstrap > >> fail on powerpc-darwin (and I guess any other 32b powerpc non-futex > target). > >> > >> Rather than contrive to build and add libatomic (which is not at > present available at the point > >> that libstdc++ is built), I wonder if there is any specific reason that > __platform_wait_t needs > >> to be 64 bits on these platforms? (Especially since the futex case uses > an int.) > >> > > I think we do want the generic case's _M_wait atomic variable to be lock > free, otherwise we use two locks for every operation, the one in libatomic > and the waiter mutex. That's more important than it being any specific > width. > > Definitely, that=E2=80=99s probably a recipe for some subtle race conditi= on .. > nested locks etc. > I didn't see any nested cases from a quick look, but it would still be better to avoid two locks. > >> Advice on the right way to fix this welcome =E2=80=94 as a work-around= to allow > bootstrap to complete > >> I applied the patch below - but that seems unlikely to be the right > thing generically . > >> > > Rather than __lp64__ I think we should check the ATOMIC_LONG_LOCK_FREE > macro and use long if it's lock free and int otherwise. But Tom needs to > confirm that. That would be approximately the same as your patch in > practice. > > OK.. that makes sense here=E2=80=99s a proposed patch (pending subsequent= input > from Tom). > > I am using =E2=80=9Clock free always=E2=80=9D as the criterion, =E2=80=9C= sometimes=E2=80=9D does not seem > useful here. > Agreed. > Although we normally build libstdc++ with the just-built GCC... > .. AFAIK the __SIZEOF_* are available from any version of GCC or clang > that would > be capable of building the sources. > Yep, but do we need the size checks at all? I was thinking we could just use 'unsigned long' or 'unsigned int' directly, instead of a uintN_t typedef. Using the typedef just seems to complicate things. > The contortion in the first #elif is attempting to cater for the > (supposed, possible) case > that there could be a 16b int target with a lock free 32b long (that might > be a stretch > so feel free to delete the second half). > > .. wider testing will follow, smoke tested only ... > > cheers > Iain > > =3D=3D=3D=3D=3D=3D=3D=3D > > diff --git a/libstdc++-v3/include/bits/atomic_wait.h > b/libstdc++-v3/include/bits/atomic_wait.h > index bd1ed56..3ef0e92 100644 > --- a/libstdc++-v3/include/bits/atomic_wait.h > +++ b/libstdc++-v3/include/bits/atomic_wait.h > @@ -64,7 +64,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > // and __platform_notify() if there is a more efficient primitive > supported > // by the platform (e.g. __ulock_wait()/__ulock_wake()) which is better > than > // a mutex/condvar based wait. > +# if (__SIZEOF_LONG__ =3D=3D 8 && ATOMIC_LONG_LOCK_FREE =3D=3D 2) || \ > + (__SIZEOF_LONG_LONG__ =3D=3D 8 && ATOMIC_LLONG_LOCK_FREE =3D=3D 2) > using __platform_wait_t =3D uint64_t; > +# elif (__SIZEOF_INT__ =3D=3D 4 && ATOMIC_INT_LOCK_FREE =3D=3D 2) || \ > + (__SIZEOF_LONG__ =3D=3D 4 && ATOMIC_LONG_LOCK_FREE =3D=3D 2) > + using __platform_wait_t =3D uint32_t; > +# elif (__SIZEOF_INT__ =3D=3D 2 && ATOMIC_INT_LOCK_FREE =3D=3D 2) > + using __platform_wait_t =3D uint16_t; > +# endif > inline constexpr size_t __platform_wait_alignment > =3D __alignof__(__platform_wait_t); > #endif > > --0000000000001af9ca05f0f95d2f--