Quando un processo cerca di accedere ad una pagina che non è nella memoria
reale, avviene quello che viene chiamato un \textit{page
- fault}\index{\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.
+ fault}\itindex{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
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}\index{\textit{page~fault}} mandando un segnale \const{SIGSEGV} al
-processo, che normalmente ne causa la terminazione immediata.
+ fault}\itindex{page~fault} mandando un segnale \const{SIGSEGV} al processo,
+che normalmente ne causa la terminazione immediata.
È pertanto importante capire come viene strutturata \textsl{la memoria
- virtuale}\index{\textit{page~fault}} di un processo. Essa viene divisa in
+ virtuale}\index{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:
Il problema più comune e più difficile da risolvere che si incontra con le
routine di allocazione è quando non viene opportunamente liberata la memoria
non più utilizzata, quello che in inglese viene chiamato \textit{memory
- leak}\index{\textit{memory~leak}}, cioè una \textsl{perdita di memoria}.
+ leak}\itindex{memory~leak}, cioè una \textsl{perdita di memoria}.
Un caso tipico che illustra il problema è quello in cui in una subroutine si
alloca della memoria per uso locale senza liberarla prima di uscire. La
momento, in corrispondenza ad una qualunque chiamata di \func{malloc}, che può
essere in una sezione del codice che non ha alcuna relazione con la subroutine
che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
-\textit{memory leak}\index{\textit{memory~leak}}.
+\textit{memory leak}\itindex{memory~leak}.
In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
-programmazione ad oggetti, il problema dei \textit{memory leak} è notevolmente
-ridimensionato attraverso l'uso accurato di appositi oggetti come gli
-\textit{smartpointers}. Questo però va a scapito delle prestazioni
-dell'applicazione in esecuzione.
-
-In altri linguaggi come il java e recentemente il C\# il problema non si pone
-nemmeno perché la gestione della memoria viene fatta totalmente in maniera
-automatica, ovvero il programmatore non deve minimamente preoccuparsi di
-liberare la memoria allocata precedentemente quando non serve più, poiché
-l'infrastruttura del linguaggio gestisce automaticamente la cosiddetta
-\index{\textit{garbage~collection}}\textit{garbage collection}. In tal caso,
-attraverso meccanismi simili a quelli del \textit{reference counting}, quando
-una zona di memoria precedentemente allocata non è più riferita da nessuna
-parte del codice in esecuzione, può essere deallocata automaticamente in
-qualunque momento dall'infrastruttura.
-
-Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
-(inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
-eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
-la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
-di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
-compilate direttamente). Questo comporta però il problema della non
-predicibilità del momento in cui viene deallocata la memoria precedentemente
-allocata da un oggetto.
+programmazione ad oggetti, il problema dei \textit{memory
+ leak}\itindex{memory~leak} è notevolmente ridimensionato attraverso l'uso
+accurato di appositi oggetti come gli \textit{smartpointers}. Questo però in
+genere va a scapito delle prestazioni dell'applicazione in esecuzione.
+
+% In altri linguaggi come il java e recentemente il C\# il problema non si pone
+% nemmeno perché la gestione della memoria viene fatta totalmente in maniera
+% automatica, ovvero il programmatore non deve minimamente preoccuparsi di
+% liberare la memoria allocata precedentemente quando non serve più, poiché
+% l'infrastruttura del linguaggio gestisce automaticamente la cosiddetta
+% \index{\textit{garbage~collection}}\textit{garbage collection}. In tal caso,
+% attraverso meccanismi simili a quelli del \textit{reference counting}, quando
+% una zona di memoria precedentemente allocata non è più riferita da nessuna
+% parte del codice in esecuzione, può essere deallocata automaticamente in
+% qualunque momento dall'infrastruttura.
+
+% Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
+% (inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
+% eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
+% la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
+% di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
+% compilate direttamente). Questo comporta però il problema della non
+% predicibilità del momento in cui viene deallocata la memoria precedentemente
+% allocata da un oggetto.
Per limitare l'impatto di questi problemi, e semplificare la ricerca di
eventuali errori, l'implementazione delle routine di allocazione delle
\label{sec:proc_mem_sbrk_alloca}
Una possibile alternativa all'uso di \func{malloc}, che non soffre dei
-problemi di \textit{memory leak}\index{\textit{memory~leak}} descritti in
-precedenza, è la funzione \funcd{alloca}, che invece di allocare la memoria
-nello heap usa il segmento di stack della funzione corrente. La sintassi è
-identica a quella di \func{malloc}, il suo prototipo è:
+problemi di \textit{memory leak}\itindex{memory~leak} descritti in precedenza,
+è la funzione \funcd{alloca}, che invece di allocare la memoria nello heap usa
+il segmento di stack della funzione corrente. La sintassi è identica a quella
+di \func{malloc}, il suo prototipo è:
\begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
Alloca \param{size} byte nello stack.
rilasciata automaticamente al ritorno della funzione.
Come è evidente questa funzione ha molti vantaggi, anzitutto permette di
-evitare alla radice i problemi di memory leak\index{\textit{memory~leak}},
+evitare alla radice i problemi di \textit{memory leak}\itindex{memory~leak},
dato che non serve più la deallocazione esplicita; inoltre la deallocazione
automatica funziona anche quando si usa \func{longjmp} per uscire da una
subroutine con un salto non locale da una funzione (vedi
crittografia richiedono il blocco di alcune pagine di memoria.
\end{itemize}
-\index{\textit{memory~locking}|(}
+\itindbeg{memory~locking}
Il meccanismo che previene la paginazione\index{paginazione} di parte della
memoria virtuale di un processo è chiamato \textit{memory locking} (o
\textsl{blocco della memoria}). Il blocco è sempre associato alle pagine della
memoria bloccata non la sblocca. Chiaramente la terminazione del processo
comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
tutti i suoi \textit{memory lock}. Infine i \textit{memory lock} non sono
-ereditati dai processi figli.\footnote{ma siccome Linux usa il \textit{copy on
- write} (vedi sez.~\ref{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 \textit{memory lock}
- del padre.}
+ereditati dai processi figli.\footnote{ma siccome Linux usa il
+ \itindex{copy~on~write}\textit{copy on write} (vedi
+ sez.~\ref{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 \textit{memory lock} del padre.}
Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce
la memoria fisica disponibile nel sistema, questo ha un evidente impatto su
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 l'occorrenza di un eventuale \textit{page
- fault}\index{\textit{page~fault}} causato dal meccanismo di \textit{copy on
- write}\index{\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.
+ fault}\itindex{page~fault} causato dal meccanismo di \textit{copy on
+ write}\itindex{copy~on~write}. Infatti se nella sezione critica si va ad
+utilizzare memoria che non è ancora stata riportata in RAM si potrebbe avere
+un \itindex{page~fault}\textit{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
che esse vengano mappate in RAM dallo stack, dopo di che, per essere sicuri
che esse siano state effettivamente portate in memoria, ci si scrive sopra.
\index{memoria~virtuale|)}
-\index{\textit{memory~locking}|)}
+\itindend{memory~locking}
Talvolta però è necessario che la funzione possa restituire indietro alla
funzione chiamante un valore relativo ad uno dei suoi argomenti. Per far
-questo si usa il cosiddetto
-\index{\textit{value~result~argument}}\textit{value result argument}, si passa
-cioè, invece di una normale variabile, un puntatore alla stessa; vedremo
-alcuni esempi di questa modalità nelle funzioni che gestiscono i socket (in
-sez.~\ref{sec:TCP_functions}), in cui, per permettere al kernel di restituire
-informazioni sulle dimensioni delle strutture degli indirizzi utilizzate,
-viene usato questo meccanismo.
+questo si usa il cosiddetto \itindex{value~result~argument}\textit{value
+ result argument}, si passa cioè, invece di una normale variabile, un
+puntatore alla stessa; vedremo alcuni esempi di questa modalità nelle funzioni
+che gestiscono i socket (in sez.~\ref{sec:TCP_functions}), in cui, per
+permettere al kernel di restituire informazioni sulle dimensioni delle
+strutture degli indirizzi utilizzate, viene usato questo meccanismo.
\subsection{Il passaggio di un numero variabile di argomenti}
projects / gapil.git / blobdiff