Кратко: race condition — это неконтролируемое взаимное влияние потоков при доступе/модификации общих данных, приводящее к некорректным результатам или UB. Приведу примеры, объясню причину, последствия и варианты синхронизации с учётом производительности.
1) Пример (C++, некорректно)
```
#include #include #include
int counter = 0; // общая переменная
void worker(int iters) {
for (int i = 0; i < iters; ++i) {
++counter; // небезопасно
}
}
int main() {
int N = 4, K = 1000000;
std::vector t;
for (int i=0;i<N;++i) t.emplace_back(worker, K);
for (auto &th : t) th.join();
std::cout << counter << '\n'; // ожидаем N*K, но часто меньше
}
```
Причина: операция `++counter` разбивается на чтение, изменение, запись; эти шаги могут перемешиваться между потоками — race condition. Если $N$ потоков делают по $K$ инкрементов, ожидаемое значение $M=N\cdot K$, но результат может быть < $M$.
Последствия: неверные результаты счётчиков, нарушение инвариантов, потеря данных, в худших случаях — UB и крах программы.
2) Исправления и их свойства
a) std::mutex (корректно, универсально)
```
std::mutex m;
void worker(int iters) {
for (int i=0;i<iters;++i){
std::lock_guard g(m);
++counter;
}
}
```
Плюсы: простая семантика, подходит для сложных критических секций. Минусы: блокировка потока при ожидании — стоимость контекстного переключения при высокой конкуренции.
b) std::atomic (эффективно для простых операций)
```
std::atomic counter{0};
void worker(int iters) {
for (int i=0;i<iters;++i){
counter.fetch_add(1, std::memory_order_relaxed);
}
}
```
Плюсы: атомарные операции обычно быстрее мьютекса, нет блокировки. Для простых инкрементов — предпочтительно. Параметр памяти (`relaxed`, `acquire/release`, `seq_cst`) управляет ordering. Минусы: при высокой конкуренции всё равно будет «качание» кэш-линий (cache-line bouncing), что снижает масштабируемость.
c) Шардирование / агрегирование (уменьшает конкуренцию)
```
std::vector<std::atomic> shards(N);
void worker(int id, int iters) {
for (int i=0;i<iters;++i) shards[id].fetch_add(1, std::memory_order_relaxed);
}
...
// итог:
int total = 0;
for (auto &s : shards) total += s.load();
```
Плюсы: уменьшает contention; хорошая производительность при большом N. Минусы: чуть сложнее логика, размер памяти ~ $O(N)$.
d) Lock-free CAS (при необходимости)
```
std::atomic x{0};
void add1() {
int old = x.load();
while (!x.compare_exchange_weak(old, old+1)) {
// old обновляется при неудаче
}
}
```
Плюсы: позволяет реализовать без блокировки. Минусы: сложность, возможный live-lock при сильной конкуренции; часто хуже читается.
3) Java: пример и оптимальные варианты
Небезопасно:
```
public class R {
int counter = 0;
void inc() { counter++; } // неатомарно
}
```
Атомарно (быстро для простых случаев):
```
import java.util.concurrent.atomic.AtomicInteger;
AtomicInteger counter = new AtomicInteger(0);
counter.getAndIncrement();
```
Для высокого контента (рекомендуется для интенсивных инкрементов):
- java.util.concurrent.atomic.LongAdder — использует полосу (cells) и уменьшает contention; суммирование быстрее масштабируется на многих потоках.
Для сложных критических секций:
- synchronized или ReentrantLock.
4) Практические рекомендации с учётом производительности
- Если операция простая (инкремент/декремент) — используйте atomics (`std::atomic`, `AtomicInteger`, `LongAdder` в Java). Для очень высокой частоты инкрементов — `LongAdder` или шардирование.
- Если критическая секция сложная (несколько полей, сложные инварианты) — используйте мьютекс/lock; минимизируйте время удержания блокировки.
- Избегайте false sharing: выпрямляйте (pad) данные, чтобы часто меняемые переменные не были на одной кэш-линии.
- Профилируйте: замеряйте масштабируемость при реальной нагрузке; атомики могут быть быстрее при низкой конкуренции, но хуже масштабироваться при высокой.
- По возможности используйте неблокирующие структуры данных из стандартных библиотек (ConcurrentHashMap, lock-free очереди).
- Понимайте memory ordering: чаще всего `std::memory_order_seq_cst` (или Java `volatile`/Atomic по умолчанию) достаточно, но для максимальной скорости используйте `relaxed` там, где порядок не важен.
Кратко вывод: выбирайте простые atomics для простых операций, мьютексы для комплексных инвариантов, шардирование/LongAdder для уменьшения contention; всегда профилируйте и следите за false sharing.