Bug introduced in definitions of pthread.h (64 bit updates)

["Gayliard, Bruce" <bruce dot gayliard at hp dot com>]

Hi.  I hope this is getting to the correct mail list...

I have an application that uses the pthread_rwlock_* functions.  This app was running fine in RHEL 4, but when introduced into an RHEL 5 environment I found that a particular thread would hang on a writer lock.  To get to the point, the writer lock is being starved when I use the pthread implementation delivered with RHEL 5.  I tracked this down to the changes in the pthread.h header file, where someone introduced the 64 bit support.  The implementor chose to modify the default rwlock behavior (see PTHREAD_RWLOCK_INITIALIZER) from writer preferred (prior implementation) to reader preferred.  Also, the PTHREAD_RWLOCK_DEFAULT_NP was changed in the same way.  Moreover, the defined values were not used to specify the various *_INITIALIZER_* constants, a practice that I am not particularly happy with, but that's just my $.02.

I have used reader writer locks in a number of applications, and I have never seen a case where the behavior resulting from "reader preferred" was expected or desired.  Regardless of my personal preferences, though, the POSIX specification seems to indicate that the "writer preferred" behavior shall be implemented (there are now some dependences on scheduling policies, but the default initializer for the rwlock is independent of those).  Moreover, I would be surprised if a change like this in the behavior specified by the default initializer is considered reasonable.

So, several items:
1) Is this something that would be considered a bug?  If so, how does one report it?
2) How did this get into the code - did it slip by a review?
3) One can reproduce the issue with a contrived program that starves a writer - should I send along such a program?

Thanks and regards -

Bruce Gayliard
High Performance Computing Division
Hewlett-Packard Company