Sophie

Sophie

distrib > Mandriva > 9.1 > i586 > by-pkgid > f1098342ec4a2b28475e34123ce17201 > files > 1247

howto-html-it-9.1-0.5mdk.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
 <TITLE>The Unix and Internet Fundamentals HOWTO: Come fa il computer a evitare che i processi si intralcino tra</TITLE>
 <LINK HREF="Unix-Internet-Fundamentals-HOWTO-10.html" REL=next>
 <LINK HREF="Unix-Internet-Fundamentals-HOWTO-8.html" REL=previous>
 <LINK HREF="Unix-Internet-Fundamentals-HOWTO.html#toc9" REL=contents>
</HEAD>
<BODY>
<A HREF="Unix-Internet-Fundamentals-HOWTO-10.html">Avanti</A>
<A HREF="Unix-Internet-Fundamentals-HOWTO-8.html">Indietro</A>
<A HREF="Unix-Internet-Fundamentals-HOWTO.html#toc9">Indice</A>
<HR>
<H2><A NAME="s9">9. Come fa il computer a evitare che i processi si intralcino tra</A>loro?</H2>

<P>Lo scheduler del kernel si prende cura di dividere il tempo tra i
processi. Il vostro sistema operativo deve dividere tra i processi
anche lo spazio, per evitare che non sconfinino oltre la porzione di
memoria loro assegnata. Le operazioni compiute dal sistema operativo
per risolvere questo problema si chiamano <EM>gestione della
memoria</EM>.
<P>Ogni processo del vostro repertorio ha la propria area di memoria
core, come luogo dal quale eseguire il proprio codice e dove
immagazzinare le variabili e i risultati. Potete pensare a questo
insieme come formato da un <EM>segmento codice</EM>, di
sola lettura (che contiene le istruzioni del processo), e da un
<EM>segmento dati</EM> (che contiene tutte le variabili
immagazzinate dal processo). Il segmento dati &egrave; sempre unico per ogni
processo, mentre nel caso due processi usino lo stesso codice Unix
automaticamente fa in modo che condividano un unico segmento codice,
come misura di efficienza.
<P>L'efficienza &egrave; importante, perch&eacute; la memoria core &egrave; costosa. A volte
non ne avete abbastanza per contenere per intero tutti i programmi che
il computer sta eseguendo, specialmente se usate un grosso programma
quale un server X. Per ovviare a questo problema Unix usa una
strategia chiamata 
<A NAME="vm"></A> <EM>memoria
virtuale</EM>. Non cerca di tenere in core tutti i dati e il
codice di un processo. Tiene piuttosto caricato solo un
<EM>working set</EM> relativamente piccolo; il resto dello
stato del processo viene lasciato in uno speciale <EM>spazio
swap</EM> sul vostro disco fisso.
<P>Come i processi sono in esecuzione Unix tenta di anticipare i
cambiamenti del working set per avere in memoria solo le parti che
servono davvero. Riuscirci in modo efficace &egrave; ingegnoso e complesso,
pertanto non cercher&ograve; di descriverlo tutto qui, ma si basa sul fatto
che il codice e i riferimenti ai dati tendono a comparire a gruppi,
ed &egrave; probabile che un nuovo gruppo si colleghi a luoghi vicini a
quelli di uno precedente. Quindi se Unix tiene caricati i dati e il
codice usati pi&ugrave; di frequente (o di recente) di solito riuscir&agrave; a
risparmiare del tempo.
<P>Notate che in passato quel ``A volte'' di due paragrafi fa era un
``Quasi
sempre'', perch&eacute; la dimensione della memoria era tipicamente ridotta
rispetto alla dimensione dei programmi in esecuzione, quindi il
ricorso allo swap era frequente. Oggi la memoria &egrave; molto meno costosa
e persino i computer di fascia bassa ne hanno parecchia. Sui moderni
computer monoutente con 64MB di memoria e oltre &egrave; possibile eseguire X
e un insieme tipico di programmi senza neppure ricorrere allo swap.
<P>Anche in questa felice situazione la parte del sistema operativo
chiamata <EM>gestore della memoria</EM> mantiene un importante ruolo
da svolgere. Deve garantire che i programmi possano modificare
soltanto il proprio segmento dati; deve cio&egrave; impedire che del codice
difettoso o malizioso in un programma rovini i dati di altri
programmi. A questo scopo tiene una tabella dei segmenti dati e
codice. La tabella &egrave; aggiornata non appena un processo richiede pi&ugrave;
memoria oppure libera memoria (quest'ultimo caso si verifica di solito
all'uscita dal programma).
<P>Questa tabella &egrave; usata per passare comandi a una parte
specializzata dell'hardware sottostante chiamata
<EM>MMU</EM> o <EM>unit&agrave; di gestione della
memoria</EM>. I processori moderni hanno MMU incorporate. La MMU
ha la peculiare capacit&agrave; di porre dei delimitatori attorno alle aree
di memoria, in modo che un riferimento che sconfina venga rifiutato e
faccia scattare uno speciale interrupt.
<P>Se avete mai visto un messaggio del tipo ``Segmentation fault'',
``core
dumped'' o qualcosa del genere, questo &egrave; esattamente quello che &egrave;
successo: un tentativo da parte del programma in esecuzione di
accedere alla memoria al di fuori dal proprio segmento ha fatto
scattare un interrupt fatale. Questo rivela un bug nel codice del
programma; il <EM>core dump</EM> (scarico della memoria)
che lascia dietro di s&eacute; costituisce una informazione diagnostica volta
ad aiutare il programmatore nell'individuazione del problema.
<P>C'&egrave; un altro aspetto che protegge i processi l'uno dall'altro, oltre
alla limitazione della memoria a cui possono accedere. Si vuole anche
poter controllare il loro accesso ai file in modo che un programma
difettoso o malizioso non possa rovinare parti critiche del sistema. &Egrave;
per questo motivo che Unix possiede le 
<A HREF="Unix-Internet-Fundamentals-HOWTO-11.html#permissions">autorizzazioni sui file</A> che vedremo in dettaglio pi&ugrave; avanti.
<P>
<HR>
<A HREF="Unix-Internet-Fundamentals-HOWTO-10.html">Avanti</A>
<A HREF="Unix-Internet-Fundamentals-HOWTO-8.html">Indietro</A>
<A HREF="Unix-Internet-Fundamentals-HOWTO.html#toc9">Indice</A>
</BODY>
</HTML>