Monitor should limit recursion

[danmoseley]

lock/Monitor supports recursion but does not seem to document or enforce a limit.

Right now it uses the object header up to 64 or so, then transitions to a sync block. That uses a 64 bit counter.

Correctness wise, it looks like the counter will just wrap (and release?) if code hits the limit -- given the size the chance of this is basically zero though.

But it might be interesting to pick a maximum recursion count that is less than ulong.MaxValue but greater than any plausible functioning code would need, then throw LockRecursionException when it's hit. This would expose any buggy code that is recursing without bound.

cc @kouvel from #34812 (comment)

[ghost]

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

Issue Details

---

lock/Monitor supports recursion but does not seem to document or enforce a limit.

Right now it uses the object header up to 64 or so, then transitions to a sync block. That uses a 64 bit counter.

Correctness wise, it looks like the counter will just wrap (and release?) if code hits the limit -- that probably doesn't matter much because it's implausible that could happen in a reasonable amount of time.

But it might be interesting to pick a maximum recursion count that is less than ulong.MaxValue but greater than any plausible functioning code would need, then throw LockRecursionException when it's hit. This would expose any buggy code that is recursing without bound.

cc @kouvel

Author:	danmoseley
Assignees:	-
Labels:	area-System.Threading
Milestone:	-

[danmoseley]

looks like nativeAOT will throw (OverflowException) if recursion fills 32 bits.

[svick]

This would expose any buggy code that is recursing without bound.

Do I understand it correctly that the goal here is to cover the (rare?) cases that don't already throw StackOverflowException, like those that are tail-call optimized, or those that call Monitor.Enter in a loop?

[kouvel]

This issue is about one thread entering a lock multiple times without exiting it. There is an inherent limit on the number of such enters after which an exception should be thrown.