Skip to content

Add notes and references to threading.lock#54638

Open
adegeo wants to merge 1 commit into
mainfrom
adegeo/48211/lock
Open

Add notes and references to threading.lock#54638
adegeo wants to merge 1 commit into
mainfrom
adegeo/48211/lock

Conversation

Copilot AI review requested due to automatic review settings July 3, 2026 19:49
@adegeo adegeo requested review from a team and BillWagner as code owners July 3, 2026 19:49
@dotnetrepoman dotnetrepoman Bot added this to the July 2026 milestone Jul 3, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds cross-cutting guidance to the .NET threading documentation to steer readers toward using System.Threading.Lock with the C# lock statement in .NET 9/C# 13+, and clarifies how lock/SyncLock map to EnterScope vs. Monitor.Enter/Exit.

Changes:

  • Added notes across multiple threading overview pages recommending a dedicated System.Threading.Lock instance for general locking scenarios in .NET 9 and C# 13 or later.
  • Updated the “Synchronized code regions” guidance to explain when lock uses Lock.EnterScope vs. Monitor.Enter/Exit, and clarified Visual Basic guidance.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 7 comments.

Show a summary per file
File Description
docs/standard/threading/threading-objects-and-features.md Adds a note recommending System.Threading.Lock with C# lock for general locking scenarios.
docs/standard/threading/synchronizing-data-for-multithreading.md Updates the synchronized-region note to describe Lock.EnterScope behavior and VB limitations.
docs/standard/threading/overview-of-synchronization-primitives.md Expands the Monitor/lock note with System.Threading.Lock guidance and VB guidance.
docs/standard/threading/managed-threading-best-practices.md Adds a best-practice bullet recommending a dedicated System.Threading.Lock instance in .NET 9/C# 13+.
docs/standard/threading/managed-threading-basics.md Adds an early note pointing readers to System.Threading.Lock guidance for C# 13/.NET 9+.

Comment on lines 1 to 7
---
title: "Managed Threading Best Practices"
description: Learn managed threading best practices in .NET. Work with difficult situations such as coordinating many threads or handling blocking threads.
ms.date: 03/13/2026
ai-usage: ai-assisted
dev_langs:
- "csharp"
- "vb"
Comment on lines +27 to +28
> [!NOTE]
> In .NET 9 and C# 13 or later, prefer a dedicated <xref:System.Threading.Lock?displayProperty=nameWithType> instance with the C# `lock` statement for general locking scenarios. This approach improves performance and reduces mistakes from locking shared objects that weren't meant for synchronization. For details, see [Overview of synchronization primitives](overview-of-synchronization-primitives.md) and [The lock statement](../../csharp/language-reference/statements/lock.md). In Visual Basic, continue to use `SyncLock`.
Comment on lines 24 to +28
|[SpinLock](spinlock.md)|Describes the <xref:System.Threading.SpinLock?displayProperty=nameWithType> structure, which is a lightweight alternative to the <xref:System.Threading.Monitor?displayProperty=nameWithType> class for certain low-level locking scenarios.|
|[SpinWait](spinwait.md)|Describes the <xref:System.Threading.SpinWait?displayProperty=nameWithType> structure, which provides support for spin-based waiting.|

> [!NOTE]
> In .NET 9 and C# 13 or later, prefer a dedicated <xref:System.Threading.Lock?displayProperty=nameWithType> instance with the C# `lock` statement for general locking scenarios. This approach improves performance and reduces mistakes from locking shared objects that weren't meant for synchronization. For details, see [Overview of synchronization primitives](overview-of-synchronization-primitives.md) and [The lock statement](../../csharp/language-reference/statements/lock.md). In Visual Basic, continue to use `SyncLock`.
Comment on lines +16 to +17
> [!NOTE]
> In .NET 9 and C# 13 or later, use a dedicated <xref:System.Threading.Lock?displayProperty=nameWithType> instance with the C# [lock statement](../../csharp/language-reference/statements/lock.md). This approach improves performance and reduces mistakes from locking the wrong object. In Visual Basic, continue to use [SyncLock](../../visual-basic/language-reference/statements/synclock-statement.md).
Comment on lines +16 to +18
> [!NOTE]
> In .NET 9 and C# 13 or later, use a dedicated <xref:System.Threading.Lock?displayProperty=nameWithType> instance with the C# [lock statement](../../csharp/language-reference/statements/lock.md). This approach improves performance and reduces mistakes from locking the wrong object. In Visual Basic, continue to use [SyncLock](../../visual-basic/language-reference/statements/synclock-statement.md).

Comment on lines 54 to +58
> [!NOTE]
> Use the [lock](../../csharp/language-reference/statements/lock.md) statement in C# and the [SyncLock](../../visual-basic/language-reference/statements/synclock-statement.md) statement in Visual Basic to synchronize access to a shared resource instead of using the <xref:System.Threading.Monitor> class directly. Those statements are implemented by using the <xref:System.Threading.Monitor.Enter*> and <xref:System.Threading.Monitor.Exit*> methods and a `try…finally` block to ensure that the acquired lock is always released.
> Use the [lock](../../csharp/language-reference/statements/lock.md) statement in C# and the [SyncLock](../../visual-basic/language-reference/statements/synclock-statement.md) statement in Visual Basic to synchronize access to a shared resource instead of using the <xref:System.Threading.Monitor> class directly.
>
> In .NET 9 and C# 13 or later, use a dedicated <xref:System.Threading.Lock?displayProperty=nameWithType> instance for best performance. In that case, `lock` uses <xref:System.Threading.Lock.EnterScope?displayProperty=nameWithType>.
>
Comment on lines 48 to +52
> [!NOTE]
> Beginning in C# 13, the `lock` statement recognizes if the locked object is an instance of <xref:System.Threading.Lock?displayProperty=nameWithType> and uses the `EnterScope` method to create a synchronized region. The `lock`, when the target isn't a `Lock` instance, and `SyncLock` statements are implemented using <xref:System.Threading.Monitor.Enter*?displayProperty=nameWithType> and <xref:System.Threading.Monitor.Exit*?displayProperty=nameWithType>, so other methods of <xref:System.Threading.Monitor> can be used in conjunction with them within the synchronized region.
> In .NET 9 and C# 13 or later, if the `lock` target is a dedicated <xref:System.Threading.Lock?displayProperty=nameWithType> instance, the `lock` statement uses <xref:System.Threading.Lock.EnterScope?displayProperty=nameWithType> to create a synchronized region.
>
> Visual Basic doesn't support `System.Threading.Lock` in `SyncLock`, so continue to use `SyncLock` with a dedicated private reference type.
>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[New article]: Guidance on when to use or not use Lock

2 participants