A micro-library that backports/polyfills .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. Optionally works as a source generator.
$ dotnet add package Backport.System.Threading.Lock
Backport.System.Threading.Lock
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.
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.
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;
#endifThis 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.
There are two methods for using this library:
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
}
}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.
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.
Check out our list of contributors!