Look Both Ways Before You Lock

Google Code Search is truly the search engine for the uber geek, and potentially a great source of sublime code and sublime comments.  K. Scott Allen, aka Mr. OdeToCode, posted a few choice samples of prose he found while searching through code (Scott, exactly what were you searching for?).

One comment he quotes strikes me as a particularly good point to remember about using locks in multithreaded programming.

Locks are analogous to green traffic lights: If you have a green light, that does not prevent the idiot coming the other way from plowing into you sideways; it merely guarantees to you that the idiot does not also have a green light at the same time. (from File.pm).

The point the comment makes is that a lock does not prevent another thread from going ahead and accessing and changing a member.  Locks only work when every thread is “obeying the rules”.

Unfortunately, unlike an intersection, there is no light to tell you whether or not the coast is clear. When you are about to write code to access a static member, you don’t necessarily know whether or not that member might require having a lock on it. To really know, you’d have to scan every access to that member.

This is why concurrency experts such as Joe Duffy recommend following a locking model.  A locking model can be as simple or as complex as needed by your situation.

In any case, have fun with Google Code Search. You might find yourself reviewing the code of a Star Trek text-based sex adventure.