Un po' di priorita` dei processi e chiusa la questione

dell'assegnazione progressiva dei pid dei processi (Thanks Algol!).

diff --git a/ChangeLog b/ChangeLog
index 82287436fe9e94d422fd42949a0dce6bb9111899..26d9895f6d660330c70e5097abd16c5648c9af2f 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2002-03-02  Simone Piccardi  <piccardi@firenze.linux.it>
+
+       * prochand.tex: Aggiunte info sui limiti superiore ed inferiore
+       dei pid verificate da A. Frusciante.
+

 2002-03-01  Simone Piccardi  <piccardi@firenze.linux.it>
 
        * prochand.tex: correzioni varie da D. Masini.
 2002-03-01  Simone Piccardi  <piccardi@firenze.linux.it>
 
        * prochand.tex: correzioni varie da D. Masini.

diff --git a/prochand.tex b/prochand.tex
index 38a9b2f18799685c4e5c23a94ce5279a33f37521..4f72ab526b705cd57ce08d9814e9ad3da38a7e27 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -103,15 +103,15 @@ init-+-keventd
 
 Dato che tutti i processi attivi nel sistema sono comunque generati da
 \cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
 
 Dato che tutti i processi attivi nel sistema sono comunque generati da
 \cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto

-  vero, in Linux ci sono alcuni processi che pur comparendo come figli di
-  init, o con \acr{pid} successivi, sono in realtà generati direttamente dal
-  kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.)} si possono classificare i
-processi con la relazione padre/figlio in un'organizzazione gerarchica ad
-albero, in maniera analoga a come i file sono organizzati in un albero di
-directory (si veda \secref{sec:file_organization}); in \curfig\ si è mostrato
-il risultato del comando \cmd{pstree} che permette di visualizzare questa
-struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
-processi.
+  vero, in Linux ci sono alcuni processi speciali che pur comparendo come
+  figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
+  direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.).} si
+possono classificare i processi con la relazione padre/figlio in
+un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
+organizzati in un albero di directory (si veda
+\secref{sec:file_organization}); in \curfig\ si è mostrato il risultato del
+comando \cmd{pstree} che permette di visualizzare questa struttura, alla cui
+base c'è \cmd{init} che è progenitore di tutti gli altri processi.

 
 
 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
 
 
 Il kernel mantiene una tabella dei processi attivi, la cosiddetta


@@ -213,11 +213,15 @@ intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato 
 \type{int}).
 
 Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
 \type{int}).
 
 Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo

-processo viene creato, fino ad un limite massimo (in genere essendo detto
-numero memorizzato in un intero a 16 bit si arriva a 32767) oltre il quale si
-riparte dal numero più basso disponibile\footnote{FIXME: verificare, non sono
-  sicuro}.  Per questo motivo, come visto in \secref{sec:proc_hierarchy}, il
-processo di avvio (\cmd{init}) ha sempre il \acr{pid} uguale a uno.
+processo viene creato, fino ad un limite che, essendo il \acr{pid} un numero
+positivo memorizzato in un intero a 16 bit, arriva ad un massimo di 32767.
+Oltre questo valore l'assegnazione riparte dal numero più basso disponibile a
+partire da un minimo di 300,\footnote{questi valori sono definiti dalla macro
+  \macro{PID\_MAX} in \file{threads.h} e direttamente in \file{fork.c} nei
+  sorgenti del kernel.} che serve a riservare i \acr{pid} più bassi ai processi
+eseguiti dal direttamente dal kernel.  Per questo motivo, come visto in
+\secref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha sempre il
+\acr{pid} uguale a uno.

 
 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
 
 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
 sono stati creati, questo viene chiamato in genere \acr{ppid} (da


@@ -846,7 +850,7 @@ segnale termina il processo o chiama una funzione di gestione.
 processo figlio termina. Se un figlio è già terminato la funzione ritorna
 immediatamente.
 
 processo figlio termina. Se un figlio è già terminato la funzione ritorna
 immediatamente.
 

-Al ritorno lo stato di termininazione del processo viene salvato nella
+Al ritorno lo stato di terminazione del processo viene salvato nella

 variabile puntata da \var{status} e tutte le informazioni relative al
 processo (vedi \secref{sec:proc_termination}) vengono rilasciate.  Nel
 caso un processo abbia più figli il valore di ritorno permette di
 variabile puntata da \var{status} e tutte le informazioni relative al
 processo (vedi \secref{sec:proc_termination}) vengono rilasciate.  Nel
 caso un processo abbia più figli il valore di ritorno permette di


@@ -1818,7 +1822,7 @@ quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
 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
 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 prendremo in esame i vari meccanismi
+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.
 
 con cui viene gestita l'assegnazione del tempo di CPU, ed illustreremo le
 varie funzioni di gestione.
 


@@ -1836,15 +1840,14 @@ 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
 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.}
+  meccanismi per determinare quale è la migliore scelta fra le diverse CPU.}

 Tutto questo comunque appartiene alle sottigliezze dell'implementazione del
 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 quindi potenzialmente anche 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.
+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.

 
 Si tenga presente inoltre che l'utilizzo della CPU è soltanto una delle
 risorse (insieme alla memoria e all'accesso alle periferiche) che sono
 
 Si tenga presente inoltre che l'utilizzo della CPU è soltanto una delle
 risorse (insieme alla memoria e all'accesso alle periferiche) che sono


@@ -1853,27 +1856,30 @@ importante. Per questo non 
 priorità di esecuzione abbia risultati significativi in termini di
 prestazioni.
 
 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 assicurassero 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 che devono essere
-eseguiti in un determinato momento non debbano aspettare la conclusione di 
-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.
+Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
+\secref{sec:proc_sched_stand}) è sempre stato basato su delle \textsl{priorità
+  dinamiche}, in modo da assicurare che tutti i processi, anche i meno
+importanti, possano ricevere un po' di tempo di CPU. In sostanza quando un
+processo ottiene la CPU la sua priorità viene diminuita. In questo modo alla
+fine, anche un processo con priorità iniziale molto bassa, finisce per avere
+una priorità sufficiente per essere eseguito.
+
+Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
+  assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
+alla normale priorità dinamica), 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 che
+devono essere eseguiti in un determinato momento non debbano aspettare la
+conclusione di altri che non hanno questa necessità.
+
+Il concetto di priorità assoluta dice che quando due processi si contendono
+l'esecuzione, vince sempre quello con la priorità assoluta più alta, anche
+quando l'altro è in esecuzione (grazie al \textit{prehemptive scheduling}).

 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},
 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},


@@ -1881,20 +1887,35 @@ eseguiti (cio
   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
   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
-
+richiesta di I/O o in stato di \textit{sleep}.  La priorità assoluta viene in
+genere indicata con un numero intero, ed un valore più alto comporta una
+priorità maggiore, su questa politica di scheduling torneremo in
+\secref{sec:proc_real_time}.  

 
 

+In generale quello che succede in tutti gli Unix moderni è che ai processi
+normali viene sempre data una priorità assoluta pari a zero, e la decisione di
+assegnazione della CPU è fatta solo in base ad una priorità dinamica che è
+calcolata indipendentemente. È tuttavia possibile assegnare anche una priorità
+assoluta nel qual caso un processo avrà la precedenza su tutti gli altri di
+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}
 

-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
+A meno che non si abbiano specifiche esigenze, l'unico meccanismo di
+scheduling con il quale si avrà a che fare è quello tradizionale che prevede
+solo priorità dinamiche, ed è di questo che di norma ci si dovrà preoccupare
+nella programmazione.
+
+Come accennato in Linux tutti i processi ordinari hanno la stessa priorità
+assoluta. Quello che determina quale, fra tutti i processi in attesa di
+esecuzione, sarà eseguito per primo, è la priorità dinamica, che è chiamata
+così proprio perché viene varia nel corso dell'esecuzione di un processo.
+
+
+

 
 \subsection{Il meccanismo di \textit{scheduling real-time}}
 \label{sec:proc_real_time}
 
 \subsection{Il meccanismo di \textit{scheduling real-time}}
 \label{sec:proc_real_time}


@@ -1902,6 +1923,17 @@ meccanismo tradizionale con cui i sistemi
 Per settare le 
 
 
 Per settare le 
 
 

+\footnote{a meno che non si siano installate le patch di RTLinux o RTAI, con i
+  quali è possibile ottenere un sistema effettivamente hard real-time.}
+
+in realtà non si tratta di un vero hard real-time, in quanto
+  la presenza di eventuali interrupt o di page fault può sempre interrompere
+  l'esecuzione di un processo, a meno di non installare le estensioni di
+  RTLinux o RTAI, il normale kernel non è real-time.
+
+
+
+

 
 \section{Problematiche di programmazione multitasking}
 \label{sec:proc_multi_prog}
 
 \section{Problematiche di programmazione multitasking}
 \label{sec:proc_multi_prog}