История изменений
Исправление xaizek, (текущая версия) :
relaxed, seq_cst, acquire/release - это всё не о самом атомике, а об окружающих его side эффектах. С этим вопросов нет.
Как минимум с relaxed это не так. Я уже сказал, какие там гарантии, по сути только атомарность и стабильность появления обновлений.
Вопрос в том, что существует ли у атомиков свой единый для всех потоков порядок изменений?
Само по себе его нет. seq_cst делает total order для всего, вроде как. А release/acquire на одной и той же переменной создают отношение happens-before между парой потоков.
Если нет порядка, то как вы реализуете std::atomic_fetch_and()? Один поток плюсанул к атомику из своего кэша, а другой к атомику из своего кэша, так выходит?
Да нет, там посложнее будет. Проверка наличия правильных данных в кэше текущего процессора, потом какая-нибудь блокировка шины и инвалидация кэшеё всех остальных процессоров. Это больше проблема разработчиков железа и опирается на инструкции процессора, это не программная реализация.
Единый порядок у атомиков должен быть (независимо от memory_order), думаю, вот только не могу найти никаких разъяснений на эту тему.
Я же говорю не стоит гадать по таким вопросам, легко ошибиться. Надо читать книги или развёрнутые статьи. Я читал «C++ Concurrency in Action» Anthony Williams, там объясняется разница между memory_order и как они работают.
Я тут подумал: compare_exchange_weak/strong - это случайно не о том, что weak возвращает false видя рассинхрон кэшей и не ожидая синхронизации, а strong ожидает?
Это о том, что не все операции нативно поддерживаются на всех архитектурах и иногда могут не выдать нужный результат, если там не одна атомарная инструкция, а несколько и у потока забрали управление посередине (как один из возможных примеров).
Исходная версия xaizek, :
relaxed, seq_cst, acquire/release - это всё не о самом атомике, а об окружающих его side эффектах. С этим вопросов нет.
Как минимум с relaxed это не так. Я уже сказал, какие там гарантии, по сути только атомарность и стабильность появления обновлений.
Вопрос в том, что существует ли у атомиков свой единый для всех потоков порядок изменений?
Само по себе его нет. seq_cst делает total order для всего, вроде как. А release/acquire на одной и той же переменной создают отношение happens-before между парой потоков.
Если нет порядка, то как вы реализуете std::atomic_fetch_and()? Один поток плюсанул к атомику из своего кэша, а другой к атомику из своего кэша, так выходит?
Да нет, там посложнее будет. Проверка наличия правильных данных в кэше текущего процессора, потом какая-нибудь блокировка шины и инвалидация кэшеё всех остальных процессоров. Это больше проблема разработчиков железа и опирается на инструкции процессора, это не программная реализация.
Единый порядок у атомиков должен быть (независимо от memory_order), думаю, вот только не могу найти никаких разъяснений на эту тему.
Я же говорю не стоит гадать по таким вопросам, легко ошибиться. Надо читать книги или развёрнутые статьи. Я читал «C++ Concurrency in Action» Anthony Williams, там объясняется разница между memory_order и как они работают.
Я тут подумал: compare_exchange_weak/strong - это случайно не о том, что weak возвращает false видя рассинхрон кэшей и не ожидая синхронизации, а strong ожидает?
Это о том, что не все операции нативно поддерживаются на всех архитектурах и иногда могут не выдать нужный результат, если там не одна атомарная инструкция, а несколько и у потока забрали управление посередине.