Плохая оптимизация блокировки в asyncio

Обновление: следующее устарело в свете моего комментария (ссылка) по проблеме с github. В комментарии отмечается, что вы можете использовать Lock.locked(), чтобы предсказать, даст ли Lock.acquire() результат или нет. Он также отмечает, что многие другие сопрограммы не работают в быстром случае, поэтому бессмысленно даже рассматривать возможность исправления их всех. Наконец, в нем рассказывается, как была устранена другая проблема, и предполагается, что ее можно было бы исправить лучше. Это был запрос на метод asyncio.nop(), который просто уступал бы планировщику и больше ничего не делал. Вместо того, чтобы добавить этот метод, они решили перегрузить asyncio.sleep(0) и «деоптимизировать» его (в контексте этого обсуждения lock.acquire()), чтобы он уступал планировщику, когда аргумент равен 0.

Оригинальный ответ ниже, но заменен абзацем выше:

Основная причина того, что реализация asyncio.lock пытается быть слишком умной в своем первые три строки и не возвращает управление планировщику, если нет официантов:

if not self._locked and all(w.cancelled() for w in self._waiters):
    self._locked = True
    return True

Однако, как показывает мой первый пример, это не позволяет другим сопрограммам даже стать официантами. У них просто нет возможности добежать до того момента, когда они попытаются получить замок.

Неэффективный обходной путь — всегда yield from asyncio.sleep(0) непосредственно перед получением блокировки.

Это неэффективно, потому что в общем случае будут другие ожидающие, и получение блокировки также вернет управление планировщику. Поэтому в большинстве случаев вы будете возвращать управление планировщику дважды, что отстой.

Также обратите внимание, что в документации для блокировки неоднозначно сказано: «Этот метод блокируется до тех пор, пока блокировка не будет разблокирована, затем устанавливает ее в заблокированную и возвращает значение True». Конечно, создается впечатление, что он передаст управление планировщику до получения блокировки.

На мой взгляд, правильно, чтобы реализация блокировки всегда уступала и не была слишком умной. В качестве альтернативы реализация блокировки должна иметь метод, который говорит вам, будет ли она уступать в случае получения, чтобы ваш код мог вручную уступить, если получение блокировки не даст. Другая альтернатива состоит в том, чтобы вызов acquire() возвращал значение, которое говорит вам, действительно ли он дал результат. Это менее предпочтительно, но все же лучше, чем статус-кво.

Кто-то может подумать, что лучшим обходным решением может быть ручной выход во время release(). Однако если вы посмотрите на узкую петлю, которая освобождает и повторно получает после части работы, то это равносильно тому же самому - в общем случае он все равно будет уступать дважды, один раз во время выпуска, снова во время получения, добавляя неэффективности.

Непонятно, чего вы пытаетесь достичь, но похоже, что Lock — это не тот инструмент, который вам нужен. Чтобы чередовать код Python, вы можете сделать так же просто, как:

def foo(tag, n):
    for i in range(n):
        print("inside", tag, i)
        yield (tag, i)


print('start')

for x in zip(foo('A', 10), foo('B', 10)):
    print(x)

print('done')

Нет необходимости в asyncio или threading. В любом случае, asyncio без IO не имеет большого смысла.

threading.Lock используется для синхронизации важных частей программы, которые в противном случае выполняются в независимых потоках. asyncio.Lock позволит другим сопрограммам продолжить ввод-вывод, пока одна сопрограмма ожидает:

import asyncio
import random

lock = asyncio.Lock()


async def foo(tag):
    print(tag, "Start")
    for i in range(10):
        print(tag, '>', i)
        await asyncio.sleep(random.uniform(0.1, 1))
        print(tag, '<', i)

    async with lock:
        # only one coroutine can execute the critical section at once.
        # other coroutines can still use IO.
        print(tag, "CRITICAL START")
        await asyncio.sleep(1)
        print(tag, "STILL IN CRITICAL")
        await asyncio.sleep(1)
        print(tag, "CRITICAL END")

    for i in range(10, 20):
        print(tag, '>', i)
        await asyncio.sleep(random.uniform(0.1, 1))
        print(tag, '<', i)

    print(tag, "Done")


print('start')

loop = asyncio.get_event_loop()
tasks = asyncio.gather(foo('A'), foo('B'), foo('C'))
loop.run_until_complete(tasks)
loop.close()

print('done')

Имейте в виду, что ключевое слово yield не всегда соответствует английскому значению yield :-) .

Вы можете видеть, что имеет больше смысла, если async with lock получит блокировку немедленно, не дожидаясь, пока другие сопрограммы выполнят дополнительную работу: первая сопрограмма, достигшая критической части, должна начать ее выполнение. (т. е. добавление await asyncio.sleep(0) перед async with lock: просто не имеет никакого смысла.)