Backport.System.Threading.Lock 2.0.5

dotnet add package Backport.System.Threading.Lock --version 2.0.5                
NuGet\Install-Package Backport.System.Threading.Lock -Version 2.0.5                
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="Backport.System.Threading.Lock" Version="2.0.5" />                
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add Backport.System.Threading.Lock --version 2.0.5                
#r "nuget: Backport.System.Threading.Lock, 2.0.5"                
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install Backport.System.Threading.Lock as a Cake Addin
#addin nuget:?package=Backport.System.Threading.Lock&version=2.0.5

// Install Backport.System.Threading.Lock as a Cake Tool
#tool nuget:?package=Backport.System.Threading.Lock&version=2.0.5                

Backport.System.Threading.Lock Backport.System.Threading.Lock

GitHub Workflow Status NuGet NuGet Codacy Grade Codecov

A micro-library that backports/polyfill .NET 9.0+'s System.Threading.Lock to prior framework versions (from .NET Framework 3.5 up to .NET 8.0), providing as much backward compatibility as possible.

Why is this useful?

Apart from streamlining locking, especially with a new lock statement pattern being proposed, and the ability to use the using pattern for locking, the more obvious reason for using it is that it gives greater performance than simply locking on an object.

Why not keep it simple?

Some developers have opted to put in code like this:

#if NET9_0_OR_GREATER
global using Lock = System.Threading.Lock;
#else
global using Lock = System.Object;
#endif

This is a trick that works in some cases but limits you in what you want to do. You will be unable to use any of the methods offered by System.Threading.Lock such as EnterScope that allows you to use the using pattern.

More importantly though, if you need to do something like lock in one method and lock with a timeout in another, you simply can't with this code you put here.

On .NET 8.0 or earlier you cannot do a myLock.Enter(5) and on .NET 9.0 or later you wouldn't be able to Monitor.Enter(myLock, 5) as this gives you the warning "CS9216: A value of type System.Threading.Lock converted to a different type will use likely unintended monitor-based locking in lock statement."

#if NET9_0_OR_GREATER
global using Lock = System.Threading.Lock;
#else
global using Lock = System.Object;
#endif

private readonly Lock myObj = new();

void DoThis()
{
   lock (myObj)
   {
      // do something
   }
}

void DoThat()
{
   myObj.Enter(5); // this will not compile on .NET 8.0
   Monitor.Enter(myObj, 5); // this will immediately enter the lock on .NET 9.0 even if another thread is locking on DoThis()
   // do something else
}

If you want to avoid limiting what you are able to do, you need a solution such as this library.

Usage

There are two methods for using this library:

  1. Clean method: If you are only targeting .NET 5.0 or greater, then you are strongly recommended to use the clean method.
  2. Factory method: If you need to target frameworks prior to .NET 5.0 (and that would also include .NET Standard 2.0 and 2.1), then you need to use the factory method because the clean method cannot be hardened against thread aborts which were removed in .NET 5.0.

Clean method (if only targeting .NET 5.0 or greater)

In order to get the performance benefits of System.Threading.Lock, you must however multi-target frameworks in your .csproj file.

Example:

<TargetFrameworks>net5.0;net9.0</TargetFrameworks>

There is also no need to reference this library as a dependency for .NET 9.0+. You can achieve that by having this in your .csproj file:

<ItemGroup Condition="!$([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net9.0'))">
  <PackageReference Include="Backport.System.Threading.Lock" Version="2.0.5" />  
</ItemGroup>

Use this library the same way you would use System.Threading.Lock. Example:

private readonly System.Threading.Lock _syncRoot = new();

public void Foo()
{
    lock (_syncRoot)
    {
        // do something
    }
}

public void Bar()
{
    using (_syncRoot.EnterScope())
    {
        // do something
    }
}

Factory method (if targeting frameworks prior to .NET 5.0)

Due to frameworks prior to .NET 5.0 supporting the notorious Thread.Abort, we cannot use the same System.Threading.Lock namespace or else the locks would not be hardened against thread aborts, so we need to use a creator method instead.

IMPORTANT: You MUST also multi-target .NET 9.0 in your .csproj file as well.

Example:

<TargetFrameworks>netstandard2.0;net9.0</TargetFrameworks>

In your .csproj file, or ideally in your Directory.Build.props file to avoid doing it to all projects, do the following:

<ItemGroup>
  <Using Condition="$([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net9.0'))" Alias="Lock" Include="System.Threading.Lock" />
  <Using Condition="!$([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net9.0'))" Alias="Lock" Include="Backport.System.Threading.Lock" />
  <Using Alias="LockFactory" Include="Backport.System.Threading.LockFactory" />
</ItemGroup>

Usage:

private readonly Lock _syncRoot = LockFactory.Create();

public void Foo()
{
    lock (_syncRoot)
    {
        // do something
    }
}

public void Bar()
{
    _syncRoot.Enter();
    // do something that cannot crash on a thread that cannot abort
    _syncRoot.Exit();
}

Use the Lock class the same way you would use System.Threading.Lock.

Performance

This library was benchmarked against locking on an object on .NET 8.0 and no speed or memory allocation difference was noted, whereas when .NET 9.0 was used the performance was ~25% better as opposed to locking on an object.

Credits

Check out our list of contributors!

Product Compatible and additional computed target framework versions.
.NET net5.0 is compatible.  net5.0-windows was computed.  net6.0 is compatible.  net6.0-android was computed.  net6.0-ios was computed.  net6.0-maccatalyst was computed.  net6.0-macos was computed.  net6.0-tvos was computed.  net6.0-windows was computed.  net7.0 is compatible.  net7.0-android was computed.  net7.0-ios was computed.  net7.0-maccatalyst was computed.  net7.0-macos was computed.  net7.0-tvos was computed.  net7.0-windows was computed.  net8.0 was computed.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed.  net9.0 is compatible. 
.NET Core netcoreapp2.0 was computed.  netcoreapp2.1 was computed.  netcoreapp2.2 was computed.  netcoreapp3.0 was computed.  netcoreapp3.1 was computed. 
.NET Standard netstandard2.0 is compatible.  netstandard2.1 was computed. 
.NET Framework net35 is compatible.  net40 is compatible.  net403 was computed.  net45 is compatible.  net451 was computed.  net452 was computed.  net46 was computed.  net461 was computed.  net462 was computed.  net463 was computed.  net47 was computed.  net471 was computed.  net472 was computed.  net48 was computed.  net481 was computed. 
MonoAndroid monoandroid was computed. 
MonoMac monomac was computed. 
MonoTouch monotouch was computed. 
Tizen tizen40 was computed.  tizen60 was computed. 
Xamarin.iOS xamarinios was computed. 
Xamarin.Mac xamarinmac was computed. 
Xamarin.TVOS xamarintvos was computed. 
Xamarin.WatchOS xamarinwatchos was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.
  • .NETFramework 3.5

    • No dependencies.
  • .NETFramework 4.0

    • No dependencies.
  • .NETFramework 4.5

    • No dependencies.
  • .NETStandard 2.0

    • No dependencies.
  • net5.0

    • No dependencies.
  • net6.0

    • No dependencies.
  • net7.0

    • No dependencies.
  • net9.0

    • No dependencies.

NuGet packages (9)

Showing the top 5 NuGet packages that depend on Backport.System.Threading.Lock:

Package Downloads
DisCatSharp

DisCatSharp Your library to write discord bots in C# with a focus on always providing access to the latest discord features. Written with love and for everyone.

DisCatSharp.Common

DisCatSharp Common Extension Common tools for DisCatSharp, like regexes and converters!

CarinaStudio.AppBase.Core

AppBase is a base library set for .NET application. CarinaStudio.AppBase.Core is the core library of AppBase, provides extensions for object, collection and threading to make your code more elegant and clear.

EasyMemoryCache

MemoryCache component, for easy MemoryCache implementation

EasilyNET.Core

业务类型库,用于一些业务方面的类,如分页,以及业务中常用的一些数据类型和枚举类型

GitHub repositories (3)

Showing the top 3 popular GitHub repositories that depend on Backport.System.Threading.Lock:

Repository Stars
MarimerLLC/csla
A home for your business logic in any .NET application.
netcorepal/netcorepal-cloud-framework
基于 ASP.NET Core 的领域驱动设计微服务架构实现方案
Aiko-IT-Systems/DisCatSharp
Your library to write discord apps in C# with focus on always providing access to the latest discord features

Made IsHeldByCurrentThread unavailable for frameworks that don't support Monitor.IsEntered rather than throwing a NotSupportedException.