История изменений

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 ожидает?

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

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 ожидает?

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