std::atomic. Модель памяти C++ в примерах

На самом деле, интереснее каноничный пример с синглтоном:

static Singleton* singleton = nullptr;
static std::mutex mtx;
 
Singleton *instance() {
	if (singleton ) // early return to avoid touching mutex every call
		return singleton;
 
	std::unique_lock l(mtx); // `mutex` locks here (acquire memory)
	if (!singleton)
		singleton = new Singleton();
        return singleton;
	// `mutex` unlocks here (release memory)
}

Казалось бы, тут всё хорошо? Но нет, Александреску в своей статье пишет что всё плохо.

singleton = new Singleton();

может развернуться в что-то типа такого

// выделили память и записали указатель,
singleton = (Singleton*)malloc(sizeof(Singleton)); 
// если второй тред прочитает указатель в этом месте, то всё упадет
// а вот теперь создали объект (тут еще куча операций)
new (singleton) Singleton();

Мы же хотим что-то типа такого

auto tmp = (Singleton*)malloc(sizeof(Singleton)); // выделили память
new (tmp) Singleton(); // создали объект
singleton = tmp; // записали указатель

Но, понятное дело, гарантий что будет выбран вариант 2 нам никто не дает (скорее всего, не будет, потому что это медленнее). Если же руками написать этот код, то компилятор также может соптимизировать в вариант 1.
К счастью, начиная с С++11 не должна больше болеть голова о синглтонах=)

Самый простой для понимания флаг синхронизации памяти — relaxed.

Флаг синхронизации памяти «единая последовательность» (sequential consistency, seq_cst) самый строгий и понятный

Хорошо, когда самых понятных флагов два. Лучше бы, конечно, три.

Можно ли использовать std::atomic с разделяемой памятью? Насколько это безопасно?

Статья весьма хорошая и интересная, но пара неточностей несколько снижает, на мой взгляд, её полезность.
1. Выполнение нескольких потоков на одном процессоре в режиме разделения времени не дает гарантии того, что выполнение оператором C++ операции вида read-modify-write будет защищено от вмешательства со стороны другого потока. Потому что эта операция транслируется в несколько машинных команд. Выполнение потока может быть прервано после одной из команд середине операции, и управление после этого может быть передано другому потоку, который внесет конфликтующие изменения.
В однопроцессорной системе есть только гарантия того, что данные не будут изменены другим потоком во время выполнения одной машинной команды, а в многопроцессорной — нет и этой гарантии. Однако с точки зрения программы на языке высокого уровня это мало что меняет.
2. Мьютекс не реализуется через атомарные операции. Для его работы требуется обращение к ядру ОС. Потому что при возникновении состояния ожидания потока необходимо обратиться к планировщику в ядре ОС, чтобы он запустил на выполнение другой поток (варианты планировщиков пользовательского режима, в которых единицей исполнения является не поток режима ядра, а другие конструкции, аналогичные promise или Task в других языках, я не тут не рассмартриваю). Ядро ОС же может использовать для синхронизации доступа к общим для нескольких процессоров структурам данных другие механизмы (например, спин-блокировки или межпроцессорные прерывания).
Да, существуют «легкие» варианты реализации мьютекса (в Windows — критическая секция), в которых обращение к ядру откладывается, насколько это возможно, чтобы не вызывать ядро, когда блокировка с передачей управления другому потоку не происходит либо состояние блокировки очень быстро проходит. И для реализации такого поведения действительно используются атомарные операции. Но для осуществления передачи процессора для выполнения другого потока обращение к ядру неизбежно.
Полную семантику мьютексов — с перепланированием потоков — на атомарных операциях реализовать невозможно, максимум что возможно — это реализовать семантику спин-блокировки, которая захватывает процессор вместо того, чтобы передать его другому потоку для выполнения.

Впрочем, в большинстве практических применений эти неточности существенной роли не играют.
И ещё. Я считаю, что, говоря о разнице между compare_exchange_strong и compare_exchange_weak, следовало бы уделить ей больше внимания хотя бы в практическом аспекте: что для надежного использования compare_exchange_weak необходимо организовывать циклическую поверку при неудачном сравнении, а вариант compare_exchange_strong этого не требует, но зато он обходится дороже (потому как требует немедленной синхронизации кэшей процессоров, что в некоторых архитектурах является весьма дорогой операцией) — в статье по приведенной ссылке все это, естественно, есть, но далеко не в первых ее словах.

Поясните, пожалуйста. Когда в примере с мьютексом вы пишете: "Он так же делает доступным те изменения памяти, которые были сделаны до вызова unlock() в коде, который будет работать после вызова lock()" — дело касается всех модифицированных переменных, не только атомиков?

Или другим потокам будут гарантированно видны только все изменённые атомики? Или всё-таки для получения актуального значения атомика надо вызвать load или acquire-операцию? В чём заключается роль мьютекса по синхронизации изменений памяти?

К моему стыду я не понимаю как «ожидание» реализовано на процессоре (пусть 86, например), поэтому задам вопрос здесь, вроде тематика подходит. Для простоты — пусть у нас есть всего один поток, есть какой-то код, который захватил мьютекс, и есть второй, который его ждет. Что именно (на уровне байткода, наверное?) происходит в момент «ожидания»? Можно просто ссылку что «покурить», буду благодарен.

Ну и второй вопрос, который как по мне схож. Вот у меня есть ядро процессора, оно выполняет 100 операций в секунду. Но в данный момент у меня есть ему предложить только 50. Понятное дело что там есть какое-то квантование по времени. Но что делает ядро в те кванты, когда делать нечего? Молотит nop'ы? Думаю что сейчас врятли, энергоэффективность же. Считаем что частоту снижать уже некуда (я сейчас про всякие «base clock 1.2, boost clock 100500 GHz». Или оно все равно снижает ниже, просто юзер не в курсе?

Программист: *хочет синхронизировать данные между двумя потоками*.
Язык программирования: вот вам конструкция для синхронизации.
Программист: спасибо.
Язык программирования: только помните, что есть нюансы для разных архитектур
Язык программирования: и 5 флагов, меняющих алгоритм работы, не синхронизируя то одно, то другое.
Программист:
Язык программирования: а если сделать вот так (*с виду логичная и непротиворечивая конструкция*), то всё упадет в самый неожиданный момент!
Программист:
Язык программирования: в следующей версии стандарта будет ещё удобнее, добавим ещё десяток флагов и способов синхронизации (с нюансами, как вы любите), не благодарите!

Здравствуйте, у меня вопрос по примеру с мьютексом и синглтоном.

singleton->do_job() приводит к segmentation fault (указатель singleton не обязан был быть синхронизирован с потоком thread1)

Правильно ли я понимаю, что для того, чтобы указатель был синхронизирован с потоком thread1 необходимо вызвать

std::unique_lock l(mtx); // `mutex` locks here (acquire memory)

?
Как я понял именно в этот момент произойдет синхронизация памяти между потоками и указатель в thread2 станет валидным.