As chamadas do sistema podem ser interrompidas?

Question

Por favor, comente a seguinte frase:

On the standard Linux kernel without the rt patch, interrupts can't interrupt ongoing system calls. The reason why our machine doesn't stop working when data is fetched from the hard disk is because the system call we used for that operation is blocking. Blocking means that once it issues the request to the hard disc it changes the process state to blocked, and willingly gives up the processor time. There are no means to interrupt an ongoing system call on a non real time kernel.

Esta é a minha compreensão do tópico, mas não tenho certeza se está correto.

    

Answer 1

As chamadas do sistema podem ser interrompidas através do uso de sinais , como SIGINT (gerado por CTRL + C ), SIGHUP , etc. Você só pode interrompê-los interagindo com as chamadas do sistema através de um PID, porém ao usar sinais Unix e o comando kill .

rt_patch & chamadas do sistema

@Alan fez a seguinte pergunta:

Is the possibility to interrupt system calls directly related with the acceptance of the rt_patch in the mainline Linux kernel?

Minha resposta:

Eu acho que sim. Ao pesquisar isso, não consegui encontrar uma arma fumegante que diga que você poderia / não poderia fazer isso, o que me leva a acreditar que você pode.

O outro ponto de dados que me faz pensar sobre isso é que os sinais subjacentes O mecanismo embutido no Unix é necessário para poder interagir com os processos. Não vejo como um sistema com esses patches funcionaria sem a capacidade de usar sinais .

Aliás, os sinais operam no nível do processo. Não há nenhum método / API que conheço para injetar interrupções em chamadas do sistema diretamente.

Referências

• Quando e como as chamadas do sistema são interrompidas?

Answer 2

É claro que as interrupções podem interromper as chamadas do sistema, a menos que um spinlock apropriado seja executado ou as interrupções sejam desativadas de alguma outra forma:

• spin_lock_irq*() obtém um spinlock e desativa interrupções de hardware (e, consequentemente, também interrupção de software e processamento de tasklet).
• spin_lock_bh() obtém um spinlock e desativa o processamento de interrupções e tarefas de software.
• irq_disable() desativa as interrupções de hardware.
• local_bh_disable() desativa a interrupção de software e o processamento de tarefas.
• preempt_disable() desativa a preempção, que também é desativada por qualquer uma das opções acima.

Agora, em kernels não preemptivos, as tarefas não podem antecipar outras tarefas no modo kernel. Portanto, se você tiver a tarefa A fazendo uma chamada pesada do sistema em sua única CPU e a tarefa B precisar gravar alguns dados no dispositivo de áudio, a tarefa B pode precisar aguardar a tarefa A encerrar a chamada do sistema, resultando na queda de áudio um clique audível. Kernels preemptivos são para esse caso.