DOMANDA funzionamento del kernel

[BonatoAlessandro]

Buonasera a tutti, il mese scorso a scuola abbiamo studiato un po'il funzionamento del kernel in un sistema operativo, ma mi è sorto un dubbio: se il kernel è un programma che gestisce l'assegnazione della cpu ai vari programmi come fa a gestire questa cosa quando un altro programma è in esecuzione sulla cpu? Non dovrebbe essere sempre in esecuzione per poter lavorare e quindi gestire i vari processi?
Ditemi se non mi sono spiegato bene.
Grazie in anticipo per le risposte.

 

[FabioNET]

dipende un po dalla tipologia di kernel e come è stato ingegnerizzato, e sopratutto con quale kernel abbiamo a che fare? con quello di Microsoft o quello dei sistemi unix che sono un concept di monolitico kernel ovvero che ha già tutto dentro e una buona manciata di driver senza doverse necessariamente installarne di altri.

ma a parte questo almeno quello di linux o unix like tipo bsd sono un po diversi ma simili o melgio si assomigliano, gestisce le periferiche tramite diramazioni virtuali caricate nel Proc che puo essere anche una partizione temporanea e gestisce i processi, carica e scarica da li con la memoria ram.

per quello che ne so io poi potrebbero anche smentirmi chi ne sa piu di me. ovviamente parlo per mia esperienza vissuta, col tempo le versioni sono cambiate e sono cambiati i metodi di gestione.

per darti giusto un riferimento è qui https://informatica.rgpsoft.it/2011/02/come-funziona-kernel-linux.html

 

[DispatchCode]

Ciao,

ti sposterò il topic nella sezione "Programmazione", in quanto è sicuramente più adatta.

se il kernel è un programma che gestisce l'assegnazione della cpu ai vari programmi come fa a gestire questa cosa quando un altro programma è in esecuzione sulla cpu?

Non è proprio così. Il Kernel non è un programma, posto che si dovrebbe prima definire cosa è effettivamente un programma, prima di ciò.
Il Kernel è composto da una serie di componenti che si occupano di un sacco di funzionalità, si spazia da HAL (Hardware abstraction layer), allo scheduling a cui ti riferisci tu, alla gestione delle chiamate alle API di sistema (ad esempio per scrivere su un file, per leggere, o per eseguire altre operazioni).

Quello a cui ti riferisci tu è lo scheduling. Prendo come esempio Windows. In Windows lo scheduling non avviene per processo, ma avviene per thread. Ogni programma ha almeno 1 thread, e il processo è in realtà qualcosa di più astratto: si tratta diciamo di un contenitore, che al suo interno ha diverse informazioni sul programma (o meglio, si dovrebbe dire "l'immagine") che è in esecuzione.

Considera che il kerne - le parti che lo compongono e tutti i driver che girano in quella che si chiama "kernel mode" - vengono schedulati e possono essere eseguiti su tutti i cores del tuo PC, non ne hanno uno dedicato. In aggiunta, quando ci sono in esecuzione alcune routine, non può avvenire lo scheduling e di fatto non avviene in quel momento, ma si aspetta il termine dell'operazione.

Il kernel dispatcher si occupa di assegnare un "quantum" a un thread; il thread verrà eseguito per tutto il tempo che gli sarà stato concesso, oppure verrà interrotto se un altro thread con priorità superiore è pronto per essere eseguito.
Windows mantiene una coda (si tratta di una struttura dati), che si chiama "dispatcher database", con al suo interno i thread che sono "in attesa" e quelli in esecuzione; tramite questo meccanismo seleziona quale thread eseguire e dove (anche qui è piuttosto articolato).
L'algoritmo usato da windows dovrebbe essere questo https://en.wikipedia.org/wiki/Multilevel_feedback_queue

E' una descrizione sommaria, lo so, ma evito di aggiungere dettagli per non farti fare confusione, attendendo magari tue domande.

 

[Andretti60]

... come fa a gestire questa cosa quando un altro programma è in esecuzione sulla cpu? ...

Quello che dici aveva senso 50 anni fa quando esistevano ancora sistemi operativi mono-processo, ossia un solo programma poteva usare la CPU finche' non avesse finito. Questo non e' più vero, tutti i sistemi operativi sono multi-processing, ossia dove tanti programmi possono girare allo stesso momento, dividendosi la CPU per piccoli intervalli (slots) di tempo ciascuno, incluso il Kernel. La cosa e' possibile specialmente perché un programma ha in genere molti "tempi morti" (per esempio sta aspettando la risposta da una periferica), e in tali tempi morti altri programmi automaticamente prendono controllo della CPU.
Senza contare ormai che nessuna CPU ha un solo processore interno, ne ha svariati con più core, per cui tutto il concetto di "processore" e' da rivedere.
Ripeto comunque quello che ha detto @DispatchCode , ossia questo solo a grandi linee, a scuola dovreste averlo studiato in Struttura dei Processori.

 

[pabloski]

se il kernel è un programma che gestisce l'assegnazione della cpu ai vari programmi come fa a gestire questa cosa quando un altro programma è in esecuzione sulla cpu?

interrupt! letto la parte scritta da DispatchCode, quando parla del quantum assegnato ad un processo o thread ( dipende dal modello di scheduling usato )? il termine del quantum è indicato da un timer che "scatta" e genera un interrupt, il quale porta all'esecuzione dello scheduler del kernel

il kernel viene eseguito sono in questo modo, cioè non è come un programma normale che parte e va da sè fino alla conclusione

il kernel è invocato sia via software ( tramite le syscall ) che tramite trap e interrupt ( quelli a cui decide di "attaccarsi" )

nel momento in cui lo scheduler ritorna in esecuzione, va a guardare nelle sue code dei processi/thread e sceglie a quale assegnare la cpu

lo stesso discorso vale per i sistemi multiprocessore/multicore, solo che lì il kernel può essere in esecuzione contemporaneamente su più core, da cui la necessità di rendere le code di cui sopra thread-safe

 

[Andretti60]

…

lo stesso discorso vale per i sistemi multiprocessore/multicore, solo che lì il kernel può essere in esecuzione contemporaneamente su più core, da cui la necessità di rendere le code di cui sopra thread-safe

Veramente non è proprio così, ma usciamo un po’ dal seminato.
Il concetto di Thread Safety non dipende dal numero di core, in quanto ogni programma gira nel suo address space, il problema sorge quando due o più thread dello stesso processo accedono la stessa locazione di memoria. Se un thread cerca di leggere una locazione di memoria che un altro thread allo stesso tempo sta modificando, la lettura sarà “sporca”. Lo stesso quando due thread cercano di modificare la stessa memoria allo stesso tempo. Il problema si risolve con la sincronizzazione, ma ripeto è presente anche in processori mono-core.

 

[pabloski]

Veramente non è proprio così, ma usciamo un po’ dal seminato.
Il concetto di Thread Safety non dipende dal numero di core, in quanto ogni programma gira nel suo address space, il problema sorge quando due o più thread dello stesso processo accedono la stessa locazione di memoria. Se un thread cerca di leggere una locazione di memoria che un altro thread allo stesso tempo sta modificando, la lettura sarà “sporca”. Lo stesso quando due thread cercano di modificare la stessa memoria allo stesso tempo. Il problema si risolve con la sincronizzazione, ma ripeto è presente anche in processori mono-core.

Mi riferivo al fatto che il kernel potrebbe essere attivo su più core e ognuna delle istanze potrebbe accedere alla stessa struttura dati ( cosa che capita con lo scheduler e le code dei processi/thread ). E ovviamente la soluzione è creare n-code oppure sincronizzare gli accessi all'unica coda presente.

 

[bigendian]

@BonatoAlessandro

dalla tua domanda mi pare tu sia un po' alle prime armi, ti potrei parlare di microkernel, kernel monolitici, round-robin, teoria dei quanti, oppure completely-fair-scheduler, kernel preemptive, interrupts, systemcalls, kernel real-time etc.

Ma sarebbe un errore, un voler pavoneggiarsi che servirebbe solo a non farti capire nulla. Per cui, provo a darti una risposta semplice.

In linea molto generale, immaginando per semplicita' di avere un unica cpu, vedi un kernel come un "programma" con poteri speciali, che viene eseguito prima di tutti gli altri, lui quindi esegue "a turno" uno spezzone di codice questi programmi, uno dopo l'altro in una divisione di tempo, e la decisione di chi eseguire avviene ogni volta che uno di questi programmi entra in "idle", o meglio, riposa e non richiede risorse alla cpu, e' qui che il controllo torna al kernel che decide chi eseguire subito dopo (il controll puo tornare al kernel anche in altri casi che ora non ti elenco). Poi ci sono molte variazioni a questa gesitone/spiegaizone semplice che non penso abbia senso illustrarti ora. Puoi approfondire quando vuoi, in rete trovi di tutto, specie nel kernel Linux hai tutto il codice dello scheduler visibile, anche se pocjhi al mondo ne capiscpono il significato.