Lines Matching +full:non +full:- +full:l
1 .. include:: ../disclaimer-ita.rst
5 :Original: :ref:`Documentation/kernel-hacking/locking.rst <kernel_hacking_lock>`
11 L'inaffidabile guida alla sincronizzazione
23 Dato il largo utilizzo del multi-threading e della prelazione nel kernel
26 multi-processore.
44 +------------------------------------+------------------------------------+
48 +------------------------------------+------------------------------------+
50 +------------------------------------+------------------------------------+
52 +------------------------------------+------------------------------------+
54 +------------------------------------+------------------------------------+
56 +------------------------------------+------------------------------------+
58 +------------------------------------+------------------------------------+
64 +------------------------------------+------------------------------------+
68 +------------------------------------+------------------------------------+
70 +------------------------------------+------------------------------------+
72 +------------------------------------+------------------------------------+
74 +------------------------------------+------------------------------------+
76 +------------------------------------+------------------------------------+
78 +------------------------------------+------------------------------------+
82 ---------------------------------
88 macchine multi-processore, le sezioni critiche sono diventate uno dei
100 che non esistano.
111 ------------------------------------------------------------
115 trattenuto solo da un processo: se non si può trattenere lo spinlock, allora
116 rimane in attesa attiva (in inglese *spinning*) finché non ci riesce.
120 ma potreste bloccarvi trattenendolo. Se non potete trattenere un mutex
121 il vostro processo si auto-sospenderà; verrà riattivato quando il mutex
123 mentre il vostro processo è in attesa. Esistono molti casi in cui non potete
132 ----------------------------------------------
135 gli spinlock non esistono. Questa è un'ottima scelta di progettazione:
137 non c'è la necessità di avere un *lock*.
142 la prelazione equivalente ad un sistema multi-processore senza preoccuparci
146 ``CONFIG_PREEMPT`` abilitate, anche quando non avete un sistema
147 multi-processore, questo vi permetterà di identificare alcuni problemi
154 -----------------------------------
161 ma questa dovrebbe essere evitata perché non ritorna in caso di segnali.
167 o scaricato (e durante l'avvio del sistema, qui non abbiamo concorrenza),
174 ---------------------------------------------------
182 l'opposto. (Il suffisso '_bh' è un residuo storico che fa riferimento al
196 ------------------------------------------------
201 ----------------------------------------------
208 ------------------------------------
216 Dato che un tasklet non viene mai eseguito contemporaneamente su due
217 processori, non dovete preoccuparvi che sia rientrante (ovvero eseguito
218 più volte in contemporanea), perfino su sistemi multi-processore.
230 ----------------------------
254 .. _`it_hardirq-context`:
264 ------------------------------------------------------------
271 sul processore che l'esegue, poi trattiene il lock. spin_unlock_irq()
272 fa l'opposto.
274 Il gestore d'interruzione hardware non ha bisogno di usare spin_lock_irq()
275 perché i softirq non possono essere eseguiti quando il gestore d'interruzione
277 più veloce. L'unica eccezione è quando un altro gestore d'interruzioni
300 --------------------------------------------------------
312 - Se siete in un contesto utente (una qualsiasi chiamata di sistema)
316 - Altrimenti (== i dati possono essere manipolati da un'interruzione) usate
319 - Evitate di trattenere uno spinlock per più di 5 righe di codice incluse
320 le chiamate a funzione (ad eccezione di quell per l'accesso come
324 ----------------------------
328 da un processore per volta, quindi non ci sono requisiti per la
354 +--------+----------------------------+
356 +--------+----------------------------+
358 +--------+----------------------------+
360 +--------+----------------------------+
362 +--------+----------------------------+
364 +--------+----------------------------+
373 dell'operazione. Posso essere usate quando non serve accedere ai dati
378 La funzione spin_trylock() non ritenta di acquisire il *lock*,
386 colpo, altrimenti se fallisce ritorna 0. Nonostante non dorma, questa funzione
387 non può essere usata in modo sicuro in contesti di interruzione hardware o
395 quando è piena, l'oggetto meno usato viene eliminato.
398 ------------------------
431 if (i->id == id) {
432 i->popularity++;
442 list_del(&obj->list);
444 cache_num--;
450 list_add(&obj->list, &cache);
454 if (!outcast || i->popularity < outcast->popularity)
466 return -ENOMEM;
468 strscpy(obj->name, name, sizeof(obj->name));
469 obj->id = id;
470 obj->popularity = 0;
488 int ret = -ENOENT;
494 strcpy(name, obj->name);
503 caso è semplice dato che copiamo i dati dall'utente e non permettiamo
508 sicuro perché nessun altro potrà accedervi finché non lo inseriremo
512 ---------------------------
518 Qui di seguito troverete la modifica nel formato *patch*: le righe ``-``
523 --- cache.c.usercontext 2003-12-09 13:58:54.000000000 +1100
524 +++ cache.c.interrupt 2003-12-09 14:07:49.000000000 +1100
525 @@ -12,7 +12,7 @@
529 -static DEFINE_MUTEX(cache_lock);
534 @@ -55,6 +55,7 @@
541 return -ENOMEM;
542 @@ -63,30 +64,33 @@
543 obj->id = id;
544 obj->popularity = 0;
546 - mutex_lock(&cache_lock);
549 - mutex_unlock(&cache_lock);
556 - mutex_lock(&cache_lock);
561 - mutex_unlock(&cache_lock);
568 int ret = -ENOENT;
571 - mutex_lock(&cache_lock);
576 strcpy(name, obj->name);
578 - mutex_unlock(&cache_lock);
584 se erano attive, altrimenti non farà niente (quando siamo già in un contesto
589 l'opzione ``GFP_KERNEL`` che è permessa solo in contesto utente. Ho supposto
594 ----------------------------------------
596 Se i vostri oggetti contengono più informazioni, potrebbe non essere
603 rende la sincronizzazione più complicata dato che non avviene più in un unico
613 Dato che c'è un solo *lock*, non potete trattenerlo a vita: altrimenti
616 La soluzione a questo problema è l'uso di un contatore di riferimenti:
618 quando il puntatore non viene più usato. Quando il contatore raggiunge lo zero
619 significa che non è più usato e l'oggetto può essere rimosso.
623 --- cache.c.interrupt 2003-12-09 14:25:43.000000000 +1100
624 +++ cache.c.refcnt 2003-12-09 14:33:05.000000000 +1100
625 @@ -7,6 +7,7 @@
633 @@ -17,6 +18,35 @@
639 + if (--obj->refcnt == 0)
645 + obj->refcnt++;
669 @@ -35,6 +65,7 @@
672 list_del(&obj->list);
674 cache_num--;
677 @@ -63,6 +94,7 @@
678 strscpy(obj->name, name, sizeof(obj->name));
679 obj->id = id;
680 obj->popularity = 0;
681 + obj->refcnt = 1; /* The cache holds a reference */
685 @@ -79,18 +111,15 @@
689 -int cache_find(int id, char *name)
693 - int ret = -ENOENT;
698 - if (obj) {
699 - ret = 0;
700 - strcpy(name, obj->name);
701 - }
705 - return ret;
710 di 'get' e 'put'. Ora possiamo ritornare l'oggetto da cache_find()
711 col vantaggio che l'utente può dormire trattenendo l'oggetto (per esempio,
716 quando l'oggetto viene inserito nella memoria. In altre versione il framework
717 non trattiene un riferimento per se, ma diventa più complicato.
725 processore del sistema, quindi non sono necessari i *lock*. In questo caso è
726 più semplice rispetto all'uso degli spinlock, benché l'uso degli spinlock
727 sia più elegante per casi non banali. Le funzioni atomic_inc() e
729 incremento e decremento, e i *lock* non sono più necessari per proteggere il
734 --- cache.c.refcnt 2003-12-09 15:00:35.000000000 +1100
735 +++ cache.c.refcnt-atomic 2003-12-11 15:49:42.000000000 +1100
736 @@ -7,7 +7,7 @@
740 - unsigned int refcnt;
745 @@ -18,33 +18,15 @@
749 -static void __object_put(struct object *obj)
750 -{
751 - if (--obj->refcnt == 0)
752 - kfree(obj);
753 -}
754 -
755 -static void __object_get(struct object *obj)
756 -{
757 - obj->refcnt++;
758 -}
759 -
762 - unsigned long flags;
763 -
764 - spin_lock_irqsave(&cache_lock, flags);
765 - __object_put(obj);
766 - spin_unlock_irqrestore(&cache_lock, flags);
767 + if (atomic_dec_and_test(&obj->refcnt))
773 - unsigned long flags;
774 -
775 - spin_lock_irqsave(&cache_lock, flags);
776 - __object_get(obj);
777 - spin_unlock_irqrestore(&cache_lock, flags);
778 + atomic_inc(&obj->refcnt);
782 @@ -65,7 +47,7 @@
785 list_del(&obj->list);
786 - __object_put(obj);
788 cache_num--;
791 @@ -94,7 +76,7 @@
792 strscpy(obj->name, name, sizeof(obj->name));
793 obj->id = id;
794 obj->popularity = 0;
795 - obj->refcnt = 1; /* The cache holds a reference */
796 + atomic_set(&obj->refcnt, 1); /* The cache holds a reference */
800 @@ -119,7 +101,7 @@
804 - __object_get(obj);
810 Proteggere l'oggetto stesso
811 ---------------------------
814 di riferimenti) non cambino mai dopo la loro creazione. Se vogliamo permettere
817 - Si può togliere static da ``cache_lock`` e dire agli utenti che devono
820 - Si può fornire una funzione cache_obj_rename() che prende il
824 - Si può decidere che ``cache_lock`` protegge solo la memoria stessa, ed
830 - un *lock* che protegge l'infrastruttura (la lista ``cache`` di questo
833 - un *lock* che protegge l'infrastruttura (inclusi i puntatori alla lista
837 - *lock* multipli per proteggere l'infrastruttura (per esempio un *lock*
844 --- cache.c.refcnt-atomic 2003-12-11 15:50:54.000000000 +1100
845 +++ cache.c.perobjectlock 2003-12-11 17:15:03.000000000 +1100
846 @@ -6,11 +6,17 @@
861 - int popularity;
865 @@ -77,6 +84,7 @@
866 obj->id = id;
867 obj->popularity = 0;
868 atomic_set(&obj->refcnt, 1); /* The cache holds a reference */
869 + spin_lock_init(&obj->lock);
878 in __cache_add(), non ho bisogno di trattenere il *lock* di ogni
881 Ho anche deciso che il campo id è immutabile, quindi non ho bisogno di
895 ----------------------------
899 il *lock* venga rilasciato (in Linux spinlocks, rwlocks e mutex non sono
901 Questo è facile da diagnosticare: non è uno di quei problemi che ti tengono
911 può succedere anche con un solo processore (Ma non sui sistemi
916 Questi casi sono facili da diagnosticare; sui sistemi multi-processore
917 il supervisione (*watchdog*) o l'opzione di compilazione ``DEBUG_SPINLOCK``
921 Esiste un caso più complesso che è conosciuto come l'abbraccio della morte;
926 del vecchio hash e di quello nuovo, quindi rimuovere l'oggetto dal vecchio ed
935 +---------------------------------+---------------------------------+
938 | Trattiene *lock* A -> OK | Trattiene *lock* B -> OK |
939 +---------------------------------+---------------------------------+
940 | Trattiene *lock* B -> attesa | Trattiene *lock* A -> attesa |
941 +---------------------------------+---------------------------------+
946 aspettando che l'altro lo rilasci. Sembra e puzza come un blocco totale.
949 --------------------
952 ordine non avrete mai un simile stallo. La pratica vi dirà che questo
953 approccio non funziona all'ingrandirsi del sistema: quando creo un nuovo
954 *lock* non ne capisco abbastanza del kernel per dire in quale dei 5000 *lock*
957 I *lock* migliori sono quelli incapsulati: non vengono esposti nei file di
958 intestazione, e non vengono mai trattenuti fuori dallo stesso file. Potete
959 rileggere questo codice e vedere che non ci sarà mai uno stallo perché
960 non tenterà mai di trattenere un altro *lock* quando lo ha già.
961 Le persone che usano il vostro codice non devono nemmeno sapere che voi
971 Gli stalli sono un problema, ma non così terribile come la corruzione dei dati.
978 --------------------------------------------------
984 Se volete eliminare l'intera collezione (diciamo quando rimuovete un modulo),
992 struct foo *next = list->next;
993 timer_delete(&list->timer);
1014 struct foo *next = list->next;
1015 if (!timer_delete(&list->timer)) {
1026 Un altro problema è l'eliminazione dei temporizzatori che si riavviano
1033 timer_shutdown() o timer_shutdown_sync() di modo che non venga più riarmato.
1046 altrimenti, non sareste interessati all'efficienza.
1049 trattenere un *lock* solo il tempo minimo necessario ma non un istante in più.
1055 l'operazione sulla *pipeline* (ovvero stalli della *pipeline*) e quant'è
1056 probabile che il processore corrente sia stato anche l'ultimo ad acquisire
1058 corrente?): su sistemi multi-processore questa probabilità precipita
1063 170/360ns (Leggetevi l'articolo di Paul McKenney's `Linux Journal RCU
1077 ------------------------
1089 trattenuto per molto tempo, allora l'uso di questo tipo di *lock* può aiutare.
1091 nella pratica l'uso di ``rwlock_t`` non ne vale la pena.
1094 --------------------------------------------
1097 Read Copy Update. Con l'uso della tecnica RCU, i lettori possono scordarsi
1110 new->next = list->next;
1112 list->next = new;
1115 scritture. Questa garantisce che la prima operazione (impostare l'elemento
1120 se non vengono istruiti altrimenti: vogliamo che i lettori non vedano
1130 l'elemento o lo salteranno.
1134 list->next = old->next;
1137 questo (la versione normale corrompe il vecchio oggetto, e non vogliamo che
1142 troppo presto, ma non accorgersi che il contenuto caricato è sbagliato quando
1146 list_for_each_entry() dato che non ci possono essere due scrittori
1150 l'elemento rimosso? Ricordate, un lettore potrebbe aver avuto accesso a questo
1155 richiamo che distrugga l'oggetto quando tutti i lettori correnti hanno
1157 synchronize_rcu() che blocca l'esecuzione finché tutti i lettori
1158 non terminano di ispezionare la lista.
1160 Ma come fa l'RCU a sapere quando i lettori sono finiti? Il meccanismo è
1163 prelazione così che i lettori non vengano sospesi mentre stanno leggendo
1166 Poi, l'RCU aspetta finché tutti i processori non abbiano dormito almeno
1167 una volta; a questo punto, dato che i lettori non possono dormire, possiamo
1170 codice RCU è un po' più ottimizzato di così, ma questa è l'idea di fondo.
1174 --- cache.c.perobjectlock 2003-12-11 17:15:03.000000000 +1100
1175 +++ cache.c.rcupdate 2003-12-11 17:55:14.000000000 +1100
1176 @@ -1,15 +1,18 @@
1186 - /* These two protected by cache_lock. */
1196 @@ -40,7 +43,7 @@
1200 - list_for_each_entry(i, &cache, list) {
1202 if (i->id == id) {
1203 i->popularity++;
1205 @@ -49,19 +52,25 @@
1219 - list_del(&obj->list);
1220 - object_put(obj);
1221 + list_del_rcu(&obj->list);
1222 cache_num--;
1223 + call_rcu(&obj->rcu, cache_delete_rcu);
1229 - list_add(&obj->list, &cache);
1230 + list_add_rcu(&obj->list, &cache);
1234 @@ -104,12 +114,11 @@
1238 - unsigned long flags;
1240 - spin_lock_irqsave(&cache_lock, flags);
1245 - spin_unlock_irqrestore(&cache_lock, flags);
1251 __cache_find(), e ora non trattiene alcun *lock*. Una soluzione
1252 potrebbe essere quella di rendere la variabile ``atomic_t``, ma per l'uso
1253 che ne abbiamo fatto qui, non ci interessano queste corse critiche perché un
1254 risultato approssimativo è comunque accettabile, quindi non l'ho cambiato.
1256 Il risultato è che la funzione cache_find() non ha bisogno di alcuna
1258 multi-processore tanto quanto lo sarebbe su un sistema mono-processore.
1261 della nostra memoria dove non c'erano contatori di riferimenti e il chiamante
1263 ancora possibile: se trattenete un *lock* nessuno potrà cancellare l'oggetto,
1264 quindi non avete bisogno di incrementare e decrementare il contatore di
1267 Ora, dato che il '*lock* di lettura' di un RCU non fa altro che disabilitare
1269 chiamate cache_find() e object_put() non necessita
1271 esporre la funzione __cache_find() dichiarandola non-static,
1275 viene scritto: l'oggetto non viene alterato in alcun modo e quindi diventa
1276 molto più veloce su sistemi molti-processore grazie alla loro memoria cache.
1280 -------------------
1287 Se questo dovesse essere troppo lento (solitamente non lo è, ma se avete
1289 e quindi non sarebbe più necessaria la mutua esclusione. Vedere
1295 per-processore; su alcune architetture sono anche più efficienti
1298 Da notare che non esiste un modo facile ed affidabile per ottenere il valore
1300 non è un problema.
1303 --------------------------------------------------------------
1306 allora i *lock* non vi servono per niente: il kernel già vi garantisce che
1307 il gestore d'interruzione non verrà eseguito in contemporanea su diversi
1312 da un'interruzione software. Il gestore d'interruzione non utilizza alcun
1333 direttamente od indirettamente: non potete chiamarle se trattenere uno
1339 ---------------------------
1348 - Accessi allo spazio utente:
1350 - copy_from_user()
1352 - copy_to_user()
1354 - get_user()
1356 - put_user()
1358 - kmalloc(GFP_KERNEL) <kmalloc>`
1360 - mutex_lock_interruptible() and
1363 C'è anche mutex_trylock() che però non dorme.
1364 Comunque, non deve essere usata in un contesto d'interruzione dato
1365 che la sua implementazione non è sicura in quel contesto.
1366 Anche mutex_unlock() non dorme mai. Non può comunque essere
1368 dallo stesso processo che l'ha acquisito.
1370 Alcune funzioni che non dormono
1371 -------------------------------
1376 - printk()
1378 - kfree()
1380 - add_timer() e timer_delete()
1382 Riferimento per l'API dei Mutex
1385 .. kernel-doc:: include/linux/mutex.h
1388 .. kernel-doc:: kernel/locking/mutex.c
1391 Riferimento per l'API dei Futex
1394 .. kernel-doc:: kernel/futex/core.c
1397 .. kernel-doc:: kernel/futex/futex.h
1400 .. kernel-doc:: kernel/futex/pi.c
1403 .. kernel-doc:: kernel/futex/requeue.c
1406 .. kernel-doc:: kernel/futex/waitwake.c
1412 - ``Documentation/locking/spinlocks.rst``: la guida di Linus Torvalds agli
1415 - Unix Systems for Modern Architectures: Symmetric Multiprocessing and
1418 L'introduzione alla sincronizzazione a livello di kernel di Curt Schimmel
1419 è davvero ottima (non è scritta per Linux, ma approssimativamente si adatta
1421 per capire la sincronizzazione nei sistemi multi-processore.
1435 Grazie alla congrega per non aver avuto alcuna influenza su questo documento.
1441 Prima del kernel 2.5, o quando ``CONFIG_PREEMPT`` non è impostato, i processi
1442 in contesto utente non si avvicendano nell'esecuzione (in pratica, il
1443 processo userà il processore fino al proprio termine, a meno che non ci siano
1444 delle interruzioni). Con l'aggiunta di ``CONFIG_PREEMPT`` nella versione
1458 Non è il contesto utente: qui si processano le interruzioni hardware e
1464 identificare il processo con la macro ``current``. Da non confondere
1482 (Uni-Processor) un solo processore, ovvero non è SMP. (``CONFIG_SMP=n``).
1484 multi-processore / SMP
1485 (Symmetric Multi-Processor) kernel compilati per sistemi multi-processore