Fix class construction recursion issue in Lock on NativeAOT

[kouvel]

• The Monitor type was being constructed due to the use of Monitor.DebugBlockingScope, added that to the initialization phase so that the relevant type is initialized before it's used on the wait path
• A better alternative may be to move DebugBlockingScope to be under Lock, it would probably make more sense for Monitor to refer to Lock as it already does, than the inverse. Based on the comments the thread-static field is apparently bound-to in debugging scenarios currently. Something to look into, for now this should unblock the CI.
• FixesNativeAOT tests crashing with infinite recursion in Lock #94227

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

• The Monitor type was being constructed due to the use of Monitor.DebugBlockingScope, added that to the initialization phase so that the relevant type is initialized before it's used on the wait path
• A better alternative may be to move DebugBlockingScope to be under Lock, it would probably make more sense for Monitor to refer to Lock as it already does, than the inverse. Based on the comments the thread-static field is apparently bound-to in debugging scenarios currently. Something to look into, for now this should unblock the CI.
• Fixes NativeAOT tests crashing with infinite recursion in Lock #94227

Author:	kouvel
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	9.0.0

[jkotas]

Based on the comments the thread-static field is apparently bound-to in debugging scenarios currently.

These comments are left-overs from .NET Native for UWP. No debugger uses this field today.

[VSadov]

These comments are left-overs from .NET Native for UWP. No debugger uses this field today.

Although it did not cause problems before, if it is useless, perhaps removing DebugBlockingScope entirely could be a better "fix"?

[kouvel]

These comments are left-overs from .NET Native for UWP. No debugger uses this field today.

Ah ok, thanks!

perhaps removing DebugBlockingScope entirely could be a better "fix"?

Sounds good to me, updated. Something like that could always be added as necessary.

[jkotas]

Sounds good to me, updated. Something like that could always be added as necessary.

Yes, we should look into whether there is any diagnostic support required for the new Lock type, across all runtimes.