-\section{L'architettura dell'accesso}
+\section{L'architettura generale}
\label{sec:file_access_arch}
Per poter accedere ai file il kernel deve mettere a disposizione dei programmi
cioè deve provvedere ad organizzare e rendere accessibile in maniera opportuna
l'informazione tenuta sullo spazio grezzo disponibile sui dischi. Questo viene
fatto strutturando l'informazione sul disco attraverso quello che si chiama un
-\textit{filesystem}, essa poi viene resa disponibile ai processi attraverso
-quello che viene chiamato il \textsl{montaggio} del filesystem.
+\textit{filesystem} (vedi \ref{sec:file_arch_func}), essa poi viene resa
+disponibile ai processi attraverso quello che viene chiamato il
+\textsl{montaggio} del \textit{filesystem}.
% (approfondiremo tutto ciò in \secref{sec:file_arch_func}).
In questa sezione faremo una panormamica generica su come il sistema presenta
ricerca (come quello in cui si cercano i comandi) non seguiremo questa
scelta dato che l'uso della parola \textit{pathname} è ormai così comune che
mantenerne l'uso è senz'altro più chiaro dell'alternativa proposta.}, cioè
-il percorso che si deve fare per accedere al file, che è composto da una serie
-di nomi separati da una \file{/}.
+il percorso che si deve fare per accedere al file a partire dalla \textit{root
+ directory}, che è composto da una serie di nomi separati da una \file{/}.
-Dopo la fase di inizializzazione il kernel riceve dal boot loader
-l'indicazione di quale dispositivo contiene il filesystem da usare come punto
-di partenza e questo viene montato come radice dell'albero (cioè nella
-directory \file{/}); tutti gli ulteriori filesystem che possono essere su
-altri dispositivi devono poi essere inseriti nell'albero montandoli su
-opportune directory del filesystem montato come radice.
+All'avvio del sistema, comletata la fase di inizializzazione il kernel riceve
+dal boot loader l'indicazione di quale dispositivo contiene il filesystem da
+usare come punto di partenza e questo viene montato come radice dell'albero
+(cioè nella directory \file{/}); tutti gli ulteriori filesystem che possono
+essere su altri dispositivi dovranno poi essere inseriti nell'albero
+montandoli su opportune directory del filesystem montato come radice.
Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad
alcune strutture interne del kernel) sono generati automaticamente dal kernel
procedimento con cui si individua il file a cui esso fa riferimento è chiamato
risoluzione del nome (\textit{file name resolution} o \textit{pathname
resolution}). La risoluzione viene fatta esaminando il \textit{pathname} da
-destra a sinistra e localizzando ogni nome nella directory indicata dal nome
+sinistra a destra e localizzando ogni nome nella directory indicata dal nome
precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il
costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente
perché il procedimento funzioni occorre che i nomi indicati come directory
\subsection{I tipi di file}
\label{sec:file_file_types}
-Come detto in precedenza in unix esistono vari tipi di file, in Linux questi
+Come detto in precedenza in Unix esistono vari tipi di file, in Linux questi
sono implementati come oggetti del \textit{Virtual File System} (vedi
\secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
un file che identifica una periferica ad accesso sequenziale \\
\textit{block device} & \textsl{dispositivo a blocchi} &
un file che identifica una periferica ad accesso diretto \\
- \textit{fifo} & \textsl{tubo} &
+ \textit{fifo} & \textsl{``tubo''} &
un file speciale che identifica una linea di comunicazione software
(unidirezionale) \\
- \textit{socket} & \textsl{manicotto} &
+ \textit{socket} & \textsl{``spina''} &
un file speciale che identifica una linea di comunicazione software
(bidirezionale) \\
\hline
problemi qualora nei programmi si facciano assunzioni sul terminatore della
riga.
+Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di
+dati e che non c'è nessun supporto del sistema per le estensioni come parte
+del filesystem. Ciò non ostante molti programmi adottano delle convenzioni per
+i nomi dei file, ad esempio il codice C normalmente si mette in file con
+l'estensione \file{.c}, ma questa è, appunto, solo una convenzione.
+
+
\subsection{Le due interfacce ai file}
\label{sec:file_io_api}
-In unix le modalità di accesso ai file e le relative interfacce di
+In Linux le modalità di accesso ai file e le relative interfacce di
programmazione sono due, basate su due diversi meccanismi con cui è possibile
accedere al loro contenuto.
-La prima è l'interfaccia standard di unix, quella che il manuale delle
+La prima è l'interfaccia standard di Unix, quella che il manuale delle
\acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file
- descriptor}). È un'interfaccia specifica di unix e provvede un accesso non
-bufferizzato, la tratteremo in dettaglio in \capref{cha:file_unix_interface}.
+ descriptor}). È un'interfaccia specifica dei sistemi unix-like e provvede
+un accesso non bufferizzato; la tratteremo in dettaglio in
+\capref{cha:file_unix_interface}.
L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
\textit{stream}\index{stream}, essa provvede funzioni più evolute e un accesso
-bufferizzato (controllato dalla implementazione fatta dalle librerie del C),
-la tratteremo in dettaglio in \capref{cha:files_std_interface}.
+bufferizzato (controllato dalla implementazione fatta dalle \acr{glibc}), la
+tratteremo in dettaglio nel \capref{cha:files_std_interface}.
Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
anche su tutti i sistemi non Unix. Gli \textit{stream} sono oggetti complessi
Entrambe le interfacce possono essere usate per l'accesso ai file come agli
altri oggetti del VFS (pipe, socket, device, sui quali torneremo in dettaglio
-a tempo opportuno), ma per poter accedere alle operazioni di controllo sul
-particolare tipo di oggetto del VFS scelto occorre usare l'interfaccia
-standard di Unix coi \textit{file descriptor}. Allo stesso modo devono essere
-usati i \textit{file descriptor} se si vuole ricorrere a modalità speciali di
-I/O come il polling o il non-bloccante (vedi \capref{cha:file_advanced}).
+a tempo opportuno), ma per poter accedere alle operazioni di controllo su un
+qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix
+coi \textit{file descriptor}. Allo stesso modo devono essere usati i
+\textit{file descriptor} se si vuole ricorrere a modalità speciali di I/O come
+il polling o il non-bloccante (vedi \capref{cha:file_advanced}).
Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
-quella dei \textit{file descriptor}, che tratta tutti i file nello stesso
-modo, con l'eccezione di poter scegliere tra diversi stili di bufferizzazione.
-Il maggior vantaggio degli \textit{stream} è che l'interfaccia per le
-operazioni di input/output è enormemente più ricca di quella dei \textit{file
- descriptor}, che provvedono solo funzioni elementari per la
-lettura/scrittura diretta di blocchi di byte. In particolare gli
-\textit{stream} dispongono di tutte le funzioni di formattazione per l'input e
-l'output adatte per manipolare anche i dati in forma di linee o singoli
-caratteri.
+quella dei \textit{file descriptor}, che permette di poter scegliere tra
+diversi stili di bufferizzazione. Il maggior vantaggio degli \textit{stream}
+è che l'interfaccia per le operazioni di input/output è enormemente più ricca
+di quella dei \textit{file descriptor}, che provvedono solo funzioni
+elementari per la lettura/scrittura diretta di blocchi di byte. In
+particolare gli \textit{stream} dispongono di tutte le funzioni di
+formattazione per l'input e l'output adatte per manipolare anche i dati in
+forma di linee o singoli caratteri.
In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da
In generale, se non necessitano specificatamente le funzionalità di basso
livello, è opportuno usare sempre gli \textit{stream} per la loro maggiore
-portabilità essendo questi ultimi definiti nello standard ANSI C;
-l'interfaccia con i \textit{file descriptor} invece segue solo lo standard
-POSIX.1 dei sistemi unix ed è pertanto di portabilità più limitata.
-
-
-\subsection{Caratteristiche specifiche dei file in Unix}
-\label{sec:fileint_unix_spec}
-
-Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
-specifiche di un sistema unix-like che devono essere tenute in conto
-nell'accesso ai file. È infatti normale che più processi o programmi possano
-accedere contemporaneamente allo stesso file e devono poter eseguire le loro
-operazioni indipendentemente da quello che fanno gli altri processi.
-
-Per questo motivo le strutture usate per all'accesso ai file sono relative al
-processo che effettua l'accesso. All'apertura di ogni file infatti viene
-creata all'interno del processo una apposita struttura in cui sono memorizzati
-tutti gli attributi del medesimo, che viene utilizzata per tutte le
-operazioni. Questa è una struttura che resta locale al processo stesso; in
-questo modo processi diversi possono usare le proprie strutture locali per
-accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
-indipendente.
-
-Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
-sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
-file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
-successiva. Essa è rappresentata da un numero intero che indica il numero di
-byte dall'inizio del file, che viene (a meno che non si apra il file in
-append) inizializzato a zero all'apertura del medesimo.
-
-Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
-ogni processo avrà la sua posizione corrente nel file, che non sarà
-influenzata da quello che altri processi possono fare. Anzi, aprire un file
-significa appunto creare ed inizializzare una tale struttura, per cui se si
-apre due volte lo stesso file all'interno dello stesso processo, si otterranno
-due file descriptor o due stream che avranno ancora una posizione corrente nel
-file assolutamente indipendente.
-
-Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
-accesso è un riferimento all'inode del file, pertanto anche se il file viene
-cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
-dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
-chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
-in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per
-cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
-file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
-saranno disponibili per tutto il tempo in cui il processo è attivo.
-
-Ritorneremo su questo più avanti in \secref{sec:file_fd}, quando tratteremo
-l'input/output sui file, esaminando in dettaglio come tutto ciò viene
-realizzato.
-
-Si ricordi infine che in ambiente unix non esistono i tipi di file e che non
-c'è nessun supporto per le estensioni come parte del filesystem. Ciò non
-ostante molti programmi adottano delle convenzioni per i nomi dei file, ad
-esempio il codice C normalmente si mette in file con l'estensione .c, ma
-questa è, appunto, solo una convenzione.
-
-
-\section{L'architettura di funzionamento}
+portabilità, essendo questi ultimi definiti nello standard ANSI C;
+l'interfaccia con i \textit{file descriptor} infatti segue solo lo standard
+POSIX.1 dei sistemi Unix, ed è pertanto di portabilità più limitata.
+
+
+% \subsection{Caratteristiche specifiche dei file in Unix}
+% \label{sec:fileint_unix_spec}
+
+% Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
+% specifiche di un sistema unix-like che devono essere tenute in conto
+% nell'accesso ai file. È infatti normale che più processi o programmi possano
+% accedere contemporaneamente allo stesso file e devono poter eseguire le loro
+% operazioni indipendentemente da quello che fanno gli altri processi.
+
+% Per questo motivo le strutture usate per all'accesso ai file sono relative al
+% processo che effettua l'accesso. All'apertura di ogni file infatti viene
+% creata all'interno del processo una apposita struttura in cui sono memorizzati
+% tutti gli attributi del medesimo, che viene utilizzata per tutte le
+% operazioni. Questa è una struttura che resta locale al processo stesso; in
+% questo modo processi diversi possono usare le proprie strutture locali per
+% accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
+% indipendente.
+
+% Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
+% sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
+% file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
+% successiva. Essa è rappresentata da un numero intero che indica il numero di
+% byte dall'inizio del file, che viene (a meno che non si apra il file in
+% append) inizializzato a zero all'apertura del medesimo.
+
+% Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
+% ogni processo avrà la sua posizione corrente nel file, che non sarà
+% influenzata da quello che altri processi possono fare. Anzi, aprire un file
+% significa appunto creare ed inizializzare una tale struttura, per cui se si
+% apre due volte lo stesso file all'interno dello stesso processo, si otterranno
+% due file descriptor o due stream che avranno ancora una posizione corrente nel
+% file assolutamente indipendente.
+
+% Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
+% accesso è un riferimento all'inode del file, pertanto anche se il file viene
+% cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
+% dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
+% chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
+% in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per
+% cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
+% file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
+% saranno disponibili per tutto il tempo in cui il processo è attivo.
+
+% Ritorneremo su questo più avanti in \secref{sec:file_fd}, quando tratteremo
+% l'input/output sui file, esaminando in dettaglio come tutto ciò viene
+% realizzato.
+
+
+\section{L'architettura della gestione dei file}
\label{sec:file_arch_func}
Per capire fino in fondo le proprietà di file e directory in un sistema
\subsection{Le funzioni \func{wait3} e \func{wait4}}
\label{sec:proc_wait4}
-Linux, seguendo una estensione di BSD, supporta altre due funzioni,
-\func{wait} e \func{waitpd}, per la lettura dello stato di terminazione di un
-processo, analoghe alle precedenti ma che prevedono un ulteriore parametro
-attraverso il quale il kernel può restituire al padre informazioni sulle
-risorse usate dal processo terminato e dai vari figli. I prototipi di queste
-funzioni, che diventano accessibili definendo la costante \macro{\_USE\_BSD},
-sono:
+Linux, seguendo una estensione di BSD, supporta altre due funzioni per la
+lettura dello stato di terminazione di un processo \func{wait3} e
+\func{wait4}, analoghe alle precedenti ma che prevedono un ulteriore
+parametro attraverso il quale il kernel può restituire al padre informazioni
+sulle risorse usate dal processo terminato e dai vari figli. I prototipi di
+queste funzioni, che diventano accessibili definendo la costante
+\macro{\_USE\_BSD}, sono:
\begin{functions}
\headdecl{sys/times.h}
\headdecl{sys/types.h}
\begin{errlist}
\item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è
montato in \cmd{noexec}, oppure non è un file normale o un interprete.
- \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid} ma l'utente non
- è root o il filesystem è montato con \cmd{nosuid}, oppure
+ \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente non
+ è root, e o il processo viene tracciato, o il filesystem è montato con
+ l'opzione \cmd{nosuid}.
\item[\macro{ENOEXEC}] il file è in un formato non eseguibile o non
riconosciuto come tale, o compilato per un'altra architettura.
\item[\macro{ENOENT}] il file o una delle librerie dinamiche o l'interprete
può anche non essere resettato a \macro{SIG\_DFL} (si veda
\secref{sec:sig_xxx}).
-La gestione dei file aperti dipende dal valore del flag di
-\textit{close-on-exec} per ciascun file descriptor (si veda
-\secref{sec:file_fcntl}); i file per cui è settato vengono chiusi, tutti gli
-altri file restano aperti. Questo significa che il comportamento di default è
-che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
-esplicita a \func{fcntl} che setti il suddetto flag.
+La gestione dei file aperti dipende dal valore che ha il flag di
+\textit{close-on-exec} (trattato in \secref{sec:file_fcntl}) per ciascun file
+descriptor. I file per cui è settato vengono chiusi, tutti gli altri file
+restano aperti. Questo significa che il comportamento di default è che i file
+restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
+\func{fcntl} che setti il suddetto flag.
Per le directory lo standard POSIX.1 richiede che esse vengano chiuse
attraverso una \func{exec}, in genere questo è fatto dalla funzione
Abbiamo detto che il \textit{real user id} ed il \textit{real group id}
restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
-l'\textit{effective user id} ed l'\textit{effective group id}, tranne il caso
-in cui il file che si va ad eseguire ha o il \acr{suid} bit o lo \acr{sgid}
-bit settato, nel qual caso \textit{effective user id} e \textit{effective
+l'\textit{effective user id} ed l'\textit{effective group id}, tranne quando
+il file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} bit
+settato, in questo caso l'\textit{effective user id} e l'\textit{effective
group id} vengono settati rispettivamente all'utente o al gruppo cui il file
appartiene (per i dettagli vedi \secref{sec:proc_perms}).
In questa sezione esamineremo le problematiche relative al controllo di
accesso dal punto di vista del processi; vedremo quali sono gli identificatori
usati, come questi possono essere modificati nella creazione e nel lancio di
-nuovi processi, e le varie funzioni per la loro manipolazione diretta e tutte
-le problematiche connesse ad una gestione accorta dei privilegi.
+nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
+problematiche connesse ad una gestione accorta dei privilegi.
\subsection{Gli identificatori del controllo di accesso}
anche poter identificare chi è che ha lanciato un certo programma, e pertanto
anche a ciascun processo è associato un utente e a un gruppo.
-Un semplice controllo di una corrispondenza fra identificativi però non
-garantisce però sufficiente flessibilità per tutti quei casi in cui è
-necessario poter disporre di privilegi diversi, o dover impersonare un altro
-utente per un limitato insieme di operazioni. Per questo motivo in generale
-tutti gli Unix prevedono che i processi abbiano almeno due gruppi di
-identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}.
+Un semplice controllo di una corrispondenza fra identificativi non garantisce
+però sufficiente flessibilità per tutti quei casi in cui è necessario poter
+disporre di privilegi diversi, o dover impersonare un altro utente per un
+limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
+prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
+rispettivamente \textit{real} ed \textit{effective}.
\begin{table}[htb]
\footnotesize
l'identificazione dell'utente e normalmente non vengono mai cambiati. In
realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, ma
solo ad un processo che abbia i privilegi di amministratore; questa
-possibilità è usata ad esempio da \cmd{login} che una volta completata la
-procedura di autenticazione lancia una shell per la quale setta questi
+possibilità è usata ad esempio da \cmd{login} che, una volta completata la
+procedura di autenticazione, lancia una shell per la quale setta questi
identificatori ai valori corrispondenti all'utente che entra nel sistema.
Al secondo gruppo appartengono l'\textit{effective user id} e
\secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
\acr{suid} o \acr{sgid} settati (il significato di questi bit è affrontato in
dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno settati
-all'utente e al gruppo proprietari del file; questo consente, per programmi in
+all'utente e al gruppo proprietari del file. Questo consente, per programmi in
cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
di un'altro (o dell'amministratore).
Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
la prima; la seconda si comporta esattamente allo stesso modo facendo
riferimento al \textit{group id} invece che all'\textit{user id}. Gli
-eventuali \textit{supplementary group id} non vengono modificati da nessuna
-delle funzioni che tratteremo in questa sezione.
+eventuali \textit{supplementary group id} non vengono modificati.
L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
eventualmente tornare indietro.
-Come esempio per chiarire dell'uso di queste funzioni prediamo quello con cui
+Come esempio per chiarire dell'uso di queste funzioni prendiamo quello con cui
viene gestito l'accesso al file \file{/var/log/utmp}. In questo file viene
registrato chi sta usando il sistema al momento corrente; chiaramente non può
essere lasciato aperto in scrittura a qualunque utente, che potrebbe
falsificare la registrazione. Per questo motivo questo file (e l'analogo
\file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
-esempio tutti i programmi di terminale in X, o il programma \cmd{screen}
-che crea terminali multipli su una console) appartengono a questo gruppo ed
-hanno il bit \acr{sgid} settato.
+esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che
+crea terminali multipli su una console) appartengono a questo gruppo ed hanno
+il bit \acr{sgid} settato.
Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato la
situazione degli identificatori è la seguente:
\label{sec:proc_setreuid}
Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino
- alla versione 4.3+BSD TODO, verificare e aggiornare la nota.} i
+ alla versione 4.3+BSD TODO, FIXME verificare e aggiornare la nota.} i
\textit{saved id}, le usava per poter scambiare fra di loro \textit{effective}
e \textit{real id}. I loro prototipi sono:
\begin{functions}
restituisce 0 in caso di successo e -1 in caso di fallimento.}
\end{functions}
\noindent la funzione esegue una scansione del database dei gruppi (si veda
-\secref{sec:sys_xxx}) e ritorna in \param{groups} la lista di quelli a cui
-l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore
+\secref{sec:sys_user_group}) e ritorna in \param{groups} la lista di quelli a
+cui l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore
perché qualora il valore specificato sia troppo piccolo la funzione ritorna -1
e passando indietro il numero dei gruppi trovati.
esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
programma alla volta.
-Pur essendo questo argomento di carattere generale, in questa sezione
-conclusiva del capitolo in cui abbiamo affrontato la gestione dei processi ci
-è parso opportuno introdurre sinteticamente queste problematiche, che
-ritroveremo a più riprese in capitoli successivi, dando una breve descrizione
-delle loro caratteristiche principali e della terminologia relativa.
+Pur essendo questo argomento di carattere generale, ci è parso opportuno
+introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
+in capitoli successivi, in questa sezione conclusiva del capitolo in cui
+abbiamo affrontato la gestione dei processi.
\subsection{Le operazioni atomiche}
Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
-\capref{cha:IPC}) o nella operazioni con i file (vedremo alcuni esempi in
+\capref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
\secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
funzioni di libreria per compiere le operazioni necessarie è garanzia
sufficiente di atomicità in quanto le system call con cui esse sono realizzate
In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
il cui accesso è assicurato essere atomico. In pratica comunque si può
-assumere che in ogni piattaforma su cui è implementato Linux il tipo
-\type{int} (e gli altri interi di dimensione inferiore) ed i puntatori sono
+assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
+\type{int}, gli altri interi di dimensione inferiore ed i puntatori sono
atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
-le strutture. In questi casi è anche opportuno marcare come \type{volatile} le
-variabili che possono essere interessate ad accesso condiviso, onde evitare
-problemi con le ottimizzazioni del codice.
+le strutture. In tutti questi casi è anche opportuno marcare come
+\type{volatile} le variabili che possono essere interessate ad accesso
+condiviso, onde evitare problemi con le ottimizzazioni del codice.
\subsection{Le \textit{race condition} e i \textit{deadlock}}
Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
diversi operano su una risorsa comune, ed in cui il risultato viene a
dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
-tipico è quella di una operazione che viene eseguita da un processo in più
+tipico è quello di una operazione che viene eseguita da un processo in più
passi, e può essere compromessa dall'intervento di un altro processo che
accede alla stessa risorsa quando ancora non tutti i passi sono stati
completati.
file, o nell'accesso a meccanismi di intercomunicazione come la memoria
condivisa. In questi casi, se non si dispone della possibilità di eseguire
atomicamente le operazioni necessarie, occorre che quelle parti di codice in
-cui si compiono le operazioni critiche sulle risorse condivise, le cosiddette
-\textsl{sezioni critiche} del programma, siano opportunamente protette da
+cui si compiono le operazioni sulle risorse condivise (le cosiddette
+\textsl{sezioni critiche}) del programma, siano opportunamente protette da
meccanismi di sincronizzazione (torneremo su queste problematiche di questo
tipo in \secref{sec:ipc_semaph}).
In tutti questi casi è di fondamentale importanza il concetto di atomicità
visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere
risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
-eseguire in maniera atomica le operazioni necessarie, proteggendo con gli
-adeguati meccanismi le \textsl{sezioni critiche} del programma.
+eseguire in maniera atomica le operazioni necessarie.
\subsection{Le funzioni rientranti}
projects / gapil.git / commitdiff