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

V>>sig_atomic_t — должен гарантировать атомарность записи в эту переменную, для тех времён было достаточно, чтобы такая переменная была шириной в машинное слово.
·>Понятие многопоточности появилось в языке совсем недавно.

Понятие многопоточности в языке появилось давно, одновременно с ключевым словом volatile.

Скорее всего ты имеешь ввиду не в языке, а в новой стандартной библиотеке?
Потому что нововведения именно в язык никак с многопоточностью не связаны.


·>Почему ты вообще решил, что sig_atomic_t имеет хоть какое-то отношение к многопоточности?

Странный вопрос. ))

Если рассматривать современную мейнстримовую многопоточность с вытеснением (а было дохера разных моделей многопоточности в те весёлые года), то сначала появилась реализация такой многопоточности поверх однопроцессорных архитектур. Вытеснение происходит за счёт асинхронного механизма прерывания. Но этот механизм гарантирует, что текущая исполняемая инструкция будет выполнена полностью перед тем, как текущий поток исполнения будет прерван. Именно поэтому требовалось читать и писать из/в память одной инструкцией.

Классика жанра таких систем — System/360.
Конкретно sig_atomic_t был введён для разрабатываемой для PDP-7 UNIX.

Обе системы однопроцессорные, мультизадачные, с похожим механизмом прерываний, который (механизм) дожил практически в неизменном виде до эпохи микропроцессоров и тоже стал мейнстримовым.

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

·> mfence

Запрет переупорядочивания, т.е. пример мимо.
Это всего-лишь артефакт дополнительного требования для сериализации доступа.
Для слабых требований mfence не нужен.
А сильные модели содержат куда как больше вариантов, чем один mfence из x86/x86_x64.


·> xchg dword ptr [rip + v], eax

Это про когерентную синхронизацию данных из разных потоков, тоже не имеет отношения к факту атомарной записи значения.


·>Никакой синхронизации, говоришь?

При чём тут синхронизация? ))
Курить, что есть атомарность.

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

_>>Это было к тому, что человек хорошо знающий C# (а я раньше именно так думал про тебя), просто физически не сможет написать, что await блокирует поток исполнения.
WH>Читать научись.
WH>Где я там написал про системный поток?
WH>Я написал про остановку исполнения асинхронного кода.

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

Значит во всей это ситуации даже в теории возможно только ровно два варианта развития событий:

1. На момент написания того своего "залётного" сообщения ты даже приблизительно не представлял как работают сопрограммы (в любом языке). Поэтому и написал такую "прелесть" и только потом на работающих C# примерах разобрался как оно на самом деле. Это выглядит весьма печально для вроде как специалиста в области .net.

2. Ты знал как работают сопрограммы, но тогда получается, что в своём изначальном "залётном" сообщение ты априори написал полную чушь, потому как правильном понимание работы сопрограмм никаких "залётов" в том моём примере увидеть физически невозможно (он абсолютно корректный).

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

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

_>>Это было к тому, что человек хорошо знающий C# (а я раньше именно так думал про тебя), просто физически не сможет написать, что await блокирует поток исполнения.
I>Цитирую WH:
I>

I>await блокирует исполнение до того момента как process_asyc вернёт результат

I>Где ты увидел здесь слово "поток" ?
I>Исполнение — блокирует. Очевидно, что сначала отработает то, что справа от await, await дождется результата, а уже потом присваивание и следующая строчка. Про поток — ни слова. Но ты прочел именно так, как будто речь про поток

ОК, предположим что это так (хотя на самом деле сомневаюсь, т.к. его последующий неверный пример кода был нацелен именно на демонстрацию несуществующей блокировки потока, но предположим). Тогда ты конечно же сможешь написать в чём была суть его придирки к моему примеру, не так ли? ))) Весь если он изначально правильно понимал, как работают сопрограммы, то у него не могло быть ни единой придирки к моему коду. Однако он написал, что это страшный "залёт" и т.п... )))

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Эээ что? А ты с какой реализацией сопрограмм то пошёл проверять? С дотнетовской что ли? ))) И откуда по твоему пример на C# возник бы в дискуссии о Rust, C++ и т.п? Для нормальных реализаций сопрограмм (а не как в .net) не требуются какие-то специальные флаги в прототипе функции
НС>Дотнетой реализации тоже никаких флагов не требуется.

Если честно, я не в курсе является ли async обязательной парой к await в C# или всё же возможны варианты одиночного использования await. Но даже если возможны, то это будет только дополнительным подтверждением моих слов в данной темке. )))

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

V>>>sig_atomic_t — должен гарантировать атомарность записи в эту переменную, для тех времён было достаточно, чтобы такая переменная была шириной в машинное слово.
V>·>Понятие многопоточности появилось в языке совсем недавно.
V>Понятие многопоточности в языке появилось давно, одновременно с ключевым словом volatile.
volatile не связана с многопоточностью. Или подтверждай слова ссылкой на Стандарт, твоё бла-бла неинтересно.

V>Скорее всего ты имеешь ввиду не в языке, а в новой стандартной библиотеке?
V>Потому что нововведения именно в язык никак с многопоточностью не связаны.
Читай memory model, я ж уже несколько раз упоминал.

V>·>Почему ты вообще решил, что sig_atomic_t имеет хоть какое-то отношение к многопоточности?
V>Странный вопрос. ))

V>Если рассматривать современную мейнстримовую многопоточность с вытеснением (а было дохера разных моделей многопоточности в те весёлые года), то сначала появилась реализация такой многопоточности поверх однопроцессорных архитектур. Вытеснение происходит за счёт асинхронного механизма прерывания. Но этот механизм гарантирует, что текущая исполняемая инструкция будет выполнена полностью перед тем, как текущий поток исполнения будет прерван. Именно поэтому требовалось читать и писать из/в память одной инструкцией.
Вот только такая многопоточность появилась на уровне оперы и железа, а сам язык "ничего не знал" об этом, поэтому никаких гарантий давать не мог, как карта ляжет, так себя код и поведёт, UB. Утверждать, что "в С++ была многопоточность" равноценно "в С++ есть http". Нюанс в том, что многопоточность — особенная штука, с т.з. ЯП, т.к. влияет непосредственно на поведение языковых конструкций, а http такими особенностями не обладает. Первыми "догадались" об этом Sun с их JMM.

V>Классика жанра таких систем — System/360.
V>Конкретно sig_atomic_t был введён для разрабатываемой для PDP-7 UNIX.

V>Обе системы однопроцессорные, мультизадачные, с похожим механизмом прерываний, который (механизм) дожил практически в неизменном виде до эпохи микропроцессоров и тоже стал мейнстримовым.
Осталось тебе разобраться какое это отношение имеет непосредственно к ЯП С/С++. И подкрепляй свои слова ссылками на Стандарт.

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

V>·> mfence
V>Запрет переупорядочивания, т.е. пример мимо.
V>Это всего-лишь артефакт дополнительного требования для сериализации доступа.
V>Для слабых требований mfence не нужен.
V>А сильные модели содержат куда как больше вариантов, чем один mfence из x86/x86_x64.
Какие модели? Это просто один из вариантов реализации (особенность gcc). Второй — xchg.

Вообще непонятно с чем ты споришь. alex_public утверждал, что инструкции для atomic vs non-atimic одинаковые. Это оказалось враньём.

V>·> xchg dword ptr [rip + v], eax
V>Это про когерентную синхронизацию данных из разных потоков, тоже не имеет отношения к факту атомарной записи значения.
С т.з. ЯП С/С++ — имеет.

V>·>Никакой синхронизации, говоришь?
V>При чём тут синхронизация? ))
Т.е. "__sync_synchronize" по-твоему к синхронизации отношения не имеет?

V>Курить, что есть атомарность.
Так кури:

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

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

V>>>>sig_atomic_t — должен гарантировать атомарность записи в эту переменную, для тех времён было достаточно, чтобы такая переменная была шириной в машинное слово.
V>>·>Понятие многопоточности появилось в языке совсем недавно.
V>>Понятие многопоточности в языке появилось давно, одновременно с ключевым словом volatile.
·>volatile не связана с многопоточностью.




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

Ты прочесть написанное уже не в состоянии, что ле? (выделил)
Еще раз, медленно, это всё обслуживается стандартной библиотекой, а не конструкциями языка.
Т.е. аналоги можно нарисовать на любых ООП-языках через аналогичные либы.


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

Язык Си, напомню, был разработан как замена Ассемблеру для развития Unix.
Поэтому, кое-какие "знания", хотя бы через typedef, в программу перетащить можно — потому что именно так и задумывалось, чтобы было можно.

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


·>поэтому никаких гарантий давать не мог, как карта ляжет, так себя код и поведёт, UB.

Это ты сейчас из пальца насасывать изволишь, а механизм сигналинга в Unix изначально был реализован через прерывания и этот механизм работает прекрасно.
Иначе бы ты не смог сегодян написать в коде kill(pid, SIGTERM) или в консоли kill 4242 -9.


·>Утверждать, что "в С++ была многопоточность" равноценно "в С++ есть http".


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


·>Нюанс в том, что многопоточность — особенная штука

Ньюанс в том, что ты применяешь много слов не по делу.
Давай ближе к теме.
Примеры, контрпримеры, разногласия, уточнения и т.д.


V>>Обе системы однопроцессорные, мультизадачные, с похожим механизмом прерываний, который (механизм) дожил практически в неизменном виде до эпохи микропроцессоров и тоже стал мейнстримовым.
·>Осталось тебе разобраться какое это отношение имеет непосредственно к ЯП С/С++.

))
Тут про молоко на губах разве что ответить можно.

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

I>>Цитирую WH:
I>>

I>>await блокирует исполнение до того момента как process_asyc вернёт результат

I>>Где ты увидел здесь слово "поток" ?
I>>Исполнение — блокирует. Очевидно, что сначала отработает то, что справа от await, await дождется результата, а уже потом присваивание и следующая строчка. Про поток — ни слова. Но ты прочел именно так, как будто речь про поток

_>ОК, предположим что это так (хотя на самом деле сомневаюсь, т.к. его последующий неверный пример кода был нацелен именно на демонстрацию несуществующей блокировки потока, но предположим). Тогда ты конечно же сможешь написать в чём была суть его придирки к моему примеру, не так ли? ))) Весь если он изначально правильно понимал, как работают сопрограммы, то у него не могло быть ни единой придирки к моему коду. Однако он написал, что это страшный "залёт" и т.п... )))

Насколько я вижу, вы говорите каждый о своём и невнимательно читаете сообщения. Кроме того, именно ты, вместо того, что бы указать на ошибку, начинаешь обсуждать квалификацию

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

V>>>>>sig_atomic_t — должен гарантировать атомарность записи в эту переменную, для тех времён было достаточно, чтобы такая переменная была шириной в машинное слово.
V>>>·>Понятие многопоточности появилось в языке совсем недавно.
V>>>Понятие многопоточности в языке появилось давно, одновременно с ключевым словом volatile.
V>·>volatile не связана с многопоточностью.
V>
Ты и ссылку на стандарт С++ привести можешь? Или ты слился как alex_public выше.

V>·>Читай memory model, я ж уже несколько раз упоминал.
V>Ты прочесть написанное уже не в состоянии, что ле? (выделил)
Читай memory model, я ж уже несколько раз упоминал.

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

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

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

V>>Это всего-лишь артефакт дополнительного требования для сериализации доступа.
V>>Для слабых требований mfence не нужен.
V>>А сильные модели содержат куда как больше вариантов, чем один mfence из x86/x86_x64.
·>Какие модели?

Модели, скажем так, "степени когерентности памяти" абстрактной машины исполнения С++ программы.

Разные алгоритмы накладывают разные требования, эти требования были перечислены явно:
https://ru.cppreference.com/w/cpp/atomic/memory_order

Пример по ссылке:

memory_order_relaxed
Ослабленное(Relaxed) упорядочение: отсутствуют ограничения синхронизации и упорядочения, для данной операции требуется только атомарность.
...
Ослабленное упорядочение
Атомарные операции, отмеченные как std::memory_order_relaxed, не являются синхронизирующими операциями, они не упорядочивают память. Они гарантируют только атомарность и согласованность порядка модификации.

Теперь см. выделенное в моём процитированном.


·>Это просто один из вариантов реализации (особенность gcc). Второй — xchg.

Ты пока не понимаешь, о чём споришь.
Путаешь разные понятия.


V>>Курить, что есть атомарность.
·>Так кури:
·>

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

Отож, второй случай.
Но ты спорил и продолжаешь спорить с первым.

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

V>Модели, скажем так, "степени когерентности памяти" абстрактной машины исполнения С++ программы.
V>Разные алгоритмы накладывают разные требования, эти требования были перечислены явно:
V>https://ru.cppreference.com/w/cpp/atomic/memory_order
V>

V>memory_order_relaxed

Это уже подмена изначального тезиса. У alex_public был вполне определённый код о котором он сделал определённые заявления. Но допустим он ошибся по незнанию и имелось в виду такое:

std::atomic<int> v;
int v1;
...
    v.store(1, std::memory_order_relaxed);
    v1=1;

В таком виде да, _в большинстве_ архитектур будет одинаковый код. Но всё равно, посмотрим на risc и ВНЕЗАПНО:
atomic:

        lui     a5,%hi(v)
        li      a4,1
        addi    a5,a5,%lo(v)
        amoswap.w zero,a4,0(a5)

non-atomic:

        lui     a5,%hi(v1)
        li      a4,1
        sw      a4,%lo(v1)(a5)

Так что как ни изгаляйся, правдивее от этого не стало, всё равно враньё.

V>Отож, второй случай.
V>Но ты спорил и продолжаешь спорить с первым.
Нет, это ты продолжаешь спорить с голосами у тебя в голове. Я такого не утверждал.

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

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 элементарным — подставляться.

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

·>В таком виде да, _в большинстве_ архитектур будет одинаковый код. Но всё равно, посмотрим на risc и ВНЕЗАПНО:

Разумеется, для тебя "внезапно". ))
Напряги внимание, плиз (цитирую себя):

Вытеснение происходит за счёт асинхронного механизма прерывания. Но этот механизм гарантирует, что текущая исполняемая инструкция будет выполнена полностью перед тем, как текущий поток исполнения будет прерван. Именно поэтому требовалось читать и писать из/в память одной инструкцией.

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


V>>Отож, второй случай.
V>>Но ты спорил и продолжаешь спорить с первым.
·>Нет, это ты продолжаешь спорить с голосами у тебя в голове. Я такого не утверждал.

Ты оспаривал тот самый первый случай по ссылке:

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

Например, простые операции чтения/записи выровненных данных, шириной в машинное слово, в упомянутых архитектурах IBM/360 (плюс все дальнейшие линейки), PDP-7 (плюс все дальнейшие линейки), x86/x86_x64 являются атомарной операцией и это гарантируется аппаратурой.

Или взять упомянутый MIPS32/64 — в его наборе команд некоторые команды чтения/записи являются атомарными, некоторые нет.
(всё еще без использования всяких interlocked-операций)

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

_>Если честно, я не в курсе является ли async обязательной парой к await в C# или всё же возможны варианты одиночного использования await.

Невозможны.
async является обязательным модификатором сигнатуры метода, чтобы скомпилировался await в теле такого метода, т.е. твои оппоненты тут бесконечно бегают аки марафонцы. ))

    static void Test(int param)
    {
        global_var = await process_asyc(global_var, param);
    }

Компилятор выдаёт:

error CS4033: The 'await' operator can only be used within an async method. Consider marking this method with the 'async' modifier and changing its return type to 'Task'.

Решарпер формулирует чуть по-другому:

The 'await' operator can only be used in a method or lambda marked with the 'async' modifier.

WolfHound, конечно, подставился тут донельзя:
http://www.rsdn.org/forum/flame.comp/7457412.1
))

Встретив указанную ошибку компиляции, предпочел убрать втихую await, а не поставить async, как рекомендовал ему компилятор прямо в тексте ошибки, бгг.

==============
Как ты там иногда спрашиваешь у меня — откуда у тебя столько терпения разгребать весь этот идиотизм? ))

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

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

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

sig_atomic_t это для "asynchronous interrupts made by signals"

из того сообщения, на которое ты начал отвечать.

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

V>>>Иначе бы ты не смог сегодян написать в коде kill(pid, SIGTERM) или в консоли kill 4242 -9.
V>·>Асинхронный механизм прерываний != многопоточность.
V>Если алгоритм не требует какой-либо сильной модели памяти, т.е. достаточно модели "relaxed", то достаточно простой атомарности операций чтения/записи переменной.
Заблуждение. Или ссылки на спеку в студию.

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

V>>Сформулируй свои возражения предметно, плиз, я тогда с ними или соглашусь, или опровергну.
·>Какие возражения?

Свои, ес-но.
От тебя пока прёт пена: "Я не согласен, потому что не согласен".
Пояснить не можешь, так и запишем.
А пролетарское твоё чутьё никому не интересно.


·>Ты заявил "многопоточность в языке появилось давно"

Дословно было сказано:

Это артефакты Си/Linux, где Си разрабатывался для целей написания многопоточной операционки.

·>но своё заявление ничем не подтвердил.

Пока мест это просто исторический факт, который не требуется подтверждать.
Разве что вместо Linux (написанного на автомате) надо подставить просто UNIX, конечно.


·>Так что либо признавайся, что ты насочинял глупостей

Либо я могу признать, что ты не способен обсуждать темы, в которые ввязываешься.


V>>1. Покажи, какие твои цитаты из стандарта я повторяю?
·>

sig_atomic_t это для "asynchronous interrupts made by signals"

Это не цитата из стандарта, это искажение информации, т.е. роспись в неумении читать.
Цитата там такова:

sig_atomic_t — an integer type which can be accessed as an atomic entity even in the presence of asynchronous interrupts made by signals.

Перевод на русский язык требуется?

А тут:

Until C++11, which introduced std::atomic and std::atomic_signal_fence, about the only thing a strictly conforming program could do in a signal handler was to assign a value to a volatile static std::sig_atomic_t variable and promptly return.

?

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

Насчёт "никто не просил" — у тебя забыли поинтересоваться.

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

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


V>>Если алгоритм не требует какой-либо сильной модели памяти, т.е. достаточно модели "relaxed", то достаточно простой атомарности операций чтения/записи переменной.
·>Заблуждение.

Дык, вперёд! Раскрой суть заблуждения!


·>Или ссылки на спеку в студию.

Спеку чего? ))
Какого-нить алгоритма, для которого достаточно relaxed-модели памяти?
Проверка в цикле некоей переменной пойдёт:

static volatile sig_atomic_t flag = 0;

void sig_handler(int signum) {
    if(signum == SIGPIPE)
        flag = 1;
}

...
while(!flag)
    printSomethingToStdout();

?

Через sigaction можно подписаться на более подробную сигнатуру, например, можно узнать, что навернулся именно stdout, а не любой другой pipe.

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

V>Если процессорная архитектура в состоянии выполнить процитированное требование, то никаких дополнительных приседаний не требуется.
Верно, ключевое слово выделил. Т.е. UB во всей красе, о чём я и говорил.

V>>>Отож, второй случай.
V>>>Но ты спорил и продолжаешь спорить с первым.
V>·>Нет, это ты продолжаешь спорить с голосами у тебя в голове. Я такого не утверждал.
V>Ты оспаривал тот самый первый случай по ссылке:
Ложь.

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

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

V>·>Ты заявил "многопоточность в языке появилось давно"
V>Дословно было сказано:
Дословно было сказано:

Понятие многопоточности в языке появилось давно, одновременно с ключевым словом volatile.

V>Это артефакты Си/Linux, где Си разрабатывался для целей написания многопоточной операционки.

Это твои фантазии.

V>·>но своё заявление ничем не подтвердил.
V>Пока мест это просто исторический факт, который не требуется подтверждать.
Требуется, конечно. Неподтверждённые факты — это фантазии.

V>>>1. Покажи, какие твои цитаты из стандарта я повторяю?
V>·>

sig_atomic_t это для "asynchronous interrupts made by signals"

V>Это не цитата из стандарта, это искажение информации, т.е. роспись в неумении читать.
V>Цитата там такова:
V>

V>sig_atomic_t — an integer type which can be accessed as an atomic entity even in the presence of asynchronous interrupts made by signals.

И где тут про многопоточность? Т.к. здесь behaviour этого типа в условиях многопоточности undefined, то использовать его в условиях многопоточности — Undefined Behaviour.

V>А тут:
V>

V>Until C++11, which introduced std::atomic and std::atomic_signal_fence, about the only thing a strictly conforming program could do in a signal handler was to assign a value to a volatile static std::sig_atomic_t variable and promptly return.

V>?
Ну да. И если ты volatile используешь не для signal handler, а для многопоточности, то у тебя не будет "strictly conforming program".

V>>>2. Чем не устроило объяснение модели вытесняющей многопоточности через механизм прерываний? Поясни ошибки в моём изложении.
V>·>Тем что это объяснение у тебя никто не просил и оно не в тему.
V>Насчёт "никто не просил" — у тебя забыли поинтересоваться.
Прощаю, в следующий раз не забывайте. Так зачем ты это всё рассказываешь?

V>Насчёт "не в тему" — пояснить ты не в состоянии, как выяснилось, хотя я уже дважды показывал, почему в тему — из-за самого механизма реализации вытесняющей многопоточности через асинхронный механизм прерываний, который точно такой же, какой в случае использования сигналов.
Да пофиг. UB от этого не перестаёт быть UB. В этом его и суть. Ты лишь пытаешься доказать, что в некоторых условиях UB может работать ожидаемо. Это очевидно. И что?
Да, если механизм потоков реализован неким конкретным способом, если у нас определённая архитекутура железа и софта, то да, возможно мы можем использовать int/volatile/sig_atomic для взаимодействия потоков. Но это всё равно будет UB, по стандарту.

V>>>Если алгоритм не требует какой-либо сильной модели памяти, т.е. достаточно модели "relaxed", то достаточно простой атомарности операций чтения/записи переменной.
V>·>Заблуждение.
V>Дык, вперёд! Раскрой суть заблуждения!
Заблуждение в том что "атомарность" в контексте асинхронных сигналов это та же атомарость, что и в случае многопоточности.

V>·>Или ссылки на спеку в студию.
V>Спеку чего? ))
V>Какого-нить алгоритма, для которого достаточно relaxed-модели памяти?
Мы говорим не о алгоритмах, а о многопоточности.

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

V>>Если процессорная архитектура в состоянии выполнить процитированное требование, то никаких дополнительных приседаний не требуется.
·>Верно, ключевое слово выделил. Т.е. UB во всей красе, о чём я и говорил.

И, чтобы подтвердить свои слова насчёт UB, тебе надо показать, что C/C++ компилятор для чтения/записи переменной:

static volatile sig_atomic_t someFlag;

(где sig_atomic_t — это простой typedef на некий целочисленный тип прямо по стандарту)
в некоей архитектуре породит код, который не будет атомарно писать и читать эту переменную.

Смогёшь?