Lines Matching refs:il
20 (locking) nel kernel. Questo documento descrive il sistema di sincronizzazione
23 Dato il largo utilizzo del multi-threading e della prelazione nel kernel
93 la stessa corsa critica. In questo caso, il thread che si avvicenda
124 Il secondo tipo è il mutex (``include/linux/mutex.h``): è come uno spinlock,
126 il vostro processo si auto-sospenderà; verrà riattivato quando il mutex
127 verrà rilasciato. Questo significa che il processore potrà occuparsi d'altro
128 mentre il vostro processo è in attesa. Esistono molti casi in cui non potete
144 Se il kernel è compilato senza ``CONFIG_SMP`` ma con ``CONFIG_PREEMPT``,
163 (``include/linux/mutex.h``). Questo è il caso più semplice: inizializzate il
171 la rimozione vengono eseguite solamente quando il modulo viene caricato
178 Sincronizzazione fra il contesto utente e i softirq
182 Primo, il contesto utente corrente potrebbe essere interroto da un softirq,
186 sul processore e trattiene il *lock*. Invece, spin_unlock_bh() fa
188 "Bottom Halves", il vecchio nome delle interruzioni software. In un mondo
272 avrete due preoccupazioni. Primo, il softirq può essere interrotto da
274 eseguita da un'interruzione hardware su un processore diverso. Questo è il caso
276 sul processore che l'esegue, poi trattiene il lock. spin_unlock_irq()
280 perché i softirq non possono essere eseguiti quando il gestore d'interruzione
309 dell'architettura il fatto che tutte le interruzioni vengano interrotte
315 Pete Zaitcev ci offre il seguente riassunto:
319 il mutex e dormire (``copy_from_user*(`` o ``kmalloc(x,GFP_KERNEL)``).
338 Ricordatevi il suggerimento qui sopra: potete sempre usare
377 ritornano immediatamente comunicato il successo od il fallimento
380 trattenendo il *lock*. Potrete acquisire il *lock* più tardi se vi
383 La funzione spin_trylock() non ritenta di acquisire il *lock*,
389 La funzione mutex_trylock() invece di sospendere il vostro processo
390 ritorna un valore diverso da zero se è possibile trattenere il lock al primo
408 e tutti gli oggetti che contiene. Ecco il codice::
507 della memoria che il suo contenuto sono protetti dal *lock*. Questo
512 impostiamo i campi dell'oggetto prima di acquisire il *lock*. Questo è
519 Ora consideriamo il caso in cui cache_find() può essere invocata
607 dobbiamo renderlo dinamico così che il resto del codice possa usarlo. Questo
611 Il secondo problema è il problema del ciclo di vita: se un'altra struttura
614 si trattiene il *lock*, altrimenti qualcuno potrebbe chiamare
619 nessun altro potrà eseguire il proprio lavoro.
622 chiunque punti ad un oggetto deve incrementare il contatore, e decrementarlo
623 quando il puntatore non viene più usato. Quando il contatore raggiunge lo zero
626 Ecco il codice::
714 Abbiamo incapsulato il contatore di riferimenti nelle tipiche funzioni
717 copy_to_user() per copiare il nome verso lo spazio utente).
719 Un altro punto da notare è che ho detto che il contatore dovrebbe incrementarsi
720 per ogni puntatore ad un oggetto: quindi il contatore di riferimenti è 1
721 quando l'oggetto viene inserito nella memoria. In altre versione il framework
724 Usare operazioni atomiche per il contatore di riferimenti
734 incremento e decremento, e i *lock* non sono più necessari per proteggere il
823 trattenere il *lock* prima di modificare il nome di un oggetto.
825 - Si può fornire una funzione cache_obj_rename() che prende il
826 *lock* e cambia il nome per conto del chiamante; si dirà poi agli utenti
839 negli oggetti), e un *lock* nell'oggetto per proteggere il resto
879 Da notare che ho deciso che il contatore di popolarità dovesse essere
883 in __cache_add(), non ho bisogno di trattenere il *lock* di ogni
884 oggetto mentre si cerca il meno popolare.
886 Ho anche deciso che il campo id è immutabile, quindi non ho bisogno di
887 trattenere il lock dell'oggetto quando si usa __cache_find()
888 per leggere questo campo; il *lock* dell'oggetto è usato solo dal chiamante
889 che vuole leggere o scrivere il campo name.
892 protetti dal *lock*. Questo è estremamente importante in quanto descrive il
894 leggendo solamente il codice. E come dice Alan Cox: “Lock data, not code”.
906 il *lock* venga rilasciato (in Linux spinlocks, rwlocks e mutex non sono
912 fra un softirq ed il contesto utente. Se usate spin_lock() per
913 proteggerlo, il contesto utente potrebbe essere interrotto da un softirq
914 mentre trattiene il lock, da qui il softirq rimarrà in attesa attiva provando
915 ad acquisire il *lock* già trattenuto nel contesto utente.
919 monoprocessore perché gli spinlock spariscano quando il kernel è compilato
924 il supervisione (*watchdog*) o l'opzione di compilazione ``DEBUG_SPINLOCK``
936 Qui abbiamo due problemi. Primo, se il vostro codice prova a spostare un
968 Le persone che usano il vostro codice non devono nemmeno sapere che voi
980 fallisce nel trovare quello che vuole, quindi rilascia il *lock* di lettura,
984 Se non riuscite a capire il perché, per favore state alla larga dal mio
1012 e prenderà il *lock* solo dopo spin_unlock_bh(), e cercherà
1013 di eliminare il suo oggetto (che però è già stato eliminato).
1015 Questo può essere evitato controllando il valore di ritorno di
1016 del_timer(): se ritorna 1, il temporizzatore è stato già
1017 rimosso. Se 0, significa (in questo caso) che il temporizzatore è in
1040 (``include/linux/timer.h``) per gestire questo caso. Questa ritorna il
1041 numero di volte che il temporizzatore è stato interrotto prima che
1050 mentre qualcuno trattiene un *lock*. La seconda è il tempo necessario per
1056 trattenere un *lock* solo il tempo minimo necessario ma non un istante in più.
1058 il *lock*, poi acquisiamo il *lock* quando siamo pronti per inserirlo nella
1063 probabile che il processore corrente sia stato anche l'ultimo ad acquisire
1064 il *lock* (in pratica, il *lock* è nella memoria cache del processore
1073 Questi due obiettivi sono in conflitto: trattenere un *lock* per il minor
1076 ma questo aumenta il numero di acquisizioni di *lock*, ed il risultato
1081 il numero di sincronizzazioni che devono essere fatte.
1089 Se state solo leggendo i dati, potete acquisire il *lock* di lettura, ma
1091 il *lock* di lettura, ma solo uno scrittore alla volta può trattenere
1094 Se il vostro codice si divide chiaramente in codice per lettori e codice
1095 per scrittori (come nel nostro esempio), e il *lock* dei lettori viene
1125 il nuovo elemento nella lista). Questo è importante perché i moderni
1128 completamente il nuovo elemento; oppure che lo vedano correttamente e quindi
1129 il puntatore ``next`` deve puntare al resto della lista.
1135 Rimuovere un elemento dalla lista è anche più facile: sostituiamo il puntatore
1144 questo (la versione normale corrompe il vecchio oggetto, e non vogliamo che
1148 attraverso il puntatore ``next`` il contenuto dell'elemento successivo
1149 troppo presto, ma non accorgersi che il contenuto caricato è sbagliato quando
1150 il puntatore ``next`` viene modificato alla loro spalle. Ancora una volta
1156 Il nostro ultimo dilemma è il seguente: quando possiamo realmente distruggere
1158 elemento proprio ora: se eliminiamo questo elemento ed il puntatore ``next``
1159 cambia, il lettore salterà direttamente nella spazzatura e scoppierà. Dobbiamo
1168 il seguente: innanzi tutto i lettori accedono alla lista solo fra la coppia
1257 Da notare che i lettori modificano il campo popularity nella funzione
1267 Esiste un'ulteriore ottimizzazione possibile: vi ricordate il codice originale
1268 della nostra memoria dove non c'erano contatori di riferimenti e il chiamante
1269 semplicemente tratteneva il *lock* prima di accedere ad un oggetto? Questo è
1271 quindi non avete bisogno di incrementare e decrementare il contatore di
1274 Ora, dato che il '*lock* di lettura' di un RCU non fa altro che disabilitare
1277 di incrementare e decrementare il contatore di riferimenti. Potremmo
1281 Il beneficio qui sta nel fatto che il contatore di riferimenti no
1306 Da notare che non esiste un modo facile ed affidabile per ottenere il valore
1314 allora i *lock* non vi servono per niente: il kernel già vi garantisce che
1315 il gestore d'interruzione non verrà eseguito in contemporanea su diversi
1351 il codice per scoprire se altre chiamate sono sicure. Se chiunque altro
1439 in contesto utente non si avvicendano nell'esecuzione (in pratica, il
1440 processo userà il processore fino al proprio termine, a meno che non ci siano
1455 Non è il contesto utente: qui si processano le interruzioni hardware e
1461 identificare il processo con la macro ``current``. Da non confondere
1486 Un processo che esegue il proprio codice fuori dal kernel.