Unlimited Spin of Glibc's Read-write-lock Implementation

[PengZheng]

Last week, I investigated a Read-write-lock implementation issue affecting ALL versions of Glibc, which is detailed in the following ML thread: https://sourceware.org/pipermail/libc-alpha/2024-March/155278.html

In summary, a reader of high RT priority that can not acquire its lock can do unlimited spin (eating all available CPUs) while a writer that holds its lock can not stop the reader from spinning because it has no chance to run.

Considering that rwlock is used in the central piece of our framework and glibc is the most extensively used C library, we should pay close attention to the progress of this issue.

Note that musl does not suffer from this issue, since it only does limited spin (up to 100 times, check the following email for an example). Neither is uclibc affected.

Event if Glibc addresses this issue quickly, we should warn our users of this issue. If it were ignored, then we may need to implement our own rdlock in the worst case. @pnoltes @xuzhenbao

Bug Report: https://sourceware.org/bugzilla/show_bug.cgi?id=31477

[PengZheng]

The unlimited spin is introduced by this commit: https://sourceware.org/git/?p=glibc.git;a=commit;h=cc25c8b4c1196a8c29e9a45b1e096b99a87b7f8c

The current glibc rwlock is completely unusable together with real time priority tasks, though it is OK to use with SCHED_OTHER.
Considering the current design is super complex, I don't expect a upstream fix will be available in a year or two.
The workaround in my day job is to revert it to Ulrich Drepper's original design and implementation.