Комментарии 4
Спасибо за статью, читается круто.
Пример с asyncio.Lock по идее ставит все обращения в очередь, тогда получается что мы не только обновляем данные в кеше последовательно, но и читаем, теряется фактически смысл кеша, так как кэш будет блокирующей частью
Но в свою очередь, мы исключаем возможность обращения к ресурсу (БД, стороннему API) "одновременно" (асинхронно) несколькими пользователями, когда кэш пустой. Первый обратившийся - пойдёт за ресурсом, остальные - дождутся получения ресурса первым и потом получат его быстро из кэша.
Когда данные в кэше уже будут, получение из него и с блокировкой, и без блокировки будет последовательным (под капотом), т.к. асинхронщина. Ток накинутся расходы за игры с lock-ом.
Поправьте если ошибся :)
асинхронность не работает параллельно! она работает конкурентно! одновременного обращения никогда не будет. для параллельного выполнения есть процессы. их и применяют для параллельного обращения.
LocK() - используется когда мы хотим чтоб некоторая часть нашего кода использовалась только одной корутиной в конкретный момент времени. А остальные корутины выполняющие этот же блок кода ждали своей очереди.
для того чтоб писать на аснхронности в python, надо иметь хорошее понимание процессов и потоков. асинхронность это не процессы и не потоки! это вообще другое и о другом. в данных примерах много заблуждений по работе с asynkio... я пока не нашел нормальных гайдов по asyncio и вообще асинхронности.. или sleep втыкают что костыль, или блокируют конкурентность что тоже костыль.. оно должно продолжить выполнение в конкурентном потоке а не блокироваться! а вот уже результат должен быть когда выполняется первая таска которая вам нужна! и это не так реализуется на деле...
прочитал и кайфанул! спасибо
Примитивы синхронизации в Python Asyncio: Исчерпывающее руководство