Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Embora uma rotina de driver mantenha um bloqueio de rotação, ela não pode causar uma exceção de hardware ou gerar uma exceção de software sem derrubar o sistema. Em outras palavras, o ISR de um driver e qualquer rotina SynchCritSection que o driver fornece numa chamada para KeSynchronizeExecution não devem causar uma falha ou interrupção, como uma falha de página ou uma exceção aritmética, e não podem gerar uma exceção de software. Uma rotina que chama KeAcquireSpinLock ou KeAcquireInStackQueuedSpinLock também não pode causar uma exceção de hardware ou gerar uma exceção de software até que tenha liberado seu bloqueio de rotação executivo e não esteja mais em execução em IRQL = DISPATCH_LEVEL.
Dados pagináveis e rotinas de suporte
Enquanto mantêm um bloqueio de rotação, os drivers não devem chamar rotinas que acessam dados pagináveis. Lembre-se de que os drivers podem chamar certas rotinas de suporte que acedem a dados pagináveis se e somente se essas chamadas ocorrerem durante a execução em um nível de IRQL estritamente inferior ao DISPATCH_LEVEL. Essa restrição de IRQL impede chamar essas rotinas de suporte enquanto mantém um bloqueio de rotação. Para obter os requisitos de IRQL para qualquer rotina de suporte específica, consulte a página de referência da rotina.
Recursão
Tentar adquirir um bloqueio ativo recursivamente certamente causará um impasse: a instância detentora de uma rotina recursiva não pode liberar o bloqueio ativo enquanto uma segunda instância espera ativamente, tentando adquirir o mesmo bloqueio ativo.
As diretrizes a seguir descrevem como você usa bloqueios de rotação com rotinas recursivas:
A rotina recursiva não deve chamar-se enquanto segura um bloqueio de rotação, ou não deve tentar adquirir o mesmo bloqueio de rotação em chamadas subsequentes.
Enquanto a rotina recursiva mantém um bloqueio de rotação, outra rotina de driver não deve chamar a rotina recursiva se a recursão puder causar um bloqueio ou fazer com que o chamador mantenha o bloqueio de rotação por mais de 25 microssegundos.
Para obter mais informações sobre rotinas de drivers recursivos, consulte Usando a Pilha do Kernel.
Aquisições aninhadas do Spin Lock
Tentar adquirir um segundo bloqueio de rotação enquanto mantém outro bloqueio de rotação também pode causar impasses ou mau desempenho do controlador.
As diretrizes a seguir descrevem como os drivers devem manter os bloqueios de rotação:
O driver não deve chamar uma rotina de suporte que usa um bloqueio de rotação, a menos que seja garantido que um impasse não ocorrerá.
Mesmo que um deadlock não possa ocorrer, o driver não deve invocar uma rotina de suporte que utilize um spinlock, a menos que técnicas de codificação alternativas não consigam fornecer desempenho e funcionalidade de driver comparáveis.
Se um driver fizer chamadas aninhadas para adquirir bloqueios de rotação, ele sempre deverá adquirir os bloqueios de rotação na mesma ordem cada vez que forem adquiridos. Esta ordem ajuda a evitar impasses.
Em geral, evite usar bloqueios de rotação aninhados para proteger subconjuntos sobrepostos ou conjuntos discretos de dados e recursos compartilhados. Considere o que pode acontecer se um driver usar dois bloqueios de rotação executivos para proteger recursos discretos, como um par de objetos de temporizador que podem ser definidos individual e coletivamente por várias rotinas de driver. O motorista travava intermitentemente em uma máquina SMP, sempre que qualquer uma das duas rotinas, cada uma segurando um bloqueio de rotação, tentava adquirir o outro bloqueio de rotação.
Para obter mais informações sobre como adquirir bloqueios de rotação aninhados, consulte Bloqueios, bloqueios e sincronização.