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

_>>4 (главное — надеюсь хотя сейчас до тебя это дойдёт). Когда ты где-то видишь фразу типа того что атомарность sig_atomic (читай int'а) является достаточной для сигналов, но недостаточной для потоков, то это идёт речь об атомарности в широком смысле (включая гарантии отсутствия переупорядочивания инструкций, который даёт std::atomic с дефолтными настройками). Если же говорить об атомарности в чистом виде (именно в таком мы её и обсуждали, причём по именно твоему определению), то никакой разницы между сигналами, потоками или чем-то ещё просто нет. Ну и да, sig_atomic + вызов atomic_thread_fence(memory_order_seq_cst) при каждом обращение даст тебе атомарность даже в широком смысле (и для сигналов и для потоков), но это к теме нашей дискуссии уже не относится.
·>Напоминаю. Разговор начался с твоего кода присвоения "int global_var" и мой тезис был с "Если это же сделать многопоточным, т.е. эту global_var будут пытаться писать одновременно разные потоки без всякой синхронизации, то возможен data race и значение global_var может быть каким угодно."

Да, всё верно. И я по прежнему утверждаю, что ты тогда сказал чушь, и значение global_var в том коде будет вполне определённым (одним из двух) даже в случае многопоточности.

·>Потом ты начал подменять тезис, изменяя int на sig_atomic, потом ещё volatile, потом маш-коды, теперь ты наконец-то дошел до atomic_thread_fence. Похоже, ты во всём разобрался. Можно сворачивать разговор.

— sig_atomic — это typedef int
— volatile в том примере кода был не нужен, т.к. не было мест, где компилятор мог бы применить опасную оптимизацию
— atomic_thread_fence в том примере кода не нужен, т.к. вообще нет обращения к другим областям памяти

Ещё комментарии будут? )))

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

V>>Сначала соглашаешься с тем, что необходимость volatile для UNIX возникла, хоть и не сразу, но в другом предложении ты утверждаешь, что не возникла, оказывается.
S>Не, так и не возникла.

Ну вообще говоря в низкоуровневом программирование (написание ОС, драйверов, кода для МК и т.п.) есть целый ряд важных конструкций, которые просто невозможно написать на C/C++ без применения ключевого слова volatile. Точнее можно, но тогда придётся полностью отключить оптимизацию кода компилятором, что очевидно тоже не вариант.

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

_>>И подробное обсуждение всей этой кривизны можно увидеть здесь https://github.com/michaeljclark/riscv-atomics/tree/master/results.
V>

V>0000000000000020 <atomic_store_explicit_int32_t_memory_order_relaxed>:
V>  20:    00000797              auipc    a5,0x0
V>  24:    00078793              mv    a5,a5
V>  28:    4705                    li    a4,1
V>  2a:    c398                    sw    a4,0(a5)
V>

V>А как быть с контролем выравнивания?

Эм, а что там с выравниваем? Я подробно с RISC-V не разбирался, так что не в курсе про какие-то особенности.

V>(а так-то обилие багов в деле генерировании флагов команд ужасает, походу этот RISC-V никому не нужен, если gcc генерит для него явно ошибочный код)

Нуу в потенциале RISC-V может стать очень интересной и популярной вещью. Приблизительно тем же самым, чем сейчас является ядро Линуха в ПО, только в мире железа. Однако сейчас это всё ещё по сути игрушка энтузиастов или стартапов, так что ситуация с качеством всего там как раз такая же как у Линуха в 1992-ом году. )))

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

_>>>Прежде чем согласиться или нет, надо в начале определить что такое "Safe rust". А то я что-то не помню официального определения. Единственное чётко формулируемое (причём даже на уровне компилятора), это "код в котором нет вызовов unsafe кода". Но как ты знаешь, при таком определение safe rust тебе банально даже не удастся завести в нём многопоточность (потому как те же Mutex и т.п. внутри unsafe). Т.е. я подозреваю, что подразумевается какое-то иное определение — озвучь его.
_>·>Код, который использует safe-конструкции. Примечание: наличие ключевого слова "unsafe" автоматически не означает что данная конструкция перестаёт быть safe, т.к. safety может быть доказана отдельно (вручную человеком, например).
_>Ааа, т.е. safe код — это такой код, в котором встречаются только куски safe кода? Ясно, понятно. )))
Ох... Что непонятного-то? Да, рекурсивное определение. Как прям в BNF: <safe> ::= <proven_safe> | <safe>+<proven_safe>, где <proven_safe> код написанный в unsafe rust или ffi, но доказан другими средствами, что заявляемые в спеке языка гарантии удовлетворяются.

Но для простоты пока можешь считать, что Safe Rust = стандартная библиотека + код без unsafe.

Safe Rust is the true Rust programming language. If all you do is write Safe Rust, you will never have to worry about type-safety or memory-safety. You will never endure a dangling pointer, a use-after-free, or any other kind of Undefined Behavior.

The standard library also gives you enough utilities out of the box that you'll be able to write high-performance applications and libraries in pure idiomatic Safe Rust.

_>Кстати, хочу тогда заметить, что safe assembler даёт гарантии не только от data race, но и ещё много от чего!
Где на такой посмотреть?

_>>>·>2. Доступ через volatile не является atomic.
_>>>Модификатор volatile вообще никак не связан с атомарностью. Т.е. через него могут быть определены как атомарные объекты, так и нет.
_>·>Ок. Сформулирую поточнее. "volatile sig_atomic_t" — не является atomic с т.з. многопоточности.
_>Является атомарным (в значение атомарности, определённом в нашей дискуссии выше) и в сигнала и в потоках и где угодно.
Ты ссылаешься на какие-то "наши" определения. Ссылку на стандарт.

_>>>·>3. Конкурентный доступ из разных потоков к volatile является data race.
_>>>Для начала надо определить что такое "доступ" (какие операции конкретно)
_>·>Как минимум одна операция записи и ещё одна операция чтения-или-записи.
_>>>и к каким конкретно типам (volatile же это модификатор, а не тип).
_>·>"volatile sig_atomic_t"
_>>>Для определённых операций (типа записи/чтения) и определённых типов данных (помещающихся в регистр целевой архитектуры) гонок не будет. А для других случаев будут.
_>·>Ссылку на стандарт в студию.
_>Не является data race согласно твоему же определению выше в теме (по которому в случае атомарного доступа у нас не data race, а "недетерминизм").
Опять. Ссылку на стандарт в студию. "моё определение" стандартом не является.

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

V>>Главный же прикол не в том, что ключевое слово volatile появилось в этом стандарте, а что стандарта до этого вообще не существовало.
S>"До этого" это до чего?

До первого стандарта Си.


V>>Сначала соглашаешься с тем, что необходимость volatile для UNIX возникла, хоть и не сразу, но в другом предложении ты утверждаешь, что не возникла, оказывается.
S>Не, так и не возникла.

И ссылка на исходники более не аргумент?

Ладно, вот ссылка на более классический UNIX.


V>>Давай я тебя подстрахую от надобности затем натягивать очередных сов на глобусы или наоборот: современный взгляд можно почерпнуть из исходников Linux, например.
S>Я бы больше поверил словам самого Линуса, чем результатам поиска в гитхабе

Потому что болтуны тянутся друг к другу. ))

Верить надо объективной реальности:

The use of the volatile keyword is common in the Linux kernel source. For example, of the 10,607 .c and .h files in the Fedora Core 1, Linux kernel source directory, 1,694 have the string "volatile" in them somewhere.

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

_>·>Напоминаю. Разговор начался с твоего кода присвоения "int global_var" и мой тезис был с "Если это же сделать многопоточным, т.е. эту global_var будут пытаться писать одновременно разные потоки без всякой синхронизации, то возможен data race и значение global_var может быть каким угодно."
_>Да, всё верно. И я по прежнему утверждаю, что ты тогда сказал чушь, и значение global_var в том коде будет вполне определённым (одним из двух) даже в случае многопоточности.
И на каком основании ты так считаешь?

_>·>Потом ты начал подменять тезис, изменяя int на sig_atomic, потом ещё volatile, потом маш-коды, теперь ты наконец-то дошел до atomic_thread_fence. Похоже, ты во всём разобрался. Можно сворачивать разговор.
_>- sig_atomic — это typedef int
Де-факто, но не де-юре.

_>- volatile в том примере кода был не нужен, т.к. не было мест, где компилятор мог бы применить
Подкрепи свои слова стандартом.

_>опасную оптимизацию
Вот какой у тебя клёвый надёжный код, что оптимизации компилятора считаешь опасными!

_>- atomic_thread_fence в том примере кода не нужен, т.к. вообще нет обращения к другим областям памяти
_>Ещё комментарии будут? )))
atomic_thread_fence упорядочивает не "другие области", а обращения к памяти. Если у тебя более одного обращения из разных тредов, пусть даже к одной области — то у тебя уже могут быть вариации.

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

V>>А как быть с контролем выравнивания?
_>Эм, а что там с выравниваем? Я подробно с RISC-V не разбирался, так что не в курсе про какие-то особенности.

АМО-операции генерят исключение, если адрес не выровнен.
ИМХО, важная особенность.


_>Нуу в потенциале RISC-V может стать очень интересной и популярной вещью. Приблизительно тем же самым, чем сейчас является ядро Линуха в ПО, только в мире железа.

ХЗ, операционка — это, всё-таки, более объемлющее понятие, а RISC — малость узкое.


_>Однако сейчас это всё ещё по сути игрушка энтузиастов или стартапов

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

Обычно, эти вещи шли одновременно, т.е. порадовало отделение мух от котлет.

Не помешал бы аналогичный проект для VLIW.

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

·>atomic_thread_fence упорядочивает не "другие области", а обращения к памяти. Если у тебя более одного обращения из разных тредов, пусть даже к одной области — то у тебя уже могут быть вариации.

Да пофик, потоки всё-равно асинхронны друг относительно друга.
Поэтому речь только о сохранении видимого из других потоков порядка изменений более одной переменной и ни о чём больше.
Т.е. синхронизируются данные.

Если требуется синхронизировать потоки, то это надо делать явно через примитивы ожидания, atomic_thread_fence не синхронизирует потоки.

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

V>·>atomic_thread_fence упорядочивает не "другие области", а обращения к памяти. Если у тебя более одного обращения из разных тредов, пусть даже к одной области — то у тебя уже могут быть вариации.
V>Да пофик, потоки всё-равно асинхронны друг относительно друга.
V>Поэтому речь только о сохранении видимого из других потоков порядка изменений более одной переменной и ни о чём больше.
V>Т.е. синхронизируются данные.
Да. Если барьеры не ставить, то данные, например, могут и не синхронизироваться или синхронизироваться как попало. Один поток что-то поменял, потом второй поменял, третий поток увидел изменение от второго, потом четвёртый — увидел от первого, а пятый вообще ничего не увидел и т.п. весёлые приключения данных.
Притом volatile от этого не поможет, ибо он влияет только на компилятор, а железу пофиг.

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

_>Ну вообще говоря в низкоуровневом программирование (написание ОС, драйверов, кода для МК и т.п.) есть целый ряд важных конструкций, которые просто невозможно написать на C/C++ без применения ключевого слова volatile. Точнее можно, но тогда придётся полностью отключить оптимизацию кода компилятором, что очевидно тоже не вариант.
Хм. Можно привести пример такой конструкции?

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

_>>Ну вообще говоря в низкоуровневом программирование (написание ОС, драйверов, кода для МК и т.п.) есть целый ряд важных конструкций, которые просто невозможно написать на C/C++ без применения ключевого слова volatile. Точнее можно, но тогда придётся полностью отключить оптимизацию кода компилятором, что очевидно тоже не вариант.
S>Хм. Можно привести пример такой конструкции?

Например:

int* mapped_register=0x12345678;
while(*mapped_register!=0);

или

for(int i=0; i<100000; i++);

или

int* mapped_port=0x12345678;
*mapped_port=0;
*mapped_port=0;
*mapped_port=0;

Надо пояснять для чего они служат, и что с ними сделает даже самый простенький оптимизатор? )

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

S>>До примерно 1983-84 никакого "множества компиляторов" в природе не существовало — был компилятор Джонсона и его порты на разные платформы.

V>Это утверждение не позволяет подтверждать или опровергать мысль о том, что компилятор с 67-го года не развивался.

А у тебя есть показать ссылкой на компилятор, статью, коммит, где будет этот самый volatile ? Скажем, если в статье, книге, компиляторе образца 197x найдется volatile, то можно считать твою версию обоснованой.

Ты ведь на это намекаешь, что де задолго до стандарта всё уже было, правильно ?

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

_>>>Ну вообще говоря в низкоуровневом программирование (написание ОС, драйверов, кода для МК и т.п.) есть целый ряд важных конструкций, которые просто невозможно написать на C/C++ без применения ключевого слова volatile. Точнее можно, но тогда придётся полностью отключить оптимизацию кода компилятором, что очевидно тоже не вариант.
S>>Хм. Можно привести пример такой конструкции?

_>Например:
_>

_>int* mapped_register=0x12345678;
_>while(*mapped_register!=0);
_>

_>или
_>

_>for(int i=0; i<100000; i++);
_>

_>или
_>

_>int* mapped_port=0x12345678;
_>*mapped_port=0;
_>*mapped_port=0;
_>*mapped_port=0;
_>

_>Надо пояснять для чего они служат, и что с ними сделает даже самый простенький оптимизатор? )

Для таких вещей всегда имелись библиотеки. А ну как придется портировать такой код на какую другую платформу, что ты будешь делать с этими mapped_xxx ?

Здравствуйте, alex_public, Вы писали:
S>>Хм. Можно привести пример такой конструкции?

_>Например:
_>

_>int* mapped_register=0x12345678;
_>while(*mapped_register!=0);
_>

_>или
_>

_>for(int i=0; i<100000; i++);
_>

_>или
_>

_>int* mapped_port=0x12345678;
_>*mapped_port=0;
_>*mapped_port=0;
_>*mapped_port=0;
_>

_>Надо пояснять для чего они служат, и что с ними сделает даже самый простенький оптимизатор? )

Ок, про отображение портов — согласен. Но это не имеет отношения к многозадачности/многопоточности. Разве что в самом широком смысле, который рискует порвать сову глобусом
Про перебор i в цикле я примера увы, не понял. С учётом того, что i у нас никуда не отображена, мы крутим регистр процессора.
Скорее всего, речь идёт о трудноуловимой баге — программист пытается выполнить задержку ненадёжным способом.
Скажем, если бы речь шла о спинлоке, то там внутри цикла должны были бы стоять не volatile, а fences — чтобы упорядочить чтения с записями из других потоков/ядер.

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

S>Про перебор i в цикле я примера увы, не понял. С учётом того, что i у нас никуда не отображена, мы крутим регистр процессора.
Я кстати тоже не понял какое отношение имеет такой цикл к volatile и что остановит компилер от выкидывания "ничего неделающего" цикла.

S>Скорее всего, речь идёт о трудноуловимой баге — программист пытается выполнить задержку ненадёжным способом.
Ну как я понимаю на каких-нибудь mcu это может быть единственный способ. С учётом известной тактовой частоты задержки вполне надёжные. Но многопоточность в данном контексте порвёт как минимум пару сов.

S>Скажем, если бы речь шла о спинлоке, то там внутри цикла должны были бы стоять не volatile, а fences — чтобы упорядочить чтения с записями из других потоков/ядер.
Верно.

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

I>А у тебя есть показать ссылкой на компилятор, статью, коммит, где будет этот самый volatile ?

Было бы хоть у кого-то, спор давно был бы исчерпан.


I>Ты ведь на это намекаешь, что де задолго до стандарта всё уже было, правильно ?

Я не намекаю, я прямо говорю, что пользовался компилятором, в котором volatile достоверно появился до выхода стандарта ANSI C.
Первую программу на Си я написал в 90-м году на Turbo C 2.0 (релиз 1988г), который вышел раньше стандарта на год (1989г).

Turbo C 1.0 я уже не застал (релиз 1987), но по нему легко ищется дока, там есть volatile.

Плюс к этому добавляй еще смещение в годах:

Turbo C — это интегрированная среда разработки плюс компилятор.
Компилятор был взят со стороны, некий Wizard C, который на тот момент уже существовал некоторое время.

Тот компилятор был уже оптимизирующий.

Или про Watcom C образца 1988 пишут, что это был лучший оптимизирующий C-компилятор того времени.

Еще о Microsoft C образца 1987-го писали "improved optimization", т.е. не "introduced", а развитие уже имеющейся.

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

_>>Ааа, т.е. safe код — это такой код, в котором встречаются только куски safe кода? Ясно, понятно. )))
·>Ох... Что непонятного-то? Да, рекурсивное определение. Как прям в BNF: <safe> ::= <proven_safe> | <safe>+<proven_safe>, где <proven_safe> код написанный в unsafe rust или ffi, но доказан другими средствами, что заявляемые в спеке языка гарантии удовлетворяются.

Только это работает исключительно в том случае, если предварительно было точно задано определение proven_safe.

·>

Safe Rust is the true Rust programming language. If all you do is write Safe Rust, you will never have to worry about type-safety or memory-safety. You will never endure a dangling pointer, a use-after-free, or any other kind of Undefined Behavior.
·>The standard library also gives you enough utilities out of the box that you'll be able to write high-performance applications and libraries in pure idiomatic Safe Rust.

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

_>>Кстати, хочу тогда заметить, что safe assembler даёт гарантии не только от data race, но и ещё много от чего!
·>Где на такой посмотреть?

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

_>>>>·>2. Доступ через volatile не является atomic.
_>>>>Модификатор volatile вообще никак не связан с атомарностью. Т.е. через него могут быть определены как атомарные объекты, так и нет.
_>>·>Ок. Сформулирую поточнее. "volatile sig_atomic_t" — не является atomic с т.з. многопоточности.
_>>Является атомарным (в значение атомарности, определённом в нашей дискуссии выше) и в сигнала и в потоках и где угодно.
·>Ты ссылаешься на какие-то "наши" определения. Ссылку на стандарт.

Давай разберёмся. Ты задал вопрос, является ли доступ к "volatile sig_atomic_t" из многопоточного кода атомарным или нет. Не определяя при этом, что ты подразумеваешь под атомарностью. Я думал, что ты подразумевал своё же старое определение этого термина — в этом случае атомарность будет. Если же ты подразумевал не то определение, а что-то другое, то тоже не проблема — сформулируй его и я тебе скажу будет ли оно соблюдаться для volatile sig_atomic_t или нет.

_>>>>·>3. Конкурентный доступ из разных потоков к volatile является data race.
_>>>>Для начала надо определить что такое "доступ" (какие операции конкретно)
_>>·>Как минимум одна операция записи и ещё одна операция чтения-или-записи.
_>>>>и к каким конкретно типам (volatile же это модификатор, а не тип).
_>>·>"volatile sig_atomic_t"
_>>>>Для определённых операций (типа записи/чтения) и определённых типов данных (помещающихся в регистр целевой архитектуры) гонок не будет. А для других случаев будут.
_>>·>Ссылку на стандарт в студию.
_>>Не является data race согласно твоему же определению выше в теме (по которому в случае атомарного доступа у нас не data race, а "недетерминизм").
·>Опять. Ссылку на стандарт в студию. "моё определение" стандартом не является.

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

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

_>>·>Напоминаю. Разговор начался с твоего кода присвоения "int global_var" и мой тезис был с "Если это же сделать многопоточным, т.е. эту global_var будут пытаться писать одновременно разные потоки без всякой синхронизации, то возможен data race и значение global_var может быть каким угодно."
_>>Да, всё верно. И я по прежнему утверждаю, что ты тогда сказал чушь, и значение global_var в том коде будет вполне определённым (одним из двух) даже в случае многопоточности.
·>И на каком основании ты так считаешь?

На том основание, что на всем железе инструкция записи регистра в память атомарна, а присвоение переменной типа int скомпилируется именно в такую инструкцию.

_>>- volatile в том примере кода был не нужен, т.к. не было мест, где компилятор мог бы применить
·>Подкрепи свои слова стандартом.

Там нет кода, который изменил бы своё поведение, в случае "кэширования" значения переменной в регистре.

_>>опасную оптимизацию
·>Вот какой у тебя клёвый надёжный код, что оптимизации компилятора считаешь опасными!

Ты похоже как-то плохо умеешь читать текст на русском языке. Я же однозначно написал, что как раз в моём примере такого кода нет. А вот если бы был, то тогда и модификатор volatile появился бы.

_>>- atomic_thread_fence в том примере кода не нужен, т.к. вообще нет обращения к другим областям памяти
_>>Ещё комментарии будут? )))
·>atomic_thread_fence упорядочивает не "другие области", а обращения к памяти. Если у тебя более одного обращения из разных тредов, пусть даже к одной области — то у тебя уже могут быть вариации.

Перестановку обращений к одной области памяти тупо недопустит сам компилятор, т.к. это изменит поведение кода. ))) Если конечно речь не идёт об оптимизациях типа объединения двух последовательных записей — это возможная оптимизация и если она вдруг тебе мешает, то ты можешь отключить её с помощью volatile.

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

_>>Надо пояснять для чего они служат, и что с ними сделает даже самый простенький оптимизатор? )
S>Ок, про отображение портов — согласен. Но это не имеет отношения к многозадачности/многопоточности. Разве что в самом широком смысле, который рискует порвать сову глобусом

А я нигде и не говорил о многозадачности/многопоточности. Я говорил о важности модификатора volatile для низкоуровневого программирования.

S>Про перебор i в цикле я примера увы, не понял. С учётом того, что i у нас никуда не отображена, мы крутим регистр процессора.
S>Скорее всего, речь идёт о трудноуловимой баге — программист пытается выполнить задержку ненадёжным способом.

Да, это именно задержка. И вполне себе надёжная. Т.е. понятно что аппаратный таймер лучше, но не во всех случаях его можно применить.

S>Скажем, если бы речь шла о спинлоке, то там внутри цикла должны были бы стоять не volatile, а fences — чтобы упорядочить чтения с записями из других потоков/ядер.

Для полноценного спинлока тебе не хватит ни volatile, ни fences. Для него необходимы уже атомарные операции типа CAS или аналоги, поддерживаемые процессором.

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

_>·>Ох... Что непонятного-то? Да, рекурсивное определение. Как прям в BNF: <safe> ::= <proven_safe> | <safe>+<proven_safe>, где <proven_safe> код написанный в unsafe rust или ffi, но доказан другими средствами, что заявляемые в спеке языка гарантии удовлетворяются.
_>Только это работает исключительно в том случае, если предварительно было точно задано определение proven_safe.
Это задано в спеках на соответствующие конструкции языка.

_>·>Safe Rust is the true Rust programming language. If all you do is write Safe Rust, you will never have to worry about type-safety or memory-safety. You will never endure a dangling pointer, a use-after-free, or any other kind of Undefined Behavior.
_>·>The standard library also gives you enough utilities out of the box that you'll be able to write high-performance applications and libraries in pure idiomatic Safe Rust.

_>И что характерно, даже в этой цитате речь идёт о разных вариациях безопасности по памяти, но нет ни слова про многопоточность... )
"or any other kind of Undefined Behavior", Data Race это Undefined Behaviour, а Data Race это как раз про многопоточность.

_>>>Кстати, хочу тогда заметить, что safe assembler даёт гарантии не только от data race, но и ещё много от чего!
_>·>Где на такой посмотреть?
_>Ну вот я его накидал, потом "доказал его безопасность другими средствами" и в соответствие с рецептом выше получил именно такой результат. )
Тоже подход, но он плох с практической точки зрения. Т.к. у тебя получится не "safe assembler", а "safe assembler program". Т.е. безопасной будет данная программа, а не ЯП. Любая модификация такого кода потребует снова доказывать всё с нуля.
Суть в том, что ЯП даёт возможность комбинировать простые безопасные конструкции в более сложные безопасные конструкции и т.п., и в итоге создать большую сложную безопасную программу.
Матлогику помнишь? Теорию моделей? Формальный язык? Аксиомы? Правила вывода? Теоремы? Так вот ЯП это такой формальный язык, который позволяет доказывать сложные теоремы, полагаясь на истинность аксиом и правил вывода, которых мало и которые простые.

_>>>·>Ок. Сформулирую поточнее. "volatile sig_atomic_t" — не является atomic с т.з. многопоточности.
_>>>Является атомарным (в значение атомарности, определённом в нашей дискуссии выше) и в сигнала и в потоках и где угодно.
_>·>Ты ссылаешься на какие-то "наши" определения. Ссылку на стандарт.
_>Давай разберёмся. Ты задал вопрос, является ли доступ к "volatile sig_atomic_t" из многопоточного кода атомарным или нет. Не определяя при этом, что ты подразумеваешь под атомарностью. Я думал, что ты подразумевал своё же старое определение этого термина — в этом случае атомарность будет.
Почему ты решил, что она будет?

_>Если же ты подразумевал не то определение, а что-то другое, то тоже не проблема — сформулируй его и я тебе скажу будет ли оно соблюдаться для volatile sig_atomic_t или нет.
На самом деле вообще-то мы о сабже. А следовательно рассуждаем о безопасности, корректности и т.п кода.
Мой тезис был в том, что "volatile sig_atomic_t" нельзя использовать из многопоточного кода, т.к. программа получится с undefined behaviour. Атомарность это детали обсуждения. Как бы мы ни определили понятие атомарости в нашей беседе, корректность кода не изменится, т.к. Стандарт явно называет это undefined behaviour, а следовательно все наложенные другими пунктами стандарта понятия типа атомарности идут лесом.
Согласен?

_>>>·>Ссылку на стандарт в студию.
_>>>Не является data race согласно твоему же определению выше в теме (по которому в случае атомарного доступа у нас не data race, а "недетерминизм").
_>·>Опять. Ссылку на стандарт в студию. "моё определение" стандартом не является.
_>Если мы не опираемся на определения, данные в начале нашей дискуссии, то тогда приводи новые и будем говорить в их терминах.
Смотри соответствующие определения в стандарте и опирайся на них. Если я сказал что-то не то, поправляй меня цитатами стандарта.