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

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

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

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

V>·>А тред должен дёргать signal().
V>Вызов signal устанавливает обработчика, а не генерирует сигнал.
V>Сигнал посылает kill/raise/alarm.
Да, точно. Опечатка.

V>Сигнал посылается процессу, а не потоку.
Именно!

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

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

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