Re: rwlock for async application

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 25/03/2022 14:16, David Mozes wrote:
> Hi all,
> I want to discuss some needs that I think need to address.
> On async coding used mainly on networking and storage applications, how ever I believe on other applications as well, what we are doing is acquiring a lock on the application level, and then call to the OS/kernel for sending/writing
> C*allback* instead of waitengin on blocking for the sending/writing to finish. After completing the OS, call the CB to release the transaction and the lock.
> The problem is that the current glibc implumnation doesn’t support taking and releasing the writer lock from different threads.
>  
> I think it needs to be address .
> Actually I did the folwing change:
>  
> index d3f36303bf..b1032cfa2a 100644
> --- a/nptl/pthread_rwlock_unlock.c
> +++ b/nptl/pthread_rwlock_unlock.c
> @@ -36,8 +36,7 @@ __pthread_rwlock_unlock (pthread_rwlock_t *rwlock)
>       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))
> +  if (atomic_load_relaxed (&rwlock->__data.__cur_writer))
>        __pthread_rwlock_wrunlock (rwlock);
>    else
>      __pthread_rwlock_rdunlock (rwlock);
>  
>  
> On the current unlock function and seems to working so far on heavy load  and 3k threads.
>  
> I believe it has some limitions and need farther review.and might be calling in different name,but I  think  it be good to have it.
>  
> Your thout?

Hi David,

As I tried to explain to you on libc-help, you can't blindly change the
algorithm without explaining why it is safe to do so. In this case it
means to explain why the test is not required and how only using 
__cur_writer is suffice to know whether the acquired lock is
a read or write.  It would be good to know also the performance 
implications, if any.

However the main issue, as pointed out my other, the POSIX standard is
explicit that it is undefined if the read-write lock rwlock is not held
by the calling thread. It means that if glibc allows, you are binding
its implementation to this specific semantic and making any program 
build on glibc potentially undefined if it is build for another libc. 
I tend to agree that enforcing write locks are held only for calling 
thread seems to work towards to make glibc more standard compatible.

One option might be to add a GNU extension to allow it, something that
PTHREAD_RWLOCK_ALLOW_WRITER_NOT_HELD_NP, which should be explicit opt-in
(instead of default).