Come ha funzionato il multitasking UNIX senza memoria virtuale? [chiuso]


7

Come ha funzionato il multitasking UNIX senza memoria virtuale? Le applicazioni non avrebbero ancora bisogno del loro spazio di memoria? O le applicazioni dovevano sapere che ora tutta la memoria visibile spaziata è la loro?

(Nota per evitare confusione: per "memoria virtuale" intendo la memoria virtualizzata, NON il file di scambio.)


"come ha fatto"? o forse "come funziona" o "come può"?
James T Snell,

Esistono sistemi Unix attuali che non usano la memoria virtuale? Il runtime C lo supporta?
Andrew J. Brehm,

@Andrew alcuni sistemi embedded MOLTO limitati funzionano senza VM (più precisamente senza MMU), vedi ad esempio uCLinux. Tuttavia, i sistemi non mmu non sono conformi a POSIX, quindi immagino che potresti dire che tecnicamente non sono un Unix ...
crasic

1
@sawdust Questo link in realtà spiega come uClinux esegue diversi processi senza VM! Eccellente.
Andrew J. Brehm,

1
C'è anche questo : "Nei sistemi segmentati come Multics (1964), il codice è intrinsecamente indipendente dalla posizione, poiché gli indirizzi in un programma sono relativi al segmento corrente piuttosto che assoluto".
Utku,

Risposte:


2

Il multitasking e il multiprocessing possono essere realizzati su computer che non dispongono di un'unità di gestione della memoria (MMU) per fornire memoria virtuale. Esistono molti sistemi operativi che supportano il multitasking e / o il multiprocessing per i processori che non dispongono di una MMU. Non so quando Unix ha utilizzato la memoria virtuale.

Esistono altri requisiti hardware oltre alla memoria virtuale di cui Unix ha bisogno per implementare le sue funzionalità multiprocessore. La chiave è la modalità protetta o supervisore della CPU, ovvero la modalità kernel rispetto alla modalità utente.

Esistono sistemi Unix attuali che non usano la memoria virtuale?

Presumo che tutte le versioni moderne di Unix utilizzino una MMU.

uClinux è una versione di Linux che non richiede una MMU e non utilizza memoria virtuale. Ma non aspettarti lo stesso livello di sicurezza tra i processi come con Linux reale. È un sistema operativo per dispositivi integrati per l'esecuzione di programmi applicativi attendibili.

Il runtime C lo supporta?

Il linguaggio di programmazione C non è legato a Unix o Linux. Né richiede memoria virtuale. C può essere utilizzato per programmare microcontrollori a 8 bit. Una libreria di runtime è specifica per una versione di un sistema operativo e un compilatore. Esistono versioni della libreria di runtime C per uClinix per processori che non dispongono di MMU.


Per essere chiari, avere la MMU in hardware è un'innovazione relativamente recente (sulla scala temporale di unix). Non c'è nulla che ti impedisca di far eseguire la traduzione dell'indirizzo al sistema operativo (anche se sarà molto più lento di una soluzione hardware). Anche se hai ragione, ciò richiederebbe che la CPU supporti le modalità di esecuzione.
crasic

Quando ho detto "runtime C" intendevo quello (i) usato da Unix (e cloni).
Andrew J. Brehm,

4

Versioni precedenti di Unix multitasking tramite scambio. Quando un'attività ha raggiunto un punto di blocco (in attesa di una lettura, ad esempio), viene scambiata su disco e un'altra attività sostituita.

Fondamentalmente un'attività alla volta potrebbe essere in memoria e tutte sono state mappate sullo stesso set di posizioni di memoria.

"Fork" (avvia una nuova attività secondaria) è stato realizzato semplicemente sostituendo l'attività corrente, quindi assegnando un nuovo ID attività all'immagine dell'attività ancora in memoria e facendola continuare a funzionare (come attività secondaria "biforcata").

Questo approccio (l'originale Bell Unix) era semplice e ha funzionato abbastanza bene su hardware primitivo, ma Berkley Unix ha sfruttato l'hardware di mappatura della memoria nei processori più recenti per consentire a più attività di essere simultaneamente in memoria, trasformandosi lentamente in uno schema di memoria virtuale completo.

(Non so quale schema utilizza Linux.)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.