public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Cc: 'GNU C Library' <libc-alpha@sourceware.org>
Subject: Re: [PATCH] elf: Use C11 like atomics on _dl_mcount
Date: Thu, 1 Sep 2022 12:30:36 -0300	[thread overview]
Message-ID: <5fd88725-8bef-2e26-420a-1216ebfa5cec@linaro.org> (raw)
In-Reply-To: <AS4PR08MB79010433FBB113D4FC548413837B9@AS4PR08MB7901.eurprd08.prod.outlook.com>



On 01/09/22 11:19, Wilco Dijkstra wrote:
> Hi Adhemerval,
> 
>> Right, I was not trying to be clever here and acquire might be a more
>> strict memory order.
>>
>> And I haven't replied yet to you atomic refactor, but I also think changing
>> step by step is indeed better than changing all the atomic altogether.
> 
> Well that's what I did, I split into about 15-20 patches rather than a single one.

Is the https://patchwork.sourceware.org/project/glibc/list/?series=10727 right? I 
think it has failed CI, could you submit again?

> 
>> Do you think using relaxed on all atomic is suffice here?
> 
> Indeed, adding acquire on these counters will not ensure correct memory ordering.
> 
> Note this particular code looks very unsafe - it is not clear to me how it blocks
> other threads from accessing new elements before they are properly initialized.
> Also the counters that are being updated atomically are read without atomic
> accesses, so may get a cached value or something newer - you don't know.
> 

I thinking we are tracking two different issues, although they are correlated.
My take is to first try to map the current code to a C11-like atomic, so we
can always use compiler builtins where applicable (there are couple of 
architecture that we might avoid using libgcc for performance reasons), and
then check if the atomic usage does make sense.

  reply	other threads:[~2022-09-01 15:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01 12:21 Wilco Dijkstra
2022-09-01 13:09 ` Adhemerval Zanella Netto
2022-09-01 14:19   ` Wilco Dijkstra
2022-09-01 15:30     ` Adhemerval Zanella Netto [this message]
2022-09-01 23:18       ` Wilco Dijkstra
2022-09-02 12:21         ` Adhemerval Zanella Netto
2022-09-02 13:27           ` Wilco Dijkstra
  -- strict thread matches above, loose matches on Subject: below --
2022-08-31 18:14 Adhemerval Zanella

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=5fd88725-8bef-2e26-420a-1216ebfa5cec@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=Wilco.Dijkstra@arm.com \
    --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).