\begin{prototype}{sys/resource.h}
{int getpriority(int which, int who)}
- Restituisce la priorità per l'insieme dei processi specificati.
+Restituisce il valore di \var{nice} per l'insieme dei processi specificati.
\bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
errore, nel qual caso \var{errno} può assumere i valori:
Analoga a \func{getpriority} la funzione \func{setpriority} permette di
settare la priorità di uno o più processi; il suo prototipo è:
\begin{prototype}{sys/resource.h}
-{int setpriority(int which, int who, int prio)}
-
+{int setpriority(int which, int who, int prio)}
Setta la priorità per l'insieme dei processi specificati.
\bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
La funzione setta la priorità al valore specificato da \param{prio} per tutti
i processi indicati dagli argomenti \parm{which} e \param{who}. La gestione
dei permessi dipende dalle varie implementazioni; in Linux, secondo le
-specifiche dello standard SUSv3, e come per tutti i sistemi che derivano da
-SYSV, è richiesto che il real o l'effective user id del processo chiamante
-corrispondano al real user id (e solo quello) del processo di cui si vuole
-cambiare la prorità; per i sistemi derivati da BSD invece (SunOS, Ultrix,
-*BSD) la corrispondenza può essere anche con l'effective user id.
+specifiche dello standard SUSv3, e come avviene per tutti i sistemi che
+derivano da SYSV, è richiesto che il real o l'effective user id del processo
+chiamante corrispondano al real user id (e solo quello) del processo di cui si
+vuole cambiare la prorità; per i sistemi derivati da BSD invece (SunOS,
+Ultrix, *BSD) la corrispondenza può essere anche con l'effective user id.
+
\subsection{Il meccanismo di \textit{scheduling real-time}}
\label{sec:proc_real_time}
+Come spiegato in \secref{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 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 o RTAI, con i quali è possibile
+ ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
+ interrupt vengono intercettati dall'interfaccia real-time, e gestiti
+ 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
+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 \secref{sec:proc_mem_lock}), il primo non è superabile e può
+comportare ritardi non prevedibili riguardo ai tempi di esecuzione di
+qualunque processo.
+
+L'interfaccia POSIX.1b comunque permette di assicurare ai processi che ne
+hanno necessità una priorità assoluta superiore a quella dei normali processi.
+In ogni caso occorre usare questo meccanismo con molta attenzione: se si dà ad
+un processo una priorità assoluta e questo finisce in un loop infinito, dato
+che fintanto che non esegue dell'I/O o viene messo in attesa nessun altro
+processo potrà essere eseguito, esso resterà esecuzione assorbendo tutto il
+tempo di esecuzione della CPU e non si avrà 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 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 due
+processi con la stessa priorità assoluta tocca al kernel decidere quale dei
+due deve essere eseguito. Questo viene fatto secondo la politica di scheduling
+che ciascuno di questi processi ha; lo standard ne prevede due:
+\begin{description}
+\item[\textit{Round robin}] ciascun processo viene eseguito a turno per un
+ certo periodo di tempo (una \textit{time slice}). Solo i processi con la
+ stessa priorità ed in stato \textit{runnable} entrano nel circolo.
+\item[\textit{FIFO}] il processo che ha atteso di più ha la precedenza e viene
+ eseguito fintanto che non cede volontariamente la CPU, si blocca, finisce o
+ viene interrotto da un processo a priorità più alta.
+\end{description}
+
+La funzione per settare politica di scheduling ed i relativi parametri è
+\func{sched\_setscheduler}; il suo prototipo è:
+\begin{prototype}{sched.h}
+{int sched\_setscheduler(pid\_t pid, int policy, const struct sched\_param *p)}
+ Setta priorità e politica di scheduling per il processo \param{pid}.
+
+ \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
+ errore, nel qual caso \var{errno} può assumere i valori:
+ \begin{errlist}
+ \item[\macro{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+ \param{which} e \param{who}.
+ \item[\macro{EINVAL}] il valore di \param{which} non è valido.
+ \item[\macro{EPERM}] un processo senza i privilegi di amministratore ha
+ specificato un valore di \param{inc} negativo.
+ \item[\macro{EACCESS}] un processo senza i privilegi di amministratore ha
+ cercato di modificare la priorità di un processo di un altro utente.
+ \end{errlist}}
+\end{prototype}
+
-Come spiegato al paragrafo precedente di norma
-Per settare le
-\footnote{a meno che non si siano installate le patch di RTLinux o RTAI, con i
- quali è possibile ottenere un sistema effettivamente hard real-time.}
-in realtà non si tratta di un vero hard real-time, in quanto
- la presenza di eventuali interrupt o di page fault può sempre interrompere
- l'esecuzione di un processo, a meno di non installare le estensioni di
- RTLinux o RTAI, il normale kernel non è real-time.
projects / gapil.git / blobdiff