Rimaneggiata ancora la parte sullo scheduler, con ancora piu` casino.
authorSimone Piccardi <piccardi@gnulinux.it>
Mon, 25 Mar 2002 18:40:09 +0000 (18:40 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Mon, 25 Mar 2002 18:40:09 +0000 (18:40 +0000)
biblio.bib
fileunix.tex
prochand.tex

index 681e3ef..3004c7d 100644 (file)
@@ -79,8 +79,7 @@
   OPTannote =   {}
 }
 @Book{glibc,
-  author =      {Sandra Loosemore with Richard M. Stallman, 
-Roland McGrath, Andrew Oram, and Ulrich Drepper},
+  author =      {Sandra Loosemore Richard M. Stallman Roland McGrath Andrew Oram and Ulrich Drepper},
   editor =      {Free Software Foundation},
   title =       {The GNU C Library Reference Manual},
   publisher =   {Free Software Foundation},
index fbc65cd..0551441 100644 (file)
@@ -549,7 +549,7 @@ In realt
 \macro{EAGAIN} non sono errori. La prima si verifica quando la \func{read} è
 bloccata in attesa di dati in ingresso e viene interrotta da un segnale; in
 tal caso l'azione da prendere è quella di rieseguire la funzione. Torneremo
-sull'argomento in \secref{sec:signal_xxx}. 
+sull'argomento in \secref{sec:sig_gen_beha}. 
 
 La seconda si verifica quando il file è in modalità non bloccante e non ci
 sono dati in ingresso: la funzione allora ritorna immediatamente con un errore
index 4bd9a46..73f2e7f 100644 (file)
@@ -133,7 +133,8 @@ riprese), 
 
 Come accennato in \secref{sec:intro_unix_struct} è lo \textit{scheduler} che
 decide quale processo mettere in esecuzione; esso viene eseguito ad ogni
-system call ed ad ogni interrupt, (ma può essere anche attivato
+system call ed ad ogni interrupt,\footnote{più in una serie di altre
+  occasioni. NDT completare questa parte.} (ma può essere anche attivato
 esplicitamente). Il timer di sistema provvede comunque a che esso sia invocato
 periodicamente, generando un interrupt periodico secondo la frequenza
 specificata dalla costante \macro{HZ}, definita in \file{asm/param.h}. Il
@@ -1821,11 +1822,9 @@ quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
 \label{sec:proc_priority}
 
 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
-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 prenderemo in esame i vari meccanismi
-con cui viene gestita l'assegnazione del tempo di CPU, ed illustreremo le
-varie funzioni di gestione.
+lo \textit{scheduler} assegna la CPU ai vari processi attivi. In particolare
+prenderemo in esame i vari meccanismi con cui viene gestita l'assegnazione del
+tempo di CPU, ed illustreremo le varie funzioni di gestione.
 
 
 \subsection{I meccanismi di \textit{scheduling}}
@@ -1836,29 +1835,47 @@ il tempo di CPU per l'esecuzione dei processi 
 ed oggetto di numerose ricerche; in ogni caso essa dipende in maniera
 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema.
 
-Si tenga presente comunque 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 caratteristica specifica di un sistema multitasking come Linux è quella del
 cosiddetto \textit{prehemptive multitasking}: questo significa che al
 contrario di altri sistemi (che usano invece il cosiddetto \textit{cooperative
   multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
 quando la CPU deve essere passata ad un altro processo. Come accennato in
-\secref{sec:proc_hierarchy} questa scelta viene eseguita dallo
-\textit{scheduler} il cui scopo è quello di distribuire al meglio il tempo di
-CPU fra i vari processi. 
+\secref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
+apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
+distribuire al meglio il tempo di CPU fra i vari processi.
 
-Il Linux un processo può trovarsi in uno degli stati riportati in 
+La cosa è resa ancora più complicata dal fatto che con le architetture
+multi-processore si introduce anche la problematica 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 determinare 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, anche
+quando si hanno più processori (e dei processi che sono eseguiti davvero in
+contemporanea), si può pensare alle politiche di scheduling come concernenti
+la risorsa \textsl{tempo di esecuzione}, la cui assegnazione sarà governata
+dagli stessi meccanismi di scelta di priorità, solo che nel caso di più
+processori sarà a disposizione di più di un processo alla volta.
+
+I processi non devono solo eseguire del codice, ad esempio molto spesso
+saranno impegnati in operazioni di I/O, possono venire bloccati da un
+comando dal terminale, sospesi per un certo periodo di tempo. In tutti questi
+casi la CPU diventa disponibile ed è compito dello kernel provvedere a mettere
+in esecuzione un altro processo.
 
+Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
+processo ,
+
+In Linux un processo può trovarsi in uno degli stati riportati in
+\tabref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
+\textit{runnable} concorrono per l'esecuzione. Questo vuol di
 
 
 \begin{table}[htb]
   \centering
-  \begin{tabular}[c]{|l|c|p{8cm}|}
+  \begin{tabular}[c]{|p{3cm}|c|p{8cm}|}
     \hline
     \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
     \hline
@@ -1876,40 +1893,27 @@ Il Linux un processo pu
     terminazione non è ancora stato letto dal padre. \\
     \hline
   \end{tabular}
-  \caption{Tabella degli stati possibili per  processo in Linux, si sono
-    riportati nella colonna \texttt{STAT} i valori dello stato ottenibili
-    dall'output del comando \cmd{ps}.}
+  \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
+    \texttt{STAT} si è riportata la corripondente lettera usata dal comando 
+    \cmd{ps} nell'omonimo campo.}
   \label{tab:proc_proc_states}
 \end{table}
 
 
 
+Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
+risorse che sono necessarie per l'esecuzione di un programma, e spesso non è
+neanche la più importante. Per questo motivo non è affatto detto che dare ad
+un programma la massima priorità di esecuzione abbia risultati significativi
+in termini di prestazioni.
 
-Una delle caratteristiche c
 
-,\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}
 
 
-La cosa è resa ancora più complicata dal fatto che con le architetture
-multi-processore si introduce anche la problematica 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 determinare 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, anche
-quando si hanno più processori (e dei processi che sono eseguiti davvero in
-contemporanea), si può pensare alle politiche di scheduling come concernenti
-la risorsa \textsl{tempo di esecuzione}, la cui assegnazione sarà governata
-dagli stessi meccanismi di scelta di priorità, solo che nel caso di più
-processori sarà a disposizione di più di un processo alla volta.
+Una delle caratteristiche c
 
+la priorità assoluta viene invece ignorata per quelli che sono bloccati su una
+richiesta di I/O o in stato di \textit{sleep}
 
 
 
@@ -1951,6 +1955,7 @@ assoluta nel qual caso un processo avr
 priorità inferiore che saranno eseguiti solo quando quest'ultimo non avrà
 bisogno della CPU.
 
+
 \subsection{Il meccanismo di \textit{scheduling} standard}
 \label{sec:proc_sched_stand}
 
@@ -2035,7 +2040,7 @@ qualunque momento, e le operazioni di un eventuale \textit{signal handler}
 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
 il solo accesso o l'assegnazione di una variabile possono non essere più
 operazioni atomiche (torneremo su questi aspetti in
-\secref{sec:sign_control}).
+\secref{sec:sig_control}).
 
 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
 il cui accesso è assicurato essere atomico.  In pratica comunque si può