> RW mutexes only make sense if the critical section is large enough. Ergo RW mutexes very rarely make sense.

I disagree :) Exclusive locks have unavoidable cache-line ping-ponging on the state, which can make a contended lock very expensive. In a write-infrequently read-frequently scenario, mutexes can do clever things to avoid that, for example have core-local reader counts.

Also there's a middle-ground between "pointer swap" and "so large that that it will block the writers enough to notice" critical sections, and often readers are in that sweet spot.

Well, yes you enter the realm of asymmetric synchronization (I like seqlocks myself), but I feel these are no longer general purpose synchronisation primitives but have often application specific trade-offs. Generic RWlocks are usually not great and do not come with these optimization

Also, yes my critical sections are often closer to the pointer swap case that might color my expectations.

My expectations may be colored by having a pretty good default implementation of a shared mutex in our codebase :) (folly::SharedMutex)

I've had to resort to seqlocks + async reclamation (either RCU or hazard pointers, depending on the case) only in a handful of very very specific cases.

Thanks, I'll take a look at folly::SharedMutex!