[Bug nptl/4979] pthread rwlock writer starvation - bad initializer, bad rdlock code

[Bug nptl/4979] pthread rwlock writer starvation - bad initializer, bad rdlock code

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4979

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/4979] pthread rwlock writer starvation - bad initializer, bad rdlock code

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2007-09-20 18:31 -------
There is nothing wrong in the implementation and nothing will change.  If you
want reliable behavior then by all means, specify it.  This is what the
attributes are for.  If you don't use them stop complaining.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME


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.

[Bug nptl/4979] pthread rwlock writer starvation - bad initializer, bad rdlock code

[bruce dot gayliard at hp dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4579 bytes --]


------- 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 <pthread.h>
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.

[Bug nptl/4979] pthread rwlock writer starvation - bad initializer, bad rdlock code

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2007-09-19 13:58 -------
AFAIK POSIX just sais that implementations may favor writers over readers,
it doesn't say they must, so the choice of the default (or even the existance
of different rwlock policies) is implementation choice.
This default has never changed in NPTL, you are probably confused by using
LinuxThreads headers in earlier glibc versions.  LinuxThreads used to
default to PREFER_WRITER, but never so in NPTL.

-- 


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.