Предотвращение race conditions

Воробьев и уже не на ЭКТ.

P.S. Я вообще говорил в терминологии тестеров.

>А в шельниках для предотвращения race всю жизнь применяли `mkdir -p 700`.

Офигеть! Это в каком же шельнике каталог "700" называется? И чем каталог с названием "700" лучше любого другого? Может, всё-таки mkdir -m 700 -p $DSF_NAME ?

> А если так? Race --- эффект гонки, race condition --- состояние гонки.

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

Тогда объясни, под "condition" что подразумевается? Набор условий, стечение обстоятельств, при которых происходит race, или только сама возможность того, что обстоятельства могут неблагоприятно сложиться?

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

> Тогда объясни, под "condition" что подразумевается? Набор условий, стечение обстоятельств, при которых происходит race, или только сама возможность того, что обстоятельства могут неблагоприятно сложиться?

С моей точки зрения, как программиста и админа, лучше всего понимать (именно _понимать_, про перевод я ещё не говорю) именно как возможность, но не абсолютная, а вызванная тем, как написана программа. Несколько формально: race condition - особенность построения программы, при которой подразумевавшиеся при её разработке временнЫе отношения между процессами (раньше/позже, или невозможность какого-то события в определённой фазе работы системы) могут быть нарушены из-за недостаточной проверки или защиты.

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

Race (обгон) будет уже состоявшимся таким нарушением, которое возникает при исполнении проблемного кода.

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

У тебя какая-то странная (just IMHO) точка зрения. Ты смотришь с точки зрения опыта схемотехника?

Когда говорится о свойствах программы, не рассматривается, происходит ли сейчас выполнение какого-то участка кода или нет. Вот этот код, например, потенциально опасен, потому что не выключили прерывания и лезем к данным, которые могут изменяться обработчиком прерывания; на языке программистов, здесь наблюдается race condition. Да, он локализован - может быть, буквально в одной строчке кода, вокруг которой надо было написать intr_disable() и intr_enable(), но в результате это оказывается свойством и этого участка кода, и всей программы, причём ещё до выполнения.

Все примеры как англоязычный народ обсуждал race conditions - однозначно ложились в эту схему, без исключений, большинство наших - тоже.

> У тебя какая-то странная (just IMHO) точка зрения. Ты смотришь с точки зрения опыта схемотехника?

К сожалению, никогда схемотехникой не занимался и даже не изучал.

> Когда говорится о свойствах программы, не рассматривается, происходит ли сейчас выполнение какого-то участка кода или нет. Вот этот код, например, потенциально опасен, потому что не выключили прерывания и лезем к данным, которые могут изменяться обработчиком прерывания; на языке программистов, здесь наблюдается race condition. Да, он локализован - может быть, буквально в одной строчке кода, вокруг которой надо было написать intr_disable() и intr_enable(), но в результате это оказывается свойством и этого участка кода, и всей программы, причём ещё до выполнения.

OK, "race condition" --- это свойство программы в целом, определяющее возможность (риск, опасность) возникновения race'ов (обгонов, гонок).

>> А в том тексте, что я процитировал, он говорит, что сигнал может
>> неожиданно прийти, даже когда ты обрабатываешь другой сигнал. Я с
> этим не согласен. Для этого есть sa_mask, и он отлично работает.
> Сигналы, генерируемые синхронно в ответ на события в коде (доступ в
> незамапленую память => SIGSEGV, неизвестная команда => SIGILL, и так
> далее) не маскируются независимо от sa_mask.
Ну знаете, не надо путать ужа с ежом:)
Если у вас в программе *такие* сигналы приходят тогда, когда
вы этого не ожидаете, то это уже не race, совсем не race.
И в общем-то тут уже не прогу надо исправлять, а как минимум
голову:)
Понятно что тот же SIGSEGV может быть следствием проявления
гонки, но никак не её причиной.
Кстати, в man не написано, что они не блокируются sa_mask.
Чем подтвердите свои слова?

4anonymous (*) (13.10.2004 22:42:18):
>Кстати, в man не написано, что они не блокируются sa_mask.
>Чем подтвердите свои слова?

Ви таки передёргиваете. Валентин же написал там же:
VN> а если будут маскироваться - это только хуже для платформы

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

//Loseki

> Ну знаете, не надо путать ужа с ежом:) Если у вас в программе *такие* сигналы приходят тогда, когда вы этого не ожидаете, то это уже не race, совсем не race.

Безусловно, не race. Но для них могут тоже существовать осмысленные обработчики: например, в случае SIGSEGV неизвестного происхождения - хотя бы просто сбросить stack trace в лог. (Корка может и не быть, так что это полезно.)

>Кстати, в man не написано, что они не блокируются sa_mask. Чем подтвердите свои слова?

Я делал тесты на разных платформах. На Linux оно не блокировалось, и думаю, что это принципиальное решение. Тест тривиален: грубо говоря, поставить обработчик, замаскировать сигнал и записать что-то в NULL.

> OK, "race condition" --- это свойство программы в целом, определяющее возможность (риск, опасность) возникновения race'ов (обгонов, гонок).

Угу.

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

К сожалению, в ряде систем сигналы такие маскируются. Результат - 100% жор процессора между обработчиком и кодом возбуждения сигнала (например, запись по NULL).

Гм, надо будет пожаловаться...

> К сожалению, в ряде систем сигналы такие маскируются. Результат - 100%
> жор процессора между обработчиком и кодом возбуждения сигнала
Да, это конечно не правельно. Но и не блокировать - тоже не
правельно, имхо. Единственный правельный путь здесь, на мой
взгляд, это вызывать do_exit() синхронно. linux так часто
делает. Например, в обработчике сигнала (любого, и не важно
даже, заблокирован ли SIGSEGV), запишите в context->cs или в
context->ss 0. SIGSEGVа не последует...
Так же и тут.
Впрочем, я лишь хотел показать, что в статье есть небольшая
неточность. А мы уже вон до чего договорились... :)