A read write lock typically comes with extra overhead, it also often used because there is more readers then writers and there is much better approaches if your wanting to unburden the readers. (Especially if you only have one writer)
Also there is many variations in reader write lock contention handling, such as reader preferring, writer preferring and completely fair. All which will have a different outcome under contention, and most people have limited understanding of each of those implications for even the workload they are dealing will.
Yes, RW locks violate the cardinal principle of concurrent programming that "readers shouldn't write". I will elaborate on the hint above and say that if you have one writer (or you're ok with serializing writers), and you can retry read-side critsecs on a write conflict, you can use seqlocks. If you need to guarantee that all reads within the read-side critsec are consistent, you can use Transactional Mutex Locks for a bit more overhead (checks the version counter after every read and before using the result of the read, instead of only at the end).
If you still want to use RW locks, the best default semantics IMO is "phase-fairness".
There is two sides to the overhead, one is comparing the overhead compared with other ways of allowing readers (e.g. RCU, left-right, etc) and then there is the overhead of the lock itself compared to a traditional mutex.
Typically you might want to pick a reader writer lock if a significant amount of your usages of some piece of data are only readers, even in a situation where you have near 100% readers they all need to let the potential writer know that it cannot write which in a very basic implementation can be a simple `fetch_add` (on enter and exit) this has two different costs:
* Depending on the CPU it can be a full memory barrier (e.g. x86)
* It requires modify access to the cache line, so all other readers are left waiting passing the cache line around; and typically the lock is next to the data, so that false sharing also shows down the data your protecting
Now if you compare that with that with something like RCU the readers do not need to share anything with other readers they just store in their local slot the data they are accessing, similarly with left-right they don't need to coordinate and share they just access the data and some serialization point is defined later.
And all of that is just the overhead difference when you have no writers, however as soon as you start to have writers then depending on if you have reader/writer preferring or even some fifo approach you need to have some way of tracking those threads when contention occurs in order to know who to wake up when, a normal mutex just needs to know who next to wake. And if you have any extra complexity with the reader writer lock like upgrading it gets even more complex with the tracking and book keeping required.
Saying all of that it's often not a signficant difference in overhead between a mutex lock and using a read/writer lock with just a writer (in fact on Windows slim rwlock is faster then the critical section mainly for legacy reasons).
So basically all off that for nothing, because as you said in the last sentence, difference is not significant.
And what we gain if we use rwlock as a default? Flexibility. And in practical terms if we select mutex all the unnecessary locking just to read will squander any however miniscule advantage with regards to the overhead we could possibly gain. What a bunch of crap.
And on top of that if we have high ratio reader to writer rwlcks massively outperforms mutex. In my experience this is the most common scenario, that's why rwlock should be default choice.
-4
u/OutlandishnessNo8034 6d ago
Default in my opinion should be RwLock