Как бы попроще выяснить будучи в юзер-моде находится ли интересующий другой тред в данный момент времени в тревожном состоянии ?

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

Подскажите вокруг какого столба копнуть) ..

KTREAD.Alertable из третьего кольца получить низя, ну разве-что кто-то на краклабе давал какой-то хитрый код работающий через PhisicalMemory что-то там с Trap было связано но не под все ОС-и

> Rouse_ ©   (10.11.11 19:10) [1]
> KTREAD.Alertable из третьего кольца получить низя


А хотелось бы)..
Полагаешь что нет и недок.ф-ций для доступа к нему из 3-го кольца ?
Или таки есть смысл пошарить ?

Ну я сначала хотел посоветовать NtWaitForSingleObject которая возвращает STATUS_ALERTED, но покопавшись в исходниках увидел что STATUS_ALERTED возвращается только при NtAlertThread.
Напрямую из тех-же исходников (NT4, W2K и ReactOS) не увидел ни одной апи которая возвращала или данный флаг, даже хотябы в что-то возвращаемое через QuerySystemInfo

ИМХО проще махонькую дровину написать, делов то KTREAD для нити вытащить..

Ну или на краклабе поинтересоваться/васм-е там очень много спецов по ядру...

Нет, Саш .. Дрова исключены).. Овчинка выделки не стоит.
Спасибо, буду подумать как обойтись без APC.

Не ну можно конечно отсплайсить все пять функций переводящих в Alertable состояние и обновлять информацию о состоянии нити до того как, но можно еще проще, обернуть вызовы данных функций в критсекцию (для каждой нити собственную) и проверять через TryEnterCriticalSection

хм... хотя проще догда чтобы сама нить сигнализировала о вызове всяких там SleepEx и т.д.
да, чет я уже перемудриваю тоже...

> чтобы сама нить сигнализировала о вызове всяких там SleepEx и т.д.

Тогда там дикий ком с синхронизацией получается..
А проект копеечный)

Я поясню - идея с IsThreadInAllertableState появилась в связи с идеей обеспечить в APC-очереди нужного треда не более одного элемента в любой момент времени.

Но возможно и я перемудриваю)

Ну можно ручками чистить очередь через NtTestAlert...

NtTestAlert, если не ошибаюсь, применима только в контексте треда ее вызывающего. Мало того, она попросту чистит APC-очередь вызвавшего ее треда, если та не пуста.

http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/APC/NtTestAlert.html

Совсем не то.

А зачем такое надо?

Есть мнение, что результат этой проверки устареет к моменту использования результата.

> Я поясню - идея с IsThreadInAllertableState появилась в связи с идеей обеспечить в APC-очереди нужного треда не более одного элемента в любой момент времени.

Добавляешь - делаешь Inc счётчику. Удаляешь - Dec.

> в APC-очереди нужного треда не более одного элемента

- а какой тогда смысл в APC, если алгоритм - по факту - синхронный получится?
И - поясните темному - какое отношение имеет состояние ожидания потока к количеству асинхронных запросов(может я действительно чего не понимаю)?

> Мало того, она попросту чистит APC-очередь вызвавшего ее треда

- не чистит, а форсирует, обеспечивая синхронную манеру работы...

> Добавляешь - делаешь Inc счётчику. Удаляешь - Dec.

- тогда уж ReleaseSemaphor/WaitForSingleObject

> не чистит, а форсирует, обеспечивая синхронную манеру работы


Здесь можно ли поподробней ?

Правильно ли я понимаю что в ходе исполнения NtTestAlert


> It check thread APC queue, and call KiUserApcDispatcher.


тред не находясь в тревожном состоянии форсированно и последовательно исполнит все имеющиеся на этот момент запросы (если таковые там вообще имеются) в своей APC-очереди ?

> тред не находясь в тревожном состоянии форсированно и последовательно

- насчет тревожного состояния не скажу, но вот тут довольно показательные циклограммы нарисованы:
http://www.rsdn.ru/article/baseserv/InjectDll.xml
см. - http://www.rsdn.ru/article/baseserv/InjectDll%5CFigure2.png
Рисунок 2. Использование APC для внедрения DLL
Будет выполняться доставка APC пользовательского режима или нет, регулируется специальным флагом отложенной доставки APC в блоке ядра потока KTHREAD, а именно: UserApcPending. Соответственно, первый раз этот флаг устанавливается в процедуре запуска потока сразу же после добавления в очередь системного АРС LdrInitializeThunk. Поэтому при первом переходе потока из режима ядра в режим пользователя этот APC будет выбран из очереди на исполнение. Вместе с этим флаг UserApcPending сбрасывается, поэтому во время исполнения LdrInitializeThunk не будет производится доставка никаких других APC режима пользователя. Это значит, что APC LoadInjectDllThunk, добавленный нами вслед за системным APC, получит шанс на исполнение только после завершения процедуры LdrInitializeThunk. Перед самым выходом APC-процедура вызывает системный сервис NtTestAlert, внутри которого флаг отложенной загрузки снова устанавливается, если очередь APC пользовательского режима не пуста. Поскольку в очереди все еще находится APC LoadInjectDllThunk, флаг будет установлен, и при переходе в режим пользователя APC будет доставлен.

- насколько я понял, NtTestAlert не вызывает KiUserApcDispatcher, а просто взводит флаг - то есть в худшем случае ничего не призодет...

Проверил, действительно NtTestAlert выгребает и исполняет поэлементно всю очередь, если она непуста.
Будем считать что в тревожное состояние при этом перехода нет.