Qué programación cooperativa suspender los procesos cuando se realiza una operación de E / S?

Question

Muchos sistemas operativos referencias dicen que con cooperativo (en contraposición a preventivo) multitarea, un proceso mantiene la CPU hasta que explícitamente suspende voluntariamente. Si un corredor lleva a cabo el proceso una solicitud de E / S que no puede ser satisfecha de inmediato (por ejemplo, pide un golpe de tecla que todavía no está disponible), ¿el planificador suspenderlo, o ¿realmente mantener la CPU hasta que la petición puede ser atendida

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

Answer 1

En un entorno verdaderamente "cooperativa", y si no había protección de hardware, un proceso sin duda podría bloquear en la I / O y no el control relinquish hasta que la E / S se realiza (o nunca el control relinquish en absoluto). Por ejemplo, Windows 3.1 fue de esta manera: si un solo proceso de usuario quería hacerse cargo de todo el equipo, y evitar que cualquier otra cosa que se ejecute, es posible.

Sin embargo, en un sistema con múltiples tareas que esperan que la API del sistema de E / S comandos para el control relinquish del procesador cuando se les llama. Así que cuando un corredor bloques de proceso de E / S, en el supuesto de que el proceso utiliza las API normales del sistema, otros procesos se pueden ejecutar hasta que la E / S se ha completado, y, finalmente, el proceso original se reanudará una vez que la E / S que se hace . En otras palabras, llamando a una función de bloqueo de E / S es una manera de que un proceso en un sistema cooperativo puede suspender voluntariamente.

Answer 2

Si un corredor bloques de proceso de E / S

El bloqueo de IO es más o menos equivalente a la suspensión de su proceso. En el contexto del núcleo de Linux, ejecutando alguna llamada al sistema IO como read() causará una sysenter o manejador de interrupciones de gatillo para cuidar de que IO, llamando do_sys_read() en última instancia. Aquí, si la petición actual no puede ser satisfecha de inmediato, la función llama sched() que luego puede ejecutar otro proceso.

En el contexto de un sistema cooperativo, yo esperaría que cuando se hace una llamada al sistema por alguna razón IO, si la petición no puede ser satisfecha las selecciones del kernel otra tarea y la ejecuta. Este documento proporciona algunos antecedentes - básicamente, si se espera en IO, usted podría ser colgado siempre a la espera de que la IO. La idea de la programación cooperativa es que usted llama con frecuencia sched() o el método relinquish-la-cpu equvalent, si el hacer tareas intensivas de la CPU.

consideraciones de modo de núcleo se ponen más interesantes. En arquitecturas donde están disponibles tales como ciertas plataformas integradas , interrupciones manipuladores todavía serán invocadas en respuesta a interrupciones de hardware o software. Por lo general es posible, en cuanto a la aplicación, a desactivar interrupt manejo , pero que también tiene inconvenientes.

Answer 3

En la programación de cooperación (preferiblemente cooperative multitasking) modelo, no existe el concepto de un planificador en un sentido que el sistema operativo no tiene ningún control de tiempo durante el que se ejecuta el proceso.

aplicación

Un programado correctamente daría voluntariamente a la CPU en la I / O. Sin embargo, las aplicaciones mal escritos podrían simplemente seguir esperando en E / S, bloqueando de esta manera otros procesos.

PS:. Este enfoque fue dada más tarde por la mayor parte del sistema operativo a favor de la preventiva-programación (que tenía un programador externo) y ahora tenemos todo tipo de diferentes algoritmos de planificación utilizados por los diferentes sistemas operativos

EDIT: Mi respuesta se basa en la programación como se describe en su forma original (hace años: P). Como se comentó Gilles algunos sistemas todavía utilizar la planificación cooperativa. Y hay un planificador. No estoy seguro de si esos sistemas utilizan COS en su forma pura y original.

Answer 4

multitarea cooperativo implica que un contexto de ejecución deberá controlar de forma explícita renuncian al programador, y si lo desea, puede impedir que un cambio de contexto que se produzcan.

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

Por lo general, sólo es posible para los procesos fallidos (o negar intencionalmente servicio al resto del sistema) para evitar frecuentes tareas de conmutación.

preferente de compra, como se explica por Gilles, es una limitación de la arquitectura del sistema que impide cronometrados interrupción de la tarea activa y cambios de contexto forzado.