[Python] Does the lock in asyncio.Condition have other purpose besides compatibility with...

I'd like to ask about asyncio.Condition. I'm not familiar with the concept, but I know and understand locks, semaphores, and queues since my student years.

I could not find a good explanation or typical use cases, just this example. I looked at the source. The core fnctionality is achieved with a FIFO of futures. Each waiting coroutine adds a new future and awaits it. Another coroutine may call notify() which sets the result of one or optionally more futures from the FIFO and that wakes up the same number of waiting coroutines. Really simple up to this point.

However, the implementation and the usage is more complicated than this. A waiting coroutine must first acquire a lock associated with the condition in order to be able to wait (and the wait() releases it while waiting). Also the notifier must acquire a lock to be able to notify(). This leads to with statement before each operation:

async with condition:
# condition operation (wait or notify)


or else a RuntimeError occurrs.

I do not understand the point of having this lock. What resource do we need to protect with the lock? In asyncio there could be always only one coroutine executing in the event loop, there are no "critical sections" as known from threading.

Is this lock really needed (why?) or is it for compatibility with threading code only?

My first idea was it is for the compatibility, but in such case why didn't they remove the lock while preserving the usage? i.e. making

async with condition:


basically an optional no-op.

Continue reading...