X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=process.tex;h=4d02cbc0a461530b5660a29ed210a13ceb5da0fa;hp=a5695b7dd004974e5b137e924f70a21cfbe09b91;hb=c3e498249706436db56faaa3be03458b7ac1113d;hpb=996f31582fc276069a62f707bc5bdb4255342062 diff --git a/process.tex b/process.tex index a5695b7..4d02cbc 100644 --- a/process.tex +++ b/process.tex @@ -253,11 +253,12 @@ esecuzione, e le varie funzioni utilizzabili per la sua gestione. Ci sono vari modi in cui i vari sistemi organizzano la memoria (ed i dettagli di basso livello dipendono spesso in maniera diretta dall'architettura dell'hardware), ma quello più tipico, usato dai sistemi unix-like come Linux è -la cosiddetta \textsl{memoria virtuale} che consiste nell'assegnare ad ogni -processo uno spazio virtuale di indirizzamento lineare, in cui gli indirizzi -vanno da zero ad un qualche valore massimo.\footnote{nel caso di Linux fino al - kernel 2.2 detto massimo era, per macchine a 32bit, di 2Gb, con il kernel - 2.4 ed il supporto per la \textit{high-memory} il limite è stato esteso.} +la cosiddetta \textsl{memoria virtuale}\index{memoria virtuale} che consiste +nell'assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare, +in cui gli indirizzi vanno da zero ad un qualche valore massimo.\footnote{nel + caso di Linux fino al kernel 2.2 detto massimo era, per macchine a 32bit, di + 2Gb, con il kernel 2.4 ed il supporto per la \textit{high-memory} il limite + è stato esteso.} Come accennato in \capref{cha:intro_unix} questo spazio di indirizzi è virtuale e non corrisponde all'effettiva posizione dei dati nella RAM del @@ -286,15 +287,15 @@ gestione della memoria (la \textit{Memory Management Unit} del processore). Poiché in genere la memoria fisica è solo una piccola frazione della memoria virtuale, è necessario un meccanismo che permetta di trasferire le pagine che servono dal supporto su cui si trovano in memoria, eliminando quelle che non -servono. Questo meccanismo è detto \textit{paging}, ed è uno dei compiti -principali del kernel. +servono. Questo meccanismo è detto \textsl{paginazione}\index{paginazione} (o +\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}; 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. +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. Dal punto di vista di un processo questo meccanismo è completamente trasparente, e tutto avviene come se tutte le pagine fossero sempre @@ -305,8 +306,8 @@ a tempi molto pi Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed in genere il sistema è molto efficiente in questo lavoro; quando però ci siano esigenze specifiche di prestazioni è possibile usare delle funzioni che -permettono di bloccare il meccanismo del paging e mantenere fisse delle pagine -in memoria (vedi \ref{sec:proc_mem_lock}). +permettono di bloccare il meccanismo della paginazione e mantenere fisse delle +pagine in memoria (vedi \ref{sec:proc_mem_lock}). \subsection{La struttura della memoria di un processo} @@ -318,9 +319,9 @@ 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 -virtuale, il kernel risponde al relativo \textit{page fault} mandando un -segnale \macro{SIGSEGV} al processo, che normalmente ne causa la terminazione -immediata. +virtuale, il kernel risponde al relativo \textit{page fault} +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 @@ -662,10 +663,10 @@ 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 riporta in RAM, ed in maniera trasparente, tutte -le pagine che gli occorrono; esistono però esigenze particolari in cui non si -vuole che questo meccanismo si attivi. In generale i motivi per cui si possono -avere di queste necessità sono due: +meccanismo della paginazione\index{paginazione} riporta in RAM, ed in maniera +trasparente, tutte le pagine che gli occorrono; esistono però esigenze +particolari in cui non si vuole che questo meccanismo si attivi. In generale i +motivi per cui si possono avere di queste necessità sono due: \begin{itemize} \item \textsl{La velocità}. Il processo della paginazione è trasparente solo se il programma in esecuzione non è sensibile al tempo che occorre a @@ -1412,7 +1413,7 @@ un'altra funzione, per cui se l'errore avviene in una funzione e la sua gestione ordinaria è in un'altra occorre usare quello che viene chiamato un \textsl{salto non-locale}. Il caso classico in cui si ha questa necessità, citato sia da \cite{APUE} che da da \cite{glibc}, è quello di un programma nel -ccui corpo principale in cui viene letto un input del quale viene eseguita +cui corpo principale in cui viene letto un input del quale viene eseguita attraverso una serie di funzioni di analisi una scansione dei contenuti da cui ottenere le indicazioni per l'esecuzione di opportune operazioni. @@ -1451,7 +1452,7 @@ in tutte le funzioni del programma. Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore diverso da zero viene restituito solo quando il ritorno è dovuto ad una -chiamata di \func{longjmp} in un'altra parte del programa. Si tenga conto che +chiamata di \func{longjmp} in un'altra parte del programma. Si tenga conto che il contesto salvato in \param{env} viene invalidato se la routine che ha chiamato \func{setjmp} ritorna, nel qual caso l'uso di \func{longjmp} può comportare conseguenze imprevedibili (e di norma fatali per il processo). @@ -1476,7 +1477,7 @@ nella chiamata deve essere diverso da zero, se si comunque restituito 1 al suo posto. In sostanza un \func{longjmp} è analogo ad un \code{return}, solo che invece -di ritornare alla riga succesiva della funzione chiamante, il programma +di ritornare alla riga successiva della funzione chiamante, il programma ritorna alla posizione della relativa \func{setjmp}, ed il ritorno può essere effettuato anche attraverso diversi livelli di funzioni annidate.