Diferença entre chamadas de sistema lentas e chamadas rápidas do sistema

Question

Qual é a diferença entre as chamadas de sistema lentas e as chamadas rápidas do sistema? Eu aprendi que a chamada lenta do sistema pode bloquear se o processo captar alguns sinais, porque os sinais capturados podem despertar a chamada do sistema bloqueada, mas não consigo entender exatamente esse mecanismo. Qualquer exemplo seria apreciado.

    

Answer 1

Existem, de fato, três gradações nas chamadas do sistema.

1. Algumas chamadas do sistema retornam imediatamente. "Imediatamente" significa que a única coisa de que precisam é um pouco de tempo de processamento. Não há limite para o tempo que eles podem levar (exceto em sistemas em tempo real ), mas essas chamadas retornam como assim que eles estiverem agendados por tempo suficiente.
   Essas chamadas geralmente são chamadas de sem bloqueio . Exemplos de chamadas sem bloqueio são as chamadas que apenas lêem um pouco do estado do sistema ou fazem uma alteração simples no estado do sistema, como getpid , gettimeofday , getuid ou setuid . Algumas chamadas do sistema podem estar bloqueando ou não bloqueando dependendo das circunstâncias; por exemplo read nunca bloqueia se o arquivo for um canal ou outro tipo que suporte não as leituras de bloqueio e a O_NONBLOCK flag estão definidas.
2. Algumas chamadas do sistema podem demorar um pouco para serem concluídas, mas não para sempre. Um exemplo típico é sleep .
3. Algumas chamadas do sistema não retornam até que algum evento externo aconteça. Essas chamadas são chamadas de bloqueio . Por exemplo, read chamado de um descritor de arquivo de bloqueio está bloqueando e, portanto, é wait .

A distinção entre as chamadas de sistema “rápidas” e “lentas” está próxima de não bloqueio vs. bloqueio, mas desta vez do ponto de vista do implementador do kernel. Um syscall rápido é aquele que é conhecido por ser capaz de completar sem bloquear ou aguardar. Quando o kernel encontra um syscall rápido, ele sabe que pode executar o syscall imediatamente e manter o mesmo processo agendado. (Em alguns sistemas operacionais com multitarefa não preemptiva , o syscalls rápido pode não ser preventivo; isso não é o caso em sistemas unix normais.) Por outro lado, um syscall lento requer potencialmente aguardar que outra tarefa seja concluída, portanto, o kernel deve se preparar para pausar o processo de chamada e executar outra tarefa.

Alguns casos são um pouco cinzentos. Por exemplo, uma leitura de disco ( read de um arquivo normal) é normalmente considerada sem bloqueio, porque não está aguardando outro processo; ele está apenas esperando pelo disco, que normalmente leva apenas um pouco de tempo para responder, mas não levará uma eternidade (então é o caso 2 acima). Mas do ponto de vista do kernel, o processo tem que esperar que o driver de disco seja concluído, então é definitivamente um syscall lento.

    

Answer 2

Uma chamada de sistema lenta é algo como uma leitura de socket TCP () - se você não tiver o O_ASYNC (ou qualquer outro) configurado, ele pode esperar por sempre.

Uma chamada rápida do sistema é algo como gettimeofday () ou getpid (), ambos retornam informações para o processo que o kernel tem imediatamente disponível.

As leituras de disco se enquadram na categoria de chamadas de sistema lentas. Se um processo faz um read () em um arquivo de disco verdadeiro, descritor de arquivo, o kernel pode ter que ler em um ou mais blocos de disco para satisfazer a leitura. Dependendo da estrutura no disco do sistema de arquivos subjacente, isso pode significar a leitura do inode do disco para obter o número de blocos de um "bloco indireto", lendo o bloco indireto para obter o bloco de dados e lendo o próprio bloco de dados . Muito demorado, pelo menos em termos de ciclos de CPU por acesso ao disco, provavelmente pior hoje do que era nos Good Old Days.

Eu não vejo isso há séculos, mas a "metade inferior" do antigo código de driver de dispositivo de unidade de disco Unix bloqueia sinais / interrupções para que seja mais fácil manter a integridade do sistema de arquivos em disco. Ocasionalmente, um driver defeituoso ou um disco com falha nunca entregaria o bloqueio de disco que um processo solicitou e o processo duraria para sempre. Mesmo um kill -9 não fez nada.