From: Simone Piccardi Date: Fri, 5 Apr 2002 17:58:13 +0000 (+0000) Subject: Iniiziate le funzioni per lo scheduling real-time X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=ccbf31a765f143e0709a6c2ef81f79b606350c64;p=gapil.git Iniiziate le funzioni per lo scheduling real-time --- diff --git a/prochand.tex b/prochand.tex index c005bbd..4aaa0fd 100644 --- a/prochand.tex +++ b/prochand.tex @@ -2019,7 +2019,7 @@ funzione \func{getpriority}, derivata da BSD, il cui prototipo \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: @@ -2097,17 +2097,73 @@ Ultrix, *BSD) la corrispondenza pu \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; benché -Linux non sia un sistema operativo real-time,\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.} è stata comunque implementata anche -una politica di scheduling corrispondente a questo meccanismo. - -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, in questo modo comunque si potrà dare . +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} + + + + + +