Lock statement patterns

David · 2월 28, 2024, 10:07오후

jrchs · 2월 29, 2024, 1:23오전

Lock 클래스는 알고 있었는데 성능 차이가 이정도인줄 몰랐네요.
앞으로는 Lock 클래스를 사용하는 걸로…

PS : 혹시 Lock 클래스를 사용하는데 주의 사항이 있을까요? 무조건 Lock Object 대신 써도 문제 없을까요?

Vincent · 2월 29, 2024, 1:46오전

.NET 9에 나올 예정인 새로운 클래스 같습니다.

아직은 없는 게 맞아서 그냥 object 쓰시면 될거 같네요.

정보도 많이 없네요.

Vincent · 2월 29, 2024, 1:50오전

core/release-notes/9.0/preview/preview1/api-diff/Microsoft.NETCore.App/9.0-preview1_System.Threading.md at main · dotnet/core (github.com)

일단 이렇게 생긴거 같습니다.

 namespace System.Threading {
+    [System.Runtime.Versioning.RequiresPreviewFeaturesAttribute]
+    public sealed class Lock {
+        public Lock();
+        public bool IsHeldByCurrentThread { get; }
+        public void Enter();
+        public Lock.Scope EnterScope();
+        public void Exit();
+        public bool TryEnter();
+        public bool TryEnter(int millisecondsTimeout);
+        public bool TryEnter(TimeSpan timeout);
+        public ref struct Scope {
+            public void Dispose();
+        }
+    }
 }

Vincent · 2월 29, 2024, 2:07오전

이걸 찾아보면서 아래 링크도 발견했는데, MS가 정말로 Windows Forms에 대해 MVVM 패턴을 완성 시키려는 목적이 보이는 거 같습니다.

Behavior 클래스 (System.Windows.Forms.Design.Behavior) | Microsoft Learn

이름만 같은건가 생각했는데 예제를 보니 WPF의 그 Behavior네요

Vincent · 2월 29, 2024, 2:08오전

아 새로운 기능이 아니군요…원래 있던거네…;;

tkm · 2월 29, 2024, 2:21오전

dotnet/csharplang/blob/main/proposals/lock-object.md

# `Lock` object

## Summary
[summary]: #summary

Special-case how `System.Threading.Lock` interacts with the `lock` keyword (calling its `EnterScope` method under the hood).
Add static analysis warnings to prevent accidental misuse of the type where possible.

## Motivation
[motivation]: #motivation

.NET 9 is introducing a new [`System.Threading.Lock` type](https://github.com/dotnet/runtime/issues/34812)
as a better alternative to existing monitor-based locking.
The presence of the `lock` keyword in C# might lead developers to think they can use it with this new type.
Doing so wouldn't lock according to the semantics of this type but would instead treat it as any other object and would use monitor-based locking.

```cs
namespace System.Threading
{
    public sealed class Lock

This file has been truncated. show original

github.com/dotnet/runtime

Add first class System.Threading.Lock type

opened 09:58AM - 10 Apr 20 UTC

benaadams

api-approved area-System.Threading

## Background and Motivation Locking on any class has overhead from the dual …role of the syncblock as both lock field and hashcode et al. (e.g. https://github.com/dotnet/runtime/issues/34800) Adding a first class lock type that didn't allow alternative uses and only acted as a lock would allow for a simpler and faster lock as well as be less ambiguous on type and purpose in source code. ## API proposal [Edit] by @kouvel based on https://github.com/dotnet/runtime/issues/34812#issuecomment-1485837123 and https://github.com/dotnet/csharplang/issues/7104 ```csharp namespace System.Threading { // This is a lock that can be entered by one thread at a time. A thread may enter the lock recursively multiple // times, in which case the thread should also exit the lock the same number of times to fully exit the lock. public sealed class Lock { // Exceptions: // - LockRecursionException if the lock was entered recursively by the current thread the maximum number of times public void Enter(); // Returns true if the lock was acquired by the current thread, false otherwise. // Exceptions: // - LockRecursionException if the lock was entered recursively by the current thread the maximum number of times. // In this corner case an exception would be better than returning false, as the calling thread cannot make // further progress with entering the lock before exiting it. public bool TryEnter(); // Returns true if the lock was acquired by the current thread, false otherwise. // Exceptions: // - ArgumentOutOfRangeException if the timeout value converted to an integer milliseconds value is negative // and not equal to -1, or greater than Int32.MaxValue // - LockRecursionException if the lock was entered recursively by the current thread the maximum number of times // In this corner case an exception would be better than returning false, as the calling thread cannot make // further progress with entering the lock before exiting it. public bool TryEnter(TimeSpan timeout); // Returns true if the lock was acquired, false otherwise. // Exceptions: // - ArgumentOutOfRangeException if the timeout value is negative and not equal to -1 // - LockRecursionException if the lock was entered recursively by the current thread the maximum number of times // In this corner case an exception would be better than returning false, as the calling thread cannot make // further progress with entering the lock before exiting it. public bool TryEnter(int millisecondsTimeout); // Exceptions: SynchronizationLockException if the current thread does not own the lock public void Exit(); // Returns true if the current thread holds the lock, false otherwise. // // This is analogous to Monitor.IsEntered(), but more similar to SpinLock.IsHeldByCurrentThread. There could // conceivably be a Lock.IsHeld as well similarly to SpinLock.IsHeld, or Lock.IsHeldByAnyThread to be more // precise, which would return true if the lock is held by any thread. public bool IsHeldByCurrentThread { get; } // Enters the lock and returns a holder. Enables integration with the "lock" keyword. // Exceptions: // - LockRecursionException if the lock was entered recursively by the current thread the maximum number of times public Scope EnterScope(); public ref struct Scope { // Exits the lock. No-op if Dispose was already called. // Exceptions: SynchronizationLockException if the current thread does not own the lock public void Dispose(); } } } ``` ## API Usage Change in usage ```csharp private object _lock = new object(); ``` Becomes the clearer ```csharp private Lock _lock = new Lock(); ``` [Edit] by @kouvel ### Usage example 1 ```c# _lock.Enter(); try { // do something } finally { _lock.Exit(); } ``` ### Usage example 2 ```c# using (_lock.EnterScope()) { // do something } ``` ### Usage example 3 After the `lock` statement integration described in https://github.com/dotnet/runtime/issues/34812#issuecomment-1485837123, the following would use `Lock.EnterScope` and `Scope.Dispose` instead of using `Monitor`. ```c# lock (_lock) { // do something } ``` ### TryEnterScope usage example The following: ```c# if (_lock.TryEnter()) { try { // do something } finally { _lock.Exit(); } } ``` Could be slightly simplified to: ```c# using (var tryScope = _lock.TryEnterScope()) { if (tryScope.WasEntered) { // do something } } ``` The latter could also help to make the exit code path less expensive by avoiding a second thread-static lookup for the current thread ID. ## Alternative Designs - `Scope` could be a regular struct instead of a `ref struct`. A `ref struct` helps to make the exit code path less expensive and can improve performance in some cases, as it guarantees that `Scope.Dispose` is called on the same thread as `EnterScope`, and the path that exits the lock would be able to avoid an extra thread-static lookup for the current thread ID. Similarly for `TryScope`. - For the `TryEnterScope` methods, an alternative is to return a nullable struct. It seems more readable to check for `WasEntered` than to check for null or the `HasValue` property to see if the lock was entered. Also a `ref struct` can't be nullable currently, and a regular struct would not benefit from a potentially less expensive exit path. - `IsHeld` instead of `IsHeldByCurrentThread`. The former is simpler, though may be a bit ambiguous, and may be confusing against `SpinLock.IsHeld`, where it means `IsHeldByAnyThread`. - Making the `Lock` type a struct instead. This may save some allocations in favor of increasing the size of the containing type. Structs can be a bit more cumbersome to work with, and the benefits may not be large enough to be worthwhile. ## Risks - There may be some changes based on the language proposal in https://github.com/dotnet/csharplang/issues/7104

github.com/dotnet/csharplang

[Proposal]: Lock statement pattern

opened 09:06PM - 07 Apr 23 UTC

stephentoub

Proposal champion

# Lock statement pattern * [x] Proposed * [ ] Prototype: Not Started * [x] …Implementation: https://github.com/dotnet/roslyn/pull/71716 * [x] Specification: https://github.com/dotnet/csharplang/blob/main/proposals/lock-object.md (This proposal comes from @kouvel. I've populated this issue primarily with text he wrote in a separate document and augmented it with a few more details.) ## Summary Enable types to define custom behaviors for entering and exiting a lock when an instance of the type is used with the C# “lock” keyword. ## Motivation [motivation]: #motivation .NET 9 is likely to introduce a new dedicated [System.Threading.Lock type](https://github.com/dotnet/runtime/issues/34812). Along with other custom locks, the presence of the `lock` keyword in C# might lead developers to think they can use it in conjunction with this new type, but doing so won't actually lock according to the semantics of the lock type and would instead treat it as any arbitrary object for use with `Monitor`. ## Detailed design [design]: #detailed-design ### Example A type would expose the following to match the proposed pattern: ```C# class Lock : ILockPattern { public Scope EnterLockScope(); public ref struct Scope { public void Dispose(); } } public interface ILockPattern { } ``` `EnterLockScope()` would enter the lock and `Dispose()` would exit the lock. The behaviors of entering and exiting the lock are defined by the type. The `ILockPattern` interface is a marker interface that indicates that usage of values of this type with the `lock` keyword would override the normal code generation for arbitrary objects. Instead, the compiler would lower the `lock` to use the lock pattern, e.g.: ```C# class MyDataStructure { private readonly Lock _lock = new(); void Foo() { lock (_lock) { // do something } } } ``` would be lowered to the equivalent of: ```C# class MyDataStructure { private readonly Lock _lock = new(); void Foo() { using (_lock.EnterLockScope()) { // do something } } } ``` ### Lock pattern and behavior details Consider a type `L` (`Lock` in this example) that may be used with the `lock` keyword. If `L` matches the lock pattern, it would meet all of the following criteria: - `L` implements interface `ILockPattern` - `L` has an accessible instance method `S EnterLockScope()` that returns a value of type `S` (`Lock.Scope` in this example). The method must be at least as visible as `L`. Extension methods don't qualify for the pattern. - A value of type `S` qualifies for use with the `using` keyword A marker interface `ILockPattern` is used to opt into the behaviors below, including through inheritance, and so that `S` may be defined by the user (for instance, as a `ref struct`). For a type `L` that implements interface `ILockPattern`: - If `L` does not fully match the lock pattern, it would result in an error - If a value of type `S` may not be used in the context, it would result in an error - If a value of type `L` is implicitly or explicitly casted to another type that does not match the lock pattern (including generic types), it would result in a warning - This includes implicit casts of `this` to a base type when calling an inherited method - This is intended to prevent accidental usage of `Monitor` with values of type `L` that may be masked under a different type and used with the `lock` keyword, such as with casts to base types, interfaces, etc. - If a value of type `L` is used with the `lock` keyword, or a value of type `S` is used with the `using` keyword, and the block contains an `await`, it would result in an error - The warning would only be issued if in-method analysis can detect it - This is intended to prevent the enter and exit from occurring on different threads. `Monitor` and `Lock` have thread affinity. - `SpinLock` is optionally thread-affinitized. It can opt into the pattern, but then usage of it with the `lock` or `using` keywords would still disallow awaits inside the block statically. ### SpinLock example `System.Threading.SpinLock` (a struct) could expose such a holder: ```C# struct SpinLock : ILockPattern { [UnscopedRef] public Scope EnterLockScope(); public ref struct Scope { public void Dispose(); } } ``` and then similarly be usable with `lock` whereas today as a struct it's not. When a variable of a struct type that matches the lock pattern is used with the `lock` keyword, it would be used by reference. Note the reference to `SpinLock` in the previous section. ## Drawbacks [drawbacks]: #drawbacks - If an existing reference type opted-in to using the pattern, it would change the meaning of `lock(objectsOfThatType)` in existing code, and in ways that might go unnoticed due to the general unobservability of locks (when things are working). This also means if System.Threading.Lock is introduced before the language support, it likely couldn't later participate. - Also if one library `L1` that exposes the type is updated to opt into the lock pattern, another library `L2` that references `L1` and was compiled for the previous version of `L1` would have different locking behavior until it is recompiled with the updated version of `L1`. - The same thing is achievable today with only a little bit more code, using `using` instead of `lock` and writing out the name of the enter method manually (i.e. writing out the lowered code in the first example). - Having the lock semantics vary based on the static type of the variable is brittle. - `ILockPattern` itself doesn't match the lock pattern, though an interface could be created to match the lock pattern. ## Alternatives [alternatives]: #alternatives - Use an attribute instead of a marker interface. A marker interface was used because it works more naturally with inheritence. Although `AttributeUsageAttribute.Inherited = true` could be used for an attribute, it doesn't seem to work with interfaces. - Use a new syntax like `using lock(x)` or other alternatives instead, which would eliminate any possibility of misusing values of the type with `Monitor`. - System.Threading.Lock could be special-cased by the compiler rather than having it be a general pattern. - Various naming options in the pattern itself. - Instead of having a holder type, instead have the compiler explicitly recognize certain enter/exit methods by naming convention or attribution. - Potentially allow/require the `ref` keyword for certain uses, e.g. in the SpinLock example. - The pattern as suggested doesn't support being hardened against thread aborts (which are themselves obsoleted). It could be extended to now or in the future. ## Unresolved questions [unresolved]: #unresolved-questions ## Design meetings https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-05-01.md#lock-statement-improvements https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-10-16.md#lock-statement-pattern https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-12-04.md#lock-statement-pattern

Vincent · 2월 29, 2024, 2:40오전

아이디어 자체는 과거에 이미 제시되었던거라고 말씀하시는건가요??

소스 브라우저 보니까 지금도 있긴하군요

Lock.cs (dot.net)

tkm · 2월 29, 2024, 2:50오전

20년에 최초 제안되었고, 23년 5월에 승인되어 .NET 9에 포함된 기능이라 보면 될 것 같습니다.

Vincent · 2월 29, 2024, 2:51오전

아 소스 브라우저에 보이는건 현재 .NET9-preview1 상태까지 보여주는 건가보군요…

감사합니다~