Even if you're read mostly, R/W locks often do a very bad job. If your critical sections are short (say, in a hash map, or fine-grained locks in a linked list or tree, or even a whole structure lock on a small tree or array), then contention on the R/W lock internals will be a bottleneck, since readers still have to update the reader count, so the count field is a shared location all the readers are doing writes to. You could have this by e.g. having a "fat" R/W lock that's made up of num_cpus primitive R/W locks (and each reader only reader-locks the lock associated with its CPU), but none of the common R/W locks actually do this (and it's not always even the right call if you're worried about node size).

Then again, lots of lock-free structures often try to handle memory management using reference counts or hazard pointers, which have their own performance issues.