[Bug nptl/23229] New: Realtime rwlock deadlock when writer has lower priority than readers

["tobias at ringis dot se" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 23229
           Summary: Realtime rwlock deadlock when writer has lower
                    priority than readers
           Product: glibc
           Version: 2.29
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: tobias at ringis dot se
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 11044
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11044&action=edit
Test program to reproduce the deadlock

The new rwlock implementation runs into a deadlock when using real-time
scheduling and the writer has lower priority than the writers.

Here's how the rwlock looks when deadlocked:

    $7 = {__data = {__readers = 35, __writers = 0, __wrphase_futex = 0,
          __writers_futex = 1, __pad3 = 0, __pad4 = 0, __flags = 0 '\000',
          __shared = 0 '\000', __rwelision = 0 '\000', __pad2 = 0 '\000',
          __cur_writer = 0}, __size = "#", '\000' <repeats 11 times>,
          "\001", '\000' <repeats 18 times>, __align = 35}

I believe this is state #8 as documented in pthread_rwlock_common.c, and that
the deadlock is caused by the reader spinning waiting for the writer to
hand-over, but since the reader has higher priority than the writer, the writer
will never run. See the for(;;) on line 435 in pthread_rwlock_common.c.

To reproduce, compile and run the attached program rwlock-deadlock.c like this:

    > sudo taskset --cpu-list 1 ./rwlock-deadlock 
    .no progress
    Aborted

(It's not required to use a single core, but it makes it deadlock faster.)

I've confirmed this issue with glibc GIT as of today.

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