Closed elachlan closed 2 weeks ago
@kirsan31 I saw you commented on the runtime issue. What are your thoughts on this?
@JeremyKuhne you might be able to shoot this down early.
One thing I am wondering is if the heavy usage of lock (this)
is on purpose?
We can explore this when the feature leaves preview state.
Runtime issue: https://github.com/dotnet/runtime/issues/34812 C# issue: https://github.com/dotnet/csharplang/issues/7104
@kirsan31 I saw you commented on the runtime issue. What are your thoughts on this?
My thots on this:
So if acquire/release without waiting will be faster (it must) then we can feel free to replace object locking in those cases where waiting is rare. In other cases some analysis will be needed I think...
The code base locks a lot on this
. Which usually isn't a good idea. I'd like this issue to review that as well.
I've raised an roslyn-analyzer rule over at: https://github.com/dotnet/runtime/issues/106907
It would make changes like this easier.
@lonitra do you know who we can ask about the new Lock type? I am wondering if we can use it based on this comment:
If we want to have a lock object type not integrated into Monitor, then there is quite a bit of work required to make sure it integrates with the diagnostics infrastructure and the threading model correctly. (Monitor is an interruptible lock as it uses a COM interruptible wait so that STA frameworks such as WinForms and WPF work correctly. Any other lock that is intended for general use will also need to follow those strictures.)
https://github.com/dotnet/runtime/issues/34812#issuecomment-612531493
Going to do this in .NET 10. I'm comfortable enough with what I've read to commit to this.
In .NET9 there is the new
System.Threading.Lock
https://learn.microsoft.com/en-us/dotnet/api/system.threading.lock?view=net-9.0Refactor the
object
used for the lock toLock
where appropriate. The newLock
class when used withlock()
will not usesystem.threading.monitor
, but instead will usesystem.threading.lock
.Benchmarks in this blog post suggest a 25% performance improvement in lock operations: https://steven-giesel.com/blogPost/4cf6d48a-ec9d-4c68-961c-31fd8d8c1340
There are some limitations, I think the team is best positioned to decide whats best here.
We won't make changes until C# takes the change to the
lock
keyword out of preview. https://github.com/dotnet/csharplang/issues/7104