X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=9a2002cf5ff987e31c1476e2ae0bf8a15cef80ca;hp=5841c54bd8a87cf6bc6a21bbaa7b27a0aa90caa1;hb=4aa6c51696d2b11c572eccd37238db1691785573;hpb=85590332c245e487cff2b566b2df286acc4289ee diff --git a/ipc.tex b/ipc.tex index 5841c54..9a2002c 100644 --- a/ipc.tex +++ b/ipc.tex @@ -1,6 +1,6 @@ %% ipc.tex %% -%% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free %% Documentation License, Version 1.1 or any later version published by the %% Free Software Foundation; with the Invariant Sections being "Un preambolo", @@ -619,7 +619,7 @@ principale del programma e le definizioni delle variabili. Il codice completo \end{figure} La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà -essere utilizzata per ricevere la risposta dal server. Si usa il \acr{pid} +essere utilizzata per ricevere la risposta dal server. Si usa il \ids{PID} del processo per essere sicuri di avere un nome univoco; dopo di che (\texttt{\small 13-18}) si procede alla creazione del relativo file, uscendo in caso di errore (a meno che il file non sia già presente sul filesystem). @@ -817,7 +817,7 @@ utilizzando, con tutte le conseguenze (negative) del caso. Un'ulteriore caratteristica negativa è che gli oggetti usati nel \textit{SysV IPC} vengono creati direttamente dal kernel, e sono accessibili solo specificando il relativo \textsl{identificatore}. Questo è un numero -progressivo (un po' come il \acr{pid} dei processi) che il kernel assegna a +progressivo (un po' come il \ids{PID} dei processi) che il kernel assegna a ciascuno di essi quanto vengono creati (sul procedimento di assegnazione torneremo in sez.~\ref{sec:ipc_sysv_id_use}). L'identificatore viene restituito dalle funzioni che creano l'oggetto, ed è quindi locale al processo che le ha @@ -947,7 +947,7 @@ il proprietario, il suo gruppo e tutti gli altri. 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'\acr{uid} e del \acr{gid} effettivo del processo +rispettivamente al valore dell'\ids{UID} e del \ids{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. @@ -967,12 +967,12 @@ controlli è simile a quello dei file, ed avviene secondo questa sequenza: \begin{itemize*} \item se il processo ha i privilegi di amministratore l'accesso è sempre consentito. -\item se l'\acr{uid} effettivo del processo corrisponde o al valore del campo +\item se l'\ids{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 \acr{gid} effettivo del processo corrisponde o al +\item se il \ids{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. @@ -1021,8 +1021,8 @@ Il sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino 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 @@ -1182,9 +1182,9 @@ Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti 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} @@ -1244,7 +1244,7 @@ gli altri campi invece: \item il campo \var{msg\_qnum}, che esprime il numero di messaggi presenti sulla coda, viene inizializzato a 0. \item i campi \var{msg\_lspid} e \var{msg\_lrpid}, che esprimono - rispettivamente il \acr{pid} dell'ultimo processo che ha inviato o ricevuto + rispettivamente il \ids{PID} dell'ultimo processo che ha inviato o ricevuto un messaggio sulla coda, sono inizializzati a 0. \item i campi \var{msg\_stime} e \var{msg\_rtime}, che esprimono rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo @@ -1303,7 +1303,7 @@ eseguire; i valori possibili sono: 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 \acr{uid} effettivo corrispondente al creatore o al proprietario della + con \ids{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 @@ -1416,7 +1416,7 @@ Una volta completato con successo l'invio del messaggio sulla coda, la funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare vengono modificati: \begin{itemize*} -\item Il valore di \var{msg\_lspid}, che viene impostato al \acr{pid} del +\item Il valore di \var{msg\_lspid}, che viene impostato al \ids{PID} del processo chiamante. \item Il valore di \var{msg\_qnum}, che viene incrementato di uno. \item Il valore \var{msg\_stime}, che viene impostato al tempo corrente. @@ -1502,7 +1502,7 @@ Una volta completata con successo l'estrazione del messaggio dalla coda, la funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare vengono modificati: \begin{itemize*} -\item Il valore di \var{msg\_lrpid}, che viene impostato al \acr{pid} del +\item Il valore di \var{msg\_lrpid}, che viene impostato al \ids{PID} del processo chiamante. \item Il valore di \var{msg\_qnum}, che viene decrementato di uno. \item Il valore \var{msg\_rtime}, che viene impostato al tempo corrente. @@ -1547,7 +1547,7 @@ principali del codice del nuovo server (il codice completo è nel file \file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un uso accorto della caratteristica di poter associate un ``tipo'' ai messaggi per permettere una comunicazione indipendente fra il server ed i vari client, -usando il \acr{pid} di questi ultimi come identificativo. Questo è possibile +usando il \ids{PID} di questi ultimi come identificativo. Questo è possibile in quanto, al contrario di una fifo, la lettura di una coda di messaggi può non essere sequenziale, proprio grazie alla classificazione dei messaggi sulla base del loro tipo. @@ -1581,9 +1581,9 @@ il ciclo principale (\texttt{\small 33--40}). Questo inizia (\texttt{\small 34}) con il porsi in attesa di un messaggio di richiesta da parte di un client; si noti infatti come \func{msgrcv} richieda un messaggio con \var{mtype} uguale a 1: questo è il valore usato per le richieste dato che -corrisponde al \acr{pid} di \cmd{init}, che non può essere un client. L'uso +corrisponde al \ids{PID} di \cmd{init}, che non può essere un client. L'uso del flag \const{MSG\_NOERROR} è solo per sicurezza, dato che i messaggi di -richiesta sono di dimensione fissa (e contengono solo il \acr{pid} del +richiesta sono di dimensione fissa (e contengono solo il \ids{PID} del client). Se non sono presenti messaggi di richiesta \func{msgrcv} si bloccherà, @@ -1595,7 +1595,7 @@ calcolandone (\texttt{\small 37}) la dimensione. Per poter permettere a ciascun client di ricevere solo la risposta indirizzata a lui il tipo del messaggio in uscita viene inizializzato (\texttt{\small 38}) -al valore del \acr{pid} del client ricevuto nel messaggio di richiesta. +al valore del \ids{PID} del client ricevuto nel messaggio di richiesta. L'ultimo passo del ciclo (\texttt{\small 39}) è inviare sulla coda il messaggio di risposta. Si tenga conto che se la coda è piena anche questa funzione potrà bloccarsi fintanto che non venga liberato dello spazio. @@ -1633,13 +1633,13 @@ il programma termina immediatamente. Una volta acquisito l'identificatore della coda il client compone il messaggio di richiesta (\texttt{\small 12--13}) in \var{msg\_read}, usando 1 -per il tipo ed inserendo il proprio \acr{pid} come dato da passare al server. +per il tipo ed inserendo il proprio \ids{PID} come dato da passare al server. Calcolata (\texttt{\small 14}) la dimensione, provvede (\texttt{\small 15}) ad immettere la richiesta sulla coda. A questo punto non resta che (\texttt{\small 16}) rileggere dalla coda la risposta del server richiedendo a \func{msgrcv} di selezionare i messaggi di -tipo corrispondente al valore del \acr{pid} inviato nella richiesta. L'ultimo +tipo corrispondente al valore del \ids{PID} inviato nella richiesta. L'ultimo passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il messaggio ricevuto. @@ -1687,7 +1687,7 @@ della risposta, quest'ultima resta nella coda (così come per le fifo si aveva il problema delle fifo che restavano nel filesystem). In questo caso però il problemi sono maggiori, sia perché è molto più facile esaurire la memoria dedicata ad una coda di messaggi che gli \itindex{inode} inode di un filesystem, -sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client +sia perché, con il riutilizzo dei \ids{PID} da parte dei processi, un client eseguito in un momento successivo potrebbe ricevere un messaggio non indirizzato a lui. @@ -1851,7 +1851,7 @@ I dati mantenuti nella struttura, ed elencati in fig.~\ref{fig:ipc_sem}, indicano rispettivamente: \begin{description*} \item[\var{semval}] il valore numerico del semaforo. -\item[\var{sempid}] il \acr{pid} dell'ultimo processo che ha eseguito una +\item[\var{sempid}] il \ids{PID} dell'ultimo processo che ha eseguito una operazione sul semaforo. \item[\var{semncnt}] il numero di processi in attesa che esso venga incrementato. @@ -1888,7 +1888,7 @@ Come per le code di messaggi anche per gli insiemi di semafori esistono una 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 @@ -1957,14 +1957,14 @@ seguenti: \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'\acr{uid} effettivo del processo deve corrispondere o al + \errcode{EIDRM}. L'\ids{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'\acr{uid} effettivo del processo deve + significativi di \var{sem\_perm.mode}. L'\ids{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 @@ -1977,7 +1977,7 @@ seguenti: \struct{sem}); va invocata con tre argomenti. Occorre avere il permesso di lettura. \item[\const{GETPID}] Restituisce come valore di ritorno della funzione il - \acr{pid} dell'ultimo processo che ha compiuto una operazione sul semaforo + \ids{PID} dell'ultimo processo che ha compiuto una operazione sul semaforo \param{semnum} dell'insieme \param{semid} (corrispondente al campo \var{sempid} di \struct{sem}); va invocata con tre argomenti. Occorre avere il permesso di lettura. @@ -2159,7 +2159,7 @@ possibili: \end{basedescript} In caso di successo della funzione viene aggiornato il campo \var{sempid} per -ogni semaforo modificato al valore del \acr{pid} del processo chiamante; +ogni semaforo modificato al valore del \ids{PID} del processo chiamante; inoltre vengono pure aggiornati al tempo corrente i campi \var{sem\_otime} e \var{sem\_ctime}. @@ -2319,7 +2319,7 @@ controllare il valore dei mutex prima di proseguire in una operazione di 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} @@ -2405,10 +2405,10 @@ invece: \item i campi \var{shm\_atime} e \var{shm\_dtime}, che esprimono rispettivamente il tempo dell'ultima volta che il segmento è stato agganciato o sganciato da un processo, vengono inizializzati a zero. -\item il campo \var{shm\_lpid}, che esprime il \acr{pid} del processo che ha +\item il campo \var{shm\_lpid}, che esprime il \ids{PID} del processo che ha eseguito l'ultima operazione, viene inizializzato a zero. -\item il campo \var{shm\_cpid}, che esprime il \acr{pid} del processo che ha - creato il segmento, viene inizializzato al \acr{pid} del processo chiamante. +\item il campo \var{shm\_cpid}, che esprime il \ids{PID} del processo che ha + creato il segmento, viene inizializzato al \ids{PID} del processo chiamante. \item il campo \var{shm\_nattac}, che esprime il numero di processi agganciati al segmento viene inizializzato a zero. \end{itemize} @@ -2434,14 +2434,14 @@ che permettono di cambiarne il valore. & \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 @@ -2485,7 +2485,7 @@ un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è: \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 \acr{gid} o dell'\acr{uid} è troppo grande per essere + valore del \ids{GID} o dell'\ids{UID} è troppo grande per essere memorizzato nella struttura puntata da \param{buf}. \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è valido. @@ -2504,7 +2504,7 @@ corrispondente comportamento della funzione, sono i seguenti: \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 \acr{uid} effettivo corrispondente o al + eseguito solo da un processo con \ids{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}, @@ -2618,7 +2618,7 @@ In caso di successo la funzione aggiorna anche i seguenti campi di \begin{itemize*} \item il tempo \var{shm\_atime} dell'ultima operazione di aggancio viene impostato al tempo corrente. -\item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul +\item il \ids{PID} \var{shm\_lpid} dell'ultimo processo che ha operato sul segmento viene impostato a quello del processo corrente. \item il numero \var{shm\_nattch} di processi agganciati al segmento viene aumentato di uno. @@ -2659,7 +2659,7 @@ In caso di successo la funzione aggiorna anche i seguenti campi di \begin{itemize*} \item il tempo \var{shm\_dtime} dell'ultima operazione di sganciamento viene impostato al tempo corrente. -\item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul +\item il \ids{PID} \var{shm\_lpid} dell'ultimo processo che ha operato sul segmento viene impostato a quello del processo corrente. \item il numero \var{shm\_nattch} di processi agganciati al segmento viene decrementato di uno. @@ -3117,9 +3117,9 @@ accedere alla seriale si limita a segnalare che la risorsa non è disponibile. 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 @@ -3141,12 +3141,12 @@ leggermente più lento. \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 @@ -3163,7 +3163,7 @@ mutex. 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à. @@ -3180,7 +3180,7 @@ La quarta funzione (\texttt{\small 24--34}) è \func{UnlockMutex} e serve a 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. @@ -3324,7 +3324,7 @@ quella particolare (si ricordi quanto visto in 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 \acr{uid} e \acr{gid} effettivi +secondo la semantica SysV: corrispondono cioè a \ids{UID} e \ids{GID} effettivi del processo che esegue la creazione. @@ -3334,8 +3334,7 @@ del processo che esegue la creazione. Le code di messaggi POSIX sono supportate da Linux a partire dalla versione 2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e Krzysztof Benedyczak, e le relative informazioni si possono trovare su - \href{http://www.geocities.com/wronski12/posix_ipc/index.html} - {\textsf{http://www.geocities.com/wronski12/posix\_ipc/index.html}}.} In + \url{http://www.geocities.com/wronski12/posix_ipc/index.html}.} In generale, come le corrispettive del SysV IPC, le code di messaggi sono poco usate, dato che i socket, nei casi in cui sono sufficienti, sono più comodi, e che in casi più complessi la comunicazione può essere gestita direttamente con @@ -3772,7 +3771,7 @@ questa operazione prima di estrarre i messaggi presenti dalla coda. L'invio del segnale di notifica avvalora alcuni campi di informazione restituiti al gestore attraverso la struttura \struct{siginfo\_t} (definita in fig.~\ref{fig:sig_siginfo_t}). In particolare \var{si\_pid} viene impostato al -valore del \acr{pid} del processo che ha emesso il segnale, \var{si\_uid} +valore del \ids{PID} del processo che ha emesso il segnale, \var{si\_uid} all'userid effettivo, \var{si\_code} a \const{SI\_MESGQ}, e \var{si\_errno} a 0. Questo ci dice che, se si effettua la ricezione dei messaggi usando esclusivamente il meccanismo di notifica, è possibile ottenere le informazioni @@ -4055,8 +4054,8 @@ presente che, come accennato in sez.~\ref{sec:ipc_posix_generic}, i semafori usano la semantica standard dei file per quanto riguarda i controlli di accesso. -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 +Questo significa che un nuovo semaforo viene sempre creato con l'\ids{UID} ed +il \ids{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.