Aggiunte sulle fifo

[gapil.git] / process.tex

diff --git a/process.tex b/process.tex
index e3a4774786115eb7561fadeb0e0d914856dc4385..b6afd42cc09f5300e25ce23a689a1d3da1eee227 100644 (file)
--- a/process.tex
+++ b/process.tex
@@ -291,8 +291,9 @@ servono. Questo meccanismo 
 \textit{paging}), ed è uno dei compiti principali del kernel.
 
 Quando un processo cerca di accedere ad una pagina che non è nella memoria
 \textit{paging}), ed è uno dei compiti principali del kernel.
 
 Quando un processo cerca di accedere ad una pagina che non è nella memoria

-reale, avviene quello che viene chiamato un \textit{page fault}\index{page
-  fault}; l'hardware di gestione della memoria genera un'interruzione e passa
+reale, avviene quello che viene chiamato un 
+\textit{page fault}\index{page fault}; 
+l'hardware di gestione della memoria genera un'interruzione e passa

 il controllo al kernel il quale sospende il processo e si incarica di mettere
 in RAM la pagina richiesta (effettuando tutte le operazioni necessarie per
 reperire lo spazio necessario), per poi restituire il controllo al processo.
 il controllo al kernel il quale sospende il processo e si incarica di mettere
 in RAM la pagina richiesta (effettuando tutte le operazioni necessarie per
 reperire lo spazio necessario), per poi restituire il controllo al processo.


@@ -319,14 +320,15 @@ tentativo di accedere ad un indirizzo non allocato 
 commette quando si è manipolato male un puntatore e genera quello che viene
 chiamato un \textit{segmentation fault}. Se si tenta cioè di leggere o
 scrivere da un indirizzo per il quale non esiste un'associazione della pagina
 commette quando si è manipolato male un puntatore e genera quello che viene
 chiamato un \textit{segmentation fault}. Se si tenta cioè di leggere o
 scrivere da un indirizzo per il quale non esiste un'associazione della pagina

-virtuale, il kernel risponde al relativo \textit{page fault}
+virtuale, il kernel risponde al relativo \textit{page fault}\index{page fault}

 mandando un segnale \macro{SIGSEGV} al processo, che normalmente ne causa la
 terminazione immediata.
 
 mandando un segnale \macro{SIGSEGV} al processo, che normalmente ne causa la
 terminazione immediata.
 

-È pertanto importante capire come viene strutturata la memoria virtuale di un
-processo. Essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
-indirizzi virtuali ai quali il processo può accedere. Solitamente un
-programma C viene suddiviso nei seguenti segmenti:
+È pertanto importante capire come viene strutturata \textsl{la memoria
+  virtuale}\index{page fault} di un processo. Essa viene divisa in
+\textsl{segmenti}, cioè un insieme contiguo di indirizzi virtuali ai quali il
+processo può accedere.  Solitamente un programma C viene suddiviso nei
+seguenti segmenti:

 
 \begin{enumerate}
 \item Il segmento di testo o \textit{text segment}. Contiene il codice del
 
 \begin{enumerate}
 \item Il segmento di testo o \textit{text segment}. Contiene il codice del


@@ -654,13 +656,13 @@ implementare una sua versione delle routine di allocazione.
 % \label{sec:proc_mem_malloc_custom}
 
 
 % \label{sec:proc_mem_malloc_custom}
 
 

-\subsection{Il controllo della memoria virtuale}  
+\subsection{Il controllo della memoria virtuale\index{memoria virtuale}}  

 \label{sec:proc_mem_lock}
 
 \label{sec:proc_mem_lock}
 

-Come spiegato in \secref{sec:proc_mem_gen} il kernel gestisce la memoria in
-maniera trasparente ai processi, decidendo quando rimuovere pagine dalla
-memoria per metterle nello swap, sulla base dell'utilizzo corrente da parte
-dei vari processi.
+Come spiegato in \secref{sec:proc_mem_gen} il kernel gestisce la memoria
+virtuale in maniera trasparente ai processi, decidendo quando rimuovere pagine
+dalla memoria per metterle nello swap, sulla base dell'utilizzo corrente da
+parte dei vari processi.

 
 Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
 meccanismo della paginazione\index{paginazione} riporta in RAM, ed in maniera
 
 Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
 meccanismo della paginazione\index{paginazione} riporta in RAM, ed in maniera


@@ -708,14 +710,14 @@ comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
 tutti i suoi \textit{memory lock}.
 
 I \textit{memory lock} non sono ereditati dai processi figli.\footnote{ma
 tutti i suoi \textit{memory lock}.
 
 I \textit{memory lock} non sono ereditati dai processi figli.\footnote{ma

-  siccome Linux usa il \textit{copy on write} (vedi \secref{sec:proc_fork})
-  gli indirizzi virtuali del figlio sono mantenuti sullo stesso segmento di
-  RAM del padre, quindi fintanto che un figlio non scrive su un segmento, può
-  usufruire del memory lock del padre.}  Siccome la presenza di un
-\textit{memory lock} riduce la memoria disponibile al sistema, con un impatto
-su tutti gli altri processi, solo l'amministratore ha la capacità di bloccare
-una pagina. Ogni processo può però sbloccare le pagine relative alla propria
-memoria.
+  siccome Linux usa il \textit{copy on write}\index{copy on write} (vedi
+  \secref{sec:proc_fork}) gli indirizzi virtuali del figlio sono mantenuti
+  sullo stesso segmento di RAM del padre, quindi fintanto che un figlio non
+  scrive su un segmento, può usufruire del memory lock del padre.}  Siccome la
+presenza di un \textit{memory lock} riduce la memoria disponibile al sistema,
+con un impatto su tutti gli altri processi, solo l'amministratore ha la
+capacità di bloccare una pagina. Ogni processo può però sbloccare le pagine
+relative alla propria memoria.

 
 Il sistema pone dei limiti all'ammontare di memoria di un processo che può
 essere bloccata e al totale di memoria fisica che può dedicare a questo, lo
 
 Il sistema pone dei limiti all'ammontare di memoria di un processo che può
 essere bloccata e al totale di memoria fisica che può dedicare a questo, lo


@@ -787,11 +789,12 @@ esempio limitandosi a tutte le pagine allocate a partire da un certo momento.
 
 In ogni caso un processo real-time che deve entrare in una sezione critica
 deve provvedere a riservare memoria sufficiente prima dell'ingresso, per
 
 In ogni caso un processo real-time che deve entrare in una sezione critica
 deve provvedere a riservare memoria sufficiente prima dell'ingresso, per

-scongiurare in partenza un eventuale page fault causato dal meccanismo di
-\textit{copy on write}.  Infatti se nella sezione critica si va ad utilizzare
-memoria che non è ancora stata riportata in RAM si potrebbe avere un page
-fault durante l'esecuzione della stessa, con conseguente rallentamento
-(probabilmente inaccettabile) dei tempi di esecuzione.
+scongiurare in partenza un eventuale page fault\index{page fault} causato dal
+meccanismo di \textit{copy on write}\index{copy on write}.  Infatti se nella
+sezione critica si va ad utilizzare memoria che non è ancora stata riportata
+in RAM si potrebbe avere un page fault durante l'esecuzione della stessa, con
+conseguente rallentamento (probabilmente inaccettabile) dei tempi di
+esecuzione.

 
 In genere si ovvia a questa problematica chiamando una funzione che ha
 allocato una quantità sufficientemente ampia di variabili automatiche, in modo
 
 In genere si ovvia a questa problematica chiamando una funzione che ha
 allocato una quantità sufficientemente ampia di variabili automatiche, in modo