@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”.

Shared-nothing is the best default when parallelisation is going to happen.
This shouldn’t be about the system design. It can be about the language, as well. As they say, `In a parallel world, imperative is the wrong default’.