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

From

Gennady Mayko ()

To

Vladimir Ivanov

Date

2002-10-08T23:16:01Z

Area

SU.WINDOWS.NT.PROG

From: "Gennady Mayko" <gennady.mayko@broadcom.com>

Добрый день!

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

 >> В-третьих, квант времени потока может уменьшаться даже тогда,
 >> когда поток прерывается внешним прерыванием или DPC или APC.
 >> Вот еще одна цитата .....
 >> Поэтому я считаю, что из-за третьего и, вероятно, второго случая,
 >> такая уловка со Sleep() не приведет гарантировано к ожидаемому
 >> поведению.

 VI>     В принципе, уловка со Sleep() выполнит всё, что от неё я ожидал -
 VI> поток
 VI> в любом случае будем в начале нового кванта. Другое дело, что квант может
 VI> оказаться короче, чем мы ожидали, тогда действительно мы можем не успеть
 VI> переписать 5 байт.
--
Скорее всего, это так.


 VI>     Насколько я понял, квант может укоротиться при обработке любого
 VI> прерывания (не обязательно таймера) на время обработки прерывания.
 VI> Ну и пусть укорачивается. Следующий квант ведь тоже будет мой (на правах
 VI> самого высокого приоритета) ?
--
Не факт. При окончании кванта времени потока шедулер ставит его в конец
очереди потоков. Поэтому, если в рассматриваемом процессе есть другие потоки с
таким же приоритетом, управлением будет передано им. Здесь как раз и может
возникнуть проблема, если эти потоки, например, попытаются выполнить вызов
перехватываемой функции.

 VI>     Учитывая вышесказанное, глюк может действительно может проявится в
 VI> том и только том случае, если в результате прерывания оставшегося кванта
 VI> хватит на выполнение ровно одной из двух операций записи в память _И_ в
 VI> процессе есть ещё как минимум один поток с таким же приоритетом как и
 VI> мой, собирающийся в следующем кванте вызвать перехватываемую функцию.
--
Именно так. И этого уже достаточно для того, что бы не рекомендовать
использовать такой метод перехвата.


 VI>     Ещё можно временно поставить максимально возможный квант времени для
 VI> потока (вроде тоже вещь настраиваемая), чем уменьшить и без того уже
 VI> мизерную вероятность сбоя. Кстати, вероятность равная нулю, в общем
 VI> случае,
 VI> не означает невозможности события :) Ещё время Sleep'а чуть-чуть
 VI> увеличить, хоть это и на баловство больше похоже :).
--
Мне кажется, что "вероятностный" подход к проектированию программ как раз и
приводит к известной ситуации с Windows, когда все ругают ее за "глючность" :)
Поэтому лучше так не проектировать...


 VI>     С APC, я к сожалению так и не понял: можешь описать случай, в котором
 VI> планировщик отберёт неисчерпанный квант потока с высоким приоритетом для
 VI> выполнения APC-процедуры более низкого, пусть даже в SMP среде?
--
Все 3 типа APC (asynchronous procedure calls) выполняются прежде кода потока;
они гарантировано имеют больший приоритет, чем обычные потоки. Поэтому они,
так же как и процедуры обработки прерывания и DPC, могут "отбирать" время от
потока.


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

С уважением,
Геннадий Майко.

--- ifmail v.2.15dev5
 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)