Visualizza Versione Completa : Sistemi operativi... come sono fatti?
Ciao a tutti,
ultimamente in un altro thread ci stavamo inoltrando sul discorso Sistemi Operativi. Mi rendo conto che, a volte, quando si entra nello specifico e si iniziano ad usare termini per così dire "tecnici" non sempre tutti ne sono a conoscenza o non sempre tali termini sono universalmente noti nello stesso modo.
Ho così pensato, visto che sono sistemista oltre che programmatore, di fornire, per chi fosse interessato, un pò di spiegazioni sui sistemi operativi, sul loro funzionamento teorico e quindi le loro implementazioni pratiche, almeno le più note.
Non ho nessuna intenzione di dire che X è meglio di Y, ma i confronti nasceranno naturalmente, per gli esseri umani è praticamente impossibile non confrontare direttamente due casi pratici assegnando dei ruoli. Se non altro, alla fine, almeno avremo le idee più chiare e partiremo tutti dagli stessi presupposti.
Iniziamo col dare una definizione di S.O.: "Un sistema operativo è l'insieme di servizi atti a rendere più agevole la comunicazione dei software applicativi con l'hardware sottostante".
In pratica il compito di un sistema operativo è quello di occuparsi di gestire l'hardware della macchina permettendo al software applicativo di occuparsi di altre cose. Questo non significa necessariamente che il software applicativo non deve conoscere l'hardware della macchina, semplicemente che chi programma non deve riscrivere ad esempio la routine per leggere un file dal disco fisso in quanto c'è già chi la scritta per lui e quindi sarebbe sciocco non adoperarla.
E' altresì vero che, un S.O. (Sistema Operativo), si occupa di gestire le risorse fisiche decidendo come distribuirle in modo, per così dire, sicuro.
Questo discorso era essenzialmente valido all'inizio, quando i computer erano grossi come stanze e facevano centinaia di operazioni al secondo. Col tempo l'informatica è divenuta un fenomeno di massa (o globalizzato) e la miniaturizzazione ci ha messo lo zampino. Risultato? Centinaia di componenti HW che fanno tutti la stessa cosa, ma di marche differenti, che comunicano con gli altri dispositivi ognuno secondo un proprio stile (i cosiddetti "protocolli"). Nel frattempo, però, non sono nati centinaia di S.O. ma in genere ve ne sono pochi che devono far funzionare, più o meno, tutto.
Così al S.O. è stato addebitato anche il compito di "astrarre" l'hardware. Ovvero far si che il software applicativo non debba più impegnarsi nel conoscere il tipo di hardware su cui gira, ma se il S.O. mette a disposizione una funzione che svolge un determinato compito deve limitarsi a chiamarla, sarà compito poi di quest'ultima eseguire il suo lavoro "al meglio".
In questo modo il S.O. prende letterlamente il controllo della macchina cercando di nasconderla del tutto al software applicativo e così se prima si poteva comunque optare per accedere, anche in modo rischioso, all'hardware in maniera diretta, ma magari in modo più efficiente, ora non si può fare altrimenti che adoperare le vie regolari. Soprattutto in un ambito denominato multitasking e che vedremo più avanti.
I sistemi operativi si dividono un due grandi categorie: Monotasking e Multitasking.
Un sistema si definisce monotasking quando permette l'esecuzione di un solo software applicativo alla volta. Per poter eseguire un altro software applicativo bisogna quindi terminare prima il software corrente e poi eseguire il nuovo. Il più famoso dei sistemi operativi monotasking è stato l'MS-DOS. Oggi tale tipo di sistema operativo sopravvive esclusivamente in ambito industriale per i compiti "mission critical". Il vantaggio di questo tipo di sistema era dato dal fatto che l'applicativo si impossessava completamente dell'hardware e quindi poteva farci sopra il bello e cattivo tempo. Lo svantaggio è dovuto al fatto che se devo trasportare delle informazioni da un applicativo ad un altro devo prima fare il lavoro sul primo, salvarlo, chiudere l'applicativo, aprire il secondo applicativo, aprire il file e quindi continuare il lavoro.
Si definisce un S.O. multitasking quando è in grado di eseguire, apparentemente o fattivamente, più programmi applicativi "contemporaneamente". Il virgolettato è d'obbligo in quanto la risorsa principale di un computer è il processore (dove per processore si intende il singolo core) e questo è comunque in grado di eseguire un'operazione alla volta (lasciamo un attimo da parte i processori paralleli). Quindi se ho due processori (o due core) al massimo il mio multitasking reale è in grado di eseguire due programmi contemporaneamente. Ma allora cos'è il multitasking? Un processore è in grado di eseguire miliardi, ormai, di operazioni al secondo, come il nostro cervello del resto, ma i tempi di reazione del nostro organismo, infinitamente più lenti, perchè più complessi, rendono il PC più veloce, ovvero lo mettono in uno stato di attesa relativo al nostro input. Si è così pensato di sfruttare questi tempi di attesa congelando il programma che in quel momento è aspetta i nostri ordini, per farne eseguire un altro e risvegliare il primo solo quando noi "comodamente" decidevamo di inviare la tanto agognata informazione. Osservando ulteriormente la situazione si è constatato che, in ogni caso, il numero di operazioni che è in grado di eseguire il computer era comunque ancora troppo elevato per due soli programmi. Si è pensato, quindi, di suddividere il tempo in fette (o timeslice) e di assegnare ad ogni singolo programma (denominato più correttamente processo) la sua bella fetta di tempo.
Pertanto se un processore è in grado di eseguire cento milioni di operazioni a secondo ed io divido un secondo per dieci timeslice ho, in modo molto grossolano ovviamente, la possibilità di eseguire fino a dieci processi in sequenza, ognuno dei quali può eseguire dieci milioni di operazioni prima di passare il controllo al successivo. Visti i normali tempi di reazione di un essere umano, a quest'ultimo sembrerà che i programmi vengano eseguiti tutti contemporaneamente. In questo caso però subentra un problema non da poco. Le risorse HW sono limitate, processori, RAM, disco fisso, VRAM, mentre ci sono molti pretendenti al loro utilizzo. In questo caso il S.O. assume oltre che il ruolo di astrazione anche quello di controllo e blocco delle risorse. In pratica se prima era sconsigliato ai software applicativi accedere alle risorse hardware, ora è, almeno in teoria, vietato. Vengono introdotti i meccanismi di gestione della memoria avanzati come lo spazio di indirizzamento privato, in pratica ogni programma vive all'interno di un suo spazio di memoria e non può uscire da esso ne può allargarlo senza il dovuto permesso. Può eventualmente comunicare con il mondo esterno (gli altri processi) ma solo sfruttando i meccanismi messi a disposizione dal S.O. senza alcuna possibilità di contravvenire a questa regola. Chi si ricorda di Amiga sa che una peculiarità di quel sistema operativo era quella di non avere, in teoria, indirizzi fissi, eccetto il 4, questo perchè un task (o processo) può essere caricato ogni volta in una porzione differente di memoria.
Logicamente partendo da quanto detto può sembrare che meno programmi girano e meglio è ed in effetti è così, questo perchè la timeslice assegnata ai singoli task è più ampia. Ma il meccanismo della rotazione ha i suoi svantaggi. Immaginate una fila di persone che deve prendere un medicinale ad uno sportello, ma non tutte le persone stanno male allo stesso modo quindi c'è chi deve prendere il medicinale più frequentemente e chi deve prenderlo meno frequentemente. Il meccanismo della rotazione (denominato tecnicamente "round-robin") non fa differenze, così avremo qualcuno che stara bene, qualcuno che soffrirà per mancata assunzione del medicinale e qualcuno che soffrirà per sovradosaggio. Lo sportellista (denominato "scheduler" o schedulatore) deve quindi valutare di volta in volta quando far tornare il paziente e fissa una specie di appuntamento, o meglio gli assegna una priorità dicendogli che anzichè tornare tra dieci persone potrà tornare tra tre. Questo è il meccanismo dei livelli di priorità. Un processo che ha necessità di maggiori cure, ovvero risorse, con maggior frequenza, può chiedere una priorità più alta, se possibile lo schedulatore la accorda, altrimenti dovrà rimettersi in fila normalmente. Va da se che nell'ambito del multitasking lo schedulatore è forse il processo in assoluto più importante di tutto il S.O. un bug al suo interno può portare a conseguenze devastanti.
E se succede un'emergenza o se il medicinale dev'essere assunto sotto sorveglianza? Nel tempo è stato tenuto conto di queste condizioni ed hanno creato le due principali branche del multitasking: il multitasking preempitivo e quello non-preempitivo.
Per spiegarli dobbiamo introdurre il concetto di livello di esecuzione. Immaginate un bersaglio delle frecce (quello a cerchi concentrici). Il livello più al centro è quello che da più punti, ma è anche quello che è più difficile da colpire. Tutti lo mirano, pochi ci riescono. Ecco immaginate che il cuore del S.O. (il da molti citato "kernel" o nocciolo) si trova lì (in realtà li si trova l'hardware, ma è un altro discorso). Mano mano che ci si allontana dal centro i punti e la difficoltà diminuiscono. I programmi applicativi si trovano nell'anello più esterno. Va da se che più all'esterno ci si trova più sono i passaggi che il nostro processo dovrà effettuare, in modo implicito, per eseguire un'operazione. Se il programma viene scritto secondo determinate regole, sempre più stringenti, può cercare di essere eseguito nei cerchi più interni, con indubbi vantaggi sulla priorità. Tornando al discorso dello sportello, in caso di emergenza è così possibile che una persona interrompa le normali procedure per avere una cura di emergenza e che il tutto venga ripristinato solo a cura completamente somministrata. Questo è il caso del multitasking non-preempitivo.
Ovvero un processo eseguito a livello più interno (riferendoci ai bersagli) non può assolutamente essere interrotto nella sua esecuzione da processi aventi livello più esterno, almeno fino a che il primo processo non rilascia esplicitamente il controllo. Ricadono in questa condizione tutti i processi di livello di sistema, quali quelli di accesso all'hardware o di sincronia. Va da se che se si scrive un programma in grado di girare a livello di sistema può impossessarsi della macchina bloccandola in quanto non può essere interrotto. Nel caso di multitasking non-preempitivo il livello di esecuzione è più importante della priorità.
Nei sistemi preempitivi (Windows 95/98/ME) semplicemente non esistono i livelli di esecuzione, in pratica esistono due cerchi il S.O. ed i programmi (e non sono neanche così ben definiti), per cui qualsiasi processo con un adeguato livello di priorità può prendere il sopravvento sugli altri.
Come conseguenza diretta del multitasking abbiamo avuto la multiutenza. Semplicemente i programmatori si sono chiesti, visto che gli umani sono così "lenti", possiamo permetterci di attendere più input, ognuno per uno specifico task, da più persone contemporaneamente, tanto il "server" sarà comunque più veloce. Da qui si è pensato di individuare prima con il termine "server" una sola macchina e poi un gruppo di macchine identificate logicamente come una singola macchina e denominate "cluster". Ma per chi fa grafica 3D il netrendering sa che è una disciplina a sé.
Negli ultimi anni la potenza dei PC è diventata letteralmente enorme, la loro capacità di lavorare anche in sinergia li ha resi ancora più incredibili e si è passati dalle centinaia, alle migliaia, ai milioni ed infine ai miliardi di operazioni al secondo, e la disponibilità di sistemi multiprocessore prima e multicore poi al grande pubblico non ha fatto altro che rimarcare ancora di più questa condizione.
I programmatori, sempre loro, sono partiti da una funzione di sistema di Unix (c'è sempre lui di mezzo) la "fork()", questa funzione permette di spezzare un processo in due e rendere i due processi indipendenti ma aventi alla base le stesse informazioni, o meglio uno riceve la copia delle informazioni dell'altro. Si sono chiesti e se invece di copiare le risorse le condividessero? Sono così nati i thread.
Cosa sono quindi i thread? Sono figli di un processo che condividono con quest'ultimo le stesse risorse (fisiche e temporali) e la stessa priorità e livello di esecuzione.
Quali sono i vantaggi? Beh in grafica 3D sono enormi, ed in genere in tutte quelle condizioni dove è possibile eseguire il calcolo parallelo. Ma anche in tutte quelle condizioni in cui lo stesso codice deve essere eseguito contemporaneamente, come ad esempio i server Web. Mi spiego meglio.
Come funziona un server web? Immaginate un centro informazioni che ha a disposizione una serie di opuscoli ed il cui compito e distribuirli su richiesta. Inizialmente le persone si mettevano in fila davanti allo sportello, ognuno faceva la sua richiesta, riceveva il suo opuscolo e se ne andava, quindi veniva il turno della persona successiva e si ricominciava.
Se si voleva rispondere a più richieste bisgnava aprire nuovi sportelli in tutto e per tutto identici al primo (si potrebbe dire clonati) col risultato si di andare più veloci, ma con aumento dei costi per gli stipendi (due persone costano più di una) e con la diminuzione dello spazio vitale in cui muoversi. Poi qualcuno ha detto: "Hei! Ma l'impiegato ha due mani! E se prendesse due opuscoli contermporaneamente?", a parte che se fosse uno statale e lavorasse in Italia l'impiegato avrebbe fatto sicuramente il gesto dell'ombrello, questi sono i thread.
Per ora mi fermo qui. A presto con il resto, sempre se vi fa piacere....
WOW!!! DEcisamente interessante! Seguo con molto piacere questa discussione... conoscere, anche solo a livello basilare, il S.O. potrebbe esserci utile per far "frullare" meglio i nostri macinini :D
Caspita, è stata proprio una bella lettura, immersiva e facile. Non vedo l'ora di leggere le differnze tra gli OS.
:clap:
Avrei qualche domanda su Unix, che mi ha da sempre incuriosito. Unix è un sistema utilizzato prevalentemente lato server e workstation, quali sono le sue peculiarità? Come ci si interfaccia, come client/administrator o ci sono anche delle frendly GUI (escluso il SO Linux)? E, quali sono le differenze principali tra i due sistemi Unix-like, Linux e BSD?
Caspita, è stata proprio una bella lettura, immersiva e facile. Non vedo l'ora di leggere le differnze tra gli OS.
:clap:
Avrei qualche domanda su Unix, che mi ha da sempre incuriosito. Unix è un sistema utilizzato prevalentemente lato server e workstation, quali sono le sue peculiarità? Come ci si interfaccia, come client/administrator o ci sono anche delle frendly GUI (escluso il SO Linux)? E, quali sono le differenze principali tra i due sistemi Unix-like, Linux e BSD?
Ciao,
le peculiarità di Unix (e più in generale dei sistemi operativi *nix) sono alla base della sua progettazione. E', in pratica, il primo S.O. multitasking a largo uso della storia. La cosa più importante è che non è un sistema operativo scritto in linguaggio macchina ma, a parte alcune trascurabili parti, scritto quasi completamente in C, in pratica è stato il primo S.O. scritto in un linguaggio di medio/alto livello (almeno per come definisco io il C), nato con l'idea della portabilità in mente e con il seme della modularità. Inoltre il C (linguaggio derivato dal BCPL) è stato creato proprio per scrivere Unix.
Il primo sistema ad adoperarlo è stato un PDP-7 per farci girare un gioco (all'anima del gioco, con questo termine all'epoca si identificavano i simulatori di volo adoperati dall'aviazione civile e militare degli USA). La sua evoluzione l'ha avuta poi su un PDP-11.
Era stato creato all'interno dei Bell Labs (poi in qualche modo fagocitati dalla AT&T) ed è stato il primo sistema operativo OpenSource (fino agli anni '80 i sorgenti erano pubblicamente disponibili, e le università degli stati uniti ne avevano una propria versione, la più famosa è poi divenuta la BeOS da cui è stato tirato fuori il sistema dei Next di Steve Jobs e su cui si basa OsX di Apple, che tra l'altro con Leopard ha avuto il riconoscimento di Sistema Operativo Unix Accreditato). Questo ha fatto si, anche perchè negli USA le spinte all'innovazione arrivano spesso dalle università, di divenire presto il primo sistema operativo multitasking non-preempitivo, multiuser, multithread e tra i più sicuri al mondo.
Linux ha seguito una strada un pò più tortuosa, appartiene anch'esso ai sistemi *nix ma non è derivato direttamente da Unix bensì dal progetto Minix (vi presi parte, in modo marginale, anche io). Verso l'inizio degli anni '90 si decise di riproporre Unix come sistema OpenSource, ma siccome era sotto Copyright un gruppo di volenterosi decise di riscriverlo da zero partendo dai documenti disponibili nell'allora nascente internet e morente Fidonet...
Venne così creato il sistema Minix. Tutti erano invitati a partecipare. Perfino la Jackson Libri pubblicò il S.O. (non il libro proprio il sistema). Tra le varie personalizzazioni quella che prese piede come diffusione fu quella di Linus Torwald, chiamata Linux.
Le GUI per gli Unix si sprecano, con Leopard la più usata è ora il Finder, ma in alternativa vi è OSF Motif (e devo dire, avendola programmata, che merita), la SCO aveva una sua versione per OpenServer, ed in genere tutte le WKS grafiche ne hanno una più o meno personalizzata (le Silicon Graphics hanno un cuore Unix e la propria interfaccia grafica).
In effetti le GUI non dovrebbero mai essere associate ad un S.O. ed in questo gli *nix sono perfettamente coerenti.
La prima a rendere l'interfaccia parte del S.O. è stata, ahimé, la Apple con Lisa prima ed il Macintosh poi. Poi è arrivata MS, con le sue fotocopiatrici a lastre distorte ed OS/2 (si OS/2 chi si aspettava che dicessi Windows?) ed è stato l'inizio della fine...
continuiamo con il discorso di prima:
Ho citato il Kernel, ma che cos'è?
Il kernel è l'insieme di tutte le funzioni principali del sistema operativo, è letteralmente il sistema operativo, tutto il resto sono semplici appendici.
Esistono due scuole di pensiero in proposito ai kernel. C'è quella che opta per un kernel monolitico e quella che opta per un link dinamico.
Vediamo le differenze, definiamo però cosa ci troviamo nel kernel.
In un kernel prendono posto tutte quelle funzionalità dedite alle seguenti attività:
- Schedulatore
- Gestione dei dispositivi (si sono inclusi anche i driver)
- Gestione delle risorse (RAM, Dischi Fissi)
- Processi di manutenzione, come il "garbage collector"
Per kernel monolitico si intende un unico modulo fisico, in cui è racchiuso tutto quanto descritto sopra. In generale il kernel monolitico è compilato ed ottimizzato sullo specifico hardware su cui viene eseguito, i vari componenti sono staticamente collegati tra di loro (in pratica so che lo schedulatore si troverà sempre nello stesso posto senza colpo ferire) e pertanto le prestazioni sono migliori. Svantaggi? Il kernel viene caricato completamente in memoria all'atto dell'avvio e la occupa sempre fino all'arresto del sistema. Pertanto possiamo dire addio ad una bella porzione di RAM, anche se ad onor del vero non è poi così tanta vista la quantità che oramai siamo abituati ad installare sui nostri sistemi, inoltre in caso di modifiche HW o di uno dei suoi componenti il Kernel va ricompilato e questa è sempre un'operazione rischiosa. Quando andrebbe usato? Sicuramente su tutti quei sistemi che richiedono elevate prestazioni, ma anche su quei sistemi che difficilmente cambiano il proprio HW, come i servers o le workstation. In genere un kernel monolitico si pappa tra i 64 ed i 128 MB di RAM (non memoria proprio RAM, poi scoprirete cosa intendo con questa sottile differenza quando parlerò degli indirizzamenti).
Di contro un kernel a link dinamico è il massimo della flessibilità, carica solo ciò che serve quando serve, i suoi componenti meno critici possono essere parcheggiati sulla memoria viruale, e nel caso di cambiamento di HW non va ricompilato. Svantaggi? E' lentooooo, ma tanto lento. Primo perchè i componenti, linkati dinamicamente, per poter essere richiamati bisogna fare ogni volta il calcolo di accesso, e poi perchè un programma applicativo mangiamemoria potrebbe richiedere l'uso di un componente che, magari per basso livello di priorità, viene parcheggiato sulla memoria virtuale e che quindi ogni volta dev'essere ricaricato.
Da un pò di tempo si sta affermando la scuola de "il giusto sta nel mezzo" ovvero il kernel è monolitico per le funzioni critiche, lasciando i componenti meno cruciali linkati dinamicamente (ad esempio i driver delle stampanti). I sistemisti Unix più sfegatati, che quindi possono decidere di intervenire direttamente sul kernel, spesso si spingono al punto di decidere cosa includere e cosa no nel blocco monolitico in base alla destinazione d'uso della macchina.
Le ultime versiondi di Windows seguono anche loro quest'ultimo approccio, prima erano un pò più dinamiche, è per questo che se prima cambiavate la piastra madre o il processore di un PC al massimo dovevate reinstallare i driver mentre ora vi compare il Blue Dead Screen. Il problema di Windows (ma per chi è un semplice utente che non vuole rivolgersi ad un sistemista scafato, va bene così) è che Microsoft ha deciso cosa inserire nel blocco monolitco e cosa no indipendentemente dalla destinazione d'uso della macchina (è per questo che esistono anche tante versioni di Windows Server 2003 e tra poco 2008).
La differenza tra un sistema operativo *nix e Windows sta principalmente in questo punto. Quando installo uno *nix posso, se voglio, adoperare un kernel compilato da me, in grado di adoperare le specifiche della mia macchina, comprese le istruzioni avanzate del processore, compilato magari con un compilatore ottimizzato per una data piattaforma. I progettisti Microsoft, non potendo rilasciare il codice sorgente, devono pertanto mandare in giro un kernel che è dato da un minimo comune multiplo dei sistemi per cui è stato progettato per girare. Pertanto se vi viene detto che Vista gira su tutti i pentium IV allora il kernel lavora con il set comune di istruzioni dei Pentium IV e degli Athlon, quindi addio estensioni proprietarie e pertanto vi è un calo di prestazioni. (E' come se oggi usassimo i dual core duo come dei sistemi pentium IV multiprocessore), va da se che anche caratteristiche specifiche come la cache e simili vengono ignorate.
Questa è appunto una delle più gravi accuse mosse dalla comunità internazionale nei confronti di MS, ovvero un finto avanzamento tecnologico proprio in virtù del fatto che i moderni processori non vengono sfruttati appieno dal nuovo S.O.
Apple dal canto suo è abbastanza fortunata, essendo produttore sia del software che dell'hardware può permettersi di mandare in giro kernel precompilati specifici per il tipo di processore che troverà il sistema all'atto dell'installazione. Inoltre il kernel di OsX è OpenSource (si chiama Darwin) e pertanto può essere addirittura compilato al volo durante l'installazione senza che Apple debba temere nulla...
Solferinom
06-02-08, 20:23
Molto, mooolto interessante. La tua capacità di spiegare processi complessi con parole semplici ed esempi alla portata di tutti è stupefacente. Perchè non scrivi un libro? Lo leggerei volentieri.
...A quando la prossima puntata?:yt:
Oggi ho parecchie cose da scrivere sul forum, speriamo di non crollare prima...
Prima ho parlato del kernel indicando in qualche modo di come esso gestisce la RAM ed in qualche modo di come la occupa.
Su un PC in generale abbiamo sentito tutti parlare di memoria virtuale, ma cosa è e come viene usata?
La memoria virtuale fu introdotta, indovinate un pò, con i sistemi Unix. In pratica i progettisti si resero conto che la memoria RAM, all'epoca costosissima, era effettivamente una risorsa troppo limitata come dimensione, soprattutto quando c'erano molti programmi in esecuzione contemporanea. Inoltre i processori erano già in grado di indirizzare una quantità di memoria ben superiore a quella generalmente disponibile su un computer medio. In compenso i dischi fissi si erano affacciati sul mercato e pertanto offrivano uno spazio di memoria decisamente più ampio. Il problema era la lentezza... Un disco fisso ragiona in termini di ms mentre la RAM lavora nei campo dei ns (nanosecondi). Come fare?
Parlando dei processi quando ho illustrato lo schedulatore ho detto che spesso un processo può essere congelato. Ma se è congelato è inutile fargli occupare memoria RAM, tanto vale spostarlo sulla memoria virtuale che risiede, sotto forma di partizione o file, sul disco fisso. E con esso anche il suo stack, il suo heap ove possibile, ed il program counter.
Ma come e quando fare tutto questo? Il quando è durante la fase di switching di processo, lo schedulatore valuta il livello di processo e può attivare le procedure di congelamento. Il come lo si ha eseguendo una mappatura settore disco/gruppo di indirizzi di memoria. I motorola 68000 e gli 80386 inoltre contenevano già dei metodi di indirizzamento che permettevano agevolmente di eseguire questa mappatura. L'idea sembra grandiosa, ma bisogna tenere conto di una serie di fattori. La memoria virtuale non dovrebbe essere mai superiore al doppio della memoria RAM fisica disponibile, pena un calo delle prestazioni, questo perchè la mappatura è trasparente anche al S.O. stesso e pertanto si rischierebbe di far risiedere un programma attivo, o una sua parte, sulla virtual memory. Va usata con parsimonia, ovvero, se il numero di scambi che avvengono tra memoria virtuale e memoria RAM è eccessivo è evidente che per le esigenze dell'utente la seconda è sottodimensionata oppure l'utente ha aumentato le sue necessità. E' per questo che in genere il primo consiglio che si da è di aumentare la RAM quando si vuole aumentare l'efficienza del proprio PC e solo in un secondo tempo il processore.
Esistono però dei processi che non possono essere spostati dalla memoria reale e sono quelli del kernel. Il kernel risiede sempre interamente nella memoria RAM, negli indirizzi fisici più bassi, non ci sono alternative, questo perchè dev'essere quello che deve garantire la massima efficienza, immaginatevi se per errore lo schedulatore finisse sulla memoria virtuale... tanto vale tornare all'MS-DOS. (Per comprendere appieno questo discorso bisogna però sapere come lavora un microprocessore, e come solo la memoria RAM, per la sua natura di accesso diretto, possa contenere un programma attivo, se vi interessa mi riprometto di spiegarlo più in là).
Quindi un kernel monolitico verrà caricato in memoria RAM e risiederà al suo interno fino allo spegnimento del sistema. Quindi se allestite un server di stampa va bene caricare il driver della stampante laser, in questo modo sarà sicuramente efficiente. Ma se fate un server Web, beh diciamo che è un pò uno spreco caricare lo stesso driver.
Sui sistemi *nix con kernel a link dinamico (parziale o totale) è possibile caricare i moduli del kernel in due separati momenti, durante la fase di avvio (detta init) o su richiesta. Alcuni moduli sono residenti (prendono il nome di demoni) e se non vengono eseguiti vengono spostati nella memoria di swap. Altri esistono solo durante la fase di esecuzione strettamente necessaria e quindi vengono completamente scaricati dalla memoria una volta eseguito il loro compito.
I sistemisti Windows hanno seguito un percorso differente, tutti i driver ed i moduli vengono caricati durante il boot e poi ci penserà lo schedulatore a decidere chi mandare nella memoria virtuale. E' per questo che quando si annuncia una nuova versione di windows si parla dei tempi di boot e shutdown, essi comprendono infatti la fase di caricamento dei moduli
e quella di (mamma chre brutto tempo) scaricamento ed è anche per questo che quando installate un nuovo driver è sempre necessario riavviare (in realtà questo succede anche sui sistemi Apple e su molti Linux, ma non necessariamente per tutti i driver, ad esempio è possibile caricare un driver di una scheda di rete ed attivarlo dopo il boot ed il sistema potrebbe adoperarlo senza riavviarsi, ma non è detto che tutti i moduli ne sentirebbero la presenza).
Come si è capito dopo la fase di gestione della sequenza dei processi, la gestione della memoria è il compito più delicato di un sistema operativo.
Ma come fa un processo a chiedere di usare la memoria? Essenzialmente non funziona in stile far west, non può dire le celle da X ad Y sono mie, perchè magari in quelle celle risiede un altro software applicativo o addirittura il kernel. Deve quindi fare il bravo bambino e chiedere al S.O. "Mi dai dieci celle per piacere?" se le celle ci sono allora tutto ok, altrimenti, peccato. Ma attenzione il problema non è ottenere le celle, quello è facile, il problema è restituirle. Il sistema operativo, in genere, tiene traccia della memoria non allocata, ma non di quella allocata e da chi, ho detto in genere e dopo vedremo il perchè. E' quindi compito del processo che ha allocato la memoria rilasciarla prima del termine della propria esecuzione, pena la perdita della memoria fino al successivo riavvio.
Prima ho però parlato del "garbage collector" che cos'è? Uno spazzino che tiene traccia della memoria allocata e da quale processo. E quando quest'ultimo termina la sua esecuzione, lo spazzino controlla che abbia rilasciato tutta la memoria e in caso negativo ne forza il rilascio.
Serve anche ad un'altra cosa, ma la vedremo più avanti.
Sembra grandioso vero? C'è solo un piccolo problema è per sua natura un processo pesante e che tende ad occupare memoria, inoltre non può essere spostato sulla memoria virtuale, in quanto la sua disponibilità dev'essere immediata (gira al centro del bersaglio, a livello system, quando parte nessuno può interromperlo). Di conseguenza non tutti sistemi lo implementano e sono pochi quelli che lo implementano del tutto.
Persino gli *nix sono divisi da questo punto di vista, alcune versioni lo montano di serie, altri ne usano una versione ridotta, altri non lo usano. Il vantaggio di Unix è che è però modulare, pertanto è possibile inserire un garbage collector nel kernel, anzi si può scegliere tra vari moduli, ognuno che lavora in modo differente rispetto agli altri (tra l'altro si può fare lo stesso anche con lo schedulatore, ce ne sono diversi ed ognuno privilegia un determinato approccio).
Windows, fino ad XP, non ha il garbage collector (e ti pareva), qualcosa si è visto con Vista (mamma), ma siamo ancora lontani.
Volete fare una prova per vedere se è vero? Prendete un programma che sapete come mandare in crash. Avviatelo, attivate il task manager (CTRL+SHIFT+ESC) e segnatevi la memoria usata. Mandate in crash il programma (non chiudetelo) e ricontrollate, troverete che la memoria non è stata liberata. In pratica non è stato attivato alcun sistema per il recupero della memoria. Se il programma prima di andare in crash ha avviato qualche meccanismo di rilascio risorse (tramite la gestione delle eccezioni) allora bene, altrimenti...
Il garbage collector ha anche un'altra funzione, forse la più importante, si occupa della deframmentazione della memoria. Tutti sapete cosa è la deframmentazione di un disco, o almeno così credo. Bene, sappiate che anche la memoria (RAM o virtuale che sia) necessita della stessa operazione di tanto in tanto (veramente abbastanza di frequente).
Questo perchè il S.O. quando alloca 10 celle consecutive su un gruppo di 100, ed alla fine le riottiene non le riunirà automaticamente ma creerà due gruppi uno di 10 celle ed uno di 90.
Sui *nix dove l'unità minima allocabile è una pagina (per cui se chiedete 10 celle e la pagina è di 64 celle, voi otterrete comunque 64 celle, ma ne vedrete 10, è anche vero che potrete sfruttare in qualche modo le altre 54, non vanno perse, ma attenzione DOVETE rilasciare le pagine non più usate) alla fine il problema è poco sentito, e si avverte soprattutto quando si allocano blocchi di memoria superiori ad una pagina (cosa che in genere non accade quasi mai, inoltre i sistemisti possono andare a definire, all'atto di compilazione del kernel, anche dimensioni di pagina differenti rispetto a quelle base), mentre su Windows dove la memoria allocata è effettivamente quella richiesta il problema della frammentazione c'è e si sente... soprattutto con la grafica.
Molto, mooolto interessante. La tua capacità di spiegare processi complessi con parole semplici ed esempi alla portata di tutti è stupefacente. Perchè non scrivi un libro? Lo leggerei volentieri.
...A quando la prossima puntata?:yt:
Ti ringrazio, troppo buono.
Una volta insegnavo programmazione e sistemi a scuola ed ho avuto un breve excurus nella facoltà di ingegneria di napoli (ingegneria areospaziale) dove mi occupavo di sviluppo di programmi per analisi interferometrica di immagini radar e di applicazioni di fluidodinamica e di gestire il CED basato su macchine Alpha della Digital (poi Compaq e poi HP).
Io il libro lo scriverei (in realtà ne sto scrivendo veramente uno relativo alla programmazione su OsX con XCode 3.0) ma il problema è chi lo pubblica...
Ciao, seguo con interesse anch'io, ma per evitare di dover esser costretti poi a ..."deframmentare" il topic, (:D) preferisco aspettare l'epilogo per porre qualche domanda in relazione a qualche mia perpelessità.
Vai come un treno Robè, :g1: (...ecco qualcuno che scrive più di me :D), ...complimenti anche per le tue capacità didattiche, ...come diceva un mio ex IP alla scuola di volo basico di Latina, "...spera che ti capiti uno che oltre a saper volare te lo sappia anche insegnare...", ed è proprio così, conoscere la materia non significa automaticamente saperla trasmettere, ...purtroppo.:rolleyes:
Mika ...ho l'impressione che ci sia altro materiale in arrivo per la serie "la collana del portale" :D
Fabio.
Ciao, seguo con interesse anch'io, ma per evitare di dover esser costretti poi a ..."deframmentare" il topic, (:D) preferisco aspettare l'epilogo per porre qualche domanda in relazione a qualche mia perpelessità.
Fabio.
Ciao Fabio,
Illustrare i concetti su cui si basa un sistema operativo è un lavoro abbastanza lungo, se hai qualche perplessità o domande ti conviene porle subito, eventualmente saranno riprese in seguito. Aspetto le tue richieste.
Caspita , interessante spetta non sono ancora riuscito a leggermi il terzo post che gia ne haib sparati giu altri tre , intanto bravo credo che questo chiarisca un po piu le idee:g1:.
Finora, probabilmente lo avrete notato, non ho praticamente mai citato l'utente ma solo i processi, parlando di S.O., come mai? Come fa l'utente ad adoperare un S.O.?
In realtà, stiamo parlando di teoria, l'utente non usa mai direttamente il S.O., si limita ad usare i programmi applicativi che, a loro volta, usano il sistema operativo.
Quando avviate un terminale su Linux o su OsX, oppure il prompt dei comandi da Windows, state non solo avviando il terminale, ma contemporaneamente anche un software applicativo denominato Shell.
Questa shell si occupa di ricevere i vostri comandi (sotto forma di parole o sigle) effettuare dei controlli e quindi se si tratta di comandi che è in grado di interpretare direttamente (gli script di shell o i comandi per settare le variabili d'ambiente) li lavora, altrimenti cerca il comando, sotto forma di file eseguibile, e lo avvia.
Il bello è che esistono tanti tipi diversi di shell, ognuno con la sua peculiarità, ma la cosa più interessante è che, essendo programmi applicativi, possono essere tutte presenti contemporaneamente nel sistema e possono essere avviate anche in parallelo tra di loro. Proprio in virtù del fatto che, non essendo integrate nel Kernel, non necessitano la sua ricompilazione per essere cambiate.
Questo, come è facile intuire, permette praticamente a chiunque di crearsi il proprio ambiente di lavoro ritagliato su misura.
Ora però abbandoniamo l'interfaccia a carattere, ci ritroviamo, quasi sempre, su di un ambiente più familiare, ci sono finestre, barre dei menu, mouse, icone. Bene anche tutto ciò per un sistema operativo è un programma (o un insieme di programmi in questo caso) applicativo e ricade anch'esso sotto il termine shell.
Esistono quindi due tipi di shell:
- CLI (Command Line Interface)
- GUI (Graphical User Interface)
Un sistema operativo le vede, entrambe, come come processi ben distinti, e questo è il vero vantaggio di quest'approccio. Vediamo perchè. Supponiamo che vi troviate nel caso in cui la GUI sia bloccata. Il fatto che essa lo sia non significa che lo è anche il S.O., anzi questo probabilmente starà facendo altre belle cose nel frattempo. Vi è però necessario spegnere la macchina in modo corretto (questo dovrebbe essere così sempre). Come procedete?
I S.O. permettono di avviare, in genere, sessioni multiple, sulla stessa macchina o anche remotamente, vi basta avviare tale sessione, entrando con un'altra shell, e quindi, tramite appositi comandi, potete decidere di ammazzare la shell bloccata (o il processo che la blocca) o fare semplicemente lo shutdown di tutto.
Questo è il primo e basilare meccanismo di sicurezza di tutti i Sistemi Operativi, i programmi applicativi possono sempre essere interrotti.
Fu per questo che quando ci furono Windows 95/98/Me la comunità internazionale chiedeva il multitasking non-preempitivo, proprio per garantirsi dalla possibilità di poter sempre interrompere un processo cattivo.
Su Linux le GUI si basano su un processo intermedio tra loro ed il kernel, nella sua attuale incarnazione si chiama XFree86, fornisce una serie di primitive per disegnare e gestire le finestre sullo schermo. il KDE, lo GNOME sono invece le specializzazioni grafiche di tali metodi. Introdurre una funzionalità nell'XFree la rende immediatamente disponibile su tutti gli ambienti che lo sfruttano, sarà poi compito loro adoperarla.
La GUI di OsX è il Finder con la sua personalizzazione Aqua, se chiamate la funzione dal menu mela per l'uscita forzata lo trovate li e se volete potete anche chiuderlo.
Sia su Linux che su OsX potete chiudere i processi relativi alle GUI, questo non significa che avete fermata il S.O. solo non potete più usare mouse e finestre.
Quali sono quindi i vantaggi? Il primo e più evidente è la robustezza e la sicurezza. Una shell non potrà mai bloccare il S.O., mai. Inoltre, su OsX non si potrebbe, insomma, ma su *nix si, se non devo usare mouse e tastiera e se non mi servono le finestre (ad esempio quando allestisco un server), posso decidere di non caricare la GUI ma optare per la CLI e quindi risparmiare un bel pò di risorse, sia in termini di RAM che in termini di impegno del processore.
GLi svantaggi? Beh se uso una GUI sui sistemi di questo tipo ho quello che chiamo effetto ovatta. In pratica il feedback relativo ad una nostra azione è leggermente più lento, quasi come se non fosse messo perfettamente a fuoco. E' come percepire la sensazione che la freccia del mouse che si muove sullo schermo sia ai nostri ordini, non una parte di noi.
Microsoft ha seguito un approccio leggermente differente, d'altronde si chiama Windows mica usix, ed ha preferito integrare la gestione della GUI all'interno del sistema operativo, o meglio ha reso alcuni processi della GUI in grado di girare a livello system (il centro del bersaglio). In effetti quando parliamo di Windows non siamo mai in grado di dire nettamente dove finisce il kernel e dove comincia la GUI, ed infatti la GUI di Windows si chiama Windows, ed il kernel? Windows!
Questo cosa comporta?
Prima i lati positivi: il feedback è, spesso, istantaneo, l'effetto ovatta è non percepibile, il mouse che si muove sullo schermo sembra effettivamente un'estensione del nostro corpo. Inoltre la possibilità di interagire con la grafica così a basso livello permette alle applicazioni performance migliori. Le DirectX sono a tutti gli effetti una parte del S.O. oramai da tempo, ed alcuni dei processi che ne fanno parte girano anch'essi a livello system, ecco quindi che giochi, modellatori ed altro offrono performance di tutto rispetto.
I lati negativi: la sicurezza e la stabilità, purtroppo, sono molto più basse dell'altro approccio. Vediamo il perchè: se eseguo una funzione della GUI a livello system, sapendo che non può essere interrotta, se tale funzione si blocca, allora tutto il sistema si blocca, irreparabilmente. Non posso neanche tentare di effettuare l'operazione di spegnimento o kill che ho descritto sopra, questo perchè il sistema sta eseguendo una funzione a livello system e non gli interessa nient'altro.
Ma anche se il sistema non si blocca posso farne crollare le prestazioni chiamando in modo molto frequente una funzione della GUI eseguita a livello system da un processo ad alta priorità in questo modo interrompo letteralmente il multitasking.
Inoltre se la GUI è parzialmente integrata nel kernel o comunque non è un processo ben definito a se stante, non posso fare a meno di caricarla. In pratica se allestico un server web (dove dell'interfaccia grafica non so che farmene) dovrò comunque rinunciare ad una bella fetta delle mie risorse che quindi non potranno essere sfruttate per servire gli utenti (in genere su un server Windows al boot mi gioco, senza colpo ferire e senza applicativi installati, anche 256 MB di memoria, quasi tutti assorbiti dalla GDI e dai driver precaricati). Da questo si evince che Windows non è nato con il concetto di multiutenza ma di s.o. multitasking monoutente e, anche se qualcuno stenterà a crederlo, è così anche per le versioni server.
Windows Server 2008 potrebbe introdurre una modalità di lavoro solo testo senza GUI. Ma per ora non posso ancora pronunciarmi, ne riparliamo a fine mese quando esce.
WOW ... spettacolo! :clap:
Ciao Roberto complimenti per l'iniziativa, stai praticamente scrivendo un libro online.
Avrei alcune domande relative ai kernel e linux che sono argomenti di cui mi piace leggere.
Ho letto che hai scritto che linux è una personalizzazione di minix ... quello che sapevo per letture varie è che il primo kernel di linux è stato riscritto con le specifiche posix, da Linus Torvald proprio perchè non era soddisfatto di minix ... è sbagliato ??
E inoltre non sono diversi i kernel dei due sistemi ?? Cioè linux utilizza un kernel monolitico mentre minix utilizza un microkernel, che non so cosa sia di preciso ma che sapevo essere due architetture differenti !! Infatti ci fu anche la storida discussione tra i due sviluppatori ...
La distinzione che hai fatto relativa ai tipi di kernel "monolitico" e a "link dinamico" è quella che in linux si fa compilando un kernel senza moduli oppure con moduli caricabili quando necessario ??
Ultima domanda :D ma Darwin non era un sistema operativo free ?? Il kernel del mc os x non si chiama XNU ??
Spero di non essere andato OT con le mie domande dato che i tuoi post sono molti tecnici e le mie domande più superficiali ... ma mi piace leggere ed essere informato su queste cose :)
Fulvio
EDIT: ... un'altimissima domanda ... quando parli di windows e del fatto che ha un kernel monilitico ... è questo il motivo per cui ogni vota che si installa un driver bisogna riavviare il sistema operativo ??
Grazie
Dunque Roberto, in linea di massima tutto chiaro escluso un punto sul quale torni spesso e che di fatto, dice esattamente il contrario di quello che ricordo io . Sicuramente sbaglierò io (e ci mancherebbe :D) essendo le mie solo riminiscenze, ma come "Amighista", conosco il significato della parola multitasking da molto tempo e quello che ricordo è che uno dei vantaggi del multitasking reso disponibile da Amiga all'epoca, era il fatto che si trattava di un vero e proprio multitasking, ma che sopratutto, si trattava di un multitasking di tipo "preemptive", ...mentre la "concorrenza" d'allora al limite poteva esser dotata di uno di tipo "cooperativo". Amiga disponendo poi anche di Chip Custom dedicati, poteva permettersi allora molti lussi, alcuni dei quali rimasero persino imbattuti, come ad esempio quello di poter aprire schermi multipli contenenti i vari task e poterli poi controllare come fossero delle normali finestre, o di poter eseguire in "parallelo" diverse operazioni, (ricordo che per ridimensionare "l'utenza avversaria", :D essenzialmente windows, bastava chiedere di formattare un Floppy Disk mentre si compiva un'altra operazione! :evil:). Il multitasking implementato in Amiga, (insieme ad altre caratteristiche pressochè uniche per quel periodo), consentiva alla macchina prestazioni interattive e multimediali impensabili per l'epoca sopperendo in seguito spesso anche a qualche carenza dell' HW quando questo divenne obsoleto permettendogli così una inusitata longevità. Un'ultima curiosità, anche il SO di Amiga discende da Unix e il sistema della memoria protetta causa di tanti Guru Meditation (http://upload.wikimedia.org/wikipedia/en/d/db/Guru_meditation.gif) :D che gli Amighisti ben ricordano, fu poi risolta in ritardo con la versione 4 di AmigaOS.
Da quello che avevo capito io allora quindi, i multitasking, (mi riferisco a quelli implementati nelle macchine dell'epoca), erano essenzialmente di due tipi:
- Quelli "Cooperativi", ossia dove lo scheduler non dispone di prelazione, nel qual caso questo può attuare un cambio di contesto solo nel caso del passaggio di un programma da uno stato all'altro, nello specifico, dallo stato di attesa (standby), a quello di esecuzione (run) e nel caso del termine del programma (end). Nel M.T. di tipo "cooperative", i processi cedono "automaticamente" il controllo al S.O. quando hanno espletato il loro compito. Questo sistema ha il vantaggio di non richiedere uno specifico supporto HW essendo quindi slegato dall'architettura della macchina su cui gira, ma al contempo ha il grave svantaggio che se uno di quei processi si blocca, o per un qualsiasi motivo comunque non ne cede il controllo, il rischio è la paralisi del sistema, in quanto il S.O. da solo non ha la capacità di riprenderne "le redini". Da quanto ne so questo sistema era adottato nelle versioni di Windows sino alla 3.1 e da MacOS sino alla versione 9.
- Quelli "Preemptivi", dove invece lo scheduler dispone delle capacità di prelazione, che sostanzialmente ricordo consistere nella capacità di interrompere un programma indipendentemente dalla disponibilità di quest'ultimo ad eseguire il comando. Questa capacità di prelazione consente sostanzialmente un cambio di contesto molto efficente con un conseguente miglior temporizzazione nelle applicazioni che da un punto di vista dell'utente si traduce anche in una maggior fluidità apparente fra i task. Perchè ciò sia possibile però, è necessario soddisfare determinati requisiti HW, senza i quali non possono attuarsi determinati automatismi che consentano il cambio di applicazione tramite "context switch". Il MT Preempitive ha quindi uno scheduler con delle possibilità in più, non solo quella di poter intervenire dal passaggio dallo stato di esecuzione a quello di attesa (come per il MT Cooperative), ma anche nel passaggio fra altri stati, ossia di quello di un programma dallo stato di esecuzione (run) allo stato di "pronto per essere eseguito" (RTR, Ready To Run) e dallo stato di attesa (standby) allo stato di pronto per essere eseguito (RTR).
Quello che non mi quadra quindi e che da ciò che dici, sembrerebbe essere un vantaggio avere un M.T. non-preempitivo, quando io ricordavo invece fosse giusto il contrario. Di certo ricorderò male io (e su questo non ho dubbi :D), ma visto che ci siamo approfitto della tua estrema disponibilità e competenza per togliermi anche questa curiosità.
Continua così! :g1:
Fabio.
Ciao Roberto complimenti per l'iniziativa, stai praticamente scrivendo un libro online.
Avrei alcune domande relative ai kernel e linux che sono argomenti di cui mi piace leggere.
Ho letto che hai scritto che linux è una personalizzazione di minix ... quello che sapevo per letture varie è che il primo kernel di linux è stato riscritto con le specifiche posix, da Linus Torvald proprio perchè non era soddisfatto di minix ... è sbagliato ??
E inoltre non sono diversi i kernel dei due sistemi ?? Cioè linux utilizza un kernel monolitico mentre minix utilizza un microkernel, che non so cosa sia di preciso ma che sapevo essere due architetture differenti !! Infatti ci fu anche la storida discussione tra i due sviluppatori ...
La distinzione che hai fatto relativa ai tipi di kernel "monolitico" e a "link dinamico" è quella che in linux si fa compilando un kernel senza moduli oppure con moduli caricabili quando necessario ??
Ultima domanda :D ma Darwin non era un sistema operativo free ?? Il kernel del mc os x non si chiama XNU ??
Spero di non essere andato OT con le mie domande dato che i tuoi post sono molti tecnici e le mie domande più superficiali ... ma mi piace leggere ed essere informato su queste cose :)
Fulvio
Ciao Fulvio,
hai decisamente centrato il problema per quanto riguard Linux. In effetti ho semplificato troppo io dicendo che Linux è una personalizzazione di Minix, in realtà Linus Torwalds lo riscrisse appunto secondo le specifiche Posix, ma la scintilla la lanciò proprio Minix con il suo tentativo di riscrivere un sistema Unix like in qualche modo OpenSource.
In realtà col tempo la visione del kernel monolitico di Torwalds si è sfaldata e vediamo il perchè.
Definizioni:
- Un kernel monolitico è un programma che implementa al suo interno, in un unico blocco la gestione dell'hardware sottostante (in pratica, ad esempio non fa uso di device drivers e pertanto se si cambia l'hardware va ricompilato)
- Un microkernel è invece un insieme di programmi (tipo macchine virtuali) che concorrono tutti insieme ad astrarre dall'hardware secondo determinate specifiche.
Quali sono dunque queste macchine virtuali? Sono tutte quelle che realizzano un'interfaccia tra il nucleo del sistema e l'hardware. Ad esempio i device driver delle schede video.
Uno dei più famosi sistemi operativi a microkernel era quello di Amiga.
Un altro microkernel (anche se non è corretto definirlo così) è XNU che è la base di Darwin che è il sistema operativo di Apple ovvero OsX senza il finder. Oggi si tende spesso a semplificare (lo so è scorretto, ma anche io ho pensato che era inutile scendere fin da subito nei dettagli di ogni singolo sistema operativo) e quando si parla di kernel di OsX lo si chiama Darwin.
Inoltre Darwin è rilasciato sotto licenza OpenSource, infatti ad ogni rilascio del sistema operativo Apple rilascia anche i sorgenti (si avete capito bene ci sono i sorgenti di Leopard disponibili). OpenDarwin è la branca completamente free di Darwin ed è nata dalla collaborazione tra Apple ed un bel gruppo di sviluppatori volenterosi (spesso, anzi, Apple ha beneficiato di questa politica, riducendo enormemente i costi).
In realtà XNU non è un microkernel completo ma un ibrido, esso è il risultato della fusione di due famosi kernel: Mach (microkernel) e FreeBSD (in un altro messaggio avevo scritto BeOS, chiedo scusa, sono un citrullo).
Quest'approccio, seguito da quasi tutti i sistemi operativi moderni (tra cui, anche se in maniera meno sbandierata, gli ultimi kernel linux, ed ecco dove ha fallito Torwald) consiste nel creare un blocco monolitico in cui risiedono tutte quelle funzioni hardware indipendent o che comunque presuppongono di trovare almeno determinati componenti (ad esempio lo schedulatore risiede qui), mentre si lascia decentrato, nella sezione esterna, tutto ciò che è hardware dipendent o comunque non critico (device driver ed altro).
Quindi, e rispondo così al tuo ultimo quesito, un kernel monolitico è quello senza moduli mente un microkernel è un kernel con caricamento di moduli separato (purchè indipendenti ed in qualche modo autosufficienti).
Ciao Fabio,
Non-Preempitivo e Cooperativo non sono la stessa cosa.
Cooperativo, come hai detto tu, significa che è il programma a scegliere quando cedere il controllo (in genere chiamando una funzione del sistema operativo).
Non-Preempitivo prevede il discorso del bersaglio. Ovvero solo i processi di livello più interno (in genere si tende a limitare il tutto a livello system ovvero di kernel) non possono essere interrotti. Ed il motivo è semplice, se avvio la scrittura di un settore del disco non posso essere interrotto, in nessun modo in quanto la risorsa è singola non condivisibile durante la fase di scrittura.
I processi a livello system (o kernel per semplificare) sono brevi, efficienti e sono quelli che accedono all'hardware ed in genere le risorse fisiche, per questo non sono interrompibili. Tutti i processi che non lavorano a questo livello invece si.
Il concetto di non preempitivo è quindi d'obbligo.
Il fatto di bloccare le interruzioni è fondamentale e vediamo il perchè:
Abbiamo detto che un un multitasking collaborativo prevede che i processi siano così buoni da rendersi conto di non esistere solo loro e quindi di tanto in tanto fanno respirare anche gli altri.
Un multitasking preempitivo invece prevede che sia il sistema operativo a decidere chi deve lavorare in un determinato istante. Ma come fa ad intervenire lo schedulatore in questo caso?
Lo schedulatore usa un hook (uncino) sull'interrupt del timer (Eh?).
In pratica il nostro hardware divide un secondo in 50 tick, ad ogni tick interrompe le normali operazioni ed esegue una routine di aggiornamento dell'orologio, tale operazione prevarica tutte le altre (in realtà in un determinato istante possono accadere più interrupt contemporaneamente tramite un meccanismo denominato livello viene stabilito l'ordine di esecuzione).
Lo schedulatore non fa altro che mettersi in coda alla routine di aggiornamento, così appena le termina inizia a lavorare lui.
In quel momento lui è "PATRONE TI MONTO" e tutti dipendono da ciò che vuole lui, è lui che "CONTROLLA IL PROGRAM COUNTER (BUA BUA BUA)".
Ora immagina che tu stia facendo la free() di una cella di memoria. Ed accade il "Mortal Interrupt" tu cosa fai lasci l'operazione a metà?
Se si tratta di pochi byte va pure bene, ma se stai deallocando 1 Mb allora la cosa diventa seria.
Ecco quindi che finchè non hai finito nessuno può interromperti. Dopo facessero quel che vogliono. Ecco a cosa serve il multitasking non preempitivo (ricordati che questo vale solo se esiste il concetto dei livelli nel S.O. altrimenti il concetto di non preempitivo non esiste).
(Per la cronaca sono un amighista anche io, lo programmavo, usavo il Lattice C originale, anzi forse sono l'unico in Italia ad aver montato su un Amiga 2000 il genlock e la scheda Janus AT, ed ancora oggi me lo piango quel sistema, in linea teorica con i dovuti adeguamenti hardware, darebbe la birra a tutti).
Piccola aggiunta:
Windows 3.1 - Cooperativo
Windows 95/08 - Preempitivo (senza livelli)
Windows NT/2000/... - Preempitivo per i programmi, non preempitivo per i processi del kernel.
Così forse sono più corretto.
Roberto
Ecco spiegato l'arcano, ...davo per scontato qualcosa che non lo era assolutamente :D, (però ...me lo sentivo che c'era un "terzo incomodo"), ...altrimenti le cose non "quagliavano"! Grazie per il chiarimento! :g1:
(Per la cronaca sono un amighista anche io, lo programmavo, usavo il Lattice C originale, anzi forse sono l'unico in Italia ad aver montato su un Amiga 2000 il genlock e la scheda Janus AT, ed ancora oggi me lo piango quel sistema, in linea teorica con i dovuti adeguamenti hardware, darebbe la birra a tutti).
No scusa, guarda ma qui pecchi di presunzione :D, ...ricorda che LWITA è una "tana d'Amighisti", ...:D e poi solo nella mia città ne conoscevo almeno 5 di utenti dotati di Amiga2000 e genlock + Janus+ HD (che lusso!!). Scherzi a parte, per conto mio posso dirti che son partito con un 500 gonfiato all'inverosimile (schede accelleratrici con 68020 e 30 espansioni di memoria etc..), per farmi poi tutto l'escursus sino ad Amiga4000 (anche questa super espansa) con 68040 e scheda grafica PicassoII e genlock esterno, c'havevo collegato di tutto e lavorando per studi professionali che adottavano sistemi analoghi al mio, ho utilizzato persino dei controller BCD (acquistato direttamente negli USA) per la registrazione della animazioni a passo 1 su Betacam, per il quale fummo costretti a editarci da soli tutti gli script di controllo... :evil: ...che tempi!
Mi fermo qui per non "inquinare" troppo (:D l'ho già fatto abbastanza), ...mi sento quasi un "virus" in questo bel topic.:rolleyes:
Fabio.
Grazie un miliardo...ke spettacolo:eek:...finalmente si inizia a capire perchè il povero windows sembra apparentemente meno performante
Corregimi se sbaglio...quindi i sistemi UNIX sono piu' stabili perchè dividono la GUI rendendola un applicativo, quindi si può sempre interrompere, mantenedndo il OS attivo...invece windows non ha questa divisione nette, risultando, a meno di blocchi e a parità di hardware, piu' performante...
Ho capito giusto o no...usando parole spicciole?
Complimenti, tu si che l'hai spremuto il "mostro", ancora oggi mi manca... io mi sono fermato al 3000.... Napoli era un mercato difficile per parlare di produzioni serie. Al massimo se ti andava bene usavi l'Amiga per i film dei matrimoni... (ed oggi è addirittura peggiorato, vabbè va).
Le notti insonni ed i mal di testa. Ti ricordi quando fu presentato il progetto per collerage i transputer (T818) all'amiga per la programmazione parallela?
Oggi ste cose non si vedono più....
In realtà col tempo la visione del kernel monolitico di Torwalds si è sfaldata e vediamo il perchè.
Definizioni:
- Un kernel monolitico è un programma che implementa al suo interno, in un unico blocco la gestione dell'hardware sottostante (in pratica, ad esempio non fa uso di device drivers e pertanto se si cambia l'hardware va ricompilato)
- Un microkernel è invece un insieme di programmi (tipo macchine virtuali) che concorrono tutti insieme ad astrarre dall'hardware secondo determinate specifiche.
Quali sono dunque queste macchine virtuali? Sono tutte quelle che realizzano un'interfaccia tra il nucleo del sistema e l'hardware. Ad esempio i device driver delle schede video.
....
...
Quindi, e rispondo così al tuo ultimo quesito, un kernel monolitico è quello senza moduli mente un microkernel è un kernel con caricamento di moduli separato (purchè indipendenti ed in qualche modo autosufficienti).
... ora mi è tutto chiaro. Non ci ero mai arrivato da solo !!
... e per il lato "storico" quindi linux è nato con una filosofia (monolitica) per poi cambiare direzione ... anche se ovviamente è sempre possibile compilare un kernel monolitico !!
Fulvio
Grazie un miliardo...ke spettacolo:eek:...finalmente si inizia a capire perchè il povero windows sembra apparentemente meno performante
Corregimi se sbaglio...quindi i sistemi UNIX sono piu' stabili perchè dividono la GUI rendendola un applicativo, quindi si può sempre interrompere, mantenedndo il OS attivo...invece windows non ha questa divisione nette, risultando, a meno di blocchi e a parità di hardware, piu' performante...
Ho capito giusto o no...usando parole spicciole?
Perfettamente Slade. E' esattamente questo il concetto.
Ricordati che in genere stabilità e velocità sono incompatibili (La fiabe della tartaruga e della lepre...)
Questo però vale se fai riferimento all'accesso ai dispositivi. Se invece parliamo di calcolo puro, ovvero le routine di calcolo di un punto nello spazio 3D, giusto per restare in tema, allora i sistemi si equivalgono. Anzi proprio per il fatto che puoi disattivare la GUI su una macchina *nix puoi risparmiarti tutte quelle interruzioni dovute al ridisegno dello schermo durante il tuo lavoro e pertanto la situazione si ribalta ed alla fine un server *nix, a parità di hardware, è più veloce e stabile dell'equivalente windows.
Immagina una renderfarm, essa è costituita da una serie di server collegati tra di loro (in genere si usano i blade con i rack collegati in fibra), durante la fase di rendering non hai uno schermo su cui visualizzare la progressione, ma in genere il risultato (frame per frame) viene depositato su una NAS.
Tramite una connessione di rete dal tuo PC (protocollo FTP o Samba) accedi alla cartella dove sono salvati i rendering e li vedi lo stato del lavoro.
In questo frangente ti rendi sicuramente conto che avere la GUI attiva non serve a nulla e pertanto visto che Linux può disattivarla e Windows no il primo risulta essere vincente.
... ora mi è tutto chiaro. Non ci ero mai arrivato da solo !!
... e per il lato "storico" quindi linux è nato con una filosofia (monolitica) per poi cambiare direzione ... anche se ovviamente è sempre possibile compilare un kernel monolitico !!
Fulvio
Ciao Fulvio,
in realtà il kernel monolitico non è tramontato ed il fatto che Linux ti permetta di scegliere l'approccio di compilazione è un enorme vantaggio.
In effetti se ti assembli un PC e cambi scheda video ogni 3 mesi allora il kernel monolitico è da scartare (a meno che non ti piaccia rischiare).
Se invece metti su una render farm allora quello da scartare è, probabilmente, il microkernel.
C'è da dire che le cose però non sono più tanto nette. L'introduzione di Quartz da parte di Apple (ovvero la possibilità di gestire la grafica non tramite il processore centrale ma tramite quello della scheda video) e l'equivalente tecnologia installata poi su Vista (non mi ricordo il nome, che figura) stanno iniziando a far pensare che la scelta del kernel ibrido sia la migliore, sempre. Anche su Linux stanno operando in questa direzione.
IMHO la vedo come la scoperta dell'acqua calda, l'Amiga faceva la stessa cosa con i suoi processori dedicati 20 anni fa...
Ciao Fulvio,
in realtà il kernel monolitico non è tramontato ed il fatto che Linux ti permetta di scegliere l'approccio di compilazione è un enorme vantaggio.
In effetti se ti assembli un PC e cambi scheda video ogni 3 mesi allora il kernel monolitico è da scartare (a meno che non ti piaccia rischiare).
Una volta che hai un kernel ottimizzato e cambi una scheda devi semplicemente aggiungere il modulo nuovo, ricompilare il tutto e pregare ...
Penso che la rottura di scatole maggiore sia la prima ricompilazione ... sbaglio ??
Fulvio
Complimenti, tu si che l'hai spremuto il "mostro", ancora oggi mi manca... io mi sono fermato al 3000.... Napoli era un mercato difficile per parlare di produzioni serie. Al massimo se ti andava bene usavi l'Amiga per i film dei matrimoni... (ed oggi è addirittura peggiorato, vabbè va).
Le notti insonni ed i mal di testa. Ti ricordi quando fu presentato il progetto per collerage i transputer (T818) all'amiga per la programmazione parallela?
Oggi ste cose non si vedono più....
E come se non me lo ricordo il famoso transputer (non vorrei allargarmi ma ...se non erro fu persino presentato un primo abbozzo di porting di AmigaOS)! ..." Oggi ste cose non si vedono più...", è proprio questo il punto, incredibilmente il "benessere informatico" ha portato una sorta di "appiattimento", dove nulla meraviglia più realmente (l'ultima cosa che mi ha un pò stupito è stata la tecnologia Surface quando fu introdotta, ma poi mica più di tanto). Una volta era lecito sognare, ...oggi mi domando chi lo faccia ancora visto che ormai è diventato superfluo o quasi.
...e l'equivalente tecnologia installata poi su Vista (non mi ricordo il nome, che figura)...forse ti riferisci ad "Aero"? Ad ogni modo nessuna "figura", ...con la quantità di nozioni che avrai in mente ci mancherebbe altro... :rolleyes:
...IMHO la vedo come la scoperta dell'acqua calda, l'Amiga faceva la stessa cosa con i suoi processori dedicati 20 anni fa...Parole sante, ...ma a dire il vero quest'ultima cosa è solo la punta dell'iceberg, in genere l'architettura di Amiga è da sempre stata "terreno di conquista" e fonte di ispirazione (in quanto cavia funzionante) per molte tecnologie poi approdate con un etichetta di "implementazione seria", ...negando la nel modo più assoluto qualsiasi attinenza con ciò che i denigratori hanno sempre bollato come "macchina da gioco". Ma chiudo qui perchè son cose che già sapete e non voglio ...infierire ulteriormente. :D
Una volta che hai un kernel ottimizzato e cambi una scheda devi semplicemente aggiungere il modulo nuovo, ricompilare il tutto e pregare ...
Penso che la rottura di scatole maggiore sia la prima ricompilazione ... sbaglio ??
Fulvio
In teoria è così, in pratica all'atto della compilazione devi assicurarti che l'interazione tra i moduli sia assolutamente compatibile, altrimenti rischi di pagare malfunzionamenti che magari emergono in la nel tempo.
Di solito si cerca di avere più copie del kernel con varie versioni dei moduli, in modo da poter tornare sempre indietro quando possibile.
Ad esempio in una società che adopera Linux come server per l'elaborazione di immagini per la videosorveglianza è successo che la MB che adoperavano di solito è uscita di produzione. Hanno così preso il modello successivo (dotato tra l'altro dello stesso chipset). Risultato? Hanno dovuto abbandonare il kernel monolitico in quanto i moduli relativi alla nuova piastra madre hanno difficoltà di funzionamento se linkati in modo statico con quelli dei framegrabber.
Sono i misteri della vita...
E come se non me lo ricordo il famoso transputer (non vorrei allargarmi ma ...se non erro fu persino presentato un primo abbozzo di porting di AmigaOS)! ..." Oggi ste cose non si vedono più...", è proprio questo il punto, incredibilmente il "benessere informatico" ha portato una sorta di "appiattimento", dove nulla meraviglia più realmente (l'ultima cosa che mi ha un pò stupito è stata la tecnologia Surface quando fu introdotta, ma poi mica più di tanto). Una volta era lecito sognare, ...oggi mi domando chi lo faccia ancora visto che ormai è diventato superfluo o quasi.
...forse ti riferisci ad "Aero"? Ad ogni modo nessuna "figura", ...con la quantità di nozioni che avrai in mente ci mancherebbe altro... :rolleyes:
Parole sante, ...ma a dire il vero quest'ultima cosa è solo la punta dell'iceberg, in genere l'architettura di Amiga è da sempre stata "terreno di conquista" e fonte di ispirazione (in quanto cavia funzionante) per molte tecnologie poi approdate con un etichetta di "implementazione seria", ...negando la nel modo più assoluto qualsiasi attinenza con ciò che i denigratori anno sempre bollato come "macchina da gioco". Ma chiudo qui perchè son cose che già sapete e non voglio ...infierire ulteriormente. :D
In realtà il benessere informatico è indotto, il problema è che la situazione si è diversificata. Venti anni fa se dicevi di voler studiare informatica ti guardavano storto, oggi se non sai usare un PC ti mandano al rogo...
La ricerca è comunque viva (logicamente non qui in Italia) ma i campi di applicazione sono così ampi che oggi le notizie bomba sono veramente poche.
Diciamo che chi ha avuto la possibilità di assistere a quanto è successo verso la metà degli anni 80, ha visto il carro iniziare a muoversi e quindi ha avuto modo di esclamare "OOOHHHHH" (Mi ricordo ancora quando nel 1991 allo SMAU vidi lo stand della NeXT con i cuboni esposti) oggi al massimo vede un'ombra sfrecciargli davanti ed a stento riesce s scansarsi...
Aero sfrutta appieno questa funzionalità, ma mi sembra che MS la avesse identificata con un altro nome...
In realtà la visione delle macchine da gioco è abbastanza cambiata da quegli anni, ora si sa che, anche grazie all'uso intensivo del 3D e delle routine della fisica e di intelligenza artificiale, se si vuole giocare ci vuole un mostro...
Il motivo per cui l'Amiga non decollò mai nel mondo professionale fu dovuto alla scempiaggine con cui alla Commodore gestirono l'aspetto commerciale. In tal proposito si narra un aneddoto che da l'idea di come la pensassero. Credo che in molti di voi abbiate visto "Star Trek IV: Rotta verso la terra", in una scena che Scotty che manovra dei PC (per essere precisi sono dei Macintosh) per mostrare la formula per l'alluminio trasparente. Ebbene in quella scena ci sarebbero dovuti essere degli Amiga, solo che la Commodore non volle mai accettare di darli in cambio di pubblicità ma pretese dei soldi (credo che all'epoca esistessero già i 3000), un bel pò. La produzione a quel punto chiese alla Apple la quale disse "SIIIIII".
Da quel momento ad hollywood nessuno chiese più a Commodore di usare i suoi PC...
...non vorrei rovinare questo capolavoro e non vorrei distrarti dai tuoi intenti seri ...però a quello Smau del 91 c'ero anch'io :yt: e come detto in altro topic, "campeggiavo" fra lo stand della Next e relativi Next-Cube e lo stand di Commodore Italia, chissà che non ci si sia persino incontrati :D
In effetti la maggior parte di chi ha un minimo d'esperienza in campo informatico sa che una macchina pensata per i videogiochi d'ultima generazione con buona probabilità potrà farci la stragande maggioranza delle "cose serie", ma per la grande massa, (specie d'una certa età), la richiesta tipo rimane "...vorrei un computer per mio figlio, niente d'impagnativo... tanto gli serve solo per giocare" :D ...vero è che a grado di informatizzazione siamo pur sempre fanalino di coda.
Nel discorso degli sbagli di Commodore "non mi ci ficco" premeditatamente, si son spesi fiumi di parlole in proposito e credo che onestamente ho già la responsabilità d'aver portato fuori dai binari la discussione, dico solo che personalmente, (a prescindere dalle indubbie colpe di mamma C), credo che anche se la gestione fosse stata diversa, tutt'al più oggi avremmo un "terzo polo" che nella più rosea delle previsioni potrebbe esser paragonata ad Apple (hai detto niente, ...lo so), ma riguardo il settore PC, la base d'installato dei compatibili Big Blue fece la differenza all'epoca e a prescindere di chi fossero stati i competitors, non "ce ne sarebbe stato" comunque per nessuno (....purtroppo, aggiungo). E' il guaio degli "standard de facto", ...non sono quasi mai degli standard per meritocrazia.
:yoo:
Fabio.
Grazie della precisazione...sto inparando un sacco di cose
Questo post me lo linko come "Enciclopedia OS":g1:, così me lo leggo con calma
Ciao e grazie del tuo lavoro
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.