У меня были проблемы с атомарным контейнером, и я увидел эту ссылку.
Есть ли причина, по которой std::atomic нельзя скопировать? Решение кажется это, где они просто передают значение T неатомарному конструктору с функцией атомарной загрузки (если я не ошибаюсь).
Итак, в целом, является ли этот конструктор копирования потокобезопасным?
template<typename T>
struct MobileAtomic
{
std::atomic<T> atomic;
explicit MobileAtomic(std::atomic<T> const& a) : atomic(a.load()) {}
};
Есть ли причина, по которой std::atomic нельзя построить с помощью копирования?
Да.
Когда вы запрашиваете конструируемую копию atomic, вы просите, чтобы «обычные» правила однопоточной последовательной согласованности применялись к переменной, которая не следует этим правилам.
По сути, универсального решения нет.
Используя конструктор, показанный в вопросе, вы жертвуете детерминированным результатом, поскольку у вас нет гарантии, что исходный и конечный объекты эквивалентны после завершения построения.
std::atomic<void*> foo, где foo может изменить то, на что он указывает, и у меня есть отдельные механизмы для поддержания времени жизни и параллелизма этих данных, на которые указывает foo. Случай будет обрабатываться атомарным shared_ptr, но я хотел бы придерживаться стандартных библиотечных решений (из которых не существует атомарного общего ptr).
- person Noah Watkins; 03.07.2017
atomic& operator=(const atomic&) = delete;, которое в основном запрещено C++. Я предполагаю, что возврат ссылки на переменную сделает то же самое, но я не уверен. - person JohnJohn schedule 06.01.2015