Здравствуйте, 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-модели памяти?
Мы говорим не о алгоритмах, а о многопоточности.

Здравствуйте, 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-модели памяти?
Мы говорим не о алгоритмах, а о многопоточности.