¿Cómo funciona la multitarea cooperativa?

Question

leí este Wikipedia text rebanada:

Debido a un sistema cooperativo multitarea se basa en cada proceso regular renunciar a tiempo a otros procesos en el sistema, un programa mal diseñado puede consumir todo el tiempo de CPU por sí mismo o hacer que todo el sistema se cuelgue.

Por curiosidad, ¿cómo renunciar a ese momento? ¿Es esto una especie de llamada al sistema operativo? Pensemos en casos no preventivos como fibras o IO con efecto que hacen multitarea cooperativa. ¿Cómo abandonan ese tiempo?

Tome este NodeJS ejemplo:

var fs = require('fs'); 
fs.readFile('/path/to/file', function(err, data) {}); 

Es obvio que el proceso no hace nada mientras está a la espera de los datos, pero ¿cómo V8 en este caso se dio por vencido el tiempo para otros procesos?

Supongamos que Linux/Windows es nuestro sistema operativo.

Editar: Descubrí cómo Google está haciendo esto con su V8.

En Windows que básicamente dormir tiempo cero:

void Thread::YieldCPU() { 
    Sleep(0); 
} 

Y en Linux que realizar una llamada de sistema operativo:

void Thread::YieldCPU() { 
    sched_yield(); 
} 

de sched.h.

Answer 1

Sí, cada programa participa en las decisiones de programación del sistema operativo, por lo que debe llamar a un syscall en particular que le indique al kernel que lo recupere. A menudo esto se llamó yield(). Si imagina lo difícil que es garantizar que se llame a una línea de código a intervalos regulares, cortos, o incluso en absoluto, se hace una idea de por qué la multitarea cooperativa no es una solución óptima.

En su ejemplo, el programador del sistema operativo interrumpe el motor javascript, si se trata de un sistema operativo preventivo. Si se trata de uno cooperativo, entonces no, el motor no funciona, y tampoco lo hace ningún otro proceso. Como resultado, tales sistemas generalmente no son adecuados para cargas de trabajo en tiempo real (o incluso graves).

Answer 2

Como regla general, la multitarea cooperativa implica las funciones que señalan que están esperando, en lugar de pasar a los bucles de rotación (donde procesan mientras esperan) se suspenden.

En este caso, el procesamiento detrás de ReadFile manejará la espera de datos y la señalización relevante de que es suspendible. Dentro de su propio código, sea lo que sea que esté escrito, debe suspender el procesamiento si está esperando un proceso prolongado, no giro. Sin embargo, en muchos casos, los procesos de suspensión se manejan automáticamente, porque las actividades de suspensión están integradas. El peligro en esto es que si forzas deliberadamente giros a largo plazo, entonces suspenderás el sistema.

La alternativa (de esa wiki) es la multitarea preventiva, donde el proceso se ve obligado a actuar después de un cierto tiempo, independientemente de lo que está haciendo. Esto significa que hagas lo que hagas, no puede ejecutarse para siempre, porque el proceso del sistema lo forzará.Sin embargo, puede ser menos eficiente ya que los puntos de quiebre no están definidos.

Answer 3

Un ejemplo de dicho sistema operativo es NetWare. En ese sistema, era necesario llamar a una función específica (creo que se llama ThreadSwitch o tal vez ThreadSwitchWithDelay). Y siempre fue una suposición sobre la frecuencia con la que se necesitaba. En cada bucle intensivo de CPU en el producto, era necesario llamar a una de esas funciones periódicamente.

Pero en ese sistema, otras llamadas darían lugar a que se ejecutaran otros subprocesos. En particular (y relacionado con la pregunta) es que las llamadas de E/S dieron como resultado que el sistema operativo tuviera la oportunidad de ejecutar otros hilos. Básicamente, cualquier llamada al sistema que diera control al sistema operativo era suficiente para permitir que se ejecutaran otros subprocesos (las llamadas mutex/semáforo son importantes).