Многопоточность в C#

Многопоточность в C# — это не набор классов из System.Threading, а модель того, что процессор и JIT имеют право сделать с вашим кодом. Два потока, читающие и пишущие одно поле, — это не «две последовательности инструкций по очереди»: компилятор переставляет обращения, ядра держат значения в своих кэшах и регистрах, а планировщик ОС вытесняет поток в произвольной точке, в том числе посередине count++. Всё, что делают примитивы синхронизации, — ограничивают этот произвол ровно там, где он вам мешает.

Отсюда и структура темы. Сначала — проблема: состояние гонки как результат несинхронизированного чередования. Затем — инструменты, каждый со своей ценой: lock даёт взаимное исключение и барьеры, но реентерабелен и не переживает await; SemaphoreSlim пропускает N владельцев и умеет ждать асинхронно, но не реентерабелен и способен заблокировать поток против самого себя; volatile даёт упорядочивание, но не атомарность; Interlocked даёт атомарность без блокировки, но только для одной переменной. Дальше — цена ошибок: взаимоблокировка, которую CLR не обнаружит и не разорвёт, и голодание пула потоков, в которое сваливается любой сервис, где блокируются на .Result внутри асинхронной цепочки. Разбор по слоям — ниже.

Карта темы

• Состояние гонки — почему count++ не атомарен и как несинхронизированное чередование потоков теряет обновления.
• Примитивы блокировки — во что разворачивается lock, чем от него отличаются Monitor и Mutex и на каком объекте блокироваться.
• Взаимоблокировки — четыре условия Коффмана, классический цикл из двух блокировок и зависание на .Result.
• Семафоры — SemaphoreSlim как ограничитель параллелизма и единственный способ «блокировки» через await.
• Видимость памяти — переупорядочивание и кэши, семантика acquire/release у volatile и почему он не заменяет lock.
• Interlocked и атомарные операции — lock-free инкремент на CAS-инструкции процессора и граница его применимости.
• Пул потоков — переиспользуемые рабочие потоки, медленная инжекция сверх минимума и голодание пула.
• Потоко-локальное состояние — [ThreadStatic], ThreadLocal<T> и почему на потоках пула значение утекает в чужую задачу.
• Конкурентные коллекции — сегментные блокировки ConcurrentDictionary, ловушка GetOrAdd, Channel<T> против BlockingCollection<T>.
• Параллельные циклы — Parallel.For/ForEach для CPU-bound работы и почему для I/O это неверный инструмент.

Частые ошибки и ловушки

Значение для собеседований

Многопоточность — традиционный водораздел между middle и senior на C#-собеседовании. Спрашивают не API, а модель: что именно делает lock помимо взаимного исключения, почему volatile не спасает счётчик, откуда берётся взаимоблокировка на .Result. Кандидат, который на вопрос про count++ сразу произносит «это read-modify-write, три шага», отвечает на порядок убедительнее того, кто говорит «нужен lock, потому что так принято».

Что обычно проверяют:

• Что такое состояние гонки и почему count++ теряет инкременты.
• Во что компилятор разворачивает lock, реентерабелен ли он и на каком объекте блокироваться.
• Чем Interlocked дешевле lock и где заканчивается его применимость.
• Что volatile гарантирует (упорядочивание) и что нет (атомарность).
• Четыре условия взаимоблокировки и какое из них ломает единый порядок захвата.
• Почему SemaphoreSlim — единственный способ «удержать блокировку» через await.
• Что такое голодание пула потоков и как в него попадает блокирующий вызов внутри async-метода.
• Почему у ConcurrentDictionary.GetOrAdd фабрика может отработать дважды.

Типичный неверный ответ: «Пометил поле volatile — и счётчик потокобезопасен». Это открывает главный разговор темы: volatile управляет видимостью и порядком, а не атомарностью; инкремент остаётся read-modify-write, и защитить его может только Interlocked.Increment или lock.