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

From

Vladimir Ivanov ()

To

Gennady Mayko

Date

2002-10-08T15:14:36Z

Area

SU.WINDOWS.NT.PROG

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

>  VI> 1. Поднимаем приоритет потока (достаточно, чтобы он был выше по
>  VI> приоритету других потоков процесса)
> Как я понимаю, предлагается повысить приоритет своего потока (наверное с
> помощью функций SetPriorityClass/SetThreadPriority, нет?). Но никто не
> гарантирует, что сразу же после этой операции другой поток так же не
поднимет
> свой приоритет до такого же уровня.
Это как раз не страшно
> Можно попытаться уменьшить приоритет других потоков или вообще их
остановить
> (SuspendThread), но непонятно, как это сделать "атомарно" так, что бы за
время
> таких операций другие thread'ы не создались или не изменили состояния тех,
с
> которыми наш thread окончил работать.
Здесь полностью согласен. Вместо одной маленькой проблемы с атомарностью
появляется несколько ещё больших :-)
>  VI> 2. Вызываем Sleep(1). В момент возврата из сна будем находится в
начале
>  VI> кванта времени
> Кстати, если гарантируется, что в потоке работает только один thread, то
эта
> операции не нужна.
Сорри, но для меня, и для многих других  "поток","thread" и "нить" - термины
эквивалентные. Уточни плиз, что ты имел в виду: fiber'ы ? - они здесь не
причём.
> А если работают несколько, то она не поможет.
Я рассматриваю как раз именно случай с несколькими конкурентными потоками.
>Windows NT не  гарантирует, что в выделенный квант времени будет выполнена
даже 1 команда.
> Поэтому переключение на выполнение другого thread'a может произойти в
любой
> момент времени, в том числе и "внутри" замены 5 байт.
Тогда наводящий вопрос: в результате _чего_ шедулер вдруг "ни с того ни с
сего" переключит мой поток с высоким приоритетом (допустим даже realtime) на
поток более низкий или равный ему, не дожидаясь завершения кванта времени
отведенному данному потоку?
Я понимаю, что пути программистов Microsoft неисповедимы, но не до абсурда
же?
>Более того, другой thread может параллельно работать на другом процессоре и
делать такую же
> замену или вызывать "заменяемую" функцию.
Многопроцессорность здесь не причём. Я (пока) лишь говорю о сведении
вероятности прерывания потока в замене пяти байт к нулю. Безусловно проблема
есть, но она не связана с рассматриваемым прерыванием потока.

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

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



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