Implicitly scoped lock statement

[skarllot]

Motivation:

Allow lock keyword to be used to lock a variable that will be unlocked at the end of the current block. This avoids creating a new block with an additional level of indentation:

Before:

public void Foo() {
    lock (numberGate) {
        number += 5;
        if (number > 1000) {
            number = 0;
        }
    }
}

After:

public void Foo() {
    lock numberGate;
    number += 5;
    if (number > 1000) {
        number = 0;
    }
}

[YairHalberstadt]

It is absolutely vital that locks are as short as possible. As such this might be considered a bad idea.

[marksmeltzer]

Same rationale as was used for simplifying using, and I love that simplification.

[theunrepentantgeek]

@marksmeltzer wrote:

Same rationale as was used for simplifying using, and I love that simplification.

The simplification for using makes sense because the vast majority of using statements finish at the end of the enclosing block:

{
    // code

    using (var thing = ...) 
    {
        // more code
    }
}

However, because of the need for lock statements to enclose as little as possible, my experience is that those blocks typically finish well before the enclosing block:

{
    // code

    lock (_thing) 
    {
        // more code
    }

    // yet more code
}

Creating a variation of lock that encourages longer lock retention would be a bad idea.

I'd also offer the observation that using statements are extremely common - so the new using declarations will benefit a lot of developers. By contrast, lock statements are relatively rare, so any benefit would accrue to a significantly smaller group.

[PathogenDavid]

I'd also offer the observation that using statements are extremely common - so the new using declarations will benefit a lot of developers.

It's also more common to end up with many using statements in the same method, so using statements can keep the number of blocks and levels of indentation required under control in a method when omitting the blocks isn't possible.

[HaloFour]

Another difference between lock and using is that the latter is tied to the declaration of a variable, and the resource is disposed at the point that the variable goes out of scope. You can't use a using declaration on an existing variable. lock must be used on an existing variable, but the duration of the lock certainly wouldn't be associated with the scope of that variable.

[SilentSin]

You can't use a using declaration on an existing variable.

Yes you can.

[HaloFour]

@SilentSin

I'm referring to the new feature slated for C# 8.0:

void M() {
    using var foo = new Foo();
    // do stuff here
} // foo automatically disposed here

Sorry, should have clarified.

[skarllot]

@theunrepentantgeek for me when using locks, is common that the scope of locks are the method/property itself.

Another side effect is to provide a feature closer to Java synchronized methods.

[HaloFour]

@skarllot

Another side effect is to provide a feature closer to Java synchronized methods.

This already exists in .NET:

[MethodImpl(MethodImplOptions.Synchronized)]
public void Method()
{
    MethodImpl();
}

C# doesn't expose it at the method level because it behaves identically to how synchronized is implemented in Java and even at that time it was known to be a bad idea. Sadly it wasn't yet understood that locking arbitrary object instead of a specific lock primitive was also a bad idea.

This is really a sidebar as I assume your proposal would keep to the concept of locking on some arbitrary object and not trying to replicate Java synchronized methods by implicitly locking this or the Type. When you are using synchronized on an arbitrary object in Java you are still required to supply a block. It's pretty much identical to C# in that regard.

[ghord]

Please consider fixed for the same feature

[DavidArno]

public void Foo() 
{
    lock (numberGate) restOfFoo();

    void restOfFoo()
    {
        number += 5;
        if (number > 1000) number = 0;
    }
}

🤡

[CodeDevAM]

It is absolutely vital that locks are as short as possible. As such this might be considered a bad idea.

and

Creating a variation of lock that encourages longer lock retention would be a bad idea.

I think that's actually a descision of the developer and has nothing to do with the syntax. The argument misses the real motivation behind this proposal. It's about making code more readable and easy to write.

One circumstance that may complicate the implementation of the suggestion is the fact that lock(_lockObject); there is already a valid systax today. However it is pretty useless.

[theunrepentantgeek]

the fact that lock(_lockObject); there is already a valid systax today. However it is pretty useless.

It is pretty useless today.

But if #7104 goes ahead, different implementations will be free to implement the pattern with different semantics. You could, for example, easily write an implementation that implements rate throttling - by blocking callers to prevent flooding another subsystem.

(And #7104 has a proposal champion, so it's far more likely to go ahead than most ideas.)

[333fred]

We generally accept the changes for special casing how System.Threading.Lock interacts with the lock keyword, but we will not adopt the full pattern at this time.

At this point, we're not doing a full pattern. Just special-casing System.Threading.Lock.

[colejohnson66]

@333fred That's fine with me, but is there a reason the team abandoned/pushed off the more generalized ILock (or whatever interface it was) pattern?

[333fred]

We didn't see the use case. The notes linked from #7104 have the full context.

[jaredpar]

That's fine with me, but is there a reason the team abandoned/pushed off the more generalized ILock

In the case of Lock the holder type is a ref struct. When designing this feature we hadn't committed to allowing ref struct in generics hence we couldn't define a ILock<T> that works with the most important type.

It's possible we could revisit this in the future but right now we don't have a motivating example.