Why is specifying a synchronization object in the lock statement mandatory

Question

I'm trying to wrap my mind around what exactly happens in the lock statement.

If I understood correctly, the lock statement is syntactic sugar and the following...

Object _lock = new Object();

lock (_lock)
{
    // Critical code section
}

...gets translated into something roughly like:

Object _lock = new Object();

Monitor.Enter(_lock);
try
{
    // Critical code section
}
finally { Monitor.Exit (_lock); }

I have used the lock statement a few times, and always created a private field _lock, as a dedicated synchronization object. I do understand why you should not lock on public variables or types.

But why does the compiler not create that instance field as well? I feel there might in fact be situations where the developer wants to specify what to lock on, but from my experience, in most cases that is of absolutely no interest, you just want that lock! So why is there no parameterless overload of lock?

lock()
{
   // First critical code section
}

lock()
{
   // Second critical code section
}

would be translated into (or similar):

[DebuggerHidden]
private readonly object _lock1 = new object()

[DebuggerHidden]
private readonly object _lock2 = new object()

Monitor.Enter(_lock1);
try
{
    // First critical code section
}
finally { Monitor.Exit(_lock1); }

Monitor.Enter(_lock2);
try
{
    // Second critical code section
}
finally { Monitor.Exit(_lock2); }

EDIT: I have obviously been unclear concerning multiple lock statements. Updated the question to contain two lock statements.

Your suggestion seems like an equivalent to lock(this) which is not a very good idea. — empi
@empi: no, it is not equivalent to lock(this) since _ lock is a member — mousio
@mousio: it will be equivalent functionally since there will be one lock object (_lock) for class instance — empi
@empi: you just explained why it is not equivalent; what about static methods requiring a lock? — mousio
@adabyron you already have an attribute that can be applied to a method for this [MethodImpl(MethodImplOptions.Synchronized)] — L.B

Jonathan Rupp Jonathan Rupp · Accepted Answer · 2013-01-01T02:27:27

In order for the no-variable thing to work, you'd have to either:

Have one auto-generated lock variable per lock block (what you did, which means that you can't have two different lock blocks locking on the same variable)
Use the same lock variable for all lock blocks in the same class (which means you can't have two independent things protected)

Plus, you'd also have the issue of deciding whether those should be instance-level or static.

In the end, I'm guessing the language designers didn't feel that the simplification in one specific case was worth the ambiguity introduced while reading code. Threading code (which is the reason to use locks) is already hard to write correctly and verify. Making it harder would be a not-good thing.

Why is specifying a synchronization object in the lock statement mandatory

4 Answers