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

From

Gennady Mayko ()

To

Vladimir Ivanov

Date

2002-10-08T18:00:31Z

Area

SU.WINDOWS.NT.PROG

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

Добрый день!

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

[skipped] 

 >>  VI> 2. Вызываем Sleep(1). В момент возврата из сна будем находится в
 >>  VI> начале кванта времени
 >> Кстати, если гарантируется, что в потоке работает только один thread, 
 >> то эта операции не нужна.

 VI> Сорри, но для меня, и для многих других  "поток","thread" и "нить" -
 VI> термины эквивалентные. Уточни плиз, что ты имел в виду: fiber'ы ? - они
 VI> здесь не причём.
--
Sorry, it is my fault :(
Вместо "в потоке работает..." следует читать "в процессе работает...".
Я не имел ввиду fiber's.



 >> А если работают несколько, то она не поможет.

 VI> Я рассматриваю как раз именно случай с несколькими конкурентными
 VI> потоками.
--
см. ниже


 >> Windows NT не  гарантирует, что в выделенный квант времени будет выполнена
 >> даже 1 команда. 
 >> Поэтому переключение на выполнение другого thread'a может произойти в
 >> любой момент времени, в том числе и "внутри" замены 5 байт.

 VI> Тогда наводящий вопрос: в результате _чего_ шедулер вдруг "ни с того ни с
 VI> сего" переключит мой поток с высоким приоритетом (допустим даже realtime)
 VI> на поток более низкий или равный ему, не дожидаясь завершения кванта
 VI> времени отведенному данному потоку?
 VI> Я понимаю, что пути программистов Microsoft неисповедимы, но не до
 VI> абсурда же?
--
Шедулер не будет переключать поток с высоким приоритетом на поток с более
низким приоритетом, это правда.

Однако, во-первых, шедулер может временно поднять приоритет другого потока
(это называется Priority boost, правда, в Windows NT, если мне не изменяет
память, этого не происходит на уровнях real-time приоритета).

Во-вторых, шедулер обязан немедленно отдать управление другому потоку с
большим приоритетом, как только он оказывается готов к выполнению; а это
возможно в любой момент времени, например, в результате обработки прерывания. 
Вот цитата is "Inside Miscrosoft Windows" D.Solomon, M.Russinovich "if another
thread with a higher priority becomes ready to run, the currently running
thread might be preempted before finishing its time slice. In fact, a thread
can be selected to run next and be preempted before even beginning its
quantum!"

В-третьих, квант времени потока может уменьшаться даже тогда, когда поток
прерывается внешним прерыванием или DPC или APC. Вот еще одна цитата из того
же источника "Even if the system were at DPC/dispatch level or above (for
example, if a DPC or an interrupt service routine was executing) when the
clock interrupt occurred, the current thread would still have its quantum
decremented, even if it hadn't been running for a full clock interval."

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



 >> Более того, другой thread может параллельно работать на другом процессоре
 >> и делать такую же замену или вызывать "заменяемую" функцию.

 VI> Многопроцессорность здесь не причём. Я (пока) лишь говорю о сведении
 VI> вероятности прерывания потока в замене пяти байт к нулю. Безусловно
 VI> проблема есть, но она не связана с рассматриваемым прерыванием потока.
--
ОК, пока оставим это.


 >> Наверное, самым простым способом замены небольшого участка кода (для
 >> архитектуры x86) будет являться использование команды CMPXCHG8B - в таком
 >> случае можно "атомарно" заменить 8 байт.

 VI> А вот это действительно красивое решение, хоть и не универсальное.

 >> Ну, а если процессор не имеет такой
 >> команды, то тогда надо аккуратно задокументировать....
 >> Как ни странно, есть (удивительно!) много способов видоизменить код или,
 >> что, по-моему, фактически то же самое, гарантировано получить 
 >> управление при выполнении данного участка кода. Я насчитал еще 
 >> не менее 5 и, думаю, это не предел...

 VI> Кстати, мне кажется, можно добиться атомарности операции, не заботясь о
 VI> гарантии не прерывания кода. Постараюсь в течение дня изложить новую
 VI> идею.
--
Будет интересно ознакомиться.


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

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

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