Question

I have some questions regarding read-write locks in POSIX Pthreads on a *nix system, say Linux for example.

I wish to know what is the default bias for read write lock i.e does it prefer reads over writes or vice versa ? Does it provide some api to change this default behaviour.

Does posix pthread provide some api so that we could change the pthread_rwlock_t to prevent writer starvation ? From what i have read(please correct me if i am wrong), the default implementation is biased towards reader threads and so writer threads can face starvation.

I have read the sample implementation of rw lock from the book Programming with Posix threads by David Butenhof.

I wish to know how posix pthreads handle starvation of writer threads ? Is there some api using which we could set the attributes of the read write lock that would prevent write starvation (i have never heard about that) ? Or does the user have to handle this problem ?

If you think that the answer is implementation-defined then please give me example of how it’s done in Linux, because thats what i am looking for.

Please note that i just want solutions for a *nix system. Don’t think that i am rude, but posting some windows-specific code is useless for me.

Thank you all for your help and patience 🙂

Answer 1

This does indeed depend on the implementation – so since you have asked about Linux specifically, my comments are refer to the current NPTL implementation of pthreads, which is used in modern glibc.

There are two related, but separate, issues here. Firstly, there is this situation:

• There are read locks currently held, and writers waiting. A new thread tries to take a read lock.

The default action here is to allow the reader to proceed – effectively “jumping the queue” over the writer. You can, however, override this. If you use the pthread_rwlockattr_setkind_np() function to set the PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP flag on the attr that you pass to pthread_rwlock_init(), then your rwlock will block the reader in the above situation.

The second situation is:

• The last holder releases the lock, and there are both readers and writers waiting.

In this situation, NPTL will always wake up a writer in preference to a reader.

Taken together, the above means that if you use the PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP flag, your writers shouldn’t be starved (of course, now a continuous stream of writers can starve the readers. C’est la vie). You can confirm all this by checking the sources (it’s all very readable¹) in pthread_rwlock_rdlock.c and pthread_rwlock_unlock.c.

Note that there is also a PTHREAD_RWLOCK_PREFER_WRITER_NP, but it appears not to have the right effect – quite possibly a bug (or possibly not – see comment by jilles below).

---

^{1. …or at least it was, back when I wrote this answer in 2010. The latest versions of NPTL are considerably more complex and I haven’t re-done the analysis.}