Кратко сравню три семантики параллелизма — потоки с примитивами синхронизации (мьютексы/сигналы/условия), акторную модель и транзакционную память (STM/HTM) — где их лучше применять и какие у них ограничения.
1) Потоки + синхронизированные примитивы (mutex, condition, semaphore, lock-free)
- Где удобны:
- Низкоуровневый, гибкий контроль за исполнением и ресурсами; хороши для высокопроизводительных вычислений и реалтайм- или системного кода.
- Можно тонко оптимизировать (разделение работы, минимизация переключений контекста, использование lock-free структур).
- Ограничения:
- Сложность: легко допустить data-race, deadlock, livelock, priority inversion.
- Сложно составлять и повторно использовать абстракции синхронизации (плохая композибельность).
- Отладка и тестирование трудноаппаратны; масштабирование на большое число ядер требует аккуратного управления ложным шарингом и связью кэшей.
- Требует явного управления безопасностью памяти и порядком действий.
2) Акторная модель (message-passing: Erlang, Akka, Orleans и др.)
- Где удобны:
- Естественна для конкурентных IO‑ориентированных и распределённых систем: изоляция состояния, обмен сообщениями, лёгкое масштабирование и распределение.
- Упрощает отказоустойчивость и модель «supervision», легче избегать data-race (нет общего изменяемого состояния между акторами).
- Позволяет моделировать асинхронные протоколы и очереди; часто проще тестировать локальные сценарии.
- Ограничения:
- Переключение в модель сообщений меняет стиль программирования (неудобно для тесно связаного, совместно используемого состояния).
- Нельзя легко выполнять атомические обновления, затрагивающие несколько акторов (требует сложных протоколов или согласования).
- Задержки из‑за сериализации сообщений, копирования/маршаллинга и очередей; сложности с backpressure и упором на согласованность.
- Отладка распределённых взаимодействий и снятие причин рассинхронизации могут быть нетривиальны.
3) Транзакционная память (STM — программная; HTM — аппаратная)
- Где удобна:
- Обеспечивает композицию атомарных операций: легко комбинировать несколько примитивов в одну атомарную транзакцию.
- Упрощает написание корректного кода при сложных взаимодействиях с общим состоянием (например, несколько структур данных нужно обновить согласованно).
- В STM — отсутствие блокировок избавляет от многих проблем deadlock’а; декларативная модель «начать/закончить транзакцию».
- Ограничения:
- Производительность чувствительна к конфликтам: при высокой конкуренции транзакции часто откатываются и перебрасываются, что даёт деградацию.
- Невозможно/неудобно выполнять I/O или другие невозвратные операции внутри транзакции (нужны обходы).
- HTM ограничена объёмом транзакционной рабочей памяти и поддержкой у процессора; STM имеет накладные расходы (логирование, проверки).
- Меньше распространена в экосистемах — ограниченная инструментальная и языковая поддержка; тонкости с приоритетами/звёздами/звездностью повторов.
Короткие рекомендации по выбору
- Нужен максимальный контроль и максимальная производительность на общем доступе к памяти — потоки + хорошо продуманные примитивы/lock-free структуры.
- Система ориентирована на распределённость, отказоустойчивость и асинхронные IO — акторы (сообщения) чаще удобнее.
- Есть сложные транзакционные обновления общих структур, хочется композиции атомарных операций и избежания ручных блокировок — STM (или гибридный подход) подходит, если нагрузка и среда это позволяют.
Гибриды практичны: например, акторы для архитектуры системы, внутри актора — STM/локальные структуры; или использовать HTM для коротких критичных участков и традиционные мьютексы для долгих операций. Выбор зависит от характера нагрузки (IO vs CPU), уровня конкуренции, требований к отказоустойчивости и доступных средств в языке/рантайме.