gh-114203: skip locking if object is already locked by two-mutex critical section

[kumaraditya303]

This fixes the issue outlined in https://gist.github.com/kumaraditya303/05cd1c93577bd7f44f573dad61674842

If the object is currently locked by a two-mutex critical section then locking is skipped. Previously locking was skipped only in case where mutex was the first mutex of the two which is decided by memory address so was nondeterministic.

• Issue: critical section should avoid parking lot when re-entering top-most held critical section #114203

[colesbury]

The behavior looks correct to me. Would you please add a test for this behavior to _testinternalcapi/test_critical_sections.c

[kumaraditya303]

Would you please add a test for this behavior to _testinternalcapi/test_critical_sections.c

I have added tests for reacquisition of both one and two mutex critical sections.

[colesbury]

LGTM:

I think it deserves a NEWS entry

I think we should backport to 3.14: it's low risk and avoids a class of bugs in third party extensions that will be annoying for everyone to deal with. @Yhg1s, what do you think?

[Yhg1s]

Yeah, I think it makes sense to backport. It doesn't really have downsides and as you say, avoids latent bugs in user code in some situations. I wish we could do more to flag those issues, but that's a task for better tooling (which we're also working on), not something we can improve on here.

[miss-islington-app]

Thanks @kumaraditya303 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

[bedevere-app]

GH-141564 is a backport of this pull request to the 3.14 branch.