rwlock different behavior on glibc 2.28 then on previous versions

[David Mozes]

Thx Florin,


-----Original Message-----
From: Florian Weimer <fweimer@redhat.com> 
Sent: Friday, March 11, 2022 3:59 PM
To: David Mozes <david.mozes@silk.us>
Cc: libc-help@sourceware.org
Subject: Re: rwlock different behavior on glibc 2.28 then on previous versions

* David Mozes:

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

Sorry, this misuse of the API has always been undefined according to
POSIX (“Results are undefined if the read-write lock rwlock is not held
by the calling thread.”).

 >> Correct, but practically we can do it on the user's responsibility.  
>>Do you know if this "if" solved some synchronization issue or just enforced the undefined  API? 

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

Could you use a different synchronization object (perhaps a condition
variable)?

>> If we use a different synchronization object like semaphores, condition variable (by the way they use mutex under the same API agreement),  we will need to write self rwlock , which has less performance than other undefined states. 
>>If we like to keep the API agreement, why not define the different async programming unlock functions? 
Thanks
Florian

Thx
David