Здравствуйте, ·, Вы писали:

V>>·>Притом volatile от этого не поможет, ибо он влияет только на компилятор, а железу пофиг.
V>>volatile поможет донести до памяти значение операции.
·>Нет

Докажи.


·>оно только лишь отключает некоторые оптимизации компилятора.

Какие именно? И с чего ты решил, что сей аргмент подтверждает твоё "нет", а не разбивает его в пух и прах?


·>А у нас ещё есть процессор и всякие его кеши.

Во-во.
Кеши ЧЕГО именно?


V>>Иногда этого достаточно, когда речь об одной переменной всего, при этом достоверно известно, что чтение и запись такой переменной атомарны.
V>>(Собсно, в 100-й раз повторяюсь уже...)
·>Атомарность не абсолютное понятие в данном случае.

Для тебя это не понятие, а набор звуков.
Де-факто, это абсолютнейшее понятие из всех возможных.


·>В общем случае — атомарная операция это такая операция, которая происходит мгновенно




·>и не имеет никакой внутренней структуры с т.з. стороннего наблюдателя. А вот кто является этим сторонним наблюдателем — очень важно.

Ты свои потёки сознания хоть чем-то подтверждать собираешься?


·>Так вот sig_atomic_t — это атомарность с т.з. асинхронного испонления сигналов

Это автоматически означает, что доступ к этому типу атомарен.
Бо пре-ры-ва-ни-я.

Включил бы хоть раз самый важный свой орган:
— компилятор, когда компилит обработчик сигнала, он понятия не имеет, что это именно обработчик сигнала, там такой же код компилится, как везде;
— обработчик сигнала вызывается из пользовательского потока, как и любой другой пользовательский код;

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


·>а std::atomic — с т.з. многопоточного исполнения.

Для атомарных типов выполняется лишь упорядочивание памяти, актуальное лишь когда в алгоритме более одной расшаренной м/у потоками переменной.


·>Притом очевидно, что второе включает в себя и первое.

Ну разумеется! Мн-во из 2-х переменных включает в себя множество из одной переменной!
А все такие дураки, спорят с тобой и возражают именно на этот важный аргумент!
(неужели тебе самому не весело себя читать)
(или специальность троллишь)
(не похож ты на тролля, те тоньше и соображающие)



V>>Допустим, у нас есть железо, которое достоверно пишет в память в указанном порядке, тогда в потоке 1 требуется fence() только для компилятора, а не проца.
·>Это допущение некорректно с т.з. кода на языке

Вообще-то, приводится пример, ЗАЧЕМ нужны разные типы fence, т.е. почему плох одинаковый на все случаи жизни.
И это было сказано явно, но ты и этого не понял. ))


V>>А спорили мы о том, есть ли в природе такая архитектура, в которой в варианте memory_order_relaxed потребуется синхронизация для атомарных типов, т.е. где будет отличие от обычного volatile.
V>>ИМХО, такой архитектуры не будет никогда, бо она будет заведомо невостребованной.
V>>Т.е., с дуру придумать можно что угодно, ес-но, но программы под "это" писать не придётся. ))
·>Это не единственно возможное проявление UB, например, ты проигнорировал покоцанную тобой цитату тут.
·>

They would be invalid for a hypothetical machine that is not tolerant of races or provides hardware race detection.

would be — условное наклонение.
hypothetical — тем более.
Т.е. в стандарте явным образом говорится о том, чего не существует.
Де-факто таких архитектур нет и в ближайшие несколько десятилетий не предвидится.
Есть аппаратные помощники по детектированию data race, но они пока не умеют работать самостоятельно, только в связке с ПО.
Потому что не обладают инфой о типе.


·>Архитектура, которая отслеживает и пришибает data race — будет востребованной уж точно.

Для атомарных типов и единственной операции?
Не будет, бо это невозможно выразить схемотехнически.
Собсно, потому что нельзя выразить логически, поэтому нельзя схемотехнически.
И ты логически выразить тоже не сможешь.
Мог бы — уже давно бы членораздельно разложил всё по полочкам, что и где не так, вместо кивания на "авторитеты" в лице стандарта, который ты и не читал целиком, а где читал — толком не разобрался всё-равно.

В общем, на аппаратном уровне или есть возможность шарить ячейки для записи, или нет.
На логическом тоже.
Третьего не дано.

Для неатомарных типов еще можно что-то такое придумать, например, можно выставить границы начала и конца слов, в которых располагается значение, и следить за тем, что пока один поток не снял такое ограничение, другой не может туда обращаться.
Или таким макаром можно блокировать всего одну ячейку для серии обращений к ней, т.е. для неатомарных операций.
Но блокировать ячейку для одной операции записи? ы-ы-ы
Она и так "блокируется" автоматом.


·>И твой говнокод там тупо разлетится на куски.

Есть такой город — Нью-Васюки.
Вам туда. ))

Здравствуйте, ·, Вы писали:

V>>·>Притом volatile от этого не поможет, ибо он влияет только на компилятор, а железу пофиг.
V>>volatile поможет донести до памяти значение операции.
·>Нет

Докажи.


·>оно только лишь отключает некоторые оптимизации компилятора.

Какие именно? И с чего ты решил, что сей аргмент подтверждает твоё "нет", а не разбивает его в пух и прах?


·>А у нас ещё есть процессор и всякие его кеши.

Во-во.
Кеши ЧЕГО именно?


V>>Иногда этого достаточно, когда речь об одной переменной всего, при этом достоверно известно, что чтение и запись такой переменной атомарны.
V>>(Собсно, в 100-й раз повторяюсь уже...)
·>Атомарность не абсолютное понятие в данном случае.

Для тебя это не понятие, а набор звуков.
Де-факто, это абсолютнейшее понятие из всех возможных.


·>В общем случае — атомарная операция это такая операция, которая происходит мгновенно




·>и не имеет никакой внутренней структуры с т.з. стороннего наблюдателя. А вот кто является этим сторонним наблюдателем — очень важно.

Ты свои потёки сознания хоть чем-то подтверждать собираешься?


·>Так вот sig_atomic_t — это атомарность с т.з. асинхронного испонления сигналов

Это автоматически означает, что доступ к этому типу атомарен.
Бо пре-ры-ва-ни-я.

Включил бы хоть раз самый важный свой орган:
— компилятор, когда компилит обработчик сигнала, он понятия не имеет, что это именно обработчик сигнала, там такой же код компилится, как везде;
— обработчик сигнала вызывается из пользовательского потока, как и любой другой пользовательский код;

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


·>а std::atomic — с т.з. многопоточного исполнения.

Для атомарных типов выполняется лишь упорядочивание памяти, актуальное лишь когда в алгоритме более одной расшаренной м/у потоками переменной.


·>Притом очевидно, что второе включает в себя и первое.

Ну разумеется! Мн-во из 2-х переменных включает в себя множество из одной переменной!
А все такие дураки, спорят с тобой и возражают именно на этот важный аргумент!
(неужели тебе самому не весело себя читать)
(или специально троллишь)
(не похож ты на тролля, те тоньше и соображающие)


V>>Допустим, у нас есть железо, которое достоверно пишет в память в указанном порядке, тогда в потоке 1 требуется fence() только для компилятора, а не проца.
·>Это допущение некорректно с т.з. кода на языке

Вообще-то, приводится пример, ЗАЧЕМ нужны разные типы fence, т.е. почему плох одинаковый на все случаи жизни.
И это было сказано явно, но ты и этого не понял. ))


V>>А спорили мы о том, есть ли в природе такая архитектура, в которой в варианте memory_order_relaxed потребуется синхронизация для атомарных типов, т.е. где будет отличие от обычного volatile.
V>>ИМХО, такой архитектуры не будет никогда, бо она будет заведомо невостребованной.
V>>Т.е., с дуру придумать можно что угодно, ес-но, но программы под "это" писать не придётся. ))
·>Это не единственно возможное проявление UB, например, ты проигнорировал покоцанную тобой цитату тут.
·>

They would be invalid for a hypothetical machine that is not tolerant of races or provides hardware race detection.

would be — условное наклонение.
hypothetical — тем более.
Т.е. в стандарте явным образом говорится о том, чего не существует.
Де-факто таких архитектур нет и в ближайшие несколько десятилетий не предвидится.
Есть аппаратные помощники по детектированию data race, но они пока не умеют работать самостоятельно, только в связке с ПО.
Потому что не обладают инфой о типе.


·>Архитектура, которая отслеживает и пришибает data race — будет востребованной уж точно.

Для атомарных типов и единственной операции?
Не будет, бо это невозможно выразить схемотехнически.
Собсно, потому что нельзя выразить логически, поэтому нельзя схемотехнически.
И ты логически выразить тоже не сможешь.
Мог бы — уже давно бы членораздельно разложил всё по полочкам, что и где не так, вместо кивания на "авторитеты" в лице стандарта, который ты и не читал целиком, а где читал — толком не разобрался всё-равно.

В общем, на аппаратном уровне или есть возможность шарить ячейки для записи, или нет.
На логическом тоже.
Третьего не дано.

Для неатомарных типов еще можно что-то такое придумать, например, можно выставить границы начала и конца слов, в которых располагается значение, и следить за тем, что пока один поток не снял такое ограничение, другой не может туда обращаться.
Или таким макаром можно блокировать всего одну ячейку для серии обращений к ней, т.е. для неатомарных операций.
Но блокировать ячейку для одной операции записи? ы-ы-ы
Она и так "блокируется" автоматом.


·>И твой говнокод там тупо разлетится на куски.

Есть такой город — Нью-Васюки.
Вам туда. ))