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

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

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

Эта цитата тоже не совпадает с тем, что приписываешь мне ты.
Разве "многопоточность в языке" не означает, что ср-вами языка можно порождать потоки?

И разве из той же подветки:

Согласно дизайну, многопоточность реализована в виде внешнего механизма.

такого пояснения было недостаточно?


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

Факт разработки языка Си для целей написания UNIX подтверждённый.


·>Неподтверждённые факты — это фантазии.

Я бы даже усилил — в отсутствии эрудиции и присутствии необоснованного упрямства — натуральная проблема.


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.
·>И где тут про многопоточность?

Конкретно про многопоточность с вытеснением здесь:
http://www.rsdn.org/forum/flame.comp/7460101.1

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


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

Какой именно модели многопоточности?
И как до стандарта C++11 работали операционки?
Как работает Linux, которая писана и вовсе на голом С?


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.
·>Ну да. И если ты volatile используешь не для signal handler, а для многопоточности, то у тебя не будет "strictly conforming program".

Если использую для вытесняющей многопоточности, реализованной через механизм прерываний, и меня интересует только relaxed memory order, то всё будет ОК.
Собсно, я всё это уже перечислял тут многократно, тебе стоило спорить с моими утверждениями целиком.


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

а-а-а
(терпение заканчивается)

По стандарту UB будет только при доступе к нескольким переменным.
Т.е. если в некоем алгоритме участвует более одной расшаренной переменной и алгоритму важен взаимный порядок изменения их значений.
Проблески понимания еще не появились? ))

Если переменная только одна в алгоритме, т.е. если никакой взаимный порядок обращения к ней приплести не получается, то никакого UB прямо по стандарту.
Из стандарта на русском:

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

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

Как смело ты проигнорил условие под "если". ))
И это при том, что тебе уже цитировали стандарт тут:
http://www.rsdn.org/forum/flame.comp/7460432.1

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

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

Мы говорим пока о твоём непонимании связи конкретных сценариев (т.е. алгоритмов) со стандартом.
Я показал тебе алгоритм, который абсолютно корректен с т.з. стандартов.
Hint: в алгоритме использовалась всего одна расшаренная переменная с атомарным доступом к ней, т.е. упорядочивание памяти не требуется, т.е. не будет никакого UB при доступе к переменной из нескольких потоков.