I haven’t looked at the code, but what you’re describing doesn’t sound that bad. If the queue is empty then it doesn’t matter whether a worker is waiting on the lock or waiting on the receiver itself. If the queue is non-empty then whoever has the lock will soon complete the receive and release the lock. It would be better to just use an actual MPMC channel, but if the traffic on the queue isn’t too high then it probably doesn’t make a significant difference. With round robin in contrast, the sender would risk sending a job to a worker that was already busy, unless it took additional measures to avoid that.

I suspect this is just an LLM hallucinating generic thread-safety boilerplate. In an async serverless runtime like Workers this pattern creates blocking risks and doesn't actually solve the distributed consistency problem.