Re: Re:самомодифицирующийся код?

From

Vladimir Ivanov ()

To

Gennady Mayko

Date

2002-10-08T21:23:25Z

Area

SU.WINDOWS.NT.PROG

From: "Vladimir Ivanov" <vivanov@tmsoft-ltd.kiev.ua>

> Шедулер не будет переключать поток с высоким приоритетом на
>поток с более низким приоритетом, это правда.
> Однако, во-первых, шедулер может временно поднять
> приоритет другого потока (это называется Priority boost, правда,
>в Windows NT, если мне не изменяет память, этого не происходит
> на уровнях real-time приоритета).
Ну Priority boost - вешь управляемая - её можно и временно отключить для
процесса ;-)
> Во-вторых, шедулер обязан немедленно отдать управление другому
> потоку с большим приоритетом, как только он оказывается готов к
> выполнению; а это возможно в любой момент времени....
Это, в общем-то нас особо не интересует (при отключенном boost или при
realtime).
> В-третьих, квант времени потока может уменьшаться даже тогда,
> когда поток прерывается внешним прерыванием или DPC или APC.
> Вот еще одна цитата .....
> Поэтому я считаю, что из-за третьего и, вероятно, второго случая,
> такая уловка со Sleep() не приведет гарантировано к ожидаемому
> поведению.
    В принципе, уловка со Sleep() выполнит всё, что от неё я ожидал - поток
в любом случае будем в начале нового кванта. Другое дело, что квант может
оказаться короче, чем мы ожидали, тогда действительно мы можем не успеть
переписать 5 байт.
    Насколько я понял, квант может укоротиться при обработке любого
прерывания (не обязательно таймера) на время обработки прерывания.
Ну и пусть укорачивается. Следующий квант ведь тоже будет мой (на правах
самого высокого приоритета) ?
    Учитывая вышесказанное, глюк может действительно может проявится в том и
только том случае, если в результате прерывания оставшегося кванта хватит на
выполнение ровно одной из двух операций записи в память _И_ в процессе есть
ещё как минимум один поток с таким же приоритетом как и мой, собирающийся в
следующем кванте вызвать перехватываемую функцию.
    Ещё можно временно поставить максимально возможный квант времени для
потока (вроде тоже вещь настраиваемая), чем уменьшить и без того уже
мизерную вероятность сбоя. Кстати, вероятность равная нулю, в общем случае,
не означает невозможности события :) Ещё время Sleep'а чуть-чуть увеличить,
хоть это и на баловство больше похоже :).
    С APC, я к сожалению так и не понял: можешь описать случай, в котором
планировщик отберёт неисчерпанный квант потока с высоким приоритетом для
выполнения APC-процедуры более низкого, пусть даже в SMP среде?

Не прощаюсь,
Владимир Иванов



--- ifmail v.2.15dev5
 * Origin: A poorly-installed InterNetNews site (2:5020/400)