Кратко — какие проблемы и какие варианты решений.
Проблемы при одновременном вызове `v.push_back(...)` без синхронизации:
- Data race и UB: `std::vector` не потокобезопасен для конкурентных модификаций — одновременные изменения внутреннего состояния (size/capacity/pointers) приводят к неопределённому поведению (коррупция памяти, крахи).
- Реаллокация/инвалидация: при переполнении `capacity` один поток может перебросить буфер (realloc), другой будет писать/читать по освобождённой памяти.
- Исключения при аллокации: если `push_back` бросает, состояние может стать неконсистентным.
- Инварианты контейнера (size, элементы, указатели) нарушаются при параллельных операциях.
Варианты решений (с краткими комментариями и примерами идей):
1) Мьютекс — самый простой и надёжный
- Использовать `std::mutex m;` и брать `std::lock_guard g(m);` вокруг `push_back`.
- Плюсы: просто, корректно.
- Минусы: полная сериализация `push_back` — возможно узкое место по производительности.
Пример:
```
std::mutex m;
std::thread t1([&]{ for(...) { std::lock_guard g(m); v.push_back(val); } });
```
2) Предвыделение + атомарный индекс (часто самый быстрый для простых типов)
- Выделить место заранее: `v.resize(N);` (важно: именно `resize`, чтобы элементы существовали).
- Использовать `std::atomic idx{0};` и для каждой вставки брать позицию `pos = idx.fetch_add(1, std::memory_order_relaxed);` и писать `v[pos] = value;`.
- Плюсы: нет глобальной блокировки, избегается реаллокация.
- Минусы: нужно знать/оценить итоговый `N` заранее; нельзя использовать `push_back` — вы пишете по индексам; требуется гарантия, что разные потоки не пишут в один и тот же индекс.
Идея-код (псевдо):
```
v.resize(N); // N — итоговый размер
std::atomic idx{0};
thread: pos = idx.fetch_add(1); v[pos] = x;
```
(в тексте числовые литералы: $N$, $1$)
3) Частичная агрегация (per-thread buffers)
- Каждый поток собирает данные в локальный `std::vector local;`, затем один поток (или под контролем мьютекса) объединяет все локальные буферы в общий `v`.
- Плюсы: минимальная синхронизация, лучшая локальность кеша.
- Минусы: потребление дополнительной памяти, финальная сшивка может стоить.
4) Специализированные потокобезопасные контейнеры / библиотеки
- Использовать готовые решения: `tbb::concurrent_vector`, `concurrent_queue` (TBB), `boost::lockfree::queue`, `folly::Function`/контейнеры, `moodycamel::ConcurrentQueue`.
- Плюсы: оптимизированы, корректны для конкурентного доступа.
- Минусы: внешняя зависимость, возможный наклад по API/семантике.
5) Lock-free/модификации с placement-new (сложнее, редко стоит делать самому)
- Теоретически можно держать предвыделённый буфер и атомарно увеличивать "size", делая конструкцию элемента через placement-new. Но это тонко: надо корректно управлять временем жизни объектов, синхронизацией видимости и исключениями.
- Рекомендую использовать проверенные библиотеки вместо самодельных lock-free реализаций.
Рекомендации:
- Если требуются простота и корректность — используйте мьютекс.
- Если высокая пропускная способность и известный итоговый объём $N$ — предвыделение + `std::atomic` индекс или per-thread буферы.
- Если нужно масштабируемое и проверенное решение — используйте `tbb::concurrent_vector` или специализированную lock-free библиотеку.
Если нужно, могу показать конкретный пример кода для варианта с атомарным индексом или с per-thread сборщиками.