Encourage use of .NET 9.0's System.Threading.Lock

[MarkCiliaVincenti]

Will improve performance once the library starts targeting .NET 9.0 as locking on System.Threading.Lock is ~25% more performant over locking on an object. Newly-added micro dependency allows backported use without affecting performance.

[fredericDelaporte]

Thanks for the proposal,

bUnit-dev/bUnit#1532 has a discussion about this which is relevant for NHibernate too.

For the simple usages we currently have (excepted the Monitor one which would have to be slightly different), using something like:

#if NET_9_0_OR_GREATER
private readonly Lock syncLock = new();
#else
private readonly object syncLock = new();
#endif

Seems enough and would avoid adding a new dependency for users to investigate if they want it in their project or not.

[fredericDelaporte]

So, it needs language version 14.0? We will likely wait for it before merging your proposal, if we accept it.

[fredericDelaporte]

I have not spotted what does require such a change. Why this change?

[MarkCiliaVincenti]

It's 13.0 as such, and comes with .NET 9.0, but for now you need to set the LangVersion to preview on .NET 9.0 in order to lock on a System.Threading.Lock object. The expectation is that this changes as soon as .NET 9.0 is released.

[fredericDelaporte]

So, that is this Nuget package, coming from your repository.

[MarkCiliaVincenti]

Yes, that is correct.

[MarkCiliaVincenti]

Thanks for the proposal,

bUnit-dev/bUnit#1532 has a discussion about this which is relevant for NHibernate too.

For the simple usages we currently have (excepted the Monitor one which would have to be slightly different), using something like:

#if NET_9_0_OR_GREATER
private readonly Lock syncLock = new();
#else
private readonly object syncLock = new();
#endif

Seems enough and would avoid adding a new dependency for users to investigate if they want it in their project or not.

Yes, it is very relevant.
bUnit-dev/bUnit#1532 (comment) in particular

Using the code you pasted above will give "CS9216: A value of type System.Threading.Lock converted to a different type will use likely unintended monitor-based locking in lock statement." when you try using it in MonitorLock / InternalLock if you do it globally, plus you won't get the performance benefits of .NET 9.0 on that class if you keep using Monitor.

[MarkCiliaVincenti]

As for your concern regarding the additional dependency, I understand, but what we can do is copy the code into NHibernate and just put in a comment at the top giving credit. It's not ideal, but if the dependency is a deal-breaker for you we can do that instead.

[hazzik]

Thanks for the contribution. It is unlikely we'll be targeting .NET 9 version as it is not LTS. Also, we would like to avoid an external dependency.

[MarkCiliaVincenti]

Thanks for the contribution. It is unlikely we'll be targeting .NET 9 version as it is not LTS. Also, we would like to avoid an external dependency.

We could copy the code in. But if you don't intend on targeting .NET 9 that's another story because this would have to wait until .NET 10.

[MarkCiliaVincenti]

@fredericDelaporte a new version of Backport.System.Threading.Lock has come out that acts as a source generator and basically dropping the DLL as a dependency. If this new development makes you reconsider, I will amend this PR accordingly.