diff options
Diffstat (limited to 'Documentation/translations/it_IT/kernel-hacking/locking.rst')
| -rw-r--r-- | Documentation/translations/it_IT/kernel-hacking/locking.rst | 55 |
1 files changed, 31 insertions, 24 deletions
diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst index 1e7c84def369..4c21cf60f775 100644 --- a/Documentation/translations/it_IT/kernel-hacking/locking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst @@ -102,16 +102,11 @@ che non esistano. Sincronizzazione nel kernel Linux ================================= -Se posso darvi un suggerimento: non dormite mai con qualcuno più pazzo di -voi. Ma se dovessi darvi un suggerimento sulla sincronizzazione: -**mantenetela semplice**. +Se dovessi darvi un suggerimento sulla sincronizzazione: **mantenetela +semplice**. Siate riluttanti nell'introduzione di nuovi *lock*. -Abbastanza strano, quest'ultimo è l'esatto opposto del mio suggerimento -su quando **avete** dormito con qualcuno più pazzo di voi. E dovreste -pensare a prendervi un cane bello grande. - I due principali tipi di *lock* nel kernel: spinlock e mutex ------------------------------------------------------------ @@ -316,7 +311,7 @@ Pete Zaitcev ci offre il seguente riassunto: - Se siete in un contesto utente (una qualsiasi chiamata di sistema) e volete sincronizzarvi con altri processi, usate i mutex. Potete trattenere - il mutex e dormire (``copy_from_user*(`` o ``kmalloc(x,GFP_KERNEL)``). + il mutex e dormire (``copy_from_user(`` o ``kmalloc(x,GFP_KERNEL)``). - Altrimenti (== i dati possono essere manipolati da un'interruzione) usate spin_lock_irqsave() e spin_unlock_irqrestore(). @@ -979,9 +974,6 @@ fallisce nel trovare quello che vuole, quindi rilascia il *lock* di lettura, trattiene un *lock* di scrittura ed inserisce un oggetto; questo genere di codice presenta una corsa critica. -Se non riuscite a capire il perché, per favore state alla larga dal mio -codice. - corsa fra temporizzatori: un passatempo del kernel -------------------------------------------------- @@ -998,7 +990,7 @@ potreste fare come segue:: while (list) { struct foo *next = list->next; - del_timer(&list->timer); + timer_delete(&list->timer); kfree(list); list = next; } @@ -1011,7 +1003,7 @@ e prenderà il *lock* solo dopo spin_unlock_bh(), e cercherà di eliminare il suo oggetto (che però è già stato eliminato). Questo può essere evitato controllando il valore di ritorno di -del_timer(): se ritorna 1, il temporizzatore è stato già +timer_delete(): se ritorna 1, il temporizzatore è stato già rimosso. Se 0, significa (in questo caso) che il temporizzatore è in esecuzione, quindi possiamo fare come segue:: @@ -1020,7 +1012,7 @@ esecuzione, quindi possiamo fare come segue:: while (list) { struct foo *next = list->next; - if (!del_timer(&list->timer)) { + if (!timer_delete(&list->timer)) { /* Give timer a chance to delete this */ spin_unlock_bh(&list_lock); goto retry; @@ -1034,10 +1026,13 @@ esecuzione, quindi possiamo fare come segue:: Un altro problema è l'eliminazione dei temporizzatori che si riavviano da soli (chiamando add_timer() alla fine della loro esecuzione). Dato che questo è un problema abbastanza comune con una propensione -alle corse critiche, dovreste usare del_timer_sync() -(``include/linux/timer.h``) per gestire questo caso. Questa ritorna il -numero di volte che il temporizzatore è stato interrotto prima che -fosse in grado di fermarlo senza che si riavviasse. +alle corse critiche, dovreste usare timer_delete_sync() +(``include/linux/timer.h``) per gestire questo caso. + +Prima di rilasciare un temporizzatore dovreste chiamare la funzione +timer_shutdown() o timer_shutdown_sync() di modo che non venga più riarmato. +Ogni successivo tentativo di riarmare il temporizzatore verrà silenziosamente +ignorato. Velocità della sincronizzazione =============================== @@ -1317,11 +1312,11 @@ se i dati vengono occasionalmente utilizzati da un contesto utente o da un'interruzione software. Il gestore d'interruzione non utilizza alcun *lock*, e tutti gli altri accessi verranno fatti così:: - spin_lock(&lock); + mutex_lock(&lock); disable_irq(irq); ... enable_irq(irq); - spin_unlock(&lock); + mutex_unlock(&lock); La funzione disable_irq() impedisce al gestore d'interruzioni d'essere eseguito (e aspetta che finisca nel caso fosse in esecuzione su @@ -1382,7 +1377,7 @@ contesto, o trattenendo un qualsiasi *lock*. - kfree() -- add_timer() e del_timer() +- add_timer() e timer_delete() Riferimento per l'API dei Mutex =============================== @@ -1396,7 +1391,19 @@ Riferimento per l'API dei Mutex Riferimento per l'API dei Futex =============================== -.. kernel-doc:: kernel/futex.c +.. kernel-doc:: kernel/futex/core.c + :internal: + +.. kernel-doc:: kernel/futex/futex.h + :internal: + +.. kernel-doc:: kernel/futex/pi.c + :internal: + +.. kernel-doc:: kernel/futex/requeue.c + :internal: + +.. kernel-doc:: kernel/futex/waitwake.c :internal: Approfondimenti @@ -1459,11 +1466,11 @@ contesto utente che hardware. interruzione hardware - Richiesta di interruzione hardware. in_irq() ritorna vero in un + Richiesta di interruzione hardware. in_hardirq() ritorna vero in un gestore d'interruzioni hardware. interruzione software / softirq - Gestore di interruzioni software: in_irq() ritorna falso; + Gestore di interruzioni software: in_hardirq() ritorna falso; in_softirq() ritorna vero. I tasklet e le softirq sono entrambi considerati 'interruzioni software'. |