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.

[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. https://github.com/bUnit-dev/bUnit/pull/1532#issuecomment-2323294989 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.