+Le funzioni di sistema più comuni che vengono usate per cambiare identità
+(cioè utente e gruppo di appartenenza) ad un processo, e che come accennato in
+sez.~\ref{sec:proc_access_id} seguono la semantica POSIX che prevede
+l'esistenza dell'\ids{UID} salvato e del \ids{GID} salvato, sono
+rispettivamente \funcd{setuid} e \funcd{setgid}; i loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{sys/types.h}
+\fdecl{int setuid(uid\_t uid)}
+\fdesc{Imposta l'\ids{UID} del processo corrente.}
+\fdecl{int setgid(gid\_t gid)}
+\fdesc{Imposta il \ids{GID} del processo corrente.}
+}
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+caso \var{errno} può assumere solo il valore \errcode{EPERM}.
+}
+\end{funcproto}
+
+Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
+la prima, la seconda si comporta esattamente allo stesso modo facendo
+riferimento al \ids{GID} invece che all'\ids{UID}. Gli eventuali \ids{GID}
+supplementari non vengono modificati.
+
+L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
+l'\ids{UID} effettivo è zero (cioè è quello dell'amministratore di sistema)
+allora tutti gli identificatori (\textit{real}, \textit{effective} e
+\textit{saved}) vengono impostati al valore specificato da \param{uid},
+altrimenti viene impostato solo l'\ids{UID} effettivo, e soltanto se il valore
+specificato corrisponde o all'\ids{UID} reale o all'\ids{UID} salvato. Negli
+altri casi viene segnalato un errore con \errcode{EPERM}.
+
+Come accennato l'uso principale di queste funzioni è quello di poter
+consentire ad un programma con i bit \itindex{suid~bit} \acr{suid} o
+\itindex{sgid~bit} \acr{sgid} impostati (vedi
+sez.~\ref{sec:file_special_perm}) di riportare l'\ids{UID} effettivo a quello
+dell'utente che ha lanciato il programma, effettuare il lavoro che non
+necessita di privilegi aggiuntivi, ed eventualmente tornare indietro.
+
+Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
+viene gestito l'accesso al file \sysfile{/var/run/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
+\sysfile{/var/log/wtmp} su cui vengono registrati login e logout) appartengono
+ad un gruppo dedicato (in genere \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} impostato.
+
+Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
+situazione degli identificatori è la seguente:
+\begin{eqnarray*}
+ \label{eq:1}
+ \textsl{group-ID reale} &=& \textrm{\ids{GID} (del chiamante)} \\
+ \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
+ \textsl{group-ID salvato} &=& \textrm{\acr{utmp}}
+\end{eqnarray*}
+in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
+programma può accedere a \sysfile{/var/run/utmp} in scrittura ed aggiornarlo.
+A questo punto il programma può eseguire una \code{setgid(getgid())} per
+impostare il \textsl{group-ID effettivo} a quello dell'utente (e dato che il
+\textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
+non sarà possibile lanciare dal terminale programmi che modificano detto file,
+in tal caso infatti la situazione degli identificatori sarebbe:
+\begin{eqnarray*}
+ \label{eq:2}
+ \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\
+ \textsl{group-ID effettivo} &=& \textrm{\ids{GID}} \\
+ \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
+\end{eqnarray*}
+e ogni processo lanciato dal terminale avrebbe comunque \ids{GID} come
+\textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
+aggiornare lo stato di \sysfile{/var/run/utmp} il programma eseguirà una
+\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
+\acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
+in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la
+funzione avrà successo e riporterà la situazione a:
+\begin{eqnarray*}
+ \label{eq:3}
+ \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\
+ \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
+ \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
+\end{eqnarray*}
+consentendo l'accesso a \sysfile{/var/run/utmp}.
+
+Occorre però tenere conto che tutto questo non è possibile con un processo con
+i privilegi di amministratore, in tal caso infatti l'esecuzione di una
+\func{setuid} comporta il cambiamento di tutti gli identificatori associati al
+processo, rendendo impossibile riguadagnare i privilegi di amministratore.
+Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
+crea una nuova shell per l'utente, ma quando si vuole cambiare soltanto
+l'\ids{UID} effettivo del processo per cedere i privilegi occorre
+ricorrere ad altre funzioni.
+
+Le due funzioni di sistema \funcd{setreuid} e \funcd{setregid} derivano da BSD
+che, non supportando (almeno fino alla versione 4.3+BSD) gli identificatori
+del gruppo \textit{saved}, le usa per poter scambiare fra di loro
+\textit{effective} e \textit{real}; i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{sys/types.h}
+\fdecl{int setreuid(uid\_t ruid, uid\_t euid)}
+\fdesc{Imposta \ids{UID} reale e \ids{UID} effettivo del processo corrente.}
+\fdecl{int setregid(gid\_t rgid, gid\_t egid)}
+\fdesc{Imposta \ids{GID} reale e \ids{GID} effettivo del processo corrente.}
+}
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+caso \var{errno} può assumere solo il valore \errcode{EPERM}.
+}
+\end{funcproto}
+
+Le due funzioni sono identiche, quanto diremo per la prima riguardo gli
+\ids{UID} si applica alla seconda per i \ids{GID}. La funzione
+\func{setreuid} imposta rispettivamente l'\ids{UID} reale e l'\ids{UID}
+effettivo del processo corrente ai valori specificati da \param{ruid}
+e \param{euid}. I processi non privilegiati possono impostare solo valori che
+corrispondano o al loro \ids{UID} effettivo o a quello reale o a quello
+salvato, valori diversi comportano il fallimento della chiamata.
+L'amministratore invece può specificare un valore qualunque. Specificando un
+argomento di valore $-1$ l'identificatore corrispondente verrà lasciato
+inalterato.
+
+Con queste funzioni si possono scambiare fra loro gli \ids{UID} reale ed
+effettivo, e pertanto è possibile implementare un comportamento simile a
+quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
+scambio, e recuperandoli, una volta eseguito il lavoro non privilegiato, con
+un secondo scambio.
+
+In questo caso però occorre porre molta attenzione quando si creano nuovi
+processi nella fase intermedia in cui si sono scambiati gli identificatori, in
+questo caso infatti essi avranno un \ids{UID} reale privilegiato, che dovrà
+essere esplicitamente eliminato prima di porre in esecuzione un nuovo
+programma, occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
+prima della \func{exec} per uniformare l'\ids{UID} reale a quello effettivo,
+perché in caso contrario il nuovo programma potrebbe a sua volta effettuare
+uno scambio e riottenere dei privilegi non previsti.
+
+Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
+si pone anche per l'\ids{UID} salvato. Ma la funzione \func{setreuid} deriva
+da un'implementazione di sistema che non ne prevede la presenza, e quindi non
+è possibile usarla per correggere la situazione come nel caso precedente. Per
+questo motivo in Linux tutte le volte che si imposta un qualunque valore
+diverso da quello dall'\ids{UID} reale corrente, l'\ids{UID} salvato viene
+automaticamente uniformato al valore dell'\ids{UID} effettivo.
+
+Altre due funzioni di sistema, \funcd{seteuid} e \funcd{setegid}, sono
+un'estensione dello standard POSIX.1, ma sono comunque supportate dalla
+maggior parte degli Unix, esse vengono usate per cambiare gli identificatori
+del gruppo \textit{effective} ed i loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{sys/types.h}
+\fdecl{int seteuid(uid\_t uid)}
+\fdesc{Imposta l'\ids{UID} effettivo del processo corrente.}
+\fdecl{int setegid(gid\_t gid)}
+\fdesc{Imposta il \ids{GID} effettivo del processo corrente.}
+}
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+caso \var{errno} può assumere solo il valore \errcode{EPERM}.
+}
+\end{funcproto}
+
+Ancora una volta le due funzioni sono identiche, e quanto diremo per la prima
+riguardo gli \ids{UID} si applica allo stesso modo alla seconda per i
+\ids{GID}. Con \func{seteuid} gli utenti normali possono impostare l'\ids{UID}
+effettivo solo al valore dell'\ids{UID} reale o dell'\ids{UID} salvato,
+l'amministratore può specificare qualunque valore. Queste funzioni sono usate
+per permettere all'amministratore di impostare solo l'\ids{UID} effettivo,
+dato che l'uso normale di \func{setuid} comporta l'impostazione di tutti gli
+identificatori.
+
+Le due funzioni di sistema \funcd{setresuid} e \funcd{setresgid} sono invece
+un'estensione introdotta in Linux (a partire dal kernel 2.1.44) e permettono
+un completo controllo su tutti e tre i gruppi di identificatori
+(\textit{real}, \textit{effective} e \textit{saved}), i loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{sys/types.h}
+\fdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)}
+\fdesc{Imposta l'\ids{UID} reale, effettivo e salvato del processo corrente.}
+\fdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)}
+\fdesc{Imposta il \ids{GID} reale, effettivo e salvato del processo corrente.}
+}
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+caso \var{errno} può assumere solo il valore \errcode{EPERM}.
+}
+\end{funcproto}
+
+Di nuovo le due funzioni sono identiche e quanto detto per la prima riguardo
+gli \ids{UID} si applica alla seconda per i \ids{GID}. La funzione
+\func{setresuid} imposta l'\ids{UID} reale, l'\ids{UID} effettivo e
+l'\ids{UID} salvato del processo corrente ai valori specificati
+rispettivamente dagli argomenti \param{ruid}, \param{euid} e \param{suid}. I
+processi non privilegiati possono cambiare uno qualunque degli\ids{UID} solo
+ad un valore corrispondente o all'\ids{UID} reale, o a quello effettivo o a
+quello salvato, l'amministratore può specificare i valori che vuole. Un valore
+di $-1$ per un qualunque argomento lascia inalterato l'identificatore
+corrispondente.
+
+Per queste funzioni di sistema esistono anche due controparti,
+\funcd{getresuid} e \funcd{getresgid},\footnote{le funzioni non sono standard,
+ anche se appaiono in altri kernel, su Linux sono presenti dal kernel 2.1.44
+ e con le versioni della \acr{glibc} a partire dalla 2.3.2, definendo la
+ macro \macro{\_GNU\_SOURCE}.} che permettono di leggere in blocco i vari
+identificatori; i loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{sys/types.h}
+\fdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)}
+\fdesc{Legge l'\ids{UID} reale, effettivo e salvato del processo corrente.}
+\fdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)}
+\fdesc{Legge il \ids{GID} reale, effettivo e salvato del processo corrente.}
+}
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} può assumere solo il valore \errcode{EFAULT} se gli
+ indirizzi delle variabili di ritorno non sono validi. }
+\end{funcproto}
+
+Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
+nessun privilegio. I valori sono restituiti negli argomenti, che vanno
+specificati come puntatori (è un altro esempio di
+\itindex{value~result~argument} \textit{value result argument}). Si noti che
+queste funzioni sono le uniche in grado di leggere gli identificatori del
+gruppo \textit{saved}.
+
+Infine le funzioni \func{setfsuid} e \func{setfsgid} servono per impostare gli
+identificatori del gruppo \textit{filesystem} che sono usati da Linux per il
+controllo dell'accesso ai file. Come già accennato in
+sez.~\ref{sec:proc_access_id} Linux definisce questo ulteriore gruppo di
+identificatori, che in circostanze normali sono assolutamente equivalenti a
+quelli del gruppo \textit{effective}, dato che ogni cambiamento di questi
+ultimi viene immediatamente riportato su di essi.
+
+C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
+identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
+ovviare ad un problema di sicurezza che si presenta quando si deve
+implementare un server NFS.
+
+Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai
+file per assumere l'identità del singolo utente remoto, ma se questo viene
+fatto cambiando l'\ids{UID} effettivo o l'\ids{UID} reale il server si espone
+alla ricezione di eventuali segnali ostili da parte dell'utente di cui ha
+temporaneamente assunto l'identità. Cambiando solo l'\ids{UID} di filesystem
+si ottengono i privilegi necessari per accedere ai file, mantenendo quelli
+originari per quanto riguarda tutti gli altri controlli di accesso, così che
+l'utente non possa inviare segnali al server NFS.
+
+Le due funzioni di sistema usate per cambiare questi identificatori sono
+\funcd{setfsuid} e \funcd{setfsgid}, ed ovviamente sono specifiche di Linux e
+non devono essere usate se si intendono scrivere programmi portabili; i loro
+prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/fsuid.h}
+\fdecl{int setfsuid(uid\_t fsuid)}
+\fdesc{Imposta l'\ids{UID} di filesystem del processo corrente.}
+\fdecl{int setfsgid(gid\_t fsgid)}
+\fdesc{Legge il \ids{GID} di filesystem del processo corrente.}
+}
+{Le funzioni restituiscono il nuovo valore dell'identificativo in caso di
+ successo e quello corrente per un errore, in questo caso non viene però
+ impostato nessun codice di errore in \var{errno}.}
+\end{funcproto}
+
+Le due funzioni sono analoghe ed usano il valore passato come argomento per
+effettuare l'impostazione dell'identificativo. Le funzioni hanno successo
+solo se il processo chiamante ha i privilegi di amministratore o, per gli
+altri utenti, se il valore specificato coincide con uno dei di quelli del
+gruppo \textit{real}, \textit{effective} o \textit{saved}.
+
+
+\subsection{Le funzioni per la gestione dei gruppi associati a un processo}
+\label{sec:proc_setgroups}
+
+Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
+gruppi supplementari cui un utente può appartenere. Ogni processo può avere
+almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
+ gruppi secondari può essere ottenuto con \func{sysconf} (vedi
+ sez.~\ref{sec:sys_limits}), leggendo il parametro
+ \texttt{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
+ereditati dal processo padre e possono essere cambiati con queste funzioni.
+
+La funzione di sistema che permette di leggere i gruppi supplementari
+associati ad un processo è \funcd{getgroups}; questa funzione è definita nello
+standard POSIX.1, ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{unistd.h}
+\fdecl{int getgroups(int size, gid\_t list[])}
+\fdesc{Legge gli identificatori dei gruppi supplementari.}
+}
+{La funzione ritorna il numero di gruppi letti in caso di successo e $-1$ per
+ un errore, nel qual caso \var{errno} assumerà uno dei valori:
+\begin{errlist}
+\item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
+\item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
+ minore del numero di gruppi supplementari del processo.
+\end{errlist}}
+\end{funcproto}
+
+La funzione legge gli identificatori dei gruppi supplementari del processo sul
+vettore \param{list} che deve essere di dimensione pari a \param{size}. Non è
+specificato se la funzione inserisca o meno nella lista il \ids{GID} effettivo
+del processo. Se si specifica un valore di \param{size} uguale a $0$ allora
+l'argomento \param{list} non viene modificato, ma si ottiene il numero di
+gruppi supplementari.
+
+Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
+ottenere tutti i gruppi a cui appartiene utente identificato per nome; il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{grp.h}
+\fdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups, int
+ *ngroups)}
+\fdesc{Legge i gruppi cui appartiene un utente.}
+}
+{La funzione ritorna il numero di gruppi ottenuto in caso di successo e $-1$
+ per un errore, che avviene solo quando il numero di gruppi è maggiore di
+ quelli specificati con \param{ngroups}.}
+\end{funcproto}
+
+La funzione esegue una scansione del database dei gruppi (si veda
+sez.~\ref{sec:sys_user_group}) per leggere i gruppi supplementari dell'utente
+specificato per nome (e non con un \ids{UID}) nella stringa passata con
+l'argomento \param{user}. Ritorna poi nel vettore \param{groups} la lista dei
+\ids{GID} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups},
+che in ingresso deve indicare la dimensione di \param{group}, è passato come
+\itindex{value~result~argument} \textit{value result argument} perché, qualora
+il valore specificato sia troppo piccolo, la funzione ritorna $-1$, passando
+comunque indietro il numero dei gruppi trovati, in modo da poter ripetere la
+chiamata con un vettore di dimensioni adeguate.
+
+Infine per impostare i gruppi supplementari di un processo ci sono due
+funzioni, che possono essere usate solo se si hanno i privilegi di
+amministratore.\footnote{e più precisamente se si ha la \itindex{capabilities}
+ \textit{capability} \macro{CAP\_SETGID}.} La prima delle due è la funzione
+di sistema \funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4,
+ ma a differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
+ poterla utilizzare deve essere definita la macro \macro{\_BSD\_SOURCE}.} ed
+il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{grp.h}
+\fdecl{int setgroups(size\_t size, gid\_t *list)}
+\fdesc{Imposta i gruppi supplementari del processo.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+caso \var{errno} assumerà uno dei valori:
+\begin{errlist}
+\item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
+\item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
+ massimo consentito di gruppi supplementari.
+\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
+\end{errlist}}
+\end{funcproto}
+
+La funzione imposta i gruppi supplementari del processo corrente ai valori
+specificati nel vettore passato con l'argomento \param{list}, di dimensioni
+date dall'argomento \param{size}. Il numero massimo di gruppi supplementari
+che si possono impostare è un parametro di sistema, che può essere ricavato
+con le modalità spiegate in sez.~\ref{sec:sys_characteristics}.
+
+Se invece si vogliono impostare i gruppi supplementari del processo a quelli
+di un utente specifico, si può usare la funzione \funcd{initgroups} il cui
+prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{grp.h}
+\fdecl{int initgroups(const char *user, gid\_t group)}
+\fdesc{Inizializza la lista dei gruppi supplementari.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+caso \var{errno} assumerà uno dei valori:
+\begin{errlist}
+\item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare lo spazio per
+ informazioni dei gruppi.
+\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
+\end{errlist}}
+\end{funcproto}
+
+La funzione esegue la scansione del database dei gruppi (usualmente
+\conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
+(di nuovo specificato per nome e non per \ids{UID}) con cui costruisce una
+lista di gruppi supplementari, a cui aggiunge anche
+\param{group}, infine imposta questa lista per il processo corrente usando
+\func{setgroups}. Si tenga presente che sia \func{setgroups} che
+\func{initgroups} non sono definite nello standard POSIX.1 e che pertanto non
+è possibile utilizzarle quando si definisce \macro{\_POSIX\_SOURCE} o si
+compila con il flag \cmd{-ansi}, è pertanto meglio evitarle se si vuole
+scrivere codice portabile.
+
+
+\section{La gestione della priorità dei processi}
+\label{sec:proc_priority}
+
+In questa sezione tratteremo più approfonditamente i meccanismi con il quale
+lo \itindex{scheduler} \textit{scheduler} assegna la CPU ai vari processi
+attivi. In particolare prenderemo in esame i vari meccanismi con cui viene
+gestita l'assegnazione del tempo di CPU, ed illustreremo le varie funzioni di
+gestione. Tratteremo infine anche le altre priorità dei processi (come quelle
+per l'accesso a disco) divenute disponibili con i kernel più recenti.
+
+
+\subsection{I meccanismi di \textit{scheduling}}
+\label{sec:proc_sched}
+
+\itindbeg{scheduler}
+
+La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
+il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
+ed oggetto di numerose ricerche; in generale essa dipende in maniera
+essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
+cui non esiste un meccanismo che sia valido per tutti gli usi.
+
+La caratteristica specifica di un sistema multitasking come Linux è quella del
+cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
+ multitasking}: questo significa che al contrario di altri sistemi (che usano
+invece il cosiddetto \itindex{cooperative~multitasking} \textit{cooperative
+ multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
+quando la CPU deve essere passata ad un altro processo. Come accennato in
+sez.~\ref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
+apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
+distribuire al meglio il tempo di CPU fra i vari processi.
+
+La cosa è resa ancora più complicata dal fatto che con le architetture
+multi-processore si deve anche scegliere quale sia la CPU più opportuna da
+utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
+ rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
+ un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
+ banale.} Tutto questo comunque appartiene alle sottigliezze
+dell'implementazione del kernel; dal punto di vista dei programmi che girano
+in \textit{user space}, anche quando si hanno più processori (e dei processi
+che sono eseguiti davvero in contemporanea), le politiche di
+\textit{scheduling} riguardano semplicemente l'allocazione della risorsa
+\textsl{tempo di esecuzione}, la cui assegnazione sarà governata dai
+meccanismi di scelta delle priorità che restano gli stessi indipendentemente
+dal numero di processori.
+
+Si tenga conto poi che i processi non devono solo eseguire del codice: ad
+esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
+venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
+tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
+kernel provvedere a mettere in esecuzione un altro processo.
+
+Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
+processo, in Linux un processo può trovarsi in uno degli stati riportati in
+tab.~\ref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
+\textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
+sia la sua priorità, un processo non potrà mai essere messo in esecuzione
+fintanto che esso si trova in uno qualunque degli altri stati.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|p{2.4cm}|c|p{9cm}|}
+ \hline
+ \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \textit{runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
+ essere eseguito (cioè è in attesa che gli
+ venga assegnata la CPU).\\
+ \textit{sleep} & \texttt{S} & Il processo è in attesa di un
+ risposta dal sistema, ma può essere
+ interrotto da un segnale.\\
+ \textit{uninterrutible sleep}& \texttt{D} & Il processo è in
+ attesa di un risposta dal sistema (in
+ genere per I/O), e non può essere
+ interrotto in nessuna circostanza.\\
+ \textit{stopped} & \texttt{T} & Il processo è stato fermato con un
+ \signal{SIGSTOP}, o è tracciato.\\
+ \textit{zombie}\itindex{zombie}& \texttt{Z} & Il processo è terminato ma il
+ suo stato di terminazione non è ancora
+ stato letto dal padre.\\
+ \textit{killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
+ 2.6.25, sostanzialmente identico
+ all'\textit{uninterrutible sleep} con la
+ sola differenza che il processo può
+ terminato con \signal{SIGKILL} (usato per
+ lo più per NFS).\\
+ \hline
+ \end{tabular}
+ \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
+ \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
+ \cmd{ps} nell'omonimo campo.}
+ \label{tab:proc_proc_states}
+\end{table}
+
+Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
+risorse che sono necessarie per l'esecuzione di un programma, e a seconda
+dello scopo del programma non è detto neanche che sia la più importante, dato
+che molti programmi dipendono in maniera molto più critica dall'I/O. Per
+questo motivo non è affatto detto che dare ad un programma la massima priorità
+di esecuzione abbia risultati significativi in termini di prestazioni.
+
+Il meccanismo tradizionale di \textit{scheduling} di Unix (che tratteremo in
+sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle
+\textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche
+i meno importanti, potessero ricevere un po' di tempo di CPU. In sostanza
+quando un processo ottiene la CPU la sua priorità viene diminuita. In questo
+modo alla fine, anche un processo con priorità iniziale molto bassa, finisce
+per avere una priorità sufficiente per essere eseguito.
+
+Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
+ assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
+alla normale priorità dinamica), per tenere conto dei sistemi
+\textit{real-time},\footnote{per sistema \textit{real-time} si intende un
+ sistema in grado di eseguire operazioni in un tempo ben determinato; in
+ genere si tende a distinguere fra l'\textit{hard real-time} in cui è
+ necessario che i tempi di esecuzione di un programma siano determinabili con
+ certezza assoluta (come nel caso di meccanismi di controllo di macchine,
+ dove uno sforamento dei tempi avrebbe conseguenze disastrose), e
+ \textit{soft-real-time} in cui un occasionale sforamento è ritenuto
+ accettabile.} in cui è vitale che i processi che devono essere eseguiti in
+un determinato momento non debbano aspettare la conclusione di altri che non
+hanno questa necessità.
+
+Il concetto di priorità assoluta dice che quando due processi si contendono
+l'esecuzione, vince sempre quello con la priorità assoluta più alta.
+Ovviamente questo avviene solo per i processi che sono pronti per essere
+eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
+genere indicata con un numero intero, ed un valore più alto comporta una
+priorità maggiore. Su questa politica di \textit{scheduling} torneremo in
+sez.~\ref{sec:proc_real_time}.
+
+In generale quello che succede in tutti gli Unix moderni è che ai processi
+normali viene sempre data una priorità assoluta pari a zero, e la decisione di
+assegnazione della CPU è fatta solo con il meccanismo tradizionale della
+priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
+assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
+priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
+bisogno della CPU.
+
+
+\subsection{Il meccanismo di \textit{scheduling} standard}
+\label{sec:proc_sched_stand}
+
+A meno che non si abbiano esigenze specifiche,\footnote{per alcune delle quali
+ sono state introdotte delle varianti specifiche.} l'unico meccanismo di
+\textit{scheduling} con il quale si avrà a che fare è quello tradizionale, che
+prevede solo priorità dinamiche. È di questo che, di norma, ci si dovrà
+preoccupare nella programmazione. Come accennato in Linux i processi ordinari
+hanno tutti una priorità assoluta nulla; quello che determina quale, fra tutti
+i processi in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
+\textsl{priorità dinamica},\footnote{quella che viene mostrata nella colonna
+ \texttt{PR} del comando \texttt{top}.} che è chiamata così proprio perché
+varia nel corso dell'esecuzione di un processo.
+
+Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
+ dipende strettamente dalla versione di kernel; in particolare a partire
+ dalla serie 2.6.x lo scheduler è stato riscritto completamente, con molte
+ modifiche susseguitesi per migliorarne le prestazioni, per un certo periodo
+ ed è stata anche introdotta la possibilità di usare diversi algoritmi,
+ selezionabili sia in fase di compilazione, che, nelle versioni più recenti,
+ all'avvio (addirittura è stato ideato un sistema modulare che permette di
+ cambiare lo scheduler a sistema attivo).} ma a grandi linee si può dire che
+ad ogni processo è assegnata una \textit{time-slice}, cioè un intervallo di
+tempo (letteralmente una fetta) per il quale, a meno di eventi esterni, esso
+viene eseguito senza essere interrotto. Inoltre la priorità dinamica viene
+calcolata dallo scheduler a partire da un valore iniziale che viene
+\textsl{diminuito} tutte le volte che un processo è in stato \textit{runnable}
+ma non viene posto in esecuzione.\footnote{in realtà il calcolo della priorità
+ dinamica e la conseguente scelta di quale processo mettere in esecuzione
+ avviene con un algoritmo molto più complicato, che tiene conto anche della
+ \textsl{interattività} del processo, utilizzando diversi fattori, questa è
+ una brutale semplificazione per rendere l'idea del funzionamento, per una
+ trattazione più dettagliata, anche se non aggiornatissima, dei meccanismi di
+ funzionamento dello scheduler si legga il quarto capitolo di
+ \cite{LinKernDev}.} Lo scheduler infatti mette sempre in esecuzione, fra
+tutti i processi in stato \textit{runnable}, quello che ha il valore di
+priorità dinamica più basso.\footnote{con le priorità dinamiche il significato
+ del valore numerico ad esse associato è infatti invertito, un valore più
+ basso significa una priorità maggiore.} Il fatto che questo valore venga
+diminuito quando un processo non viene posto in esecuzione pur essendo pronto,
+significa che la priorità dei processi che non ottengono l'uso del processore
+viene progressivamente incrementata, così che anche questi alla fine hanno la
+possibilità di essere eseguiti.
+
+Sia la dimensione della \textit{time-slice} che il valore di partenza della
+priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o
+\textit{niceness}) del processo.\footnote{questa è una delle tante proprietà
+ che ciascun processo si porta dietro, essa viene ereditata dai processi
+ figli e mantenuta attraverso una \func{exec}; fino alla serie 2.4 essa era
+ mantenuta nell'omonimo campo \texttt{nice} della \texttt{task\_struct}, con
+ la riscrittura dello scheduler eseguita nel 2.6 viene mantenuta nel campo
+ \texttt{static\_prio} come per le priorità statiche.} L'origine del nome di
+questo parametro sta nel fatto che generalmente questo viene usato per
+\textsl{diminuire} la priorità di un processo, come misura di cortesia nei
+confronti degli altri. I processi infatti vengono creati dal sistema con un
+valore nullo e nessuno è privilegiato rispetto agli altri. Specificando un
+valore di \textit{nice} positivo si avrà una \textit{time-slice} più breve ed
+un valore di priorità dinamica iniziale più alto, mentre un valore negativo
+darà una \textit{time-slice} più lunga ed un valore di priorità dinamica
+iniziale più basso.
+
+Esistono diverse funzioni che consentono di indicare un valore di
+\textit{nice} di un processo; la più semplice è \funcd{nice}, che opera sul
+processo corrente, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int nice(int inc)}
+\fdesc{Aumenta il valore di \textit{nice} del processo corrente.}
+}
+{La funzione ritorna il nuovo valore di \textit{nice} in caso di successo e
+ $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+\begin{errlist}
+ \item[\errcode{EPERM}] non si ha il permesso di specificare un valore
+ di \param{inc} negativo.
+\end{errlist}}
+\end{funcproto}
+
+L'argomento \param{inc} indica l'incremento da effettuare rispetto al valore
+di \textit{nice} corrente, che può assumere valori compresi fra
+\const{PRIO\_MIN} e \const{PRIO\_MAX}; nel caso di Linux sono fra $-20$ e
+$19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di
+ kernel, ed è questo a partire dal kernel 1.3.43, anche se oggi si può avere
+ anche l'intervallo fra $-20$ e $20$.} ma per \param{inc} si può specificare
+un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare
+il risultato nell'intervallo consentito. Valori positivi comportano maggiore
+\textit{cortesia} e cioè una diminuzione della priorità, valori negativi
+comportano invece un aumento della priorità. Con i kernel precedenti il 2.6.12
+solo l'amministratore\footnote{o un processo con la \itindex{capabilities}
+ \textit{capability} \const{CAP\_SYS\_NICE}, vedi
+ sez.~\ref{sec:proc_capabilities}.} può specificare valori negativi
+di \param{inc} che permettono di aumentare la priorità di un processo, a
+partire da questa versione è consentito anche agli utenti normali alzare
+(entro certi limiti, che vedremo in sez.~\ref{sec:sys_resource_limit}) la
+priorità dei propri processi.
+
+Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
+di \textit{nice} del processo; tuttavia la \textit{system call} di Linux non
+segue questa convenzione e restituisce sempre $0$ in caso di successo e $-1$
+in caso di errore; questo perché $-1$ è anche un valore di \textit{nice}
+legittimo e questo comporta una confusione con una eventuale condizione di
+errore. La \textit{system call} originaria inoltre non consente, se non dotati
+di adeguati privilegi, di diminuire un valore di \textit{nice} precedentemente
+innalzato.
+
+Fino alla \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
+risultato dalla \textit{system call}, violando lo standard, per cui per
+ottenere il nuovo valore occorreva una successiva chiamata alla funzione
+\func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
+reimplementata e non viene più chiamata la omonima \textit{system call}, con
+questa versione viene restituito come valore di ritorno il valore di
+\textit{nice}, come richiesto dallo standard.\footnote{questo viene fatto
+ chiamando al suo interno \func{setpriority}, che tratteremo a breve.} In
+questo caso l'unico modo per rilevare in maniera affidabile una condizione di
+errore è quello di azzerare \var{errno} prima della chiamata della funzione e
+verificarne il valore quando \func{nice} restituisce $-1$.
+
+Per leggere il valore di \textit{nice} di un processo occorre usare la
+funzione di sistema \funcd{getpriority}, derivata da BSD; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/time.h}
+\fhead{sys/resource.h}
+\fdecl{int getpriority(int which, int who)}
+\fdesc{Legge un valore di \textit{nice}.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+caso \var{errno} assumerà uno dei valori:
+\begin{errlist}
+\item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli
+ elencati in tab.~\ref{tab:proc_getpriority}.
+\item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+ \param{which} e \param{who}.
+\end{errlist}}
+\end{funcproto}
+
+La funzione permette, a seconda di quanto specificato
+nell'argomento \param{which}, di leggere il valore di \textit{nice} di un
+processo, di un gruppo di processi (vedi sez.~\ref{sec:sess_proc_group}) o di
+un utente indicato dall'argomento \param{who}. Nelle vecchie versioni può
+essere necessario includere anche \headfile{sys/time.h}, questo non è più
+necessario con versioni recenti delle librerie, ma è comunque utile per
+portabilità.
+
+I valori possibili per \param{which}, ed il tipo di valore che occorre usare
+in corrispondenza per \param{who} solo elencati nella legenda di
+tab.~\ref{tab:proc_getpriority} insieme ai relativi significati. Usare un
+valore nullo per \param{who} indica, a seconda della corrispondente
+indicazione usata per \param{which} il processo, il gruppo di processi o
+l'utente correnti.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|c|l|}
+ \hline
+ \param{which} & \param{who} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{PRIO\_PROCESS} & \type{pid\_t} & processo \\
+ \const{PRIO\_PRGR} & \type{pid\_t} & \itindex{process~group}
+ \textit{process group}\\
+ \const{PRIO\_USER} & \type{uid\_t} & utente \\
+ \hline
+ \end{tabular}
+ \caption{Legenda del valore dell'argomento \param{which} e del tipo
+ dell'argomento \param{who} delle funzioni \func{getpriority} e
+ \func{setpriority} per le tre possibili scelte.}
+ \label{tab:proc_getpriority}
+\end{table}
+
+In caso di una indicazione che faccia riferimento a più processi, la funzione
+restituisce la priorità più alta (cioè il valore più basso) fra quelle dei
+processi corrispondenti. Come per \func{nice} $-1$ è un valore possibile
+corretto, per cui di nuovo per poter rilevare una condizione di errore è
+necessario cancellare sempre \var{errno} prima della chiamata alla funzione e
+quando si ottiene un valore di ritorno uguale a $-1$ per verificare che essa
+resti uguale a zero.
+
+Analoga a \func{getpriority} è la funzione di sistema \funcd{setpriority} che
+permette di impostare la priorità di uno o più processi; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/time.h}
+\fhead{sys/resource.h}
+\fdecl{int setpriority(int which, int who, int prio)}
+\fdesc{Imposta un valore di \textit{nice}.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+caso \var{errno} assumerà uno dei valori:
+\begin{errlist}
+\item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere
+ sufficienti privilegi.
+\item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli
+ elencati in tab.~\ref{tab:proc_getpriority}.
+\item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
+ cercato di modificare la priorità di un processo di un altro utente.
+\item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+ \param{which} e \param{who}.
+\end{errlist}}
+\end{funcproto}
+
+La funzione imposta la priorità dinamica al valore specificato da \param{prio}
+per tutti i processi indicati dagli argomenti \param{which} e \param{who}, per
+i quali valgono le stesse considerazioni fatte per \func{getpriority} e lo
+specchietto di tab.~\ref{tab:proc_getpriority}.
+
+In questo caso come valore di \param{prio} deve essere specificato il valore
+di \textit{nice} da assegnare, e non un incremento (positivo o negativo) come
+nel caso di \func{nice}, nell'intervallo fra \const{PRIO\_MIN} ($-20$) e
+\const{PRIO\_MAX} ($19$). La funzione restituisce il valore di \textit{nice}
+assegnato in caso di successo e $-1$ in caso di errore, e come per \func{nice}
+anche in questo caso per rilevare un errore occorre sempre porre a zero
+\var{errno} prima della chiamata della funzione, essendo $-1$ un valore di
+\textit{nice} valido.
+
+Si tenga presente che solo l'amministratore\footnote{o più precisamente un
+ processo con la \itindex{capabilities} \textit{capability}
+ \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} ha la
+possibilità di modificare arbitrariamente le priorità di qualunque
+processo. Un utente normale infatti può modificare solo la priorità dei suoi
+processi ed in genere soltanto diminuirla. Fino alla versione di kernel
+2.6.12 Linux ha seguito le specifiche dello standard SUSv3, e come per tutti i
+sistemi derivati da SysV veniva richiesto che l'\ids{UID} reale o quello
+effettivo del processo chiamante corrispondessero all'\ids{UID} reale (e solo
+a quello) del processo di cui si intendeva cambiare la priorità. A partire
+dalla versione 2.6.12 è stata adottata la semantica in uso presso i sistemi
+derivati da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere
+anche con l'\ids{UID} effettivo.
+
+Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
+ordinari poter aumentare la priorità dei propri processi specificando un
+valore di \param{prio} negativo. Questa operazione non è possibile però in
+maniera indiscriminata, ed in particolare può essere effettuata solo
+nell'intervallo consentito dal valore del limite \const{RLIMIT\_NICE}
+(torneremo su questo in sez.~\ref{sec:sys_resource_limit}).
+
+Infine nonostante i valori siano sempre rimasti gli stessi, il significato del
+valore di \textit{nice} è cambiato parecchio nelle progressive riscritture
+dello \textit{scheduler} di Linux, ed in particolare a partire dal kernel
+2.6.23 l'uso di diversi valori di \textit{nice} ha un impatto molto più forte
+nella distribuzione della CPU ai processi. Infatti se viene comunque calcolata
+una priorità dinamica per i processi che non ricevono la CPU così che anche
+essi possano essere messi in esecuzione, un alto valore di \textit{nice}
+corrisponde comunque ad una \textit{time-slice} molto piccola che non cresce
+comunque, per cui un processo a bassa priorità avrà davvero scarse possibilità
+di essere eseguito in presenza di processi attivi a priorità più alta.
+
+
+
+\subsection{Il meccanismo di \textit{scheduling real-time}}
+\label{sec:proc_real_time}
+
+Come spiegato in sez.~\ref{sec:proc_sched} lo standard POSIX.1b ha introdotto
+le priorità assolute per permettere la gestione di processi real-time. In
+realtà nel caso di Linux non si tratta di un vero \textit{hard real-time}, in
+quanto in presenza di eventuali interrupt il kernel interrompe l'esecuzione di
+un processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
+ siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
+ ottenere un sistema effettivamente \textit{hard real-time}. In tal caso
+ infatti gli interrupt vengono intercettati dall'interfaccia
+ \textit{real-time} (o nel caso di Adeos gestiti dalle code del nano-kernel),
+ in modo da poterli controllare direttamente qualora ci sia la necessità di
+ avere un processo con priorità più elevata di un \textit{interrupt
+ handler}.} mentre con l'incorrere in un \itindex{page~fault} \textit{page
+ fault} si possono avere ritardi non previsti. Se l'ultimo problema può
+essere aggirato attraverso l'uso delle funzioni di controllo della memoria
+virtuale (vedi sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può
+comportare ritardi non prevedibili riguardo ai tempi di esecuzione di
+qualunque processo.
+
+Nonostante questo, ed in particolare con una serie di miglioramenti che sono
+stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire
+ dalla versione 2.6.18 sono stati inserite nel kernel una serie di modifiche
+ che consentono di avvicinarsi sempre di più ad un vero e proprio sistema
+ \textit{real-time} estendendo il concetto di \textit{preemption} alle
+ operazioni dello stesso kernel; esistono vari livelli a cui questo può
+ essere fatto, ottenibili attivando in fase di compilazione una fra le
+ opzioni \texttt{CONFIG\_PREEMPT\_NONE}, \texttt{CONFIG\_PREEMPT\_VOLUNTARY}
+ e \texttt{CONFIG\_PREEMPT\_DESKTOP}.} si può arrivare ad una ottima
+approssimazione di sistema \textit{real-time} usando le priorità assolute.
+Occorre farlo però con molta attenzione: se si dà ad un processo una priorità
+assoluta e questo finisce in un loop infinito, nessun altro processo potrà
+essere eseguito, ed esso sarà mantenuto in esecuzione permanentemente
+assorbendo tutta la CPU e senza nessuna possibilità di riottenere l'accesso al
+sistema. Per questo motivo è sempre opportuno, quando si lavora con processi
+che usano priorità assolute, tenere attiva una shell cui si sia assegnata la
+massima priorità assoluta, in modo da poter essere comunque in grado di
+rientrare nel sistema.
+
+Quando c'è un processo con priorità assoluta lo \textit{scheduler} lo metterà
+in esecuzione prima di ogni processo normale. In caso di più processi sarà
+eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
+processi con la stessa priorità assoluta questi vengono tenuti in una coda e
+tocca al kernel decidere quale deve essere eseguito. Il meccanismo con cui
+vengono gestiti questi processi dipende dalla politica di \textit{scheduling}
+che si è scelta; lo standard ne prevede due:
+\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
+\item[\textit{First In First Out} (FIFO)] Il processo viene eseguito
+ fintanto che non cede volontariamente la CPU (con la funzione
+ \func{sched\_yield}), si blocca, finisce o viene interrotto da un processo a
+ priorità più alta. Se il processo viene interrotto da uno a priorità più
+ alta esso resterà in cima alla lista e sarà il primo ad essere eseguito
+ quando i processi a priorità più alta diverranno inattivi. Se invece lo si
+ blocca volontariamente sarà posto in coda alla lista (ed altri processi con
+ la stessa priorità potranno essere eseguiti).
+\item[\textit{Round Robin} (RR)] Il comportamento è del tutto analogo a quello
+ precedente, con la sola differenza che ciascun processo viene eseguito al
+ massimo per un certo periodo di tempo (la cosiddetta \textit{time-slice})
+ dopo di che viene automaticamente posto in fondo alla coda dei processi con
+ la stessa priorità. In questo modo si ha comunque una esecuzione a turno di
+ tutti i processi, da cui il nome della politica. Solo i processi con la
+ stessa priorità ed in stato \textit{runnable} entrano nel
+ \textsl{girotondo}.
+\end{basedescript}
+
+Lo standard POSIX.1-2001 prevede una funzione che consenta sia di modificare
+le politiche di \textit{scheduling}, passando da \textit{real-time} a
+ordinarie o viceversa, che di specificare, in caso di politiche
+\textit{real-time}, la eventuale priorità statica; la funzione di sistema è
+\funcd{sched\_setscheduler} ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sched.h}
+\fdecl{int sched\_setscheduler(pid\_t pid, int policy, const struct
+ sched\_param *p)}
+\fdesc{Imposta priorità e politica di \textit{scheduling}.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+caso \var{errno} assumerà uno dei valori:
+\begin{errlist}
+ \item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il
+ relativo valore di \param{p} non è valido per la politica scelta.
+ \item[\errcode{EPERM}] il processo non ha i privilegi per attivare la
+ politica richiesta.
+ \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
+ \end{errlist}}
+\end{funcproto}
+
+La funzione esegue l'impostazione per il processo specificato dall'argomento
+\param{pid}, un valore nullo di questo argomento esegue l'impostazione per il
+processo corrente. La politica di \textit{scheduling} è specificata
+dall'argomento \param{policy} i cui possibili valori sono riportati in
+tab.~\ref{tab:proc_sched_policy}; la parte alta della tabella indica le
+politiche \textit{real-time}, quella bassa le politiche ordinarie. Un valore
+negativo per \param{policy} mantiene la politica di \textit{scheduling}
+corrente.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{6cm}|}
+ \hline
+ \textbf{Politica} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{SCHED\_FIFO} & \textit{Scheduling real-time} con politica
+ \textit{FIFO}. \\
+ \const{SCHED\_RR} & \textit{Scheduling real-time} con politica
+ \textit{Round Robin}. \\
+ \hline
+ \const{SCHED\_OTHER}& \textit{Scheduling} ordinario.\\
+ \const{SCHED\_BATCH}& \textit{Scheduling} ordinario con l'assunzione
+ ulteriore di lavoro \textit{CPU
+ intensive} (dal kernel 2.6.16).\\
+ \const{SCHED\_IDLE} & \textit{Scheduling} di priorità estremamente
+ bassa (dal kernel 2.6.23).\\
+ \hline
+ \end{tabular}
+ \caption{Valori dell'argomento \param{policy} per la funzione
+ \func{sched\_setscheduler}.}
+ \label{tab:proc_sched_policy}
+\end{table}