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.
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.
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.