| > iirc RWMutex used to be much slower than standard Mutex so there was no good use case for it over standard Mutext. That might have gotten fixed, don't know. If you check the implementation RWMutex actually uses a Mutex underneath.
The `RLock` is just an atomic increment if you don't have a writer. The `Lock`(write lock) is normal `Mutex.Lock` + an atomic add. > Secondly, you can use atomics instead of mutexes. They will be faster by about 400% iirc. The golang community and the guys that actually implementing golang usually says `share via commuinication` and don't use any locks in the first place. You don't need even atomics in that case. But in some cases, in production, you can measure and see that locking is better. I can admit that most of the projects can get away with not using locks and follow the guideline. So I guess, if performance is important, try everything and measure. > Thirdly, you do not need to be concerned for readers ... Well, the use case was guarding multiple things under single lock. So the read lock needs to be there because you need a consistent view of the world. Otherwise, the reader see that a field is changed but another is not. And it is a bug for our case . A simplified concrete example,
Under write lock, user can call REDIS MSET command. https://redis.io/commands/mset/ Related part of the commands doc ```
MSET is atomic, so all given keys are set at once. It is not possible for clients to see that some of the keys were updated while others are unchanged.
`` So the readers should see that all updated or none updated. That is why for example one one can need a read lock. Obviously, aside from the contract we have a lot going on in the background.
Some of the data is in memory. some are loading. Some are just written in memory and dirty, therefore next read needs to wait for it to persisted to disk if it is evicted from memory etc.... All of these needs coordination between readers and writers. |