Typically, in a RwLock, once a Writer locks, Readers are blocked, until the Writer unlocks. Similarly, a Writer lock waits until all current Readers unlock too, so you get contention on both sides. RwLock only lets multiple concurrent Readers lock against themselves, but any mixture causes full locking.
In this article, the locks are mutually exclusive. Reads are not blocked by Writes, and vice-versa, but Writers would block against other Writers.
The downside is that Readers need to check which "version" of the data they read, to see if it was modified during the operation by a Writer--since Writers do not block for Readers like they do with RwLock.
It's elegant because, in most scenarios, Readers will not need to re-read because the version won't change mid-run between an optimistic read lock and its unlock. In the cases where that does happen, your code needs to handle retrying the read / loop logic, which is why the article argues for a compiler mechanism to enforce that check and avoid "foot gun" scenarios.
In this article, the locks are mutually exclusive. Reads are not blocked by Writes, and vice-versa, but Writers would block against other Writers.
The downside is that Readers need to check which "version" of the data they read, to see if it was modified during the operation by a Writer--since Writers do not block for Readers like they do with RwLock.
It's elegant because, in most scenarios, Readers will not need to re-read because the version won't change mid-run between an optimistic read lock and its unlock. In the cases where that does happen, your code needs to handle retrying the read / loop logic, which is why the article argues for a compiler mechanism to enforce that check and avoid "foot gun" scenarios.