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

V>>>>Понятие многопоточности в языке появилось давно, одновременно с ключевым словом volatile.
V>>·>volatile не связана с многопоточностью.
V>>
·>Ты и ссылку на стандарт С++ привести можешь?

Я пока жду осмысленных возражений, вместо простого "А Баба-Яга против!"
Сформулируй свои возражения предметно, плиз, я тогда с ними или соглашусь, или опровергну.
Пока что твои ко мне воззвания слишком напоминают попытку поиграть в одни ворота.
С хрена ли, как грится? ))


·>Или ты слился как alex_public выше.

Или жду следования логике спора.


V>>В случае sig_atomic_t требовалось протащить то "знание", что чтение и запись в эту переменную будет выполняться одной инструкцией процессора.
V>>Этого достаточно, чтобы асинхронный механизм прерываний работал в такой программе непротиворечиво.
·>Верно. Ты повторяешь мои цитаты из стандарта, но не отвечаешь на вопрос "какое это всё имеет отношение к многопоточности".

1. Покажи, какие твои цитаты из стандарта я повторяю?
2. Чем не устроило объяснение модели вытесняющей многопоточности через механизм прерываний? Поясни ошибки в моём изложении.


V>>·>поэтому никаких гарантий давать не мог, как карта ляжет, так себя код и поведёт, UB.
V>>Это ты сейчас из пальца насасывать изволишь, а механизм сигналинга в Unix изначально был реализован через прерывания и этот механизм работает прекрасно.
V>>Иначе бы ты не смог сегодян написать в коде kill(pid, SIGTERM) или в консоли kill 4242 -9.
·>Асинхронный механизм прерываний != многопоточность.

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

Т.е. если даже твой (пользовательский) код не является многопоточным, но обслуживание прерываний в момент исполнения твоего кода таковым является.
Например, ты подписался на некие сигналы UNIX, тем самым автоматически превратил свою однопоточную программу в многопоточную с вытесняющей многозадачностью, т.е. должен начинать обыгрывать гарантии, требуемые в случае вытесняющей многопоточности, для разделяемых данных м/у основной программой и подпрограммами обработки сигналов.
Если алгоритм не требует какой-либо сильной модели памяти, т.е. достаточно модели "relaxed", то достаточно простой атомарности операций чтения/записи переменной.
Например, для удовлетворения именно таких гарантий и был введен тип sig_atomic_t.

ИМХО, это всё элементарно как дважды два. ))
Спорить c элементарным — подставляться.