[LTP] [PATCH] open_posix: Update pthread_rwlock_rdlock 2nd assertion

[Cyril Hrubis]

Hi!
> The pthread_rwlock_rdlock/2-*.c tests are broken because they rely on an
> old version of the POSIX standard which says:
> 
>   If the Thread Execution Scheduling option is supported, and the threads
>   involved in the lock are executing with the scheduling policies
>   SCHED_FIFO or SCHED_RR, the calling thread shall not acquire the lock if
>   a writer holds the lock or if writers of higher or equal priority are
>   blocked on the lock; otherwise, the calling thread shall acquire the
>   lock.
> 
> Whereas the new version says:
> 
>   If the Thread Execution Scheduling option is supported, and the threads
>   that hold or are blocked on the lock are executing with the scheduling
>   policies SCHED_FIFO or SCHED_RR, the calling thread shall not acquire the
>   lock if a writer holds the lock or if the calling thread does not already
>   hold a read lock and writers of higher or equal priority are blocked on
>   the lock; otherwise, the calling thread shall acquire the lock.

I wouldn't say that these tests are broken because of the change in
POSIX. The change in POSIX only fixed the specs in the case of recursive
locking that is situation where we have a thread that has rdlock and
attempts to do rwlock while there is higher priority thread that
attempts rwlock. In that situation the previous definition would caused
deadlock.

But as far as I can see these tests do not attempt recursive locks, so
that part of POSIX wasn't really problem.

> This behaviour is not supported by default on GNU/Linux, so add a call to
> Glibc pthread_rwlockattr_setkind_np() to set the correct lock kind as a
> prerequisite to the 2-1.c and 2-2.c tests.

This is where the problem is, glibc decided to deviate from the POSIX
since they think that the standard is not well designed. That is a glibc
design choice. I'm not againts working around that with requesting POSIX
confirming variant on glibc, but the patch should clearly say this
instead.

Also we should split this into two patches, one that adjusts the specs
and one that adds glibc workaround.

-- 
Cyril Hrubis
chrubis@suse.cz