Right. I could have been clearer. There are two errors to avoid here: - Read lock, read some data, unlock, relock for writing, act on data read during previou

Right. I could have been clearer. There are two errors to avoid here: - Read lock, read some data, unlock, relock for writing, act on data read during previous locked period. That's a time of check/time of use error. - Acquire a read lock, then upgrade to a write lock. MutexLock does not let you do that. If you do that from two threads, you can deadlock. You can do that in SQL, but SQL can back out a transaction that deadlocks. This is not a problem with Rust. Rust prevented the author from shooting themself in the foot.