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

·>А вот race condition действительно относится к семантике и может быть "так и задумано".

Ты уже с терминологией решил начать спорить. ))

Race condition означает условное поведение всей программы в зависимости от как повезёт.
Data race — означает одновременные попытки читать и писать некие данные, или одновременные попытки писать.

Соотносятся эти определения следующим образом: data race быть причиной race condition.
Но может быть и частью алгоритма.


·>Нет. std::atomic гарантирует отсутсвие data race:

Только для тех типов, для которых он специализируется с мьютексом унутре.


·>"A program that has two conflicting evaluations has a data race unless ... both conflicting evaluations are atomic operations (see std::atomic) ..."
·>Без всяких оговорок о конкретном memory_order или о том, какими типами они специализированы.

На заборе тоже написано... А компиллируешь — там дрова, обычный data race.


V>>·>И это можно даже проверить для каждого конкретного случая, см. метод is_lock_free().
V>>Проверить-то можно, но не то, что ты формулируешь словами.
·>Я цитирую стандарт.

Ты там делал странные выводы из просмотра исходников, а не цитировал стандарт.
Выводы неверные, достаточно посмотреть на реализацию atomic.


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

Нет, не очевидно.


·>что я даже не понимаю что здесь требуется подтверждать.

Свою громкую заяву требуется подтверждать, ес-но.
Особенно с учётом большого кол-ва инфы, которой тебя кормили несколько дней.


·>Тот факт, что мы передали указатель на функцию куда-то, это ещё не означает, что эту функцию стало безопасно дёргать из многопоточки.

А что в теле этой ф-ии рекомендуется лишь установить значение единственной переменной static volatile sig_atomic_t и выйти, ты уже забыл?


V>>·>Я ж отвечал уже — платформено-зависимыми функциями — ассемблерные вставки, сисколлы.
V>>Для однопроцессорных мультизадачных операционок никаких дополнительных приседаний в виде ассемблерных вставок не требовалось.
·>В смысле "у меня всё работало"? Отличный аргумент.

У всех работало.
Исходники System V доступны, там для обсуждаемых вещей никаких ассемблерных вставок.

И да, у меня тоже работало. ))
На 3-м курсе по "Операционкам" был коллективная курсовая работа.
Для реального режима X86 писали многозадачную учебную операционку.
Мне с другом достался как раз планировщик и семафоры.
Садились на прерывание таймера, перепрограммировали ему частоту и вперёд, всё работает.


·>И что? Ничто из этого не означает, что обработчик сигнала можно вызывать из треда напрямую.

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


·>Ядро ответственно за корректную синхронизацию вызовов хендлеров.

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

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

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

·>А вот race condition действительно относится к семантике и может быть "так и задумано".

Ты уже с терминологией решил начать спорить. ))

Race condition означает условное поведение всей программы в зависимости от как повезёт.
Data race — означает одновременные попытки читать и писать некие данные, или одновременные попытки писать.

Соотносятся эти определения следующим образом: data race может быть причиной race condition.
Но может быть и частью алгоритма.


·>Нет. std::atomic гарантирует отсутсвие data race:

Только для тех типов, для которых он специализируется с мьютексом унутре.


·>"A program that has two conflicting evaluations has a data race unless ... both conflicting evaluations are atomic operations (see std::atomic) ..."
·>Без всяких оговорок о конкретном memory_order или о том, какими типами они специализированы.

На заборе тоже написано... А компиллируешь — там дрова, обычный data race.


V>>·>И это можно даже проверить для каждого конкретного случая, см. метод is_lock_free().
V>>Проверить-то можно, но не то, что ты формулируешь словами.
·>Я цитирую стандарт.

Ты там делал странные выводы из просмотра исходников, а не цитировал стандарт.
Выводы неверные, достаточно посмотреть на реализацию atomic.


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

Нет, не очевидно.


·>что я даже не понимаю что здесь требуется подтверждать.

Свою громкую заяву требуется подтверждать, ес-но.
Особенно с учётом большого кол-ва инфы, которой тебя кормили несколько дней.


·>Тот факт, что мы передали указатель на функцию куда-то, это ещё не означает, что эту функцию стало безопасно дёргать из многопоточки.

А что в теле этой ф-ии рекомендуется лишь установить значение единственной переменной static volatile sig_atomic_t и выйти, ты уже забыл?


V>>·>Я ж отвечал уже — платформено-зависимыми функциями — ассемблерные вставки, сисколлы.
V>>Для однопроцессорных мультизадачных операционок никаких дополнительных приседаний в виде ассемблерных вставок не требовалось.
·>В смысле "у меня всё работало"? Отличный аргумент.

У всех работало.
Исходники System V доступны, там для обсуждаемых вещей никаких ассемблерных вставок.

И да, у меня тоже работало. ))
На 3-м курсе по "Операционкам" был коллективная курсовая работа.
Для реального режима X86 писали многозадачную учебную операционку.
Мне с другом достался как раз планировщик и семафоры.
Садились на прерывание таймера, перепрограммировали ему частоту и вперёд, всё работает.


·>И что? Ничто из этого не означает, что обработчик сигнала можно вызывать из треда напрямую.

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


·>Ядро ответственно за корректную синхронизацию вызовов хендлеров.

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

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