\item la directory di lavoro e la directory radice (vedi
\secref{sec:file_work_dir} e \secref{sec:file_chroot}).
\item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
-\item la maschera dei segnali bloccati (vedi \secref{sec:sig_sigpending}) e le
+\item la maschera dei segnali bloccati (vedi \secref{sec:sig_sigmask}) e le
azioni installate (vedi \secref{sec:sig_gen_beha}).
\item i segmenti di memoria condivisa agganciati al processo (vedi
\secref{sec:ipc_xxx}).
\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:
\end{prototype}
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
+i processi indicati dagli argomenti \param{which} e \param{who}. La gestione
dei permessi dipende dalle varie implementazioni; in Linux, secondo le
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
\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}
+
+
+
+
+
+
projects / gapil.git / blobdiff