Let me pitch in with 2 comments regarding read-write locks:

1) When using them, find out if and how do the locking functions you’re using handle starvation. For example, say you have 3 threads on 3 cpus (one on each). Threads 1 and 2 pretty much do their entire work under the lock in read mode (they release it between tasks but are constantly doing tasks). The 3rd thread runs very rarely but when it does it needs the lock in write mode. Now, imagine an implementation where access is always granted when possible (e.g. Linux 2.6 kernel rwlock_t locks). So, thread 1 obtains the lock for read and do a task. Now thread 3 wants the lock for write so it waits. Midway through thread’s 1 work, thread 2 obtains the lock for read. Now thread 1 finishes its task and release the (read) lock but thread 2 still hold it (for read) so thread 3 can’t get it (for write). Now, while thread 2 is in the middle of its task, thread 1 starts another task and takes the lock for read. And you can see where I’m going with this. Thread 3 is starved “forever”.

2) Assuming you’re familiar with the need to define a hierarchy between different locks, read-write locks present some extra difficulty (they actually do that even if you’re unfamiliar with locking hierarchy). Suppose you hold a read lock on a data structure, do some work and now decide you need to change the data structure which requires the lock in write mode. Can you change the read lock you have to write mode? You can, but you have to first release the lock for read and then obtain it for write to prevent hierarchy issues (at least in some implementation - otherwise two readers trying to change to write will get into deadlock). What’s the added complication here? Between the point were you released the read lock and the point where you obtained the write lock another thread could have modified the database and whatever you’ve decided to do while holding the read lock and for which you obtained the write lock might not be relevant anymore (which is a nice way to say that your code can crash). Thus, you may need to re-verify some assumptions after you obtain the lock for write.

@Saurabh: Who says that the list is protected by a lock anyways?

Also similar to the object pooling in item 8 is reference counting.

Of course, like every other dev, I’ve got an opinion to put in about the article - while RW locks seem like a good idea to implement in any scenario that fits conceptually, you should remember that a RW lock typically uses 2 locks and you have to wait on people more, so they could be costing you more than just using a simple lock. However, if you’ve got a resource that has a *lot* of readers and only occasional writers, it’s a win.

But how much is a lot? Don’t guess, profile! There’s far too many factors to accurately guess which one to use.

For reference, see SPJ’s OSCon talk or http://haskell.org/ghc/docs/latest/html/libraries/stm/Control-Monad-STM.html

@Revence: I am not going to get myself into a language war with you, thats for sure :-).

@Brian: thanks for your insightful comment (and for the book, for that matter ), you are right, a warning about the applicability of the techniques is in order. I have added it in big bold letters. Must not forget that people don’t read all of my articles, but merely some of them so I need to repeat myself frequently (for example, I have a whole post warning about premature optimization).

These are all good recommendations — but some of them should be pursued ONLY IF you are experiencing performance or scalability problems. However, the majority of the time I see some of these techniques in use (lock striping and RW locks especially), they are premature optimization. I’d prefer to see some disclaimers to that effect, because programmers are drawn to “optimization” like flies to you-know-what.

There is a significant trade-off associated with these techniques. I’ll take lock striping as an example, but the reasoning works for RW locks, excessive splitting of synchronized blocks, etc. Lock striping gives you finer-grained access control, enabling greater concurrency — but is harder to get right. With one big fat lock, it’s much easier to verify thread safety; with many, its harder. So this is a tradeoff where you get better potential scalability at the cost of maintainability / fragility.

This is sometimes a great trade — but often is a lousy one. Do you _know_ that the code in question is the source of performance problems? If not, you’ve made your code more complicated, more fragile, and less maintainable for no benefit. Add this to the fact that most programmers have terrible intuition about where the bottlenecks are. Without a good measurement program in place, or a deep understanding of the issues (in which case the reader probably doesn’t need this advice), most of the time applying these techniques is (at best) premature optimization.

I would rename item #5 “Trust the libraries”.