La pianificazione cooperativa sospende i processi quando eseguono un'operazione di I / O?

Molti riferimenti di sistemi operativi affermano che con il multitasking cooperativo (anziché preventivo), un processo mantiene la CPU fino a quando non si sospende volontariamente. Se un processo in esecuzione esegue una richiesta I / O che non può essere immediatamente soddisfatta (ad esempio, richiede un colpo di chiave non ancora disponibile), lo scheduler lo sospende o mantiene davvero la CPU fino a quando la richiesta non può essere soddisfatta?

[Modificato per sostituire "blocchi su I / O" con "esegue una richiesta I / O che non può essere immediatamente soddisfatta."]

In un'impostazione veramente "cooperativa", e se non vi fosse alcuna protezione hardware, un processo potrebbe certamente bloccare l'I / O e non rinunciare al controllo fino a quando l'I / O non è stato eseguito (o mai rinunciare al controllo). Ad esempio, Windows 3.1 era in questo modo: se un singolo processo utente voleva assumere il controllo dell'intero computer e impedire l'esecuzione di qualsiasi altra cosa, poteva farlo.

Ma su un sistema con multitasking ti aspetti che i comandi I / O dell'API di sistema abbandonino il controllo del processore quando vengono chiamati. Pertanto, quando un processo in esecuzione si blocca sull'I / O, presupponendo che il processo utilizzi le normali API di sistema, sarà consentito l'esecuzione di altri processi fino al completamento dell'I / O e alla fine il processo originale riprenderà al termine dell'I / O . In altre parole, chiamare una funzione I / O di blocco è un modo in cui un processo su un sistema cooperativo può sospendersi volontariamente.

Se un processo in esecuzione si blocca su I / O

Il blocco su IO è praticamente equivalente alla sospensione del processo. Nel contesto del kernel linux, l'esecuzione di alcune chiamate di sistema IO come ad esempio read()causerà l' sysenterattivazione di un gestore di interrupt o per occuparsi di tale IO, chiamando do_sys_read()infine. Qui, se la richiesta corrente non può essere immediatamente soddisfatta, la funzione chiama sched()che quindi può eseguire un altro processo.

Nel contesto di un sistema cooperativo, mi aspetto che quando si effettua una chiamata di sistema per qualche motivo di IO, se la richiesta non può essere soddisfatta il kernel sceglie un'altra attività ed esegue quella. Questo documento fornisce alcune informazioni di base: fondamentalmente, se si aspettava l'IO, si potrebbe essere appesi per sempre in attesa di quell'IO. L'idea della pianificazione cooperativa è quella che si chiama frequentemente sched()o il metodo equivalente rinuncia alla CPU, se si eseguono attività che richiedono molta CPU.

Le considerazioni sulla modalità kernel diventano più interessanti. Sulle architetture in cui sono disponibili, ad esempio alcune piattaforme integrate , i gestori degli interrupt verranno comunque richiamati in risposta a interruzioni hardware o software. Di solito è possibile, per quanto riguarda l'implementazione, disabilitare la gestione degli interrupt , ma ciò ha anche degli svantaggi.

Nel modello di pianificazione cooperativa (preferibilmente cooperative multitasking), non esiste un concetto di scheduler nel senso che il sistema operativo non ha alcun controllo sulla durata del processo.

Un'applicazione programmata correttamente rinuncerebbe volontariamente alla CPU in I / O. Tuttavia, le applicazioni scritte in modo errato potrebbero semplicemente continuare ad attendere sull'I / O, bloccando così altri processi.

PS: Questo approccio è stato successivamente abbandonato dalla maggior parte del sistema operativo a favore della pianificazione preventiva (che aveva un programmatore esterno) e ora abbiamo tutti i tipi di algoritmi di pianificazione diversi utilizzati da sistemi operativi diversi.

EDIT: La mia risposta si basava sulla programmazione come descritto nella sua forma originale (anni fa: P). Come ha commentato Gilles, alcuni sistemi utilizzano ancora la programmazione cooperativa. E c'è un programmatore. Non sono sicuro che tali sistemi utilizzino COS nella sua forma pura e originale.

Il multitasking cooperativo implica che un contesto in esecuzione deve rinunciare esplicitamente al controllo dello scheduler e, se lo desidera, può impedire il verificarsi di un cambio di contesto.

La maggior parte delle implementazioni esegue esplicitamente un cambio di contesto per qualsiasi chiamata di sistema che non ritorni prontamente, e spesso anche se lo fanno, per aumentare l'equità dell'allocazione del processore.

Di solito è possibile solo per processi falliti (o negare intenzionalmente il servizio al resto del sistema) per impedire frequenti cambi di task.

La prelazione, come spiegato da Gilles, è una limitazione dell'architettura del sistema che impedisce l'interruzione temporizzata dell'attività attiva e dei cambi di contesto forzati.