Evitar 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. Sondar um dispositivo é uma operação cara que torna qualquer computação do sistema operacional associada ao driver de sondagem. Um driver de dispositivo que faz muita sondagem interfere nas operações de E/S em outros dispositivos e pode tornar o sistema lento e sem resposta para os 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 esteja concluída.

No entanto, alguns dispositivos ainda em uso foram projetados para funcionar com processadores antigos, que tinham barramentos de dados estreitos, taxas de relógio lentas e sistemas operacionais de tarefas individuais de usuário único que faziam E/S síncrona. 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" um intervalo mínimo enquanto o dispositivo atualiza os registros, é improvável que um 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 for compilado com um bom compilador de otimização, o compilador poderá remover a variável de contador do driver e os loops em que ele é incrementado.

Nota Siga esta diretriz de implementação se o driver precisar parar enquanto o hardware do dispositivo atualizar o estado: um driver pode chamar KeStallExecutionProcessor antes de ler os registros do dispositivo. O driver deve minimizar o intervalo que ele para e deve, em geral, especificar um intervalo de parada não mais do que 50 microssegundos.

A granularidade de um intervalo KeStallExecutionProcessor é de um microssegundo.

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