Como o SO protege da interação de drivers em multitarefa?

Question

Eu estive pensando. Vamos considerar este exemplo: Temos dois programas em execução no PC. O primeiro é, por exemplo, o navegador de internet, e o segundo é algum software de digitalização WiFi. Agora, o navegador quer usar a conexão de internet através de WiFi, mas o scanner WiFi precisa do adaptador WiFi para ser ligado no modo de verificação ...

OK, então, qual lado de uma arquitetura moderna de SO é responsável por lidar com esses tipos de colisão? Alguma camada do sistema operacional, driver de dispositivo ou o próprio programa?

Porque, por exemplo, o scanner do scanner WiFi mudou o adaptador WiFi para o modo de verificação. Agora, o navegador foi lançado. Assim, o sistema operacional muda o tempo da CPU para o navegador. Ele chama uma camada abstrata do sistema operacional para rede que chama o driver WiFi e deseja receber dados dele.

Basicamente, eu quero saber como essas situações são resolvidas. Eu tenho pensado muito sobre isso, mas eu nunca percebi isso. Porque existem várias opções:

Por exemplo, funções integradas da API do SO, como por exemplo API básica para imprimir texto no console, ou desenhar em identificadores do Windows que processam o quadro real na própria tela, e chama o driver da GPU em si, sem colisão .

Mas você pode escrever seus próprios drivers, não sob alguma API pesada do sistema operacional. E então 2 aplicativos podem usar este driver para duas funções opostas. Meu principal problema em entender isso é o ambiente multitarefa. Como o processo 2 pode chamar alguma função de driver se o processo 1 a chamar antes, e ela tiver passado para o processo 2 antes da solicitação do driver ser concluída? Obrigado.

    

Answer 1

Responda a sua pergunta específica (navegador com scanner). Em cada sistema operacional eu sei, se a placa WiFi for alternada para outro modo, outro aplicativo perderá a conectividade (no caso de não conseguir mudar esse modo de volta, mas é improvável para um navegador). A conectividade retorna quando a varredura está concluída.

E mais resposta abstrata. Em cada sistema operacional sane há uma HAL - Camada de Abstração de Hardware . Mesmo o sistema de janelas do X Server nem do Windows não chama diretamente o driver de vídeo / mouse / teclado. Cada requisição tem que passar por HAL (assim, por exemplo, um sistema de arquivos não precisa saber se um dispositivo específico é pendrive, disco rígido ou qualquer outra coisa, é apenas um dispositivo de bloco).

Tenho certeza de que o HAL mantém algum tipo de fila de solicitações que precisam ser passadas para um driver específico. Portanto, basicamente, apenas os problemas causados por multithreading são condições de corrida, já que essa fila é FIFO ( primeiro em primeiro lugar ). Assim, em uma situação com um scanner e navegador, se o scanner for o primeiro aplicativo / thread a acessar a placa WiFi, ele ganhará e a conectividade regular será perdida. Mas, se um navegador fizer sua solicitação primeiro, ele poderá receber dados e o modo será alternado um pouco mais tarde.

Espero que isso resolva as coisas.