Почему традиционный механизм 'lock' не подходит для использования в асинхронном программировании?

Почему обычные локи не работают с асинхронными операциями

Суть проблемы

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

Основные проблемы с локами в асинхронном коде

Риск дедлока

• Когда заблокированный ресурс позже используется в том же логическом потоке выполнения, но на другом треде, могут возникнуть дедлоки
• Это особенно проблематично в асинхронных контекстах, где исполнение может перескакивать между тредами

Нагрузка на планировщик потоков

• Блокирование тредов снижает эффективность планировщика
• Вместо того чтобы освободиться для обработки других операций, тред остаётся заблокированным
• Это подрывает основное преимущество асинхронного программирования: неблокирующее исполнение

Потеря преимуществ async

• Асинхронный код разработан для того, чтобы awaitить операции без удержания треда
• Традиционные локи это предотвращают, держа треды занятыми
• Результат — впустую потраченные вычислительные ресурсы и сниженная отзывчивость приложения

Решение

Вместо традиционных локов асинхронный код должен использовать async-совместимые примитивы синхронизации, такие как:

• SemaphoreSlim
• ReaderWriterLockSlim (с осторожностью)
• Другие механизмы координации, совместимые с async
• Lock-free структуры данных там, где это применимо

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