[Bug nptl/14958] Concurrent reader deadlock in pthread_rwlock_rdlock()

["triegel at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
                 CC|                            |triegel at redhat dot com

--- Comment #7 from Torvald Riegel <triegel at redhat dot com> ---
I think it is, strictly speaking, debatable whether the test case (and
underlying assumption about the required behavior) is correct.  If Thread
Execution Scheduling were not supported, the behavior is
implementation-defined:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_rdlock.html

glibc claims it does support it, but the testcase does not explicitly set a
scheduling policy; I would read the POSIX spec as still allowing
implementation-defined behavior in this case.  Nonetheless, given that the
current rwlock implementation ignores the priorities (see bug 13701) and tries
to prefer readers (unless PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP),
it seems better to support this test case.  For a reader-preferring
implementation, it seems intuitive for programmers to expect that if one thread
has acquired a read lock, another thread will acquire a read lock eventually as
well, even in the case of concurrent writer acquisition attempts.

Recursive read-locks are allowed too for the default rwlock type, which would
be similar in that concurrent writers cannot block readers (this is already
treated correctly by the implementation).

Therefore, I think supporting this use case makes sense even if not strictly
required.

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