Generally code samples use locks this way:
static readonly object lockForWorkingWithSharedObject = new object();
lock(lockForWorkingWithSharedObject)
{
// do something with shared object
}
This way we need many locks in a large class. Is it good practice to use the shared object itself as the synchronization object ?
// of course here sharedObject is a reference type
lock(sharedObject)
{
// do something with sharedObject
}
In Java and .NET, the point of having each object lockable is precisely because language designers thought it would be useful to use the object itself as the lock; hence also the synchronized keyword in Java.
If you need much finer granularity of locking, I would assume that you better split the state of your object in multiple objects, grouped by things that semantically belong together, and thus likely also need to protected against concurrent access together.
