Когда несколько потоков разделяют данные, их операции могут чередоваться (interleave) посреди многошагового обновления, порождая race condition — баг, где результат зависит от непредсказуемого тайминга. Синхронизация — это набор инструментов, навязывающих безопасный порядок.
выглядит атомарным, но на самом деле это чтение-изменение-запись (read-modify-write):
count++// two threads, shared int count = 0, each does count++ once
// thread A: read count (0) ─┐ interleaving loses an update:
// thread B: read count (0) ─┤ both read 0, both write 1 → count == 1, not 2
// thread A: write 1 │
// thread B: write 1 ┘
Окно между чтением и записью — это critical section (критическая секция): код, который касается разделяемого состояния и не должен выполняться параллельно.
pthread_mutex_lock(&m);
count++; // critical section — exclusive
pthread_mutex_unlock(&m);
Блокировки решают гонки, но вносят новые риски: deadlock (потоки ждут блокировок друг друга), priority inversion (инверсия приоритетов) и contention (конкуренция — потоки сериализуются, убивая параллелизм). Практическое правило: держите критические секции короткими и всегда захватывайте несколько блокировок в согласованном глобальном порядке.
Баги конкурентности — одни из самых сложных для поиска: они недетерминированы и часто исчезают под отладчиком. Интервьюеры хотят увидеть, что вы можете распознать критическую секцию, выбрать правильный примитив (mutex vs semaphore vs atomic) и рассуждать о режимах отказа (deadlock, contention). Это напрямую применимо к любому многопоточному серверу, разделяемому кэшу или счётчику.
Библиотека вопросов для IT-собеседований с подробными ответами — от Junior до Senior.
Поддержать