Mandatory locking
[gapil.git] / signal.tex
index 48d45b3f8dbefdefb3e4631a9b9f0e670dfe7a9d..7cbda4f9ae2bef49a47f19251e5cfd504a544ece 100644 (file)
@@ -140,9 +140,9 @@ Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
 \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
 per tutto il tempo che passa fra la generazione del segnale e la sua consegna
 esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
-procedura viene effettuata dallo scheduler quando, riprendendo l'esecuzione
-del processo in questione, verifica la presenza del segnale nella
-\var{task\_struct} e mette in esecuzione il gestore.
+procedura viene effettuata dallo scheduler\index{scheduler} quando,
+riprendendo l'esecuzione del processo in questione, verifica la presenza del
+segnale nella \var{task\_struct} e mette in esecuzione il gestore.
 
 In questa semantica un processo ha la possibilità di bloccare la consegna dei
 segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
@@ -211,11 +211,12 @@ verr
 ignorarlo).
 
 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
-avviene non appena questo viene rimesso in esecuzione dallo scheduler che
-esegue l'azione specificata. Questo a meno che il segnale in questione non sia
-stato bloccato prima della notifica, nel qual caso l'invio non avviene ed il
-segnale resta \textsl{pendente} indefinitamente. Quando lo si sblocca il
-segnale \textsl{pendente} sarà subito notificato.
+avviene non appena questo viene rimesso in esecuzione dallo
+scheduler\index{scheduler} che esegue l'azione specificata. Questo a meno che
+il segnale in questione non sia stato bloccato prima della notifica, nel qual
+caso l'invio non avviene ed il segnale resta \textsl{pendente}
+indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
+notificato.
 
 Si ricordi però che se l'azione specificata per un segnale è quella di essere
 ignorato questo sarà scartato immediatamente al momento della sua generazione,
@@ -1347,11 +1348,11 @@ Chiaramente, anche se il tempo pu
 nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
 temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
 specificato, ma prima che il processo possa tornare ad essere eseguito
-occorrerà almeno attendere il successivo giro di scheduler e cioè un tempo che
-a seconda dei casi può arrivare fino a 1/\macro{HZ}, (sempre che il sistema
-sia scarico ed il processa venga immediatamente rimesso in esecuzione); per
-questo motivo il valore restituito in \param{rem} è sempre arrotondato al
-multiplo successivo di 1/\macro{HZ}.
+occorrerà almeno attendere il successivo giro di scheduler\index{scheduler} e
+cioè un tempo che a seconda dei casi può arrivare fino a 1/\macro{HZ}, (sempre
+che il sistema sia scarico ed il processa venga immediatamente rimesso in
+esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
+arrotondato al multiplo successivo di 1/\macro{HZ}.
 
 In realtà è possibile ottenere anche pause più precise del centesimo di
 secondo usando politiche di scheduling real time come \macro{SCHED\_FIFO} o