то есть пока до моего драйвера доходит очередь, контекст пользовательского процесса меняется, и FileName.Buffer указывает уже на что-то в АП другого потока.
А если драйвер находтися на вершине стека, то процессор просто не успевает переключится на другой поток?
Никаких гонок нет. Успел- не успел. Не то.
Блин, когда же народ прекратит думать что ядро работает по каким-то особенным правилам! Нет там никаких гонок!
Если драйвер на вершине стека то он всегда в контексте вызываемого потока, пусть он хоть на час уйдет после этого в работу, его вызов аналогичен вызову любой ф-ции в юзер моде. Он вызывается в контексте юзерского потока и будет в нем ВСЕГДА! Только он сам может перевести обработку в другой контекст.
Если драйвер не на вершине, то все зависит от верхних драйверов. Только они могут изменить контекст вызова. Вот некоторые из случаев когда контекст меняется из-за верхних драйверов:
1) Откладывание отработки IRP в отдельный системный поток, и вызов нижележащего драйвера из него. Сюда же входят и системные очереди.
2) Отработка с использованием DPC.
когда происходит (когда гарантированно не происходит) переключение контекстов?
Переключение контекстов происходит при IRQL<=APC_LEVEL в произвольный момент времени, при IRQL>=DISPATCH_LEVEL потоки не переключаются.
Также имей в виду, что если драйвер вызван из потока, а потом потоки переключили, то процедура драйвера не выполняется пока опять этот же поток не запланируют на выполнение. Процедура лрайвера работает по тем же правилам, что и пользовательский код.
Кто переключает контексты
Планировщик потоков- это набор ф-ций, которые вызываются для определения того надо ли переключать потоки и если надо, то на какой переключится.
Переключение потоков производится в определенных точках ядра.
Ф-ция переключающая потоки-
KiSwapThread
а процессы-
KiSwapProcess
Вот в точках где они вызываются и происходит переключение контекстов.