Hi Pavel, > Can we assume all systems supporting pthreads are conforming to this > specs? That was pretty big (and pretty recent) change of specification.
The change in the specification [4] mentions that the issue arose with glibc, and it points to two tests from the Linux test project [5][6]. Can you run these tests on your Koji system? It would be interesting to see if they fail or hang as well. > If we really want to test _this_ behavior (writers preferred over readers, > i.e. no rdlock when at least one wrlock acquired), shouldn't we apply > something like the patch from [3]? Than that test would be detrerministic for > everybody, now it is really matter of luck. > > Can we define (documment) what is the real issue we try to test by > test_rwlock? The test_rwlock function in test-lock.c is meant to test the gl_rwlock_t API from glthread/lock.h (which, in our case, is just a transparent layer over the POSIX API) in a textbook situation. It is not meant to test against a particular bug. If you can think of another simple textbook way to use rwlocks - without hacks and without using *_NP functions - then you're welcome to change or replace the test_rwlock function. But if you cannot, then the Austin group should throw the rwlocks out of POSIX. The sentence from [4] "applications should probably be encouraged to use mutexes unless rwlocks are needed for performance reasons" also goes into this direction. > I'll try ask glibc guys, or kernel guys (Fedora/RHEL). Thanks! This is the only promising avenue, and you can do it because you can reproduce the issue on your Koji system (whereas for me, test_rwlock always completes after a couple of seconds). > shouldn't we apply something like the patch from [3]? Well, the patch in [3] would make the test hang on all platforms, because the writers would never get a chance to take the lock. This is pointless. > Simply, after spending some time on this issue (and I'm not the first > one), I'd like to see some fix in gnulib so nobody else in future will > face similar issues. The pessimistic suggestion would be to change the gnulib documentation to state that rwlocks are never reliable, because of the way they are implemented in glibc, and should therefore never be used. If we agree on this, then I'm willing to put a #if 0 around test_rwlock. Bruno > [3] https://lists.gnu.org/archive/html/bug-gnulib/2017-01/msg00024.html [4] http://austingroupbugs.net/view.php?id=722&nbn=5 [5] https://github.com/linux-test-project/ltp/blob/master/testcases/open_posix_testsuite/conformance/interfaces/pthread_rwlock_rdlock/2-1.c [6] https://github.com/linux-test-project/ltp/blob/master/testcases/open_posix_testsuite/conformance/interfaces/pthread_rwlock_rdlock/2-2.c
