Синхронизация читателей/писателей в NT kernel-mode

From

Eugene Muzychenko (2:5000/14)

To

Gennady Mayko ()

Date

2003-01-26T23:21:39Z

Area

SU.WINDOWS.NT.PROG

Привет!

26 Jan 03 17:42, you wrote to me:

 GM> Во-первых, какая OS?

NT, какая же еще? ;) Я же в subj написал. Другие винды мультипроцессорности не поддерживают пока :)

 EM>> по таймерным событиям (DPC_LEVEL).

 GM> Здесь, наверное, имеется ввиду DISPATCH_LEVEL, нет?

Угу, отчего-то мне казалось, что есть такой синоним для DISPATCH_LEVEL, а оказалось, что нет.

 EM>> Как лучше поступить: сэмулировать такой Spin Lock самому, тупо крутя
 EM>> пустой цикл, или сделать отложенный вызов DPC-шек, чтобы вся
 EM>> обработка шла на PASSIVE_LEVEL и можно было пользоваться KeWaitXXX?

 GM> Здесь тоже не понятно - насколько я знаю, DPC процедуры будут
 GM> стартоваться и выполняться на DISPATCH_LEVEL, а не на PASSIVE_LEVEL.

Строго говоря, они вызываются при опускании уровня ниже DISPATCH, но для непрерывности им перед вызовом уровень принудительно поднимается до DISPATCH. Я имел в виду проверять в DPC, не захватил ли кто-то список на PASSIVE, и если да, то откладывать отработку до возврата из того обработчика.

 GM> Нужно не забывать, что в один и тот же момент времени на SMP машине
 GM> могут выполняться несколько DPC, что в любом случае требует наличия
 GM> той или иной синхронизации при доступе из кода DPC к разделяемым
 GM> данным.

Угу, тоже проблема :( Похоже, по-человечески ее фиг решишь, придется таки вешать обычный spin lock :(

 GM> Если же используется один отдельный thread, через который (только)
 GM> организуется доступ к списку, то его код гарантировано
 GM> будет выполняться на одном процессоре и его синхронизировать с "самим
 GM> собой" не нужно.

Это понятно, но процессы-то в реальном времени. Если spin lock'и будут тормозить систему, то такой подход будет тормозить сам процесс...

Всего доброго!
Евгений Музыченко

--- GoldED+/W32 1.1.4.7
 * Origin: Fox Tracks, Novosibirsk, Russia (2:5000/14)