Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>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.</p> <p>There are two related, but separate, issues here. Firstly, there is this situation:</p> <ul> <li>There are read locks currently held, and writers waiting. A new thread tries to take a read lock.</li> </ul> <p>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 <code>pthread_rwlockattr_setkind_np()</code> function to set the <code>PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP</code> flag on the <code>attr</code> that you pass to <code>pthread_rwlock_init()</code>, then your rwlock will block the reader in the above situation.</p> <p>The second situation is:</p> <ul> <li>The last holder releases the lock, and there are both readers and writers waiting.</li> </ul> <p>In this situation, NPTL will always wake up a writer in preference to a reader.</p> <p>Taken together, the above means that if you use the <code>PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP</code> flag, your writers shouldn't be starved (of course, now a continuous stream of writers can starve the readers. <em>C'est la vie</em>). You can confirm all this by checking the sources (it's all very readable<sup>1</sup>) in <a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthread_rwlock_rdlock.c;h=31eb508a0d34bbeaa8c3112c6cde58c0d06a7734;hb=e28c88707ef0529593fccedf1a94c3fce3df0ef3" rel="nofollow noreferrer">pthread_rwlock_rdlock.c</a> and <a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthread_rwlock_unlock.c;h=a7ef71a11382c507d4883bad4102bb3c0c85db05;hb=e28c88707ef0529593fccedf1a94c3fce3df0ef3" rel="nofollow noreferrer">pthread_rwlock_unlock.c</a>.</p> <p>Note that there is also a <code>PTHREAD_RWLOCK_PREFER_WRITER_NP</code>, but it appears <em>not</em> to have the right effect - quite possibly a bug (<em>or possibly not - see <a href="https://stackoverflow.com/questions/2190090/how-to-prevent-writer-starvation-in-a-read-write-lock-in-pthreads/2190271#comment-6945209">comment by jilles below</a></em>).</p> <p><hr> <sup>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.</sup></p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload