This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] pthread_rwlockattr_setkind_np.3: Remove bug notes.

Hello Carlos,

On 11/15/18 4:03 PM, Carlos O'Donell wrote:
> The notes in pthread_rwlockattr_setkind_np.3 imply there is a bug
> in glibc's implementation of PTHREAD_RWLOCK_PREFER_WRITER_NP (a
> non-portable constant anyway), but this is not true. The implementation
> of PTHREAD_RWLOCK_PREFER_WRITER_NP is made almost impossible by the
> POSIX standard requirement that reader locks be allowed to be recursive,
> and that requirement makes writer preference deadlock without an impossibly
> complex requirement that we track all reader locks. Therefore the only
> and disallow recursive reader locks if you want writer preference.
> This patch removes the bug description and documents the current state
> and recommendations for glibc. I have also updated bug 7057 with this
> information, answering Steven Munroe's almost 10 year old question :-)
> I hope Steven is enjoying his much earned retirement.
> Tested on master.
> Please apply to master.

Thanks. Patch applied.

> Should we move the glibc discussion to some footnote? Some libc may be
> able to implement the requirement to avoid deadlocks in the future, but
> I doubt it (fundamental CS stuff).

I think the text is okay as is.



> 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
> @@ -79,7 +79,31 @@ starved.
>  This is intended as the write lock analog of
> -But see BUGS.
> +This is ignored by glibc because the POSIX requirement to support
> +recursive writer locks would cause this option to create trivial
> +deadlocks; instead use
> +which ensures the application developer will not take recursive
> +read locks thus avoiding deadlocks.
> +.\" ---
> +.\" 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.
> +.\"
> +.\" If a thread which holds a read lock tries to acquire another read lock,
> +.\" and now one or more writers is waiting for a write lock, then the algorithm
> +.\" will lead to an obvious deadlock. The reader will be suspended, waiting for
> +.\" the writers to acquire and release the lock, and the writers will be
> +.\" suspended waiting for every existing read lock to be released.
> +.\" ---
> +.\"
> +.\"
>  .TP
>  Setting the lock kind to this
> @@ -115,17 +139,5 @@ functions first appeared in glibc 2.1.
>  These functions are non-standard GNU extensions;
>  hence the suffix "_np" (nonportable) in the names.
> -Setting the value read-write lock kind to
> -results in the same behavior as setting the value to
> -As long as a reader thread holds the lock, the thread holding a
> -write lock will be starved.
> -Setting the lock kind to
> -allows writers to run, but, as the name implies a writer
> -may not lock recursively.
> -.\"
>  .BR pthreads (7)
> ---
> Cheers,
> Carlos.

Michael Kerrisk
Linux man-pages maintainer;
Linux/UNIX System Programming Training:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]