¿La programación cooperativa suspende los procesos cuando realizan una operación de E / S?

Muchas referencias de sistemas operativos dicen que con la multitarea cooperativa (en lugar de preventiva), un proceso mantiene la CPU hasta que se suspende voluntariamente de forma explícita. Si un proceso en ejecución realiza una solicitud de E / S que no puede satisfacerse de inmediato (por ejemplo, solicita una pulsación de tecla que aún no está disponible), ¿el programador la suspende o realmente mantiene la CPU hasta que la solicitud pueda ser atendida?

[Editado para reemplazar "bloques en E / S" con "realiza una solicitud de E / S que no puede ser satisfecha de inmediato"]

En un entorno verdaderamente "cooperativo", y si no hubiera protección de hardware, un proceso ciertamente podría bloquear la E / S y no ceder el control hasta que se realizara la E / S (o nunca ceder el control). Por ejemplo, Windows 3.1 fue de esta manera: si un solo proceso de usuario quisiera apoderarse de toda la computadora y evitar que se ejecutara cualquier otra cosa, podría hacerlo.

Pero en un sistema con multitarea, se espera que los comandos de E / S de la API del sistema renuncien al control del procesador cuando se los llama. Por lo tanto, cuando un proceso en ejecución se bloquea en E / S, suponiendo que el proceso utiliza las API normales del sistema, se permitirá que se ejecuten otros procesos hasta que se complete la E / S, y finalmente el proceso original se reanudará una vez que se haya completado la E / S . En otras palabras, llamar a una función de bloqueo de E / S es una forma en que un proceso en un sistema cooperativo puede suspenderse voluntariamente.

Si un proceso en ejecución se bloquea en E / S

Bloquear en IO es prácticamente equivalente a suspender su proceso. En el contexto del kernel de Linux, la ejecución de alguna llamada al sistema IO como read()causará que un sysentercontrolador de interrupción se active para cuidar de ese IO, llamando en do_sys_read()última instancia. Aquí, si la solicitud actual no puede ser satisfecha de inmediato, la función llama sched()y luego puede ejecutar otro proceso.

En el contexto de un sistema cooperativo, esperaría que cuando realiza una llamada al sistema por algún motivo de E / S, si no se puede satisfacer la solicitud, el kernel elige otra tarea y la ejecuta. Este documento proporciona algunos antecedentes: básicamente, si esperaba en IO, podría estar colgado para siempre esperando ese IO. La idea de la programación cooperativa es que usted llama con frecuencia sched()o el método equivalente de renunciar a la CPU, si realiza tareas intensivas de CPU.

Las consideraciones del modo kernel se vuelven más interesantes. En las arquitecturas donde están disponibles, como ciertas plataformas integradas , los controladores de interrupciones aún se invocarán en respuesta a interrupciones de hardware o software. Por lo general, es posible, en términos de implementación, deshabilitar el manejo de interrupciones , pero eso también tiene inconvenientes.

En el cooperative multitaskingmodelo de programación cooperativa (preferiblemente ), no existe el concepto de un planificador en el sentido de que el sistema operativo no tiene ningún control sobre cuánto tiempo se ejecuta el proceso.

Una aplicación programada correctamente cedería voluntariamente la CPU en E / S. Pero, las aplicaciones mal escritas podrían seguir esperando E / S, bloqueando así otros procesos.

PD: Este enfoque fue abandonado por la mayoría del sistema operativo en favor de la programación preventiva (que tenía un programador externo) y ahora tenemos todo tipo de algoritmos de programación diferentes utilizados por diferentes sistemas operativos.

EDITAR: Mi respuesta se basó en la programación como se describe en su forma original (hace años: P). Como comentó Gilles, algunos sistemas aún utilizan la programación cooperativa. Y hay un planificador. No estoy seguro de si esos sistemas usan COS en su forma pura y original.

La multitarea cooperativa implica que un contexto en ejecución debe ceder explícitamente el control al planificador y, si lo desea, puede evitar que ocurra un cambio de contexto.

La mayoría de las implementaciones realizan explícitamente un cambio de contexto para cualquier llamada al sistema que no regrese rápidamente, y a menudo incluso si lo hacen, para aumentar la imparcialidad de la asignación del procesador.

Por lo general, solo es posible que los procesos fallidos (o que nieguen intencionalmente el servicio al resto del sistema) eviten el cambio frecuente de tareas.

La opción preferente, como explica Gilles, es una limitación de la arquitectura del sistema que evita la interrupción temporizada de la tarea activa y los cambios de contexto forzados.