occasioni. NDT completare questa parte.} (ma può essere anche attivato
esplicitamente). Il timer di sistema provvede comunque a che esso sia invocato
periodicamente, generando un interrupt periodico secondo la frequenza
-specificata dalla costante \macro{HZ}, definita in \file{asm/param.h}. Il
-valore usuale è 100\footnote{è così per tutte le architetture eccetto l'alpha,
- per la quale è 1000} ed è espresso in Hertz. Si ha cioè un interrupt dal
-timer ogni centesimo di secondo.
+specificata dalla costante \macro{HZ}, definita in \file{asm/param.h}, ed il
+cui valore è espresso in Hertz.\footnote{Il valore usuale di questa costante è
+ 100, per tutte le architetture eccetto l'alpha, per la quale è 1000. Occorre
+ fare attenzione a non confondere questo valore con quello dei clock tick
+ (vedi \secref{sec:sys_unix_time}).}
+%Si ha cioè un interrupt dal timer ogni centesimo di secondo.
Ogni volta che viene eseguito, lo \textit{scheduler} effettua il calcolo delle
priorità dei vari processi attivi (torneremo su questo in
azioni installate (vedi \secref{sec:sig_gen_beha}).
\item i segmenti di memoria condivisa agganciati al processo (vedi
\secref{sec:ipc_xxx}).
-\item i limiti sulle risorse (vedi \secref{sec:sys_xxx}).
+\item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
\item le variabili di ambiente (vedi \secref{sec:proc_environ}).
\end{itemize*}
le differenze fra padre e figlio dopo la \func{fork} invece sono:
\item il \textit{process id}.
\item il \textit{parent process id} (quello del figlio viene settato al
\acr{pid} del padre).
-\item i valori dei tempi di esecuzione (vedi \secref{sec:sys_xxx}) che
- nel figlio sono posti a zero.
+\item i valori dei tempi di esecuzione della struttura \var{tms} (vedi
+ \secref{sec:sys_cpu_times}) che nel figlio sono posti a zero.
\item i \textit{file lock} (vedi \secref{sec:file_locking}), che non
vengono ereditati dal figlio.
\item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_gen_beha}), che
queste funzioni, che diventano accessibili definendo la costante
\macro{\_USE\_BSD}, sono:
\begin{functions}
- \headdecl{sys/times.h}
- \headdecl{sys/types.h}
- \headdecl{sys/wait.h}
- \headdecl{sys/resource.h}
+ \headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
+ \headdecl{sys/resource.h}
+
\funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage
- * rusage)}
- È identica a \func{waitpid} sia per comportamento che per i
- valori dei parametri, ma restituisce in \param{rusage} un sommario delle
- risorse usate dal processo (per i dettagli vedi \secref{sec:sys_xxx})
+ * rusage)}
+ È identica a \func{waitpid} sia per comportamento che per i valori dei
+ parametri, ma restituisce in \param{rusage} un sommario delle risorse usate
+ dal processo.
\funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
\end{functions}
\noindent
la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
-utilizzata anche dalla funzione \func{getrusage} (vedi \secref{sec:sys_xxx})
-per ottenere le risorse di sistema usate da un processo; la sua definizione è
-riportata in \figref{fig:sys_rusage_struct}.
-
-In genere includere esplicitamente \file{<sys/time.h>} non è più
-necessario, ma aumenta la portabilità, e serve in caso si debba accedere
-ai campi di \var{rusage} definiti come \type{struct timeval}. La
-struttura è ripresa da BSD 4.3, attualmente (con il kernel 2.4.x) i soli
-campi che sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime},
-\var{ru\_minflt}, \var{ru\_majflt}, e \var{ru\_nswap}.
+utilizzata anche dalla funzione \func{getrusage} (vedi
+\secref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
+processo; la sua definizione è riportata in \figref{fig:sys_rusage_struct}.
\subsection{Le funzioni \func{exec}}
\secref{sec:file_locking}).
\item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
\secref{sec:sig_sigmask}).
-\item i limiti sulle risorse (vedi \secref{sec:sys_limits}).
+\item i limiti sulle risorse (vedi \secref{sec:sys_resource_limits}).
\item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
- \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).
+ \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:sys_xxx}).
\end{itemize*}
Inoltre i segnali che sono stati settati per essere ignorati nel processo
assegnazione sarà governata dai meccanismi di scelta delle priorità che
restano gli stessi indipendentemente dal numero di processori.
-I processi non devono solo eseguire del codice, ad esempio molto spesso
-saranno impegnati in operazioni di I/O, possono venire bloccati da un comando
-dal terminale, 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.
+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
\hline
\end{tabular}
\caption{Elenco dei possibili stati di un processo in Linux, nella colonna
- \texttt{STAT} si è riportata la corripondente lettera usata dal comando
+ \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
\cmd{ps} nell'omonimo campo.}
\label{tab:proc_proc_states}
\end{table}
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,
+vuole cambiare la priorità; per i sistemi derivati da BSD invece (SunOS,
Ultrix, *BSD) la corrispondenza può essere anche con l'effective user id.
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 più
-processi con la stessa priorità assoluta questi vegono tenuti in una coda
+processi con la stessa priorità assoluta questi vengono tenuti in una coda
tocca al kernel decidere quale deve essere eseguito.
di \param{pid} esegue il settaggio per il processo corrente, solo un processo
con i privilegi di amministratore può settare delle priorità assolute diverse
da zero. La politica di scheduling è specificata dall'argomento \param{policy}
-i cui possibili valori sono riportati in \tabref{tab:proc_sched_policy}.
+i cui possibili valori sono riportati in \tabref{tab:proc_sched_policy}; un
+valore negativo per \param{policy} mantiene la politica di scheduling
+corrente.
\begin{table}[htb]
\centering
\label{tab:proc_sched_policy}
\end{table}
-Il valore della priorità è passato attraverso la struttura \var{sched\_param},
-riportata in \figref{fig:sig_sched_param}. Il solo campo che serve è
-\var{sched\_priority} che nel caso delle priorità assolute deve essere
-specificato nell'intervallo fra 1 e 99 (il valore zero è legale, ma indica i
-processi normali). I processi con politica di scheduling \macro{SCHED\_OTHER}
-devono specificare un valore nullo (altrimenti si avrà un errore
-\macro{EINVAL}), questo valore infatti non ha niente a che vedere con la
-priorità dinamica determinata dal valore di \var{nice}.
+Il valore della priorità è passato attraverso la struttura \var{sched\_param}
+(riportata in \figref{fig:sig_sched_param}), il cui solo campo attualmente
+definito è \var{sched\_priority}, che nel caso delle priorità assolute deve
+essere specificato nell'intervallo fra 1 e 99 (il valore zero è legale, ma
+indica i processi normali). Lo standard POSIX.1b prevede comunque che questi
+due valori possano essere ottenuti per ciascuna politica di scheduling dalle
+funzioni \func{sched\_get\_priority\_max} e \func{sched\_get\_priority\_min},
+i cui prototipi sono:
+\begin{functions}
+ \headdecl{sched.h}
+
+ \funcdecl{int sched\_get\_priority\_max(int policy)} Legge il valore
+ massimo della priorità statica per la politica di scheduling \param{policy}.
+
+
+ \funcdecl{int sched\_get\_priority\_min(int policy)} Legge il valore minimo
+ della priorità statica per la politica di scheduling \param{policy}.
+
+ \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
+ e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
+ \begin{errlist}
+ \item[\macro{EINVAL}] il valore di \param{policy} è invalido.
+ \end{errlist}}
+\end{functions}
+
+
+I processi con politica di scheduling \macro{SCHED\_OTHER} devono specificare
+un valore nullo (altrimenti si avrà un errore \macro{EINVAL}), questo valore
+infatti non ha niente a che vedere con la priorità dinamica determinata dal
+valore di \var{nice}, che deve essere settato con le funzioni viste in
+precedenza.
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
\begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
struct sched_param {
- ...
int sched_priority;
- ...
};
\end{lstlisting}
\end{minipage}
esegue sempre il primo della lista, mentre un nuovo processo che torna in
stato \textit{runnable} viene sempre inserito in coda alla lista. Se la
politica scelta è \macro{SCHED\_FIFO} quando il processo viene eseguito viene
-automaticamente rimesso in coda alla lista, ma la sua esecuzione continua e
-tolto dalla lista, la sua esecuzione fintanto che non viene bloccato da una
-richiesta di I/O, o non rilascia volontariamente la CPU (in tal caso, tornando
-nello stato \textit{runnable} sarà reinserito in coda alla lista; l'esecuzione
-viene ripresa subito solo nel caso che esso sia stato interrotto da un
-processo a priorità più alta.
+automaticamente rimesso in coda alla lista, e la sua esecuzione continua
+fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
+volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
+sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
+nel caso che esso sia stato interrotto da un processo a priorità più alta.
+
+La priorità assoluta può essere riletta indietro dalla funzione
+\func{sched\_getscheduler}, il cui prototipo è:
+\begin{prototype}{sched.h}
+{int sched\_getscheduler(pid\_t pid)}
+ Legge la politica di scheduling per il processo \param{pid}.
+
+ \bodydesc{La funzione ritorna la politica di scheduling in caso di successo
+ e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
+ \begin{errlist}
+ \item[\macro{ESRCH}] il processo \param{pid} non esiste.
+ \item[\macro{EINVAL}] il valore di \param{pid} è negativo.
+ \end{errlist}}
+\end{prototype}
+La funzione restituisce il valore (secondo la quanto elencato in
+\tabref{tab:proc_sched_policy}) della politica di scheduling per il processo
+specificato; se \param{pid} è nullo viene restituito quello del processo
+chiamante.
+Se si intende operare solo sulla priorità assoluta di un processo si possono
+usare le funzioni \func{sched\_setparam} e \func{sched\_getparam}, i cui
+prototipi sono:
+
+\begin{functions}
+ \headdecl{sched.h}
+
+ \funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *p)}
+ Setta la priorità assoluta del processo \param{pid}.
+
+
+ \funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *p)}
+ Legge la priorità assoluta del 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}] il processo \param{pid} non esiste.
+ \item[\macro{EINVAL}] il valore di \param{pid} è negativo.
+ \end{errlist}}
+\end{functions}
+
+L'uso di \func{sched\_setparam} che è del tutto equivalente a
+\func{sched\_setscheduler} con \param{priority} uguale a -1. Come per
+\func{sched\_setscheduler} specificando 0 come valore di \param{pid} si opera
+sul processo corrente. La disponibilità di entrambe le funzioni può essere
+verificata controllando la macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è
+definita nell'header \macro{sched.h}.
+
+L'ultima funzione che permette di leggere le informazioni relative ai processi
+real-time è \func{sched\_rr\_get\_interval}, che permette di ottenere la
+lunghezza della \textit{time slice} usata dalla politica \textit{round robin};
+il suo prototipo è:
+\begin{prototype}{sched.h}
+ {int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} Legge in
+ \param{tp} la durata della \textit{time slice} per il processo \param{pid}.
+
+ \bodydesc{La funzione ritorna 0in caso di successo e -1 in caso di errore,
+ nel qual caso \var{errno} può assumere i valori:
+ \begin{errlist}
+ \item[\macro{ESRCH}] il processo \param{pid} non esiste.
+ \item[\macro{ENOSYS}] la system call non è stata implementata.
+ \end{errlist}}
+\end{prototype}
+
+La funzione restituisce il valore dell'intervallo di tempo usato per la
+politica \textit{round robin} in una struttura \var{timespec}, (la cui
+definizione si può trovare in \figref{fig:sys_timeval_struct}).
+
+
+Come accennato ogni processo che usa lo scheduling real-time può rilasciare
+volontariamente la CPU; questo viene fatto attraverso la funzione
+\func{sched\_yield}, il cui prototipo è:
+\begin{prototype}{sched.h}
+ {int sched\_yield(void)}
+
+ Rilascia volontariamente l'esecuzione.
+
+ \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
+ nel qual caso \var{errno} viene settata opportunamente.}
+\end{prototype}
+La funzione fa si che il processo rilasci la CPU, in modo da essere rimesso in
+coda alla lista dei processi da eseguire, e permettere l'esecuzione di un
+altro processo; se però il processo è l'unico ad essere presente sulla coda
+l'esecuzione non sarà interrotta. In genere usano questa funzione i processi
+in modalità \textit{fifo}, per permettere l'esecuzione degli altri processi
+con pari priorità quando la sezione più urgente è finita.
\section{Problematiche di programmazione multitasking}
projects / gapil.git / blobdiff