O planejamento cooperativo suspende os processos quando eles executam uma operação de E / S?

Muitas referências de sistemas operacionais dizem que, com a multitarefa cooperativa (e não preventiva), um processo mantém a CPU até que ela se suspenda explicitamente. Se um processo em execução executa uma solicitação de E / S que não pode ser satisfeita imediatamente (por exemplo, solicita um pressionamento de tecla que ainda não está disponível), o agendador o suspende ou mantém realmente a CPU até que a solicitação possa ser atendida?

[Editado para substituir "blocos na E / S" por "executa uma solicitação de E / S que não pode ser satisfeita imediatamente."]

Em uma configuração verdadeiramente "cooperativa", e se não houvesse proteção de hardware, um processo certamente poderia bloquear a E / S e não abrir mão do controle até que a E / S estivesse concluída (ou nunca abrir mão do controle). Por exemplo, o Windows 3.1 era assim: se um único processo de usuário quisesse dominar todo o computador e impedir a execução de qualquer outra coisa, ele poderia.

Mas em um sistema com multitarefa, você espera que os comandos de E / S da API do sistema abandone o controle do processador quando eles são chamados. Portanto, quando um processo em execução é bloqueado na E / S, assumindo que o processo use as APIs normais do sistema, outros processos poderão ser executados até que a E / S seja concluída e, eventualmente, o processo original será retomado assim que a E / S for concluída. . Em outras palavras, chamar uma função de E / S de bloqueio é uma das maneiras pelas quais um processo em um sistema cooperativo pode se suspender voluntariamente.

Se um processo em execução bloquear na E / S

Bloquear IO é praticamente equivalente a suspender seu processo. No contexto do kernel do linux, a execução de alguma chamada do sistema de E / S, como read()fará com que um sysentermanipulador ou interrupção seja acionado para cuidar dessa E / S, chamando do_sys_read()finalmente. Aqui, se a solicitação atual não puder ser satisfeita imediatamente, a função chama sched()e, em seguida, pode executar outro processo.

No contexto de um sistema cooperativo, eu esperaria que, quando você fizer uma chamada de sistema por algum motivo de E / S, se a solicitação não puder ser atendida, o kernel escolherá outra tarefa e a executará. Este documento fornece alguns antecedentes - basicamente, se você esperou no IO, poderia ficar pendurado para sempre esperando por esse IO. A idéia do agendamento cooperativo é que você chama com frequência sched()ou o método equivalente de renunciar à CPU, se estiver executando tarefas que exigem muita CPU.

As considerações no modo kernel ficam mais interessantes. Nas arquiteturas em que estão disponíveis, como certas plataformas incorporadas , os manipuladores de interrupções ainda serão chamados em resposta a interrupções de hardware ou software. Geralmente, é possível, em termos de implementação, desativar o tratamento de interrupções , mas isso também tem desvantagens.

No cooperative multitaskingmodelo de agendamento cooperativo (preferencialmente ), não há conceito de agendador no sentido de que o sistema operacional não tenha controle de quanto tempo o processo é executado.

Um aplicativo programado corretamente desistiria voluntariamente da CPU na E / S. Mas, aplicativos mal escritos podem continuar aguardando E / S, bloqueando outros processos.

PS: Essa abordagem foi posteriormente adotada pela maioria do SO em favor do agendamento preventivo (que tinha um agendador externo) e agora temos todo tipo de algoritmo de agendamento usado por SO diferente.

EDIT: Minha resposta foi baseada no agendamento conforme descrito em sua forma original (anos atrás: P). Como Gilles comentou, alguns sistemas ainda usam agendamento cooperativo. E há um agendador. Não tenho certeza se esses sistemas usam o COS em sua forma pura e original.

A multitarefa cooperativa implica que um contexto de execução deve renunciar explicitamente ao controle do planejador e, se desejar, pode impedir a ocorrência de uma alternância de contexto.

A maioria das implementações executa explicitamente uma alternância de contexto para qualquer chamada do sistema que não retorne prontamente, e geralmente mesmo se retornar, para aumentar a imparcialidade da alocação do processador.

Geralmente, é possível apenas para processos com falha (ou negar intencionalmente o serviço ao restante do sistema) para impedir a alternância frequente de tarefas.

A preferência, conforme explicado por Gilles, é uma limitação da arquitetura do sistema que impede a interrupção temporizada da tarefa ativa e as alternâncias forçadas de contexto.