# Standard library, synchronization primitives, and undefined behavior

**URL:** https://internals.rust-lang.org/t/standard-library-synchronization-primitives-and-undefined-behavior/8439
**Category:** libs
**Created:** [September 20, 2018, 6:09pm UTC](https://internals.rust-lang.org/t/standard-library-synchronization-primitives-and-undefined-behavior/8439 "2018-09-20T18:09:34Z")
**Posts on this page:** 1
**Showing post:** 9

<div class="post-metadata">

### Author: ![Amanieu](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/amanieu/32/4095_2.png) [@Amanieu](https://internals.rust-lang.org/u/Amanieu)
#### Post date: [September 21, 2018, 12:10pm UTC](https://internals.rust-lang.org/t/standard-library-synchronization-primitives-and-undefined-behavior/8439/9 "2018-09-21T12:10:17Z")

</div>

> [@RalfJung](#):
>
> Oh, so we do not have a guarantee that when the current thread holds a read lock, trying to acquire another read lock is guaranteed to succeed? That could conflict with fairness but it is also extremely useful – actually it seems to be it is basically a requirement to make reentrant read locking not a hazard.
> 
> But I see this is a method on `RwLock` (I somehow expected it would be on `RwLockReadGuard` ), so I could get my guarantee by always using `read_recursive` . I just have to know I have to do that. (Also, once we come to API bikeshedding I’d suggest to call it `read_reentrant` . This is not just about recursive functions.)

It is useful to have `RwLock` prefer writers over readers since this avoids writer starvation if there is a continuous stream of overlapping readers. To make this work, new readers need to block if there is a pending writer, even if they could acquire a read lock directly (i.e. the lock is currently owned by existing readers). The downside is that if you try to acquire a read lock when you already own one in the current thread, you could deadlock _if_ there is a writer currently waiting on the lock.

`read_recursive` (I don't mind changing the name) simply changes the behavior to always acquire a read lock if possible, even if there is a pending writer. The downside, as mentioned before, is that it may lead to writer starvation.

---

_[View the full topic](https://internals.rust-lang.org/t/standard-library-synchronization-primitives-and-undefined-behavior/8439)._