Краткий ответ

Нет. std::shared_ptr обычно обеспечивает безопасное управление общим владением: операции с контрольным блоком и счётчиком владельцев согласованы между потоками. Но это не делает потокобезопасным сам объект, на который указывает указатель: его состояние нужно защищать отдельно.

Исторический контекст

std::shared_ptr появился как стандартный инструмент для управления разделяемым временем жизни объектов без ручного подсчёта ссылок и явного удаления. Разные экземпляры умных указателей могут совместно владеть одним ресурсом, поэтому библиотеке потребовался контрольный блок со счётчиком владельцев.

Потокобезопасность операций владения и потокобезопасность объекта — разные задачи. Первая относится к внутреннему состоянию shared_ptr, вторая — к данным и инвариантам управляемого объекта.

Постановка проблемы

Если два потока одновременно изменяют объект через разные копии std::shared_ptr, сам указатель может корректно сохранять объект живым, но доступ к его полям всё равно может привести к гонке данных. Результат такой гонки не определён стандартом C++.

Даже если один поток копирует или уничтожает свою копию shared_ptr, а другой работает с другой копией, это не означает автоматическую синхронизацию операций над объектом. Дополнительный риск возникает при одновременном изменении одного и того же экземпляра std::shared_ptr без синхронизации.

Подробное решение

У std::shared_ptr есть сам указатель и контрольный блок. В контрольном блоке хранятся, в частности, счётчик сильных владельцев, счётчик слабых ссылок и информация об освобождении ресурса.

Копирование разных экземпляров shared_ptr, связанных с одним контрольным блоком, может выполняться из разных потоков. Уничтожение одной копии уменьшает счётчик владельцев, а уничтожение последней вызывает deleter и завершает время жизни управляемого объекта. Однако эти операции не устанавливают блокировку на поля объекта.

#include <memory>
#include <thread>

int main() {
    auto value = std::make_shared<int>(0);
    auto first = value;
    auto second = value;

    std::thread one([first] { ++*first; });
    std::thread two([second] { ++*second; });
    one.join();
    two.join();
}

В примере владение и время жизни объекта управляются корректно, но инкременты одного int выполняются без синхронизации. Для изменяемого общего состояния применяют std::mutex, другой подходящий примитив синхронизации или атомарный тип, например std::atomic для поддерживаемых им операций.

Важно различать два случая. Разные экземпляры shared_ptr можно использовать параллельно, если они не изменяют один и тот же экземпляр указателя. Одновременная запись в один объект shared_ptr требует внешней синхронизации; специализированные атомарные операции над shared-указателями решают задачу публикации и замены владения, но не защищают поля управляемого объекта.

Ситуация из практики

Сервис передаёт нескольким рабочим потокам shared_ptr на общий объект конфигурации. Сначала разработчики считают, что разделяемое владение уже обеспечивает безопасность, но при обновлении конфигурации получают гонки и повреждённые промежуточные значения.

Вариант с обычным shared_ptr без синхронизации прост, но некорректен для изменяемого объекта. Вариант с глобальной блокировкой устраняет гонку, однако снижает параллелизм и усложняет контроль времени удержания блокировки. Вариант с неизменяемыми снимками позволяет потокам читать данные без блокировки: при обновлении создаётся новый объект, а затем атомарно публикуется новый разделяемый указатель.

Для конфигурации выбирают неизменяемые снимки, если чтений значительно больше записей. Это отделяет управление временем жизни через shared_ptr от синхронизации публикации и не заставляет читателей конкурировать за mutex; для часто изменяемого состояния разумнее защищать данные mutex-ом или использовать специализированную конкурентную структуру.

Что кандидаты часто упускают

Безопасно ли одновременно копировать разные shared_ptr, указывающие на один объект?

Да, операции с разными экземплярами std::shared_ptr, связанными с одним контрольным блоком, рассчитаны на такое использование: счётчик владельцев и время жизни ресурса должны оставаться корректными. Но чтение или изменение самого объекта этими потоками всё равно требует собственной гарантии безопасности.

Защищает ли mutex внутри одного метода объекта все операции со shared_ptr на этот объект?

Нет, если другие методы или внешние участки кода обращаются к тем же данным без того же mutex. Защита должна охватывать согласованный набор операций и все пути доступа к общему состоянию. Сам факт хранения объекта в shared_ptr не сообщает библиотеке, какой mutex связан с его полями.

Можно ли заменить shared_ptr на atomic и считать задачу полностью решённой?

Нет. Атомарные операции над разделяемым указателем синхронизируют публикацию, замену и получение самого владения, но не делают произвольные поля объекта атомарными и не защищают составные инварианты. Например, атомарная замена указателя не превращает последовательность из чтения, вычисления и записи поля в неделимую операцию; для неё нужны mutex, атомарные переменные или неизменяемая модель данных.