Здравствуйте, ·, Вы писали:
_>>·>А как это объяснишь? https://godbolt.org/z/LLNDkD
_>>Это кривая реализация встроенной функции gcc __atomic_store_n для данной маргинальной платформы. Собственно тут (https://github.com/michaeljclark/riscv-atomics) можно увидеть две реализации и та, что на сайте godbolt, использует именно кривой вариант через встроенную функцию gcc, а не через ассемблер. Нормальную реализацию можно увидеть например здесь https://github.com/michaeljclark/riscv-atomics/blob/master/src/stdatomic_asm.h#L95. И подробное обсуждение всей этой кривизны можно увидеть здесь https://github.com/michaeljclark/riscv-atomics/tree/master/results.
·>Ок, ты в очередной раз подменяешь тезис. Но пусть кривая. В любом случае, она ничему не противоречит и имеет право на жизнь. Возможно лишь ухудшает перформанс.
·>И уж тем более это никак не доказывает, что volatile sig_atomic можно использовать в многопоточке. Доказательством будет фраза в стандарте. А стандарт наоборот это явно запрещает.
1. Я не пытаюсь что-то доказать, т.к. факт атомарности записи регистра в память общеизвестен (мне вообще странно, что ты начал об этом спорить).
2. Что-то доказать пытаешься тут ты, причём весьма странным способом — пытаясь найти реализацию std::atomic, в которой операция записи реализовывалась бы не через стандартные инструкции записи. Хотя очевидно, что даже если бы ты вдруг такое и нашёл, это не стало бы доказательство неатомарности обычных инструкций.
3. Стандарт вообще ничего не запрещает. )))
4 (главное — надеюсь хотя сейчас до тебя это дойдёт). Когда ты где-то видишь фразу типа того что атомарность sig_atomic (читай int'а) является достаточной для сигналов, но недостаточной для потоков, то это идёт речь об атомарности в широком смысле (включая гарантии отсутствия переупорядочивания инструкций, который даёт std::atomic с дефолтными настройками). Если же говорить об атомарности в чистом виде (именно в таком мы её и обсуждали, причём по именно твоему определению), то никакой разницы между сигналами, потоками или чем-то ещё просто нет. Ну и да, sig_atomic + вызов atomic_thread_fence(memory_order_seq_cst) при каждом обращение даст тебе атомарность даже в широком смысле (и для сигналов и для потоков), но это к теме нашей дискуссии уже не относится.
