Rimaneggiata ancora la parte sullo scheduler, con ancora piu` casino.

diff --git a/biblio.bib b/biblio.bib
index 681e3ef6a568b023be12e9736fbde66cb42c995a..3004c7d0b2cec734a35ad7f4c82ccddad6ad3a4e 100644 (file)
--- a/biblio.bib
+++ b/biblio.bib
@@ -79,8 +79,7 @@
   OPTannote =   {}
 }
 @Book{glibc,
   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},
   editor =      {Free Software Foundation},
   title =       {The GNU C Library Reference Manual},
   publisher =   {Free Software Foundation},

diff --git a/fileunix.tex b/fileunix.tex
index fbc65cd02b6a267506ba8b866ce9eebb03330447..0551441851c1b3d01b7a55482e64fde5b81609b9 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -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
 \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
 
 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

diff --git a/prochand.tex b/prochand.tex
index 4bd9a46c034a1d34de5fcae5775838f1e71b6d5d..73f2e7fb7e154388c55ce952497a41d5ab27e972 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -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
 
 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
 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
 \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}}
 
 
 \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.
 
 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
 
 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{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
     \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}
     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}
 
 
 
   \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.
 
 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}
 
 \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
 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ò
 
 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ò