Здравствуйте, ·, Вы писали:

_>>shared pointer нужен в случае параллельного доступа к данным из разных потоков с неизвестным заранее временем жизни. Это совсем не частный случай даже в системах с подобным параллельным доступом. А если использовать более продуманные архитектуры (типа той же модели акторов), то подобные вопросы не встают в принципе. Тем более, что при использование семантики перемещения модель акторов становится такой же эффективной, как и просто общая память (в варианте без блокировок).
·>Это не частный случай, а наиболее простая имплементация. Конечно, можно внимательно изучить, установить время жизни каждого объектика, но это сложно контролировать и тестировать, а в случае ошибки — undefined behaviour. В случае же java — самое страшное что будет — это latency spike из-за garbage collection, а не порча данных, как в случае ошибок с указателями.

Ничего подобного. Ты путаешь время жизни объектов и время жизни потоков. Вот смотри, допустим у нас есть главный поток (не обязательно по приложению, а скажем по задачке некой), который порождает N других потоков, с которыми взаимодействует через общую память (не факт что лучшее решение, но раз ты его хочешь, то давай обсудим). Для этого достаточно выделить память в главном потоке и хранить её как unique_ptr (или вообще просто объявить локальную переменную, что заметно удобнее). А дочерним потокам передать голый указатель (или вообще ссылку, что заметно удобнее) на эти данные. Такая система будет 100% безопасна в случае гарантий завершения дочерних потоков раньше главного. Если подобные гарантии не следуют из логики задачи, то их можно легко получить ручным способом, разместив в конце главного потока код ожидания (банальный thread.join() в случае C++) завершения дочерних потоков.

Так что, как видишь, у нас нет никаких намёков на необходимость использования shared_ptr для реализации взаимодействия потоков через общую память.

·>Модель акторов — в первую очередь для упрощения параллелизма, а не low latency.

Всё правильно, упрощение. Которое при этом обеспечивает ещё и гарантию безопасности (которую в случае модели общей памяти надо достигать локами, в любом языке программирования) взаимодействия потоков. Ну а при правильной реализации можно получить ещё и быстродействие не хуже модели общей памяти.