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

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

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


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

Ес-но.
Поэтому я и не утверждал, что "в языке есть потоки", я утверждал, что в языке есть "понятие о многопоточности".
Явным образом оперирования потоками (создание, ожидание, доступ к информации о потоке) и т.д. в языке Си нет.


V>>Факт разработки языка Си для целей написания UNIX подтверждённый.
·>Интересует взаимосвязь этого факта с многопоточностью.

UNIX многозадачна by design.


V>>Я бы даже усилил — в отсутствии эрудиции и присутствии необоснованного упрямства — натуральная проблема.
·>"А в стандарте C11 в язык добавили реализацию потоков и поддержку атомарных типов"

До С++11 жизни не было, что ле?


V>>Если тебя интересует другая модель многопоточности, то просьба уточнить, какая именно.
·>Перечисли модели многопоточности какие есть в языке С/С++.

В языке Си нет никаких моделей многопоточности.
Модель многопоточности — это абстракция, от языка зависит мало.

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

В стандарт С++11 добавили поддержку конкретно SMP-многопоточности.
Заметь, не в конструкции языка, а в стандартизированную часть его библиотек.

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


V>>·>Т.к. здесь behaviour этого типа в условиях многопоточности undefined, то использовать его в условиях многопоточности — Undefined Behaviour.
V>>Какой именно модели многопоточности?
·>Это тебя надо спросить, почему ты до сих пор не прочитал о memory model.

ЧТД. ))


V>>И как до стандарта C++11 работали операционки?
·>Мы обсуждаем язык, а не операционки.

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


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

Это верно для той эпохи, когда появились interlocked-операции, но компиляторы их еще не поддерживали.
Я и сам выдирал из исходников линухов ассемблерные вставки в 2000-х для реализации cas в отстутствии соотвeтствующих built-in's в gcc.

Но простое переключение потоков исполнения, достаточное для реализации многозадачности поверх однопроцессорности (одноядерности) несложно делается через long jump.
Доступ к аппаратуре — через inp/outp.
Так же из Си возможно было обращаться напрямую к регистрам — они в ту пору вводились как некие предопределённые глобальные переменные.
Не вижу никаких сложностей.
И разработчики Си тоже не видели, бо язык должен был позволить описать работу операционки UNIX.


V>>Собсно, я всё это уже перечислял тут многократно, тебе стоило спорить с моими утверждениями целиком.
·>Возможно будет, но этого нет в стандарте языка, а значит UB.

Тут работает более одного пункта стандарта одновременно.
К уже процитированному добавляется:

6.8.2.1.20
Two actions are potentially concurrent if
(20.1) — they are performed by different threads, or
(20.2) — they are unsequenced, at least one is performed by a signal handler, and they are not both performed
by the same signal handler invocation.
...
The execution of a program contains a data race if it contains two potentially concurrent conflicting actions,
at least one of which is not atomic...
Any such data race results in undefined behavior.

V>>По стандарту UB будет только при доступе к нескольким переменным.
·>Хватит бла-бла. Приведи ссылку на стандарт.

Тебе приводились цитаты из cppreference.
Ссылка на то же самое на английском:
https://en.cppreference.com/w/cpp/atomic/memory_order

when multiple threads simultaneously read and write to several variables, one thread can observe the values change in an order different from the order another thread wrote them.

Как стандарте если — там тебе было бы еще сложнее:

The enumeration memory_order specifies the detailed regular (non-atomic) memory synchronization order as defined in 6.8.2 and may provide for operation ordering.

Собсно, до прошлого сообщения я и сам не понимал, что тебе может быть непонятного в самоописываемом идентификаторе memory_order?
Мне понадобилось несколько раундов, чтобы сообразить, что для тебя выделенное — пустой звук.
А том сообщении, на которое я отвечаю, ты и вовсе спросил меня прямо: "почему ты до сих пор не прочитал о memory model?"
Бгг, вот так ослиные уши песочницы ака "Джава" гордо воссияли в топике С++. ))

В C++ с этим более чем просто:

A program that has two conflicting evaluations has a data race unless:
— both evaluations execute on the same thread or in the same signal handler, or
— both conflicting evaluations are atomic operations (see std::atomic), or
- one of the conflicting evaluations happens-before another (see std::memory_order)

Ключевое выделил.
Теперь вернись на прошлое моё сообщение и медитируй до просветления.


V>>Я показал тебе алгоритм, который абсолютно корректен с т.з. стандартов.
·>Ты показал сигналы, а не многопоточность. И да, тот код корректен, но к многопоточности отношения не имеет.

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

Дабы исключить лишний пинг-понг, на этот счёт тоже есть оговорки в стандарте:

6.8.2.1.23
Transformations that introduce a speculative read of a potentially shared memory location may not
preserve the semantics of the C++ program as defined in this document, since they potentially introduce a
data race. However, they are typically valid in the context of an optimizing compiler that targets a specific
machine with well-defined semantics for data races.

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

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

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


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

Ес-но.
Поэтому я и не утверждал, что "в языке есть потоки", я утверждал, что в языке есть "понятие о многопоточности".
Явным образом оперирования потоками (создание, ожидание, доступ к информации о потоке) и т.д. в языке Си нет.


V>>Факт разработки языка Си для целей написания UNIX подтверждённый.
·>Интересует взаимосвязь этого факта с многопоточностью.

UNIX многозадачна by design.


V>>Я бы даже усилил — в отсутствии эрудиции и присутствии необоснованного упрямства — натуральная проблема.
·>"А в стандарте C11 в язык добавили реализацию потоков и поддержку атомарных типов"

До С++11 жизни не было, что ле?


V>>Если тебя интересует другая модель многопоточности, то просьба уточнить, какая именно.
·>Перечисли модели многопоточности какие есть в языке С/С++.

В языке Си нет никаких моделей многопоточности.
Модель многопоточности — это абстракция, от языка зависит мало.

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

В стандарт С++11 добавили поддержку конкретно SMP-многопоточности.
Заметь, не в конструкции языка, а в стандартизированную часть его библиотек.

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


V>>·>Т.к. здесь behaviour этого типа в условиях многопоточности undefined, то использовать его в условиях многопоточности — Undefined Behaviour.
V>>Какой именно модели многопоточности?
·>Это тебя надо спросить, почему ты до сих пор не прочитал о memory model.

ЧТД. ))


V>>И как до стандарта C++11 работали операционки?
·>Мы обсуждаем язык, а не операционки.

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


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

Это верно для той эпохи, когда появились interlocked-операции, но компиляторы их еще не поддерживали.
Я и сам выдирал из исходников линухов ассемблерные вставки в 2000-х для реализации cas в отстутствии соотвeтствующих built-in's в gcc.

Но простое переключение потоков исполнения, достаточное для реализации многозадачности поверх однопроцессорности (одноядерности) несложно делается через long jump.
Доступ к аппаратуре — через inp/outp.
Так же из Си возможно было обращаться напрямую к регистрам — они в ту пору вводились как некие предопределённые глобальные переменные.
Не вижу никаких сложностей.
И разработчики Си тоже не видели, бо язык должен был позволить описать работу операционки UNIX.


V>>Собсно, я всё это уже перечислял тут многократно, тебе стоило спорить с моими утверждениями целиком.
·>Возможно будет, но этого нет в стандарте языка, а значит UB.

Тут работает более одного пункта стандарта одновременно.
К уже процитированному добавляется:

6.8.2.1.20
Two actions are potentially concurrent if
(20.1) — they are performed by different threads, or
(20.2) — they are unsequenced, at least one is performed by a signal handler, and they are not both performed
by the same signal handler invocation.
...
The execution of a program contains a data race if it contains two potentially concurrent conflicting actions,
at least one of which is not atomic...
Any such data race results in undefined behavior.

V>>По стандарту UB будет только при доступе к нескольким переменным.
·>Хватит бла-бла. Приведи ссылку на стандарт.

Тебе приводились цитаты из cppreference.
Ссылка на то же самое на английском:
https://en.cppreference.com/w/cpp/atomic/memory_order

when multiple threads simultaneously read and write to several variables, one thread can observe the values change in an order different from the order another thread wrote them.

Как стандарте если — там тебе было бы еще сложнее:

The enumeration memory_order specifies the detailed regular (non-atomic) memory synchronization order as defined in 6.8.2 and may provide for operation ordering.

Собсно, до прошлого сообщения я и сам не понимал, что тебе может быть непонятного в самоописываемом идентификаторе memory_order?
Мне понадобилось несколько раундов, чтобы сообразить, что для тебя выделенное — пустой звук.
В том сообщении, на которое я отвечаю, ты и вовсе спросил меня прямо: "почему ты до сих пор не прочитал о memory model?"
Бгг, вот так ослиные уши песочницы ака "Джава" гордо воссияли в топике С++. ))

В C++ с этим более чем просто:

A program that has two conflicting evaluations has a data race unless:
— both evaluations execute on the same thread or in the same signal handler, or
— both conflicting evaluations are atomic operations (see std::atomic), or
- one of the conflicting evaluations happens-before another (see std::memory_order)

Ключевое выделил.
Теперь вернись на прошлое моё сообщение и медитируй до просветления.


V>>Я показал тебе алгоритм, который абсолютно корректен с т.з. стандартов.
·>Ты показал сигналы, а не многопоточность. И да, тот код корректен, но к многопоточности отношения не имеет.

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

Дабы исключить лишний пинг-понг, на этот счёт тоже есть оговорки в стандарте:

6.8.2.1.23
Transformations that introduce a speculative read of a potentially shared memory location may not
preserve the semantics of the C++ program as defined in this document, since they potentially introduce a
data race. However, they are typically valid in the context of an optimizing compiler that targets a specific
machine with well-defined semantics for data races.