-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Fix Deadlock Inside Metrics Code #105259
Fix Deadlock Inside Metrics Code #105259
Conversation
@stephentoub @jkotas could you please help review this fix? Thanks! |
Do you think this will fix #105189? |
Very possible. I'll close this one when I merge to see if this will show up again. |
// 2. Instrument.Publish is called and enters the SyncObject lock. | ||
// 3. Within the lock block, MeterListener is called, triggering its static constructor. | ||
// 4. The static constructor creates runtime metrics instruments, causing re-entry to Instrument.Publish and leading to a deadlock. | ||
RuntimeHelpers.RunClassConstructor(typeof(MeterListener).TypeHandle); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been thinking about it and this seems OK - I didn't come up with another place where the MeterListener static constructor would be a problem. In the future if we did discover any more it might be worthwhile to move the runtime metrics initialization out of the static constructor and instead do it as a lazy initialization within the MeterListener instance constructor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we can consider moving the initialization later out of the static constructor.
src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/Metrics/Instrument.cs
Show resolved
Hide resolved
src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/Metrics/Instrument.cs
Show resolved
Hide resolved
- Trigger the RuntimeMetrics initialization only when actually needed in the MeterListener constructor. - Delete the lock-ordering workaround and wrong comment introduced in dotnet#105259. Trigger the RuntimeMetrics initialization only when actually needed should make the lock-ordering workarond unnecessary.
- Trigger the RuntimeMetrics initialization only when actually needed in the MeterListener constructor. - Delete the lock-ordering workaround and wrong comment introduced in dotnet#105259. Trigger the RuntimeMetrics initialization only when actually needed should make the lock-ordering workarond unnecessary.
* Simplify initialization of RuntimeMetrics - Trigger the RuntimeMetrics initialization only when actually needed in the MeterListener constructor. - Delete the lock-ordering workaround and wrong comment introduced in #105259. Trigger the RuntimeMetrics initialization only when actually needed should make the lock-ordering workarond unnecessary. * Delete unnecessary static fields * Update src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/Metrics/RuntimeMetrics.cs
This is a regression from the change in #104680.
Thanks to @rokonec who caught it and suggested the fix too.