Lock behavior differs between asyncio and trio after the lock changes in 4.5.0

[gruuuve]

Things to check first

• I have searched the existing issues and didn't find my bug already reported there

• I have checked that my bug is still present in the latest release

AnyIO version

AnyIO 4.6.0

Python version

3.12.5

What happened?

Prior to AnyIO 4.5.0, an exception would be raised when a caller attempted to acquire a lock that was already claimed on both the asyncio and trio backends.
Exception output: RuntimeError: attempt to re-acquire an already held Lock

Now, in both 4.5.0 and 4.6.0, asyncio will hang indefinitely. In the context manager example, RuntimeError: The current task is not holding this lock is output when the process is interrupted with ctrl-c . Trio still behaves the same as it did prior to 4.5.0, so it appears this issue is only with the asyncio changes.

How can we reproduce the bug?

Simplest case to demonstrate the error:

async def main() -> None:
    _lock = anyio.Lock()

    await _lock.acquire()


    await _lock.acquire()

if __name__ == "__main__":
    anyio.run(main)#, backend="trio")

Similar behavior with context managers:

async def main() -> None:
    _lock = anyio.Lock()

    async def get_lock() -> None:
        async with _lock:
            print("Error should be raised here")

    async with _lock:
        await get_lock()

if __name__ == "__main__":
    anyio.run(main)#, backend="trio")

[gruuuve]

I tested this on python 3.11.9 as well to check for any variance with the standard library, and the same behavior occurred.

[agronholm]

An unfortunate regression. I'll see this fixed in v4.6.1. I may also need to release v4.5.1 for Python 3.8 compatibility.

[vfazio]

Thanks @agronholm, we're coming off 3.7.1 so for now we plan to pin to 4.4.0 to avoid the regression and will attempt taking 4.6.1 when released.

[gruuuve]

Awesome, thank you so much @agronholm!