public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Noah Goldstein <goldstein.w.n@gmail.com>
Cc: 'GNU C Library' <libc-alpha@sourceware.org>
Subject: [PATCH v1 2/4] nptl: Continue use arch prefered atomic exchange in spinlock loop
Date: Thu, 29 Sep 2022 16:35:16 +0000	[thread overview]
Message-ID: <AS4PR08MB7901047C27E59D57D67F854C83579@AS4PR08MB7901.eurprd08.prod.outlook.com> (raw)

Hi Noah,

Did you try building it both ways? I don't think this could ever compile:

+  if (__glibc_likely (pthread_spin_lock_grab_lock (lock, &val, 1)))

and:

+#  define pthread_spin_lock_grab_lock(mem, val, c) \
+    atomic_compare_exchange_weak_acquire (lock, &val, 1))

The define uses 'lock' and 'mem' inconsistently and the use of the macro
expands into &&val...

Apart from that there is the question whether we should keep the weird
ATOMIC_EXCHANGE_USES_CAS setting - I have removed it in my atomic
patch series since most targets appear confused as to what it means (so
are likely to have the wrong setting). Also there is no evidence it is actually
faster. So using exchange in both cases is easier (and less error prone!).

Also you do realize that no matter how much you change this code, it
won't make a difference on x86, right?

Cheers,
Wilco

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

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29 16:35 Wilco Dijkstra [this message]
2022-09-29 18:38 ` Noah Goldstein
2022-09-29 18:50   ` Wilco Dijkstra
2022-09-29 18:51   ` H.J. Lu
  -- strict thread matches above, loose matches on Subject: below --
2022-09-29  3:14 [PATCH v1 1/4] Benchtests: Add benchtests for pthread_spin_lock and mutex_trylock Noah Goldstein
2022-09-29  3:14 ` [PATCH v1 2/4] nptl: Continue use arch prefered atomic exchange in spinlock loop Noah Goldstein

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=AS4PR08MB7901047C27E59D57D67F854C83579@AS4PR08MB7901.eurprd08.prod.outlook.com \
    --to=wilco.dijkstra@arm.com \
    --cc=goldstein.w.n@gmail.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).