Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di
\struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono impostati
-rispettivamente al valore dell'user-ID e del group-ID effettivo del processo
+rispettivamente al valore dell'\acr{uid} e del \acr{gid} effettivo del processo
che ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
\begin{itemize*}
\item se il processo ha i privilegi di amministratore l'accesso è sempre
consentito.
-\item se l'user-ID effettivo del processo corrisponde o al valore del campo
+\item se l'\acr{uid} effettivo del processo corrisponde o al valore del campo
\var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
in \var{mode} è appropriato\footnote{per appropriato si intende che è
impostato il permesso di scrittura per le operazioni di scrittura e quello
di lettura per le operazioni di lettura.} l'accesso è consentito.
-\item se il group-ID effettivo del processo corrisponde o al
+\item se il \acr{gid} effettivo del processo corrisponde o al
valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
per il gruppo in \var{mode} è appropriato l'accesso è consentito.
\item se il permesso per gli altri è appropriato l'accesso è consentito.
altri limiti relativi al \textit{SysV IPC}) solo con una ricompilazione del
kernel, andando a modificarne la definizione nei relativi header file. A
partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
- scrivendo sui file \procrelfile{/proc/sys/kernel}{shmmni},
- \procrelfile{/proc/sys/kernel}{msgmni} e \procrelfile{/proc/sys/kernel}{sem}
+ scrivendo sui file \sysctlrelfile{kernel}{shmmni},
+ \sysctlrelfile{kernel}{msgmni} e \sysctlrelfile{kernel}{sem}
di \file{/proc/sys/kernel} o con l'uso di \func{sysctl}.} e per ciascuno di
essi viene mantenuto in \var{seq} un numero di sequenza progressivo che viene
incrementato di uno ogni volta che l'oggetto viene cancellato. Quando
negli header e corrispondenti alle prime tre costanti riportate in
tab.~\ref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
modificare questi limiti attraverso l'uso di \func{sysctl} o scrivendo nei
-file \procrelfile{/proc/sys/kernel}{msgmax},
-\procrelfile{/proc/sys/kernel}{msgmnb} e
-\procrelfile{/proc/sys/kernel}{msgmni} di \file{/proc/sys/kernel/}.
+file \sysctlrelfile{kernel}{msgmax},
+\sysctlrelfile{kernel}{msgmnb} e
+\sysctlrelfile{kernel}{msgmni} di \file{/proc/sys/kernel/}.
\begin{figure}[!htb]
\centering \includegraphics[width=13cm]{img/mqstruct}
riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su
funzioni di lettura o di scrittura sulla coda saranno svegliati ricevendo
il medesimo errore. Questo comando può essere eseguito solo da un processo
- con user-ID effettivo corrispondente al creatore o al proprietario della
+ con \acr{uid} effettivo corrispondente al creatore o al proprietario della
coda, o all'amministratore.
\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in
serie di limiti, i cui valori sono associati ad altrettante costanti, che si
sono riportate in tab.~\ref{tab:ipc_sem_limits}. Alcuni di questi limiti sono
al solito accessibili e modificabili attraverso \func{sysctl} o scrivendo
-direttamente nel file \procfile{/proc/sys/kernel/sem}.
+direttamente nel file \sysctlfile{kernel/sem}.
La funzione che permette di effettuare le varie operazioni di controllo sui
semafori (fra le quali, come accennato, è impropriamente compresa anche la
\item[\const{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture
dati, con effetto immediato. Tutti i processi che erano stato di
\textit{sleep} vengono svegliati, ritornando con un errore di
- \errcode{EIDRM}. L'user-ID effettivo del processo deve corrispondere o al
+ \errcode{EIDRM}. L'\acr{uid} effettivo del processo deve corrispondere o al
creatore o al proprietario dell'insieme, o all'amministratore. L'argomento
\param{semnum} viene ignorato.
\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
dell'insieme. I valori devono essere passati in una struttura
\struct{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i
campi \var{sem\_perm.uid}, \var{sem\_perm.gid} e i nove bit meno
- significativi di \var{sem\_perm.mode}. L'user-ID effettivo del processo deve
+ significativi di \var{sem\_perm.mode}. L'\acr{uid} effettivo del processo deve
corrispondere o al creatore o al proprietario dell'insieme, o
all'amministratore. L'argomento \param{semnum} viene ignorato.
\item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo
sblocco non servirebbe comunque, dato che l'operazione non sarebbe atomica.
Vedremo in sez.~\ref{sec:ipc_lock_file} come sia possibile ottenere
un'interfaccia analoga a quella appena illustrata, senza incorrere in questi
-problemi, usando il \index{file!locking} \textit{file locking}.
+problemi, usando il \itindex{file~locking} \textit{file locking}.
\subsection{Memoria condivisa}
& \textbf{Significato} \\
\hline
\hline
- \const{SHMALL}& 0x200000&\procrelfile{/proc/sys/kernel}{shmall}
+ \const{SHMALL}& 0x200000&\sysctlrelfile{kernel}{shmall}
& Numero massimo di pagine che
possono essere usate per i segmenti di
memoria condivisa.\\
- \const{SHMMAX}&0x2000000&\procrelfile{/proc/sys/kernel}{shmmax}
+ \const{SHMMAX}&0x2000000&\sysctlrelfile{kernel}{shmmax}
& Dimensione massima di un segmento di memoria
condivisa.\\
- \const{SHMMNI}& 4096&\procrelfile{/proc/sys/kernel}{msgmni}
+ \const{SHMMNI}& 4096&\sysctlrelfile{kernel}{msgmni}
& Numero massimo di segmenti di memoria condivisa
presenti nel kernel.\\
\const{SHMMIN}& 1& --- & Dimensione minima di un segmento di
\item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o
\const{IPC\_RMID} senza i permessi necessari.
\item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il
- valore del group-ID o dell'user-ID è troppo grande per essere
+ valore del \acr{gid} o dell'\acr{uid} è troppo grande per essere
memorizzato nella struttura puntata da \param{buf}.
\item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è
valido.
\item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la
rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
processo ad esso agganciato si sarà staccato. Questo comando può essere
- eseguito solo da un processo con user-ID effettivo corrispondente o al
+ eseguito solo da un processo con \acr{uid} effettivo corrispondente o al
creatore del segmento, o al proprietario del segmento, o all'amministratore.
\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
del segmento. Per modificare i valori di \var{shm\_perm.mode},
Dato che i \index{file!di lock} file di lock presentano gli inconvenienti
illustrati in precedenza, la tecnica alternativa di sincronizzazione più
-comune è quella di fare ricorso al \index{file!locking} \textit{file locking}
-(trattato in sez.~\ref{sec:file_locking}) usando \func{fcntl} su un file
-creato per l'occasione per ottenere un write lock. In questo modo potremo
+comune è quella di fare ricorso al \itindex{file~locking} \textit{file
+ locking} (trattato in sez.~\ref{sec:file_locking}) usando \func{fcntl} su un
+file creato per l'occasione per ottenere un write lock. In questo modo potremo
usare il lock come un \textit{mutex}: per bloccare la risorsa basterà
acquisire il lock, per sbloccarla basterà rilasciare il lock. Una richiesta
fatta con un write lock metterà automaticamente il processo in stato di
\end{minipage}
\normalsize
\caption{Il codice delle funzioni che permettono per la gestione dei
- \textit{mutex} con il \index{file!locking} \textit{file locking}.}
+ \textit{mutex} con il \itindex{file~locking} \textit{file locking}.}
\label{fig:ipc_flock_mutex}
\end{figure}
Il codice delle varie funzioni usate per implementare un mutex utilizzando il
-\textit{file locking} \index{file!locking} è riportato in
+\textit{file locking} \itindex{file~locking} è riportato in
fig.~\ref{fig:ipc_flock_mutex}; si è mantenuta volutamente una struttura
analoga alle precedenti funzioni che usano i semafori, anche se le due
interfacce non possono essere completamente equivalenti, specie per quanto
La seconda funzione (\texttt{\small 6--10}) è \func{FindMutex}, che, come la
precedente, è stata definita per mantenere una analogia con la corrispondente
funzione basata sui semafori. Anch'essa si limita (\texttt{\small 9}) ad
-aprire il file da usare per il \index{file!locking} \textit{file locking},
+aprire il file da usare per il \itindex{file~locking} \textit{file locking},
solo che in questo caso le opzioni di \func{open} sono tali che il file in
questione deve esistere di già.
rilasciare il mutex. La funzione è analoga alla precedente, solo che in questo
caso si inizializza (\texttt{\small 28--31}) la struttura \var{lock} per il
rilascio del lock, che viene effettuato (\texttt{\small 33}) con la opportuna
-chiamata a \func{fcntl}. Avendo usato il \index{file!locking} \textit{file
+chiamata a \func{fcntl}. Avendo usato il \itindex{file~locking} \textit{file
locking} in semantica POSIX (si riveda quanto detto
sez.~\ref{sec:file_posix_lock}) solo il processo che ha precedentemente
eseguito il lock può sbloccare il mutex.
sez.~\ref{sec:ipc_sysv_access_control}) che viene usata per gli oggetti del
SysV IPC. Per quanto riguarda l'attribuzione dell'utente e del gruppo
proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata
-secondo la semantica SysV: corrispondono cioè a user-ID e group-ID effettivi
+secondo la semantica SysV: corrispondono cioè a \acr{uid} e \acr{gid} effettivi
del processo che esegue la creazione.
usano la semantica standard dei file per quanto riguarda i controlli di
accesso.
-Questo significa che un nuovo semaforo viene sempre creato con l'user-ID ed il
-group-ID effettivo del processo chiamante, e che i permessi indicati con
+Questo significa che un nuovo semaforo viene sempre creato con l'\acr{uid} ed il
+\acr{gid} effettivo del processo chiamante, e che i permessi indicati con
\param{mode} vengono filtrati dal valore della \itindex{umask} \textit{umask}
del processo. Inoltre per poter aprire un semaforo è necessario avere su di
esso sia il permesso di lettura che quello di scrittura.
projects / gapil.git / blobdiff