On 11/15/18 10:21 AM, G. Branden Robinson wrote: > At 2018-11-15T10:03:41-0500, Carlos O'Donell wrote: >> diff --git a/man3/pthread_rwlockattr_setkind_np.3 b/man3/pthread_rwlockattr_setkind_np.3 >> index 3cca7d864..6b2b8db39 100644 >> --- a/man3/pthread_rwlockattr_setkind_np.3 >> +++ b/man3/pthread_rwlockattr_setkind_np.3 > [...] >> +.\" Here is the relevant wording: >> +.\" >> +.\" A thread may hold multiple concurrent read locks on rwlock (that is, >> +.\" successfully call the pthread_rwlock_rdlock() function n times). If >> +.\" so, the thread must perform matching unlocks (that is, it must call >> +.\" the pthread_rwlock_unlock() function n times). >> +.\" >> +.\" By making write-priority work correctly, I broke the above requirement, >> +.\" because. I had no clue that recursive read locks are permissible. > ^ > This period is not in the original quotation and grammatically doesn't > belong there. My mistake. It should not be there, I must have added it by accident when I wrapped the text from the email. > Is the Austin Group aware of the larger issue? It seems reasonable to > assume that they don't intend to mandate that system implementors > resolve an unsolved problem in computer science. In a sense this isn't an Austin Group issue. The POSIX interfaces do not allow you to specify a writer preference, and by default can lead to writer starvation. You might consider TPS with priority scheduling to allow such writers of higher priority to have preference, but we don't implement that in glibc (see issue #1111 below). The writer preference was added by glibc to mirror the reader preference. The writer preference defaults to doing nothing, because it is believed that doing anything *and* supporting recursive readlocks leads to deadlock. Therefore to make it clear to developers that you *must* never use recursive read locks a 3rd constant was provided for the rwlock kind. At a high level the Austin Group *is* aware of the issue. http://austingroupbugs.net/view.php?id=720 In issue #720 it was ruled that read locks are recursive, and write locks are not recursive. http://austingroupbugs.net/view.php?id=1111 In issue #1111 it is discussed that only through TPS can you achieve writer preference at the cost of never allowing recursive read locks on that lock. See "Description" for the bug, item (2). Thus the most directly applicable issue was #1111, since it involved TPS and writer threads that can preempt reader threads, but even there the consideration was that the deadlocks caused by the recursive reader locks were a program bug. In glibc we took the position that we would simply not allow the deadlocks to occur. Your choices in glibc are: (a) PTHREAD_RWLOCK_PREFER_READER_NP - Prefer readers. - Support recursive read locks. (b) PTHREAD_RWLOCK_PREFER_WRITER_NP (misleading) - Prefer readers. - Support recursive read locks. - Results in writer starvation but *not* deadlocks. (c) PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP - Prefer writers. - Ban recursive read locks. - Results in reader starvation. Does that answer your question? -- Cheers, Carlos.
