From: Simone Piccardi <piccardi@gnulinux.it>
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/?p=gapil.git;a=commitdiff_plain;h=ccbf31a765f143e0709a6c2ef81f79b606350c64;hp=a727c2850d3ac092f165081059cbf1c5d9d9849e

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}
+
+
+
+
+
+