------- Additional Comments From bruce dot gayliard at hp dot com 2007-09-20 18:18 ------- Hmmm - this is the spec I am looking at: -------------------------------------------- IEEE Std 1003.1™, 2004 Edition The Open Group Technical Standard Base Specifications, Issue 6 Includes IEEE Std 1003.1™-2001, IEEE Std 1003.1™-2001/Cor 1-2002 and IEEE Std 1003.1™-2001/Cor 2-2004 ... pthread_rwlock_rdlock( ) System Interfaces 35616 NAME 35617 pthread_rwlock_rdlock, pthread_rwlock_tryrdlock—lock a read-write lock object for reading 35618 SYNOPSIS 35619 THR #include 35620 int pthread_rwlock_rdlock(pthread_rwlock_t *rwlock); 35621 int pthread_rwlock_tryrdlock(pthread_rwlock_t *rwlock); 35622 35623 DESCRIPTION 35624 The pthread_rwlock_rdlock( ) function shall apply a read lock to the read-write lock referenced by 35625 rwlock. The calling thread acquires the read lock if a writer does not hold the lock and there are 35626 no writers blocked on the lock. 35627 TPS If the Thread Execution Scheduling option is supported, and the threads involved in the lock are 35628 executing with the scheduling policies SCHED_FIFO or SCHED_RR, the calling thread shall not 35629 acquire the lock if a writer holds the lock or if writers of higher or equal priority are blocked on 35630 the lock; otherwise, the calling thread shall acquire the lock. 35631 TPS TSP If the Threads Execution Scheduling option is supported, and the threads involved in the lock 35632 are executing with the SCHED_SPORADIC scheduling policy, the calling thread shall not 35633 acquire the lock if a writer holds the lock or if writers of higher or equal priority are blocked on 35634 the lock; otherwise, the calling thread shall acquire the lock. 35635 If the Thread Execution Scheduling option is not supported, it is implementation-defined 35636 whether the calling thread acquires the lock when a writer does not hold the lock and there are 35637 writers blocked on the lock. If a writer holds the lock, the calling thread shall not acquire the 35638 read lock. If the read lock is not acquired, the calling thread shall block until it can acquire the 35639 lock. The calling thread may deadlock if at the time the call is made it holds a write lock. ------------------------------------------------------------------- You could take the position that if a "reader preferred" lock was specified, that reader locks have priority. However, as I stated in my original writeup, that should not be the default. By the way, I did not see "may" in the above. Please let me know if I am looking at the wrong specification. I assume you are echoing my opinion that it is not an issue to provide the "reader preferred" capability, and I agree that the spec does not disallow that. I will say that in 30 years of working with parallel / shared memory applications, I have never run across a situation where a "reader preferred" lock (as the behavior is referred to in the library code) would be desired. That opinion seems to be reflected in the language of the specification. The code I am looking at comes from the following tree: glibc-2.5-25.src.rpm /usr/src/redhat/SOURCES/nptl/sysdeps/pthread/pthread.h /usr/src/redhat/SOURCES/nptl/sysdeps/pthread/pthread_rwlock_rdlock.c /usr/src/redhat/SOURCES/nptl/pthread_rwlock_init.c It is in the pthread.h file supplied at the path above where the modification that I pointed out in the PTHREAD_RWLOCK_DEFAULT_NP had occurred - clearly a modification from writer preferred to reader preferred for the default. Whether or not the prior RHEL4 version used nptl is actually moot - the fact of the matter is that there are bugs (as I reported) in the version of glibc that I mention above, and probably in a number of other versions as well. The bugs can be readily reproduced with the supplied test program, which should be allowing writes to occur regardless of whether BUG1 or BUG2 is defined. So, I assumed nptl was the correct place to report, based on the directory tree in which the code was found. If this is in error, apologies - please let me know where I should enter this bug report. Finally, I will re-iterate that I found this due to a failure of an application that was previously working (i.e. in RHEL4). Some behavior, clearly, has changed in the transition to RHEL5. The application code had not been changed. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4979 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.