Vedi: Comprensione del kernel Linux , 3a edizione di Daniel P. Bovet, Marco Cesati
- Editore: O'Reilly
- Data pub: novembre 2005
- ISBN: 0-596-00565-2
- Pagine: 942
Nella loro introduzione, Daniel P. Bovet e Marco Cesati hanno dichiarato:
Tecnicamente parlando, Linux è un vero kernel Unix, sebbene non sia un sistema operativo Unix completo, perché non include tutte le applicazioni come utilità per filesystem, sistemi di finestre e desktop grafici, comandi di amministratore di sistema, editor di testo, compilatori e così via su. Ciò che leggi in questo libro e vedi nel kernel di Linux, quindi, può aiutarti a capire anche le altre varianti di Unix.
Nei prossimi paragrafi, cercherò di indirizzare i tuoi punti di vista basandomi sulla mia comprensione dei fatti presentati in "Comprensione del kernel Linux" che è in larga misura simile a quelli di Unix.
Cosa significa un processo? :
I processi sono come esseri umani, sono generati, hanno una vita più o meno significativa, facoltativamente generano uno o più processi figlio e alla fine muoiono. Un processo ha cinque parti fondamentali: codice ("testo"), dati (VM), stack, file I / O e tabelle dei segnali
Lo scopo di un processo nel kernel è di agire come un'entità alla quale sono allocate le risorse di sistema (tempo della CPU, memoria, ecc.). Quando viene creato un processo, è quasi identico al suo genitore. Riceve una copia (logica) dello spazio degli indirizzi del genitore ed esegue lo stesso codice del genitore, a partire dall'istruzione successiva a seguito della chiamata di sistema per la creazione del processo. Sebbene il genitore e il figlio possano condividere le pagine contenenti il codice del programma (testo), hanno copie separate dei dati (stack e heap), in modo che le modifiche del figlio in una posizione di memoria siano invisibili al genitore (e viceversa) .
Come funzionano i processi?
Un programma in esecuzione ha bisogno di qualcosa di più del semplice codice binario che dice al computer cosa fare. Il programma ha bisogno di memoria e varie risorse del sistema operativo per funzionare. Un "processo" è ciò che chiamiamo un programma che è stato caricato in memoria insieme a tutte le risorse necessarie per operare. Un thread è l'unità di esecuzione all'interno di un processo. Un processo può avere ovunque da un solo thread a molti thread. All'avvio di un processo, vengono assegnati memoria e risorse. Ogni thread nel processo condivide tale memoria e risorse. Nei processi a thread singolo, il processo contiene un thread. Il processo e il thread sono la stessa cosa e sta succedendo solo una cosa. Nei processi multithread, il processo contiene più di un thread e il processo sta realizzando più cose contemporaneamente.
La meccanica di un sistema multi-elaborazione include processi leggeri e pesanti:
In un processo pesante, più processi funzionano insieme in parallelo. Ogni processo pesante in parallelo ha il proprio spazio di indirizzi di memoria. La comunicazione tra processi è lenta poiché i processi hanno indirizzi di memoria diversi. Il cambio di contesto tra processi è più costoso. I processi non condividono la memoria con altri processi. La comunicazione tra questi processi implicherebbe meccanismi di comunicazione aggiuntivi come prese o tubi.
In un processo leggero, chiamato anche thread. I thread vengono utilizzati per condividere e dividere il carico di lavoro. I thread usano la memoria del processo a cui appartengono. La comunicazione tra thread può essere più veloce della comunicazione tra processi perché i thread dello stesso processo condividono la memoria con il processo a cui appartengono. di conseguenza la comunicazione tra i thread è molto semplice ed efficiente. Il cambio di contesto tra thread dello stesso processo è meno costoso. I thread condividono la memoria con altri thread dello stesso processo
Esistono due tipi di thread: thread a livello utente e thread a livello di kernel. I thread a livello utente evitano il kernel e gestiscono il lavoro da soli. I thread a livello utente hanno il problema che un singolo thread può monopolizzare l'intervallo di tempo, facendo morire di fame gli altri thread all'interno dell'attività. I thread a livello di utente sono generalmente supportati sopra il kernel nello spazio utente e sono gestiti senza il supporto del kernel. Il kernel non sa nulla dei thread a livello di utente e li gestisce come se fossero processi a thread singolo. Pertanto, i thread a livello utente sono molto veloci, funziona 100 volte più velocemente dei thread del kernel.
I thread a livello di kernel sono spesso implementati nel kernel usando diverse attività. In questo caso, il kernel pianifica ogni thread all'interno della finestra temporale di ogni processo. In questo caso, poiché il segno di spunta determina i tempi di commutazione, è meno probabile che un'attività esegua l'interruzione della sequenza temporale dagli altri thread all'interno dell'attività. I thread a livello di kernel sono supportati e gestiti direttamente dal sistema operativo. La relazione tra thread a livello di utente e thread a livello di kernel non è completamente indipendente, in effetti esiste un'interazione tra questi due livelli. In generale, i thread a livello di utente possono essere implementati utilizzando uno dei quattro modelli: molti-a-uno, uno-a-uno, molti-a-molti e modelli a due livelli. Tutti questi modelli associano thread a livello di utente a thread a livello di kernel e causano un'interazione in gradi diversi tra i due livelli.
Discussioni vs. Processi
- Il programma inizia come un file di testo con codice di programmazione,
- Il programma è compilato o interpretato in forma binaria,
- Il programma viene caricato in memoria,
- Il programma diventa uno o più processi in esecuzione.
- I processi sono in genere indipendenti l'uno dall'altro,
- Mentre i thread esistono come sottoinsieme di un processo.
- I thread possono comunicare tra loro più facilmente di quanto possano fare i processi,
- Ma i thread sono più vulnerabili ai problemi causati da altri thread nello stesso processo
Riferimenti:
Comprensione del kernel Linux, terza edizione
Altro 1 2 3 4 5
...............................................
Ora, semplifichiamo tutti questi termini ( questo paragrafo è dalle mie prospettive ). Il kernel è un'interfaccia tra software e hardware. In altre parole, il kernel si comporta come un cervello. Manipola una relazione tra il materiale genetico (cioè i codici e il suo software derivato) e i sistemi del corpo (cioè hardware o muscoli).
Questo cervello (cioè il kernel) invia segnali a processi che agiscono di conseguenza. Alcuni di questi processi sono come i muscoli (cioè i fili), ogni muscolo ha la sua funzione e il suo compito, ma tutti lavorano insieme per finire il carico di lavoro. La comunicazione tra questi fili (cioè i muscoli) è molto efficiente e semplice, quindi svolgono il loro lavoro in modo regolare, rapido ed efficace. Alcuni dei fili (cioè i muscoli) sono sotto il controllo dell'utente (come i muscoli delle mani e delle gambe). Altri sono sotto il controllo del cervello (come i muscoli del nostro stomaco, degli occhi, del cuore che non controlliamo).
I thread dello spazio utente evitano il kernel e gestiscono le attività stesse. Spesso questo si chiama "multitasking cooperativo", e in effetti è come le nostre estremità superiori e inferiori, è sotto il nostro controllo e lavora tutti insieme per raggiungere il lavoro (cioè esercizi o ...) e non ha bisogno di ordini diretti da il cervello. Dall'altro lato, i thread di Kernel-Space sono completamente controllati dal kernel e dal suo scheduler.
...............................................
In risposta alle tue domande:
Un processo è sempre implementato in base a uno o più processi leggeri? La figura 3.4 sembra dire di si. Perché la Figura 3.5 (a) mostra i processi direttamente sulle CPU?
Sì, esistono processi leggeri chiamati thread e processi heavyweight.
Un processo pesante (puoi chiamarlo processo thread thread) richiede al processore stesso di fare più lavoro per ordinarne l'esecuzione, ecco perché la Figura 3.5 (a) mostra i processi direttamente sulle CPU.
Un processo leggero è sempre implementato sulla base di un thread del kernel? La figura 3.4 sembra dire di si. Perché la Figura 3.5 (b) mostra i processi leggeri direttamente sopra i processi?
No, i processi leggeri sono suddivisi in due categorie: processi a livello di utente e a livello di kernel, come menzionato sopra. Il processo a livello di utente si basa sulla propria libreria per elaborare i suoi compiti. Il kernel stesso pianifica un processo a livello di kernel. I thread a livello utente possono essere implementati utilizzando uno dei quattro modelli: molti-a-uno, uno-a-uno, molti-a-molti e due livelli. Tutti, questi modelli associano thread a livello di utente a thread a livello di kernel.
I thread del kernel sono le uniche entità che possono essere programmate?
No, i thread a livello di kernel sono creati dal kernel stesso. Sono diversi dai thread a livello di utente in quanto i thread a livello di kernel non hanno uno spazio di indirizzi limitato. Vivono esclusivamente nello spazio del kernel, senza mai passare al regno della terra dell'utente. Tuttavia, sono entità completamente programmabili e preemprabili, proprio come i normali processi (nota: è possibile disabilitare quasi tutti gli interrupt per importanti azioni del kernel). Lo scopo dei thread del kernel è principalmente quello di eseguire compiti di manutenzione sul sistema. Solo il kernel può avviare o interrompere un thread del kernel. Dall'altro lato, il processo a livello di utente può pianificare se stesso in base alla propria libreria e allo stesso tempo può essere programmato dal kernel in base ai modelli a due livelli e molti-a-molti (menzionati sopra),
I processi leggeri sono pianificati solo indirettamente tramite la pianificazione dei thread del kernel sottostanti?
I thread del kernel sono controllati dallo stesso programmatore del kernel. Supportare i thread a livello di utente significa che esiste una libreria a livello di utente collegata all'applicazione e questa libreria (non la CPU) fornisce tutta la gestione nel supporto di runtime per i thread. Supporterà le strutture di dati necessarie per implementare l'astrazione del thread e fornirà tutta la sincronizzazione della pianificazione e altri meccanismi necessari per prendere una decisione di gestione delle risorse per questi thread. Ora, alcuni dei processi di thread a livello di utente possono essere mappati nei thread a livello di kernel sottostanti e questo include il mapping uno a uno, uno a molti e molti a molti.
I processi sono pianificati solo indirettamente tramite la pianificazione dei processi leggeri sottostanti?
Dipende se si tratta di un processo pesante o leggero. Pesanti sono i processi pianificati dal kernel stesso. il processo leggero può essere gestito a livello di kernel e a livello di utente.
