public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
* rwlock different behavior on glibc 2.28 then on previous versions
@ 2022-03-07 20:13 David Mozes
  2022-03-11 13:58 ` Florian Weimer
  0 siblings, 1 reply; 10+ messages in thread
From: David Mozes @ 2022-03-07 20:13 UTC (permalink / raw)
  To: libc-help

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;
}



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-03-24 15:42 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-07 20:13 rwlock different behavior on glibc 2.28 then on previous versions David Mozes
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

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).