— Мне не надо явно использовать какие-либо примитивы синхронизации для одновременного read-write доступа из нескольких потоков для любых объектов класса std::atomic<T>
— Операции, выполняемые над объектами класса std::atomic<T>, могут быть как lock-free, так и non-lock-free, в зависимости от конкретной реализации
— std::atomic_bool и std::atomic<bool> (а также другие подобные им типы из C++11), на самом деле, одно и то же
— std::atomic_flag -- единственный класс, для объектов которого стандартом гарантируется, что все операции будут lock-free
И ещё -- кто-нибудь может посоветовать годный мануал на тему std::memory_order и его правильного использования?
Здравствуйте, FrozenHeart, Вы писали:
FH>- Мне не надо явно использовать какие-либо примитивы синхронизации для одновременного read-write доступа из нескольких потоков для любых объектов класса std::atomic<T>
Дополнительные — нет, если правильно задан memory order операции и ничего дополнительно не нужно.
FH>- Операции, выполняемые над объектами класса std::atomic<T>, могут быть как lock-free, так и non-lock-free, в зависимости от конкретной реализации
Ну в общем да. Хотя сейчас сложно встретить платформу, где для этого потребуется лок. Вот LL/SC цикл — да, возможно (и может быть примерно так же дорого, как явный лок).
FH>И ещё -- кто-нибудь может посоветовать годный мануал на тему std::memory_order и его правильного использования?
Здравствуйте, FrozenHeart, Вы писали:
FH>Здравствуйте, коллеги.
FH>Правильно ли я понял:
FH>- Мне не надо явно использовать какие-либо примитивы синхронизации для одновременного read-write доступа из нескольких потоков для любых объектов класса std::atomic<T>
Если значения переменных должны быть согласованы, то нужно. В противном случае, поток может увидеть несогласованное состояние, даже если вы используете std::atomic.
FH>- Операции, выполняемые над объектами класса std::atomic<T>, могут быть как lock-free, так и non-lock-free, в зависимости от конкретной реализации
Операции не могут быть lock-free, lock-free это свойство алгоритма, которое гарантирует что хотя бы один поток будет совершать прогресс.
FH>- std::atomic_flag -- единственный класс, для объектов которого стандартом гарантируется, что все операции будут lock-free
Здравствуйте, FrozenHeart, Вы писали:
FH>Правильно ли я понял:
FH>- Мне не надо явно использовать какие-либо примитивы синхронизации для одновременного read-write доступа из нескольких потоков для любых объектов класса std::atomic<T>
Да, только нужно указывать корректный memory_order для операций с ним.
Согласованность доступа гарантируется при использовании std::memory_order_seq_cst (используется по умолчанию).
Корректное использование сочетания .store(..., std::memory_order_acquire) с .load(..., std::memory_order_release) также гарантирует
отсутствие гонок при меньших накладных расходах, чем std::memory_order_seq_cst.
Использование std::memory_order_relaxed не рекомендуется, т.к. почти ничего не гарантирует.
FH>- Операции, выполняемые над объектами класса std::atomic<T>, могут быть как lock-free, так и non-lock-free, в зависимости от конкретной реализации
Да.
FH>- std::atomic_bool и std::atomic<bool> (а также другие подобные им типы из C++11), на самом деле, одно и то же
Да.
FH>- std::atomic_flag -- единственный класс, для объектов которого стандартом гарантируется, что все операции будут lock-free
Да
FH>И ещё -- кто-нибудь может посоветовать годный мануал на тему std::memory_order и его правильного использования?
Очень рекомендую Anthony Williams "C++ Concurrency in Action. Practical Multithreading", там рассмотрены множество вопросов
(включая разработку lock-free и lock-based структур данных) помимо использования std::atomic.
