Usando uma rotina de CustomTimerDpc

Para desativar um objeto de temporizador definido anteriormente, um driver chama KeCancelTimer. Essa rotina remove o objeto de temporizador da fila de temporizadores do sistema. Geralmente, o objeto de temporizador não é definido para o estado sinalizado e a rotina CustomTimerDpc não é enfileirada para execução. No entanto, se o temporizador estiver prestes a expirar quando KeCancelTimer for chamado, a expiração pode ocorrer antes que KeCancelTimer tenha a chance de aceder à fila de temporização, caso em que a sinalização e o enfileiramento de DPC ocorrerão.

Recordar KeSetTimer ou KeSetTimerEx, com temporizador previamente especificado e ponteiros Dpc, antes que o intervalo especificado anteriormente expire, tem os seguintes efeitos:

• O kernel remove o objeto de temporizador da fila do temporizador, sem definir o objeto no estado sinalizado ou enfileirar a rotina CustomTimerDpc.

• O kernel reinsere o objeto de temporizador na fila de temporizadores, usando o novo valor DueTime.

Usar o mesmo objeto de temporizador para diferentes fins pode causar condições de corrida ou erros graves do motorista. Por exemplo, suponha que um driver especifica um único objeto de temporizador tanto para configurar uma chamada à rotina CustomTimerDpc como para configurar espera num thread dedicado ao driver. Sempre que a thread dedicada ao driver chama KeSetTimer, KeSetTimerExou KeCancelTimer para o objeto de temporizador comum, a thread cancelava as chamadas para a rotina CustomTimerDpc, se o objeto de temporizador já estivesse enfileirado para uma chamada CustomTimerDpc.

Se um driver tiver rotinas de CustomTimerDpc e também esperar por objetos do temporizador em um contexto de thread não arbitrário, deve:

• Nunca use um objeto de temporizador sensível ao contexto de thread em um contexto de thread não arbitrário ou vice-versa.

• Aloque um objeto de temporizador separado para cada rotina CustomTimerDpc. Cada conjunto de threads de driver ou rotinas de driver que são chamados em um contexto de thread não arbitrário deve ter seu próprio conjunto de objetos de temporizador "esperáveis".

Se utilizar uma rotina CustomTimerDpc, escolha com cuidado o intervalo que o driver passa em chamadas para KeSetTimer ou KeSetTimerEx. Além disso, considere todos os efeitos possíveis de uma chamada para KeCancelTimer com o mesmo objeto de temporizador de qualquer rotina de driver que faça essa chamada, particularmente em plataformas SMP.

Lembre-se do seguinte fato sobre rotinas de CustomTimerDpc:

Apenas uma instanciação de um objeto DPC representando uma rotina DPC específica pode ser enfileirada para execução a qualquer momento.

Se uma segunda rotina de driver chamar KeSetTimer ou KeSetTimerEx para executar a rotina CustomTimerDpc antes que o intervalo especificado pelo primeiro chamador expire, a rotina CustomTimerDpc será executada apenas após o intervalo especificado pelo segundo chamador expirar. Nessas circunstâncias, o CustomTimerDpc não faz nenhum dos trabalhos para os quais a primeira rotina chamada KeSetTimer ou KeSetTimerEx.

Para os drivers que têm rotinas de CustomTimerDpc e usam temporizadores periódicos:

Um driver não pode desalocar um temporizador periódico de uma rotina DPC. Os drivers podem desalocar apenas temporizadores não periódicos de uma rotina DPC.

Considere a seguinte diretriz de design para drivers que têm rotinas de CustomDpc e CustomTimerDpc:

Para evitar condições de corrida, nunca passe o mesmo ponteiro de Dpc para KeSetTimer ou KeSetTimerEx e KeInsertQueueDpc.

Em outras palavras, suponha que uma rotina de chamadas StartIo de um driver chama KeSetTimer ou KeSetTimerEx para enfileirar uma rotina CustomTimerDpc, e o ISR do driver chama KeInsertQueueDpc simultaneamente a partir de outro processador com o mesmo ponteiro Dpc. Essa rotina DPC será executada quando o IRQL em um processador cair abaixo de DISPATCH_LEVEL ou o intervalo do temporizador expirar, o que ocorrer primeiro. Seja qual for o que vier primeiro, algum trabalho essencial para o StartIo ou para o ISR seria simplesmente omitido pela rotina do DPC.

Além disso, um DPC usado por duas rotinas de driver padrão com funcionalidade muito diferente apresentaria um desempenho inferior em comparação com rotinas separadas CustomTimerDpc e CustomDpc. O DPC teria que determinar quais operações realizar, dependendo das condições que fizeram com que a rotina StartIo ou o ISR a enfileirasse. O teste dessas condições no DPC usaria ciclos de CPU adicionais.