Многопоточность и синхронизация

Взаимоблокировка — это когда потоки навсегда ждут блокировки, уже удерживаемые другими, и ни один не может продолжить. Поток A берёт lock 1, затем хочет lock 2; поток B берёт lock 2, затем хочет lock 1. Каждый держит нужное другому, и оба стоят вечно.

Блокируйтесь на private readonly object, видимом только вашему классу. lock(this) делает блокировку публичной: чужой код с вашим экземпляром тоже может её взять и заблокировать вас. lock("key") хуже: литералы интернируются, и блокировка становится общей на процесс.

Состояние гонки — это когда результат зависит от несинхронизированного чередования потоков. count++ — не одна операция: он читает, прибавляет единицу и записывает обратно. Два потока могут прочитать одно значение, оба прибавить единицу и оба записать — один инкремент теряется.

Без блокировки два потока могут вклиниться друг в друга посреди read-modify-write и оставить состояние несогласованным. lock даёт взаимное исключение — объект блокировки одновременно держит только один поток — и публикует записи следующему владельцу.

Пул потоков — это управляемый рантаймом набор переиспользуемых рабочих потоков. Task.Run ставит работу в него, поэтому вы не платите за создание потока, а пул ограничивает параллелизм. Каждый new Thread стоит около 1 МБ стека плюс работа ОС.

ConcurrentDictionary разносит блокировки по сегментам: писатели в разные ключи почти не конкурируют, а чтения не берут блокировку, а Dictionary под lock сериализует всё. Но фабрика GetOrAdd идёт вне блокировки и может отработать дважды для ключа.

lock — сахар над Monitor.Enter/Monitor.Exit в try/finally; оба внутрипроцессные, управляемые и реентерабельные для одного потока. Monitor добавляет TryEnter с таймаутом и Wait/Pulse. Mutex — более медленный объект ядра, именуемый между процессами.

Parallel.ForEach разбивает CPU-bound работу по потокам пула и блокирует вызывающий поток — верно для расчётов, неверно для I/O, где он занимает поток пула на операцию, а await не держит ни одного. Тело цикла обязано быть потокобезопасным.

Все четыре должны выполняться одновременно: взаимное исключение, удержание с ожиданием, отсутствие вытеснения и круговое ожидание. Нарушьте любое одно — и взаимоблокировка невозможна. Единый порядок захвата убирает круговое ожидание, а Monitor.TryEnter с таймаутом — удержание.

Оба делают инкремент атомарным. Interlocked.Increment — одна lock-free инструкция с полным барьером памяти: без блокировки и переключения контекста, поэтому при конкуренции дешевле. Но она покрывает лишь одну переменную, а lock — несколько полей.

SemaphoreSlim пропускает до N владельцев, ограничивая параллелизм, а не сводя его к одному. Его WaitAsync освобождает поток вместо блокировки, поэтому семафор можно удерживать через await, чего lock не позволяет. Он не реентерабельный.

BlockingCollection<T> оборачивает конкурентную коллекцию и блокирует поток в Take() на пустой очереди или в Add() на полной. Channel<T> — асинхронный аналог: ReadAsync/WriteAsync освобождают поток, а ограниченный канал заставляет писателя ждать.

SynchronizationContext захватывается на await, и продолжение отправляется обратно в него — в цикл сообщений UI или контекст запроса ASP.NET. ConfigureAwait(false) отменяет захват, и продолжение идёт на любом потоке пула: без перехода контекста и взаимоблокировки.

.Result блокирует поток UI, а await в FetchAsync захватил SynchronizationContext диспетчера и отправляет продолжение в этот же заблокированный цикл. Лечится сквозной асинхронностью: ожидайте задачу через await в async-методе.

Голодание — работа приходит быстрее, чем у пула есть потоки. Блокирующие вызовы (.Result, SemaphoreSlim.Wait(), синхронный I/O, блокирующее тело Parallel.ForEach) занимают потоки пула. Сверх минимума пул добавляет их медленно, и задержки растут.

Оба дают каждому потоку свою копию значения. У [ThreadStatic] нет инициализатора для потока, значение стартует с default; ThreadLocal<T> берёт фабрику и инициализируется лениво. Потоки пула переиспользуются, и старое значение утекает в следующую задачу.

В new Thread или колбэке пула необработанное исключение фатально — CLR обрушивает процесс. Внутри Task оно перехватывается: .Wait()/.Result бросают его в AggregateException, await разворачивает, а ненаблюдённая задача его теряет.

volatile даёт упорядочивание, а не атомарность: чтение имеет семантику acquire, запись — release, поэтому обращения не переносятся через них, а записанное значение становится видимым другим потокам. Атомарным count++ он не делает — нужен Interlocked или lock.