seguente la \func{fork}; il processo figlio è però una copia del padre, e
riceve una copia dei segmenti di testo, stack e dati (vedi
\secref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
-padre, ma la memoria è copiata, non condivisa\footnote{In generale il segmento
+padre, ma la memoria è copiata, non condivisa,\footnote{In generale il segmento
di testo, che è identico, è condiviso e tenuto in read-only, Linux poi
utilizza la tecnica del \textit{copy-on-write}, per cui la memoria degli
altri segmenti viene copiata dal kernel per il nuovo processo solo in caso
di scrittura, rendendo molto più efficiente il meccanismo della creazione di
- un nuovo processo.}, pertanto padre e figlio vedono variabili diverse.
+ un nuovo processo.} pertanto padre e figlio vedono variabili diverse.
La differenza che si ha nei due processi è che nel processo padre il valore di
ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
\label{sec:proc_priority}
In questa sezione tratteremo più approfonditamente i meccanismi con il quale
-lo \textit{scheduler} assegna la CPU ai vari processi attivi, illustrando le
-varie funzioni che permettono di leggere e modificare le priorità di
-esecuzione dei programmi.
-
+lo \textit{scheduler}\footnote{che è la parte del kernel che si occupa di
+ stabilire quale processo dovrà essere posto in esecuzione.} assegna la CPU
+ai vari processi attivi. In particolare prendremo in esame i vari meccanismi
+con cui viene gestita l'assgnazione del tempo di CPU, ed illustreremo le varie
+funzioni di gestione.
+
+
+\subsection{I meccanismi di \textit{scheduling}}
+\label{sec:proc_sched}
+
+La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
+il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
+ed oggetto di numerose ricerche; in ogni caso essa dipende in maniera
+essenziale anche dal tipo di utilizzo che deve essere fatto del sistema.
+
+La cosa è resa ancora più complicata dal fatto che con sistemi
+multi-processore si introduce anche la complessità dovuta alla scelta di quale
+sia la CPU più opportuna da utilizzare.\footnote{nei processori moderni la
+ presenza di ampie cache può rendere poco efficiente trasferire l'esecuzione
+ di un processo da una CPU ad un'altra, per cui occorrono meccanismi per
+ determininare quale è la migliore scelta fra le diverse CPU.} Tutto questo
+comunque appartiene alle sottigliezze dell'implementazione del kernel, e dal
+punto di vista dei programmi che girano in user space di può pensare sempre
+alla risorsa tempo di esecuzione, governata dagli stessi mecca, che nel caso
+di più processori sarà a disposizione di più di un processo alla volta.
+
+Si tenga presente inoltre che l'utilizzo della CPU è soltanto una delle
+risorse (insieme alla memoria e all'accesso alle periferiche) che sono
+necessarie per l'esecuzione di un programma, e spesso non è neanche la più
+importante. Per questo non è affatto detto che dare ad un programma la massima
+priorità di esecuzione abbia risultati significativi in termini di
+prestazioni.
+
+La politica tradizionale di scheduling di Unix (che tratteremo in
+\secref{sec:proc_sched_stand}) è sempre stata basata su delle priorità
+dinamiche, che assicurassaro che tutti i processi, anche i meno importanti,
+potessero ricevere un po' di tempo di CPU.
+
+Lo standard POSIX però per tenere conto dei sistemi real-time,\footnote{per
+ sistema real-time si intende un sistema in grado di eseguire operazioni in
+ tempo reale; in genere si tende a distinguere fra l'\textit{hard real-time}
+ in cui è necessario che i tempi di esecuzione di un programma siano
+ determinabili con certezza assoluta, come nel caso di meccanismi di
+ controllo di macchine, dove uno sforamento dei tempi avrebbe conseguenze
+ disastrose, e \textit{soft-real-time} in cui un occasionale sforamento è
+ ritenuto accettabile.} in cui è vitale che i processi in che devono essere
+eseguiti in un determinato momento non debbano aspettare la conclusione di un
+altri processi che non hanno questa necessità, ha introdotto il concetto di
+\textsl{priorità assoluta}, chimata anche \textsl{priorità statica}, in
+contrapposizione con la normale priorità dinamica.
+
+Il concetto di prorità assoluta dice che quando due processi si contendono
+l'esecuzione, vince sempre quello con la priorità assoluta più alta, anche,
+grazie al \textit{prehemptive scheduling}, se l'altro è in esecuzione.
+Ovviamente questo avviene solo per i processi che sono pronti per essere
+eseguiti (cioè nello stato \textit{runnable}\footnote{lo stato di un processo
+ è riportato nel campo \texttt{STAT} dell'output del comando \cmd{ps},
+ abbiamo già visto che lo stato di \textit{zombie} è indicato con \texttt{Z},
+ gli stati \textit{runnable}, \textit{sleep} e di I/O (\textit{uninteruttible
+ sleep}) sono invece indicati con \texttt{R}, \texttt{S} e \texttt{D}.}),
+la priorità assoluta viene invece ignorata per quelli che sono bloccati su una
+richiesta di I/O o in stato di \textit{sleep}.
+
+Questa viene in genere indicata con un numero
+
+
+
+
+\subsection{Il meccanismo di \textit{scheduling} standard}
+\label{sec:proc_sched_stand}
+
+In Linux tutti i processi hanno sostanzialmente la stessa priorità; benché sia
+possibile specificare una priorità assoluta secondo lo standard POSIX
+(argomento che tratteremo più avanti) l'uso comune segue quello che è il
+meccanismo tradizionale con cui i sistemi
projects / gapil.git / commitdiff