Объясните, пожалуйста, как работает interruptspinlock?

[Anonymous]

Тот который устанавливается командой KeAcquireInterruptSpinLock.
В доках про это как-то сильно кратко и непонятно.

[SlavaI]

Как и любой другой spin lock. Используется по назначению- для синхронизации доступа к разделяемымм ресурсам. Необходим например если осуществляется доступ к одному участку памяти как из ISR так и из другого места в драйвере, тогда необходимо при доступе к памяти не из ISR воспользоваться этой блокировкой. Единственное отличие от обычной спин блокировки в том, что IRQL процессора поднимается до Device IRQL, приписанному прерыванию.
 Вот пример из W. Oney
VOID StartIo(...)
  {
  KIRQL oldirql =
    KeAcquireInterruptSpinLock(pdx->InterruptObject);
  <initialize device for new operation>
  KeReleaseInterruptSpinLock(pdx->InterruptObject, oldirql);
  }

[Anonymous]

Да, но что при этом происходит с прерыванием?
Что происходит если произошло аппаратное прерывание, а ресурс заблокирован и неизвестно будет ли он вообще освобожден?

[SlavaI]

ISR не будет вызвана, пока не освободишь спин блокировку. Если ты не освободишь блокировку то все так и повиснет. Если система однопроцессорная, то зависнет вся система, так как перепланировка потоков при IRQL>=DISPATCH невозможна. В многопроцессорной отключится заблокированный процессор.

ресурс заблокирован и неизвестно будет ли он вообще освобожден?

Подобное должно быть исключено при использовании любых спин блокировок, иначе станет невозможна перепланировка потоков на процессоре. Если это может произойти- это проблема разработчика. Спин блокировки надо захватывать на минимальное время иначе система тормознет.

[Anonymous]

Т.е. перывание не будет потеряно? А если их приедет два? Поставятся в очередь?
Из вашего объяснения, кстати спасибо большое, я понял, что механизм этот довольно опасный и использовать его надо ограничено без всяких гарантий. А существуют более "устойчивые" механизмы?

[SlavaI]

Т.е. перывание не будет потеряно? А если их приедет два? Поставятся в очередь?

Не будет. Очередей вроде никаких нет.

А существуют более "устойчивые" механизмы?

Для прерываний - нет, у них очень высокий IRQL, там невозможно применение других методов синхронизации, кроме спин блокировок. Есть еще KeSynchronizeExecution, но это то же самое что и спин блокировка.

[Anonymous]

Если других механизмов нет, тогда я попробую задать другой вопрос.
Что _нельзя_ делать в заблокированом участке?
Проблема в том, что есть функция (не моя) которая использует совместные ресурсы с обработчиком прерываний. Если они не пересекаются все работает хорошо, но если пересекаются начинаются проблемы от безобидных до зависания. Соотвественно хотелось бы их разделять. Но при выполненой комманде  KeAcquireInterruptSpinLock эта самая функция намертво вешает  систему, даже софтайс не помогает. Соответсвенно и вопрос: какими действиями можно породить такой эффект.

[SlavaI]

Нельзя вызывать ф-ции наподобии KeWaitForSingleObject c ненулевым временем ожидания, так как может произойти попытка перепланировки потоков. Нельзя использовать любые средства синхронизации, кроме спин блокировок для этого IRQL. Нельзя испольтзовать любые ф-ции, находящиеся в подкачиваемой области памяти. Нельзя использовать ф-ции которые могут работать только при IRQL<Device IRQL. Читай документацию и смотри на каком IRQL разрешено вызывать эту ф-цию. Обычно ф-ции делятся по такому принципу- те что можно вызывать только на PASSIVE_LEVEL, те что можно вызывать при IRQL<=APC_LEVEL, те что можно вызывать при IRQL<=DISPATCH_LEVEL и те что могут быть вызваны на любом IRQL. Тебе подходят только последние.

 Зависание без синего экрана обычно связано с dead lock'ом такого типа-
первый поток хватает блокировки так
KeAcquireSpinLock(A)
..................
KeAcquireSpinLock(B)

а другой в обратной последовательности

KeAcquireSpinLock(B)
.....................
KeAcquireSpinLock(A)

Естественно KeAcquireSpinLock можно вызывать только при IRQL<=DISPATCH_LEVEL, я их привел только для примера.
Или зависание связано с блокировкой внутренних структур ядра. Если нет синего экрана- то это случай блокирования ресурса без его освобождения по какой-то причине.
Возможно к зависанию или блокировке ведет вызов некоторых ф-ций на высоком IRQL. Например вызов ф-ций, для завершения своей работы использующих APC(в основном ф-ции с префиксами Zw, Nt), при IRQL>PASSIVE_LEVEL ведет к зависанию, так как APC не вызываются, так как нет понижения IRQL до APC_LEVEL.