Compartilhar via


Contexto do Thread do Driver

Conforme mostrado na figura processando IRPs em drivers em camadas , um sistema de arquivos é um driver de duas partes:

  1. Um FSD (driver do sistema de arquivos), que é executado no contexto de um thread no modo de usuário que chama um serviço de sistema de E/S

    O gerente de E/S envia o IRP correspondente para o FSD. Caso o FSD configure uma rotina de conclusão para um IRP, sua rotina de conclusão não será necessariamente chamada no contexto original da thread do modo de usuário.

  2. Um conjunto de threads do sistema de arquivos e, possivelmente, um FSP (Processo de Sistema de Arquivos)

    Um FSD pode criar um conjunto de threads de sistema dedicadas ao driver, mas a maioria dos FSDs usa threads de trabalho do sistema para realizar o trabalho sem associar threads em modo de usuário que fazem solicitações de E/S. Qualquer FSD pode configurar seu próprio espaço de endereço de processo no qual seus threads dedicados ao driver são executados, mas os FSDs fornecidos pelo sistema evitam essa prática para conservar a memória do sistema.

Os sistemas de arquivos geralmente usam threads de trabalho do sistema para configurar e gerenciar filas de trabalho internas de IRPs que eles enviam para um ou mais drivers de nível inferior, possivelmente para dispositivos diferentes.

Embora o driver de nível mais baixo mostrado na figura Processamento de IRPs em Drivers em Camadas processe cada IRP em estágios através de um conjunto de rotinas discretas fornecidas pelo driver, ele não utiliza threads do sistema, ao contrário do que faz o sistema de arquivos. Um driver de nível mais baixo não precisa de seu próprio contexto de thread, a menos que a configuração de seu dispositivo para E/S seja um processo tão prolongado que tenha um efeito perceptível no desempenho do sistema. Poucos drivers intermediários ou de nível mais baixo precisam configurar seus próprios threads de sistema dedicados ao driver ou ao dispositivo, e aqueles que precisam sofrem uma penalidade de desempenho causada por comutações de contexto para seus threads.

A maioria dos drivers de modo kernel, como o driver de dispositivo físico na figura PROCESSAMENTO DE IRPs EM DRIVERS EM CAMADAS, executa em um contexto de thread arbitrário: no contexto de qualquer thread que esteja atual no momento em que são chamados para processar um IRP. Consequentemente, os drivers geralmente mantêm o estado sobre suas operações de E/S e os dispositivos que eles servem em uma parte de seus objetos de dispositivo definida pelo driver, chamada de extensão de dispositivo.