Evite dispositivos de sondagem

Um driver de dispositivo deve evitar sondar seu dispositivo, a menos que seja absolutamente necessário, e nunca deve usar uma fatia de tempo inteira para sondagem. A sondagem de um dispositivo é uma operação cara que sobrecarrega a computação de qualquer sistema operativo no driver de sondagem. Um driver de dispositivo que faz muita sondagem interfere com as operações de E/S em outros dispositivos e pode tornar o sistema lento e sem resposta aos usuários.

Dispositivos desenvolvidos recentemente, que são tão avançados tecnologicamente quanto os processadores nos quais o Windows foi projetado para ser executado, raramente exigem um driver para sondar seu dispositivo, seja para garantir que o dispositivo esteja pronto para iniciar uma operação de E/S ou que uma operação seja concluída.

No entanto, alguns dispositivos ainda em uso foram projetados para funcionar com processadores antigos, que tinham barramentos de dados estreitos, frequências de relógio lentas e sistemas operacionais de usuário único e tarefa única que faziam entrada/saída síncronas. Esses dispositivos podem exigir sondagem ou algum outro meio de esperar que o dispositivo atualize seus registros.

Embora possa parecer lógico resolver um problema de dispositivo lento codificando um loop simples que incrementa um contador, "desperdiçando" assim um intervalo mínimo enquanto o dispositivo atualiza os registros, é improvável que tal driver seja portátil em plataformas Windows. O máximo do contador de loop exigiria personalização para cada plataforma. Além disso, se o driver é compilado com um bom compilador de otimização, o compilador pode remover a variável contadora do driver e o(s) loop(s) onde ele é incrementado.

Observação Siga esta diretriz de implementação se o driver precisar aguardar enquanto o estado de atualização do hardware do dispositivo: Um driver pode chamar KeStallExecutionProcessor antes de ler os registros do dispositivo. O controlador deve minimizar o intervalo de inatividade e deve, em geral, especificar um intervalo de inatividade não superior a 50 microssegundos.

A granularidade de um intervalo KeStallExecutionProcessor é de um microssegundo.

Se o dispositivo frequentemente requer mais de 50 microssegundos para atualizar o estado, considere configurar um thread dedicado ao dispositivo no driver.