public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Iain Sandoe <iain@sandoe.co.uk>
Cc: "libstdc++" <libstdc++@gcc.gnu.org>,
	Thomas Rodgers <trodgers@redhat.com>
Subject: Re: [RFA] choosing __platform_wait_t on targets without lock-free 64 atomics
Date: Thu, 29 Dec 2022 12:09:29 +0000	[thread overview]
Message-ID: <CAH6eHdRQAGFO6UTGTTW=UCmQJtCODL1_ArNZ59dsGzJTsammPw@mail.gmail.com> (raw)
In-Reply-To: <6640F26B-F267-40E0-9223-2F0F45462176@sandoe.co.uk>

[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

On Thu, 29 Dec 2022, 11:29 Iain Sandoe, <iain@sandoe.co.uk> wrote:

> Hi,
>
> The recent addition of the tz handling has pulled in a dependency on
> </bits/atomic_wait.h>
>
> 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.


> Advice on the right way to fix this welcome — 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.






> thanks
> Iain
>
> ----
>
>
> diff --git a/libstdc++-v3/include/bits/atomic_wait.h
> b/libstdc++-v3/include/bits/atomic_wait.h
> index bd1ed56..2f67180 100644
> --- a/libstdc++-v3/include/bits/atomic_wait.h
> +++ b/libstdc++-v3/include/bits/atomic_wait.h
> @@ -64,7 +64,11 @@ _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 __LP64__
>      using __platform_wait_t = uint64_t;
> +#else
> +    using __platform_wait_t = uint32_t;
> +#endif
>      inline constexpr size_t __platform_wait_alignment
>        = __alignof__(__platform_wait_t);
>
>

  reply	other threads:[~2022-12-29 12:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-29 11:28 Iain Sandoe
2022-12-29 12:09 ` Jonathan Wakely [this message]
2022-12-29 15:30   ` Iain Sandoe
2022-12-29 15:44     ` Jonathan Wakely
2022-12-29 15:56       ` Iain Sandoe
2022-12-29 17:02         ` Jonathan Wakely
2022-12-30 10:51           ` Iain Sandoe
2023-01-02  0:53             ` Thomas Rodgers
2023-01-02  7:47               ` Iain Sandoe
2023-01-03  1:13                 ` Thomas Rodgers
2023-01-06  0:22                   ` Jonathan Wakely
2023-01-12  1:27                     ` Thomas Rodgers
2023-01-12 11:01                       ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH6eHdRQAGFO6UTGTTW=UCmQJtCODL1_ArNZ59dsGzJTsammPw@mail.gmail.com' \
    --to=jwakely.gcc@gmail.com \
    --cc=iain@sandoe.co.uk \
    --cc=libstdc++@gcc.gnu.org \
    --cc=trodgers@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).