[Bug nptl/13701] New: pthread_rwlock_rdlock & realtime scheduling writer lock precedence

[Bug nptl/13701] New: pthread_rwlock_rdlock & realtime scheduling writer lock precedence

[chrubis at suse dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=13701

             Bug #: 13701
           Summary: pthread_rwlock_rdlock & realtime scheduling writer
                    lock precedence
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: chrubis@suse.cz
    Classification: Unclassified


The pthread_rwlock_rdlock() together with thread scheduling priority set to
SCHED_FIFO or SCHED_RR should prefer writer locks. This doesn't seem to work,
at least corresponding LTP test fails and I couldn't find anything wrong about
it.

The corresponding test source:

http://ltp.git.sourceforge.net/git/gitweb.cgi?p=ltp/ltp.git;a=blob;f=testcases/open_posix_testsuite/conformance/interfaces/pthread_rwlock_rdlock/2-1.c

The corresponding POSIX definition:

http://pubs.opengroup.org/onlinepubs/007904975/functions/pthread_rwlock_rdlock.html

The original SUSE bug:

https://bugzilla.novell.com/show_bug.cgi?id=66013

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/13701] pthread_rwlock_rdlock & realtime scheduling writer lock precedence

[schwab@linux-m68k.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13701

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|drepper.fsp at gmail dot    |unassigned at sourceware
                   |com                         |dot org

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/13701] pthread_rwlock_rdlock & realtime scheduling writer lock precedence

[vapier at gentoo dot org]

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

Mike Frysinger <vapier at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://austingroupbugs.net/
                   |                            |view.php?id=722
                 CC|                            |vapier at gentoo dot org
           See Also|                            |https://bugzilla.novell.com
                   |                            |/show_bug.cgi?id=66013,
                   |                            |http://austingroupbugs.net/
                   |                            |view.php?id=722

--- Comment #1 from Mike Frysinger <vapier at gentoo dot org> ---
discussion has moved to the austin group tracker now

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

[Bug nptl/13701] pthread_rwlock_rdlock & realtime scheduling writer lock precedence

[wangxg.fnst at cn dot fujitsu.com]

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

Xiaoguang Wang <wangxg.fnst at cn dot fujitsu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wangxg.fnst at cn dot fujitsu.com

--- Comment #2 from Xiaoguang Wang <wangxg.fnst at cn dot fujitsu.com> ---
According to austin group's discussion results, it seems that write locks
should be implemented to take precedence before the read locks. 

Whether is this considered as a glibc bug or should be fixed? Thanks.

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

[Bug nptl/13701] pthread_rwlock_rdlock & realtime scheduling writer lock precedence

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

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

[Bug nptl/13701] pthread_rwlock_rdlock & realtime scheduling writer lock precedence

[triegel at redhat dot com]

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

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3
                 CC|                            |triegel at redhat dot com
           Severity|normal                      |enhancement

--- Comment #3 from Torvald Riegel <triegel at redhat dot com> ---
Precisely, if Thread Execution Scheduling is supported (and glibc claims it
is), and if the threads use SCHED_FIFO / SCHED_RR / SCHED_SPORADIC,
pthread_rwlock_rdlock() must prefer blocked writers if and only if their
priority is higher or equal to that of the reader; otherwise, the reader is
preferred:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_rdlock.html

The current implementation does not guarantee that; instead, it prefers readers
if other readers have already acquired the lock, or neither readers nor writers
have acquired the lock.  The former seems to be, intuitively, the right
behavior given that recursive rdlock acquisitions are allowed also.

Implementing the special requirements for Thread Execution Scheduling seems
difficult, especially in an efficient way, and given the futex facilities we
have today and the role userspace has when using them (e.g., the rwlock
implementation would need to track the maximum priority of all blocked writers,
yet we'd need to still support process-shared rwlocks).  Therefore, unless
there is strong demand for this feature, I don't think it's worthwhile to spend
significant time on this.

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