Qual é a diferença entre chamadas lentas do sistema e rápidas do sistema? Aprendi que a chamada lenta do sistema pode bloquear se o processo captar alguns sinais, porque os sinais capturados podem ativar a chamada bloqueada do sistema, mas não consigo entender exatamente esse mecanismo. Quaisquer exemplos seriam apreciados.
Respostas:
De fato, existem três gradações nas chamadas do sistema.
getpid, gettimeofday, getuidou setuid. Algumas chamadas do sistema podem estar bloqueando ou não, dependendo das circunstâncias; por exemplo, readnunca bloqueia se o arquivo é um canal ou outro tipo que suporta leituras sem bloqueio e o O_NONBLOCKsinalizador está definido.sleep.readchamado em um descritor de arquivo de bloqueio está bloqueando, e o mesmo acontece wait.A distinção entre chamadas de sistema “rápidas” e “lentas” é quase sem bloqueio versus bloqueio, mas desta vez do ponto de vista do implementador do kernel. Um syscall rápido é aquele que é capaz de concluir sem bloquear ou esperar. 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 , os syscalls rápidos podem não ser preemptivos; esse não é o caso em sistemas unix normais.) Por outro lado, um syscall lento requer a espera de outra tarefa para ser concluída, portanto, o kernel deve se preparar para pausar o processo de chamada e executar outra tarefa.
Alguns casos são um pouco de uma área cinza. Por exemplo, uma leitura de disco ( readde um arquivo comum) é normalmente considerada sem bloqueio, porque não está aguardando outro processo; está apenas aguardando o disco, que normalmente leva apenas um pouco de tempo para responder, mas não levará uma eternidade (então é o caso 2 acima). Mas, da perspectiva do kernel, o processo precisa aguardar a conclusão do driver do disco, por isso é definitivamente um syscall lento.
O_NONBLOCKbandeira. Se o sinalizador estiver definido, o syscall pode ser concluído sem aguardar mais nada, portanto é sem bloqueio e o kernel pode tratá-lo como um syscall rápido.
Uma chamada lenta do sistema é algo como um soquete TCP read () - se você não tiver o O_ASYNC (ou o que seja) definido, poderá esperar para sempre.
Uma chamada rápida do sistema é algo como gettimeofday () ou getpid (), os quais retornam informações ao processo que o kernel disponibilizou imediatamente.
As leituras de disco caem na categoria de chamadas lentas do sistema. Se um processo faz um read () em um arquivo de disco verdadeiro, descritor de arquivo, o kernel pode precisar ler em um ou mais blocos de disco para satisfazer a leitura. Dependendo da estrutura em disco do sistema de arquivos subjacente, isso pode significar ler o inode em disco para obter o número do bloco de disco de um "bloco indireto", ler o bloco indireto para obter o bloco de dados e, em seguida, ler o próprio bloco de dados . Consome bastante tempo, pelo menos em termos de ciclos de CPU por acesso ao disco, provavelmente pior hoje do que nos bons velhos tempos.
Eu não vejo isso há muito tempo, mas a "metade inferior" do antigo código de driver de dispositivo de unidade de disco Unix bloqueava sinais / interrupções, para que fosse mais fácil manter a integridade do sistema de arquivos em disco. Ocasionalmente, um driver com falha ou um disco com falha nunca entregaria o bloco de disco solicitado por um processo, e o processo dormia para sempre. Até uma morte -9 não fez nada.