Same Resource, Same Lock or else locking won't give you the protection you need

I sometimes see funny locking patterns because there is a mental assumption that the lock keyword (via Monitor features of the runtime) automatically guards the contents of the locked region. This isn't the case. All that is guaranteed is that only one thread can hold the monitor (i.e. the locked object) at any moment. This doesn't result in resource protection at all unless you, by policy, always take the same lock when accessing the same resource.

Of course locking choices can have profound performance ramifications but that's not really the point here. The thing to remember is that locking alone generally does not provide protection -- you get protection by applying a consistent locking policy to a resource or set of resources.

Sometimes, in the name of performance, complex locking schemes get invented but then race conditions are introduced so correctness goes out the window. It's always important to remember that, as I'm fond of saying, "It's easy to make it fast if it doesn't have to work."