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

Я тебе это уже доказал цитатами.

V>>>Data race — означает одновременные попытки читать и писать некие данные, или одновременные попытки писать.
V>·>Да. И ведёт к undefined behaviour.
V>Докажи.

If a data race occurs, the behavior of the program is undefined.

(с) https://en.cppreference.com/w/cpp/language/memory_model

V>>>Соотносятся эти определения следующим образом: data race может быть причиной race condition.
V>·>Наоборот — race condition может быть причиной data race
V>Это уже ненормальность, однако. ))

A race condition is per se not bad. A race condition can be the reason for a data race. In contrary, a data race is an undefined behaviour. Therefore, all reasoning about your program makes no sense anymore.

(с) https://www.modernescpp.com/index.php/race-condition-versus-data-race

V>·>если "мы не подумали, что тут лок может не захватиться".
V>Никаких если.
V>Ты споришь с базовой терминологией.
V>Впрочем, однажды я от тебя подобную жесть уже наблюдал.
Я спорю с твоими фантазиями.

V>>>Но может быть и частью алгоритма.
V>·>Data race не может быть частью корректного алгоритма, т.к. является undefined behaiour и никакие характеристики алгоритма обеспечить не может.
V>Докажи.

If a data race occurs, the behavior of the program is undefined.

(с) https://en.cppreference.com/w/cpp/language/memory_model

V>>>·>Нет. std::atomic гарантирует отсутсвие data race:
V>>>Только для тех типов, для которых он специализируется с мьютексом унутре.
V>·>Это твои фантазии.
V>Докажи.
Доказывать твои фантазии? Упаси боже. Ты глупость сказал, ты и доказывай.

V>>>·>"A program that has two conflicting evaluations has a data race unless ... both conflicting evaluations are atomic operations (see std::atomic) ..."
V>>>·>Без всяких оговорок о конкретном memory_order или о том, какими типами они специализированы.
V>>>На заборе тоже написано... , обычный data race.
V>·>Это твои фантазии.
V>Докажи.
Доказывать твои фантазии? Упаси боже. Ты глупость сказал, ты и доказывай.

V>Я хочу сказать, что такой код всегда корректный.
Это твои фантазии.

V>Обратное требуется доказать.
Корректность кода ты не доказал.

V>>>Исходники System V доступны, там для обсуждаемых вещей никаких ассемблерных вставок.
V>·>Не понял что ты имеешь в виду. Дай ссылку что-ли.
V>Ссылку легко найдёшь сам.
Это твои фантазии.

V>>>А во вторых, разрешено всё, что не запрещено.
V>·>Использование типов кроме std::atomic конкурентно запрещено явно.
V>Не запрещено.

Objects of atomic types are the only objects that are free from data races, that is, they may be modified by two threads concurrently or modified by one and read by another.

(с) https://en.cppreference.com/w/c/language/atomic

V>·>Ну запрещено в том смысле, что объявлено как UB.
V>Объявлено как data race, а не UB.
data race всегда UB.

V>>>Вызывать собственный обработчик никем не запрещено.
V>·>Вызывать можно функцию, а не "обработчик". Функция начинает обрабатывать сигнал, когда ось дёргает её для обработки сигнала. А просто вызов функции работает как... ээ.. вызов функции — со всеми соответствующими гарантиями.
V>И что тебя смущает?
Что вызывать код с data race не даёт никаких гарантий.

V>·>Это не значит, что они могут шарить данные как хотят.
V>Могут как хотят.
Это твои фантазии.

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