public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
	'GNU C Library' <libc-alpha@sourceware.org>
Subject: Re: [PATCH] Use C11 atomics instead of atomic_increment(_val)
Date: Thu, 22 Sep 2022 13:27:39 +0000	[thread overview]
Message-ID: <AS4PR08MB790100A963BBCFF2CD957FC2834E9@AS4PR08MB7901.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <b7c7b925-17ac-7b7c-be08-aa7773b629da@linaro.org>

Hi Adhemerval,

In general you only need acquire/release for locks that synchronize access to
shared data which does not use atomic accesses. If there is no such shared
data, there is no need for acquire/release. Similarly only using acquire and never
release (as the old atomics did) makes no sense - you need a release atomic
to synchronize with.

> I am not sure if relaxed MO is correct here, shouldn't it synchronize with the
> __nptl_setxid_sighandler ?

The counter cntr in nptl/nptl_setxid.c is just a simple atomic counter to keep
track of the number of outstanding signals that were sent to threads. There is
no data it is trying to synchronize with, so release/acquire semantics do not
make sense here.

> Not sure if this is correct for hurd, __pthread_total is used on __pthread_exit
> to call exit although for i686 atomic_decrement_and_test will be used and it
> has strong MO.

The same is true for pthread_total counter, it is used to call exit when the last
thread stops. Note while the increment is done optimistically (thread creation
can fail, and then it is decremented again), the decrement resulting in a call to
exit can only happen once even if multiple threads are finishing concurrently
(and that happen once is what is required). 

Cheers,
Wilco



> diff --git a/htl/pt-create.c b/htl/pt-create.c
> index ce52ed9f52210a4e4c7a049ebee817ec9ccfeeb1..14f02cd2b8a19e8581a170dfba2b948ef8304203 100644
> --- a/htl/pt-create.c
> +++ b/htl/pt-create.c
> @@ -228,7 +228,7 @@ __pthread_create_internal (struct __pthread **thread,
>       the number of threads from within the new thread isn't an option
>       since this thread might return and call `pthread_exit' before the
>       new thread runs.  */
> -  atomic_increment (&__pthread_total);
> +  atomic_fetch_add_relaxed (&__pthread_total, 1);
>  
>    /* Store a pointer to this thread in the thread ID lookup table.  We
>       could use __thread_setid, however, we only lock for reading as no

Not sure if this is correct for hurd, __pthread_total is used on __pthread_exit
to call exit although for i686 atomic_decrement_and_test will be used and it
has strong MO.


> diff --git a/nptl/nptl_setxid.c b/nptl/nptl_setxid.c
> index aa863c7ea8122ea01d1aa4cffe101bbb7c11270c..3b7e2d434abe8a15145349d1a08a4e706061c74d 100644
> --- a/nptl/nptl_setxid.c
> +++ b/nptl/nptl_setxid.c
> @@ -163,7 +163,7 @@ setxid_signal_thread (struct xid_command *cmdp, struct pthread *t)
>    /* If this failed, it must have had not started yet or else exited.  */
>    if (!INTERNAL_SYSCALL_ERROR_P (val))
>      {
> -      atomic_increment (&cmdp->cntr);
> +      atomic_fetch_add_relaxed (&cmdp->cntr, 1);
>        return 1;
>      }
>    else

I am not sure if relaxed MO is correct here, shouldn't it synchronize with the
__nptl_setxid_sighandler ?

  reply	other threads:[~2022-09-22 13:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-08 14:01 Wilco Dijkstra
2022-09-21 17:17 ` Adhemerval Zanella Netto
2022-09-22 13:27   ` Wilco Dijkstra [this message]
2022-09-23 13:26     ` Adhemerval Zanella Netto

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=AS4PR08MB790100A963BBCFF2CD957FC2834E9@AS4PR08MB7901.eurprd08.prod.outlook.com \
    --to=wilco.dijkstra@arm.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    /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).