Un po' di priorita` dei processi e chiusa la questione
authorSimone Piccardi <piccardi@gnulinux.it>
Sat, 2 Mar 2002 16:33:27 +0000 (16:33 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sat, 2 Mar 2002 16:33:27 +0000 (16:33 +0000)
dell'assegnazione progressiva dei pid dei processi (Thanks Algol!).

ChangeLog
prochand.tex

index 8228743..26d9895 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.
index 38a9b2f..4f72ab5 100644 (file)
@@ -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
-  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
@@ -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
-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
@@ -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.
 
-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
@@ -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
-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.
 
@@ -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
-  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
-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
@@ -1853,27 +1856,30 @@ importante. Per questo non 
 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},
@@ -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
-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}
 
-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}
@@ -1902,6 +1923,17 @@ meccanismo tradizionale con cui i sistemi
 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}