-
Notifications
You must be signed in to change notification settings - Fork 10k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use System.Threading.Lock throughout ASP.NET Core #56794
Labels
area-networking
Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Perf
Comments
dotnet-issue-labeler
bot
added
the
area-networking
Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
label
Jul 15, 2024
1 task
|
Yes, they would be ideal candidates. I used static in the example, but any |
I've raised an issue for an analyzer rule at: dotnet/runtime#106907 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area-networking
Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Perf
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
.NET 9 added a new lock type: dotnet/runtime#34812. The benefits are some small performance improvements, and disambiguation about locking on any type.
We should see if we can use this in ASP.NET Core. Could be performance gains in lock heavy code.
Describe the solution you'd like
The new type is only available in .NET 9 or later. However, some ASP.NET Core code targets back to .NET standard. It's not as simple as updating
private static readonly object _lock
fields with theLock
type because of this.We could add a shim
Lock
type that is conditionally included in older targets. A shim type would avoid spreading#ifdefs
throughout the code.Additional context
No response
The text was updated successfully, but these errors were encountered: