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

V>>·>т.к. такое его использование — data race, а значит ub. Использование std::atomic не является data race.
V>>1. Data race не всегда UB, часто так и задумано.
·>Всегда.
·>Не путай data race и race condition.

Давай разбираться, кто путает:

The definition of a data race is pretty clear, and therefore, its discovery can be automated. A data race occurs when 2 instructions from different threads access the same memory location, at least one of these accesses is a write and there is no synchronization that is mandating any particular order among these accesses.

A race condition is a semantic error. It is a flaw that occurs in the timing or the ordering of events that leads to erroneous program behavior.

V>>2. Использование std::atomic, защищает от data race неатомарные типы, для специализаций под эти типы структура std::atomic содержит внутри себя мьютекс.
V>>Что характерно, что для таких типов memory_order не играет никакого значения, т.к. оперирование примитивами синхронизации означает выполнение самых строгих гарантий, т.е. обсуждаемый memory_order актуален только для типов, которые проц умеет сохранять/читать атомарно.
·>Опять фантазируешь.

Тут лучше не выдумывать из головы, а внимать.
Ценной информацией делюсь, ваще-то.
Например, насчёт выделенного.


·>Мьютекс содержат только те std::atomic, которые данная имплементация языка не может защитить от data race без мьютекса.

Data race в случае memory_order_release происходит в полный рост для атомарных типов.
При некоторых других комбинациях (на стороне записи и чтения) — тоже аж бегом.


·>И это можно даже проверить для каждого конкретного случая, см. метод is_lock_free().

Проверить-то можно, но не то, что ты формулируешь словами.
Продолжаешь не понимать предмет.


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

Интересная заява. ))
И как ты собрался её подтверждать, мне уже любопытно?


V>>·>В этом случае сработают соответсвующие механизмы atomic.
V>>А как до атомик-то жили? ))
·>Я ж отвечал уже — платформено-зависимыми функциями — ассемблерные вставки, сисколлы.

Для однопроцессорных мультизадачных операционок никаких дополнительных приседаний в виде ассемблерных вставок не требовалось.
И никакой atomic для семантики memory_order_release не требуется даже для мультипроцессорных.
Требуется атомарность.
Впрочем, ты уже показал тут десятки раз, что не понимаешь, что такое атомарность.


V>>Т.е. обработчики сигнала могут работать конкурентно
·>Не могут. Опять фантазии, явно противоречащие спекам:
·>Signals generated for a process are delivered to only one thread. Thus, if more than one thread is eligible to receive a signal, one has to be chosen.
·>(c) http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#tag_22_02_04_02

А смысл цитировать некие частности после моего:

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

Сверху еще посылка сигналов конкретным потокам через либу pthread.
В общем, не надо пытаться всё упрощать до удобной тебе модельки, реальность чуть сложнее.


·>Т.е. операционка следит за тем, чтобы сигналы процессу шли последовательно.

И опять не понимаю, зачем ты насасываешь из пальца столь громкие утверждения?
— сигналы могуть быть реентерабельны;
— сигналы могут возникать одновременно/независимо.
Например, в одном потоке AV, в другом переполнение математики.
А у тебя в программе один обработчик на все сигналы (часто так и делают).