public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: David Mozes <david.mozes@silk.us>
To: "libc-help@sourceware.org" <libc-help@sourceware.org>
Subject: rwlock different behavior on glibc 2.28 then on previous versions
Date: Mon, 7 Mar 2022 20:13:26 +0000	[thread overview]
Message-ID: <AM9PR04MB82916263FDAD1DB3221E89ABF1089@AM9PR04MB8291.eurprd04.prod.outlook.com> (raw)

I like to consult with you regarding the flowing issue

The rwlock rewrite commit:

commit cc25c8b4c1196a8c29e9a45b1e096b99a87b7f8c
Author: Torvald Riegel <triegel@redhat.com>
Date:   Thu May 22 16:00:12 2014 +0200

changed the behavior of the rwlock as well!

On the previous version of Glibc (before the commit) We could release write lock with different thread as the one that owned the lock (If we like) . This is help very much for async program that has a many threads that communicate with some target.
And we like to define a call back function instead of blocking on aio thread that send the data in order to release the rwlock.this improves the performance dramatically .
For backward compatibility and better performance  I suggest a small change as describe below:
Remove the THREAD_SELF checking(See below) ,unless this change is danger!

Does such fix is danger ?
Do you aware why this check was added in the first place?


Other option is to define anther function /Type that enable less restricted operation to not violate the API agreement and it will be on the user responsibly whether to use the new type or not for better performance.
What do you think?

Thx
David



The  previous code before  cc25c8b4c1196a8c29e9a45b1e096b99a87b7f8c was look like that:
__pthread_rwlock_unlock (pthread_rwlock_t *rwlock)
{
  lll_lock (rwlock->__data.__lock, rwlock->__data.__shared);
  if (rwlock->__data.__writer)
    rwlock->__data.__writer = 0;
  else
    --rwlock->__data.__nr_readers;
  if (rwlock->__data.__nr_readers == 0)
    {
      if (rwlock->__data.__nr_writers_queued)
        {

Our application has many inflight IO threads


After the cc25c8b4c1196a8c29e9a45b1e096b99a87b7f8c commit:

     int
___pthread_rwlock_unlock (pthread_rwlock_t *rwlock)
{
  LIBC_PROBE (rwlock_unlock, 1, rwlock);

  /* We distinguish between having acquired a read vs. a write lock by looking
     at the writer TID.  If it's equal to our TID, we must be the writer
     because nobody else can have stored this value.  Also, if we are a
     reader, we will read from the wrunlock store with value 0 by the most
     recent writer because that writer happens-before us.  */
  if (atomic_load_relaxed (&rwlock->__data.__cur_writer)
      == THREAD_GETMEM (THREAD_SELF, tid))
      __pthread_rwlock_wrunlock (rwlock);
  else
    __pthread_rwlock_rdunlock (rwlock);
  return 0;
}





The change I propose is :


What do you think regarding such a small fix  like this:

   if (atomic_load_relaxed (&rwlock->__data.__cur_writer))
      __pthread_rwlock_wrunlock (rwlock);
  else
    __pthread_rwlock_rdunlock (rwlock);
  return 0;
}



             reply	other threads:[~2022-03-07 20:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07 20:13 David Mozes [this message]
2022-03-11 13:58 ` Florian Weimer
2022-03-13 10:23   ` David Mozes
2022-03-20 16:44     ` David Mozes
2022-03-21  6:19       ` Christian Hoff
2022-03-21 14:01         ` David Mozes
2022-03-21 17:01           ` Adhemerval Zanella
2022-03-21 19:46             ` David Mozes
2022-03-21 20:19               ` Adhemerval Zanella
2022-03-24 15:41                 ` David Mozes

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=AM9PR04MB82916263FDAD1DB3221E89ABF1089@AM9PR04MB8291.eurprd04.prod.outlook.com \
    --to=david.mozes@silk.us \
    --cc=libc-help@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).