Add managed entry points for raising Contention events

[kouvel]

• Added the events similarly to how the PortableThreadPool events are currently set up
• The events are not raised anywhere from the managed side yet, it's expected that they will eventually be raised by a new Lock type and at least by NativeAOT's Lock

[ghost]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

Issue Details

---

• Added the events similarly to how the PortableThreadPool events are currently set up
• The events are not raised anywhere from the managed side yet, it's expected that they will eventually be raised by a new Lock type and at least by NativeAOT's Lock

Author:	kouvel
Assignees:	kouvel
Labels:	area-System.Threading
Milestone:	8.0.0

[stephentoub]

The events are not raised anywhere from the managed side yet, it's expected that they will eventually be raised by a new Lock type and at least by NativeAOT's Lock

Do we expect to raise these as well from SpinLock? What about other managed lock types, like ReaderWriterLockSlim?

[kouvel]

Do we expect to raise these as well from SpinLock? What about other managed lock types, like ReaderWriterLockSlim?

It would be nice to in the future, though I haven't seen much desire for it. For doing that though, could maybe consider adding an enum field that indicates what type caused the contention for easier filtering. Although the ContentionStart event has stacks, stack tracing can be missed sometimes. Or maybe they can be different events for each type, that would make it easier to identify quickly from a profile, but then there's also a question about whether Monitor.LockContentionCount should include contention from all of those types or if we should have different contention properties on the appropriate types, and what the dotnet-monitor contention count would show. My inclination currently is to evaluate expanding it based on need.

[davmason]

LGTM

[lateralusX]

This file was not included previously if FeaturePortableThreadPool wasn't true and never on Mono/CoreCLR, now it looks like this will always be included if FeaturePerfTracing != 'true' and that is at least the case for TargetsBrowser (WASM).

[kouvel]

Previously the file contained events that would only be raised by the portable thread pool. I reused the same file for contention events and they could be raised from anywhere. Some thread pool events too may be raised from different implementations in the future.

The condition that enables FeaturePortableThreadPool in Mono is currently similar to the one that enables FeaturePerfTracing. I believe the correct condition would be just '$(FeaturePerfTracing)' != 'true', as FeaturePerfTracing seems to be the one used to set up eventing (and using genRuntimeEventSources.py). In NativeAOT, currently FeaturePerfTracing is true but the eventing stuff appears to not be set up yet, so I modified the conditions so that the same file as before would for now be included in NativeAOT.