Lines Matching refs:un
31 In un normale programma, potete incrementare un contatore nel seguente modo:
82 Questa sovrapposizione, ovvero quando un risultato dipende dal tempo che
90 interrompendo un processo nella sua sezione critica otterremo comunque
95 simultanei, ed utilizzare i *lock* per accertarsi che solo un'istanza
103 Se posso darvi un suggerimento: non dormite mai con qualcuno più pazzo di
104 voi. Ma se dovessi darvi un suggerimento sulla sincronizzazione:
111 pensare a prendervi un cane bello grande.
117 spinlock (``include/asm/spinlock.h``), un semplice *lock* che può essere
118 trattenuto solo da un processo: se non si può trattenere lo spinlock, allora
123 ma potreste bloccarvi trattenendolo. Se non potete trattenere un mutex
127 permettervi di sospendere un processo (vedere
138 gli spinlock non esistono. Questa è un'ottima scelta di progettazione:
140 non c'è la necessità di avere un *lock*.
145 la prelazione equivalente ad un sistema multi-processore senza preoccuparci
149 ``CONFIG_PREEMPT`` abilitate, anche quando non avete un sistema
160 allora, per proteggerla, potete utilizzare un semplice mutex
179 Se un softirq condivide dati col contesto utente, avete due problemi.
180 Primo, il contesto utente corrente potrebbe essere interroto da un softirq,
181 e secondo, la sezione critica potrebbe essere eseguita da un altro
185 l'opposto. (Il suffisso '_bh' è un residuo storico che fa riferimento al
186 "Bottom Halves", il vecchio nome delle interruzioni software. In un mondo
201 Questo caso è uguale al precedente, un tasklet viene eseguito da un softirq.
206 Anche questo caso è uguale al precedente, un timer viene eseguito da un
213 Qualche volta un tasklet od un timer potrebbero condividere i dati con
214 un altro tasklet o timer
219 Dato che un tasklet non viene mai eseguito contemporaneamente su due
226 Se un altro tasklet/timer vuole condividere dati col vostro tasklet o timer,
229 in un tasklet ed avete la garanzia che nessun altro verrà eseguito sullo
235 Spesso un softirq potrebbe condividere dati con se stesso o un tasklet/timer.
240 Lo stesso softirq può essere eseguito su un diverso processore: allo scopo
255 su un diverso processore.
262 Solitamente le interruzioni hardware comunicano con un tasklet o un softirq.
264 preso in carico da un softirq.
269 Se un gestore di interruzioni hardware condivide dati con un softirq, allora
271 un'interruzione hardware, e secondo, la sezione critica potrebbe essere
272 eseguita da un'interruzione hardware su un processore diverso. Questo è il caso
279 è in esecuzione: per questo si può usare :c:func:`spin_lock()`, che è un po'
280 più veloce. L'unica eccezione è quando un altro gestore d'interruzioni
292 potrà essere utilizzato in un'interruzione hardware (dove le interruzioni sono
293 già disabilitate) e in un softirq (dove la disabilitazione delle interruzioni
297 da un'interruzione hardware, quindi :c:func:`spin_lock_irq()` interrompe
315 - Se siete in un contesto utente (una qualsiasi chiamata di sistema)
319 - Altrimenti (== i dati possono essere manipolati da un'interruzione) usate
331 da un processore per volta, quindi non ci sono requisiti per la
332 sincronizzazione (per esempio, un thread può essere eseguito solo su un
333 processore alla volta, ma se deve condividere dati con un altro thread, allora
337 :c:func:`spin_lock_irqsave()`, che è un sovrainsieme di tutte le altre funzioni
374 Ci sono funzioni che provano a trattenere un *lock* solo una volta e
382 se ci riesce al primo colpo ritorna un valore diverso da zero, altrimenti
383 se fallisce ritorna 0. Questa funzione può essere utilizzata in un qualunque
388 ritorna un valore diverso da zero se è possibile trattenere il lock al primo
396 Guardiamo un semplice esempio: una memoria che associa nomi a numeri.
519 essere un timer che elimina oggetti dalla memoria.
587 se erano attive, altrimenti non farà niente (quando siamo già in un contesto
594 questa opzione deve diventare un parametro di :c:func:`cache_add()`.
601 codice potrebbero avere un puntatore a questi oggetti piuttosto che cercarli
606 rende la sincronizzazione più complicata dato che non avviene più in un unico
609 Il secondo problema è il problema del ciclo di vita: se un'altra struttura
610 mantiene un puntatore ad un oggetto, presumibilmente si aspetta che questo
613 :c:func:`cache_delete()` o peggio, aggiungere un oggetto che riutilizza lo
616 Dato che c'è un solo *lock*, non potete trattenerlo a vita: altrimenti
619 La soluzione a questo problema è l'uso di un contatore di riferimenti:
620 chiunque punti ad un oggetto deve incrementare il contatore, e decrementarlo
718 per ogni puntatore ad un oggetto: quindi il contatore di riferimenti è 1
720 non trattiene un riferimento per se, ma diventa più complicato.
726 Ci sono un certo numbero di operazioni atomiche definite
821 trattenere il *lock* prima di modificare il nome di un oggetto.
828 un altro *lock* è necessario per la protezione del nome.
830 Teoricamente, possiamo avere un *lock* per ogni campo e per ogni oggetto.
833 - un *lock* che protegge l'infrastruttura (la lista ``cache`` di questo
836 - un *lock* che protegge l'infrastruttura (inclusi i puntatori alla lista
837 negli oggetti), e un *lock* nell'oggetto per proteggere il resto
840 - *lock* multipli per proteggere l'infrastruttura (per esempio un *lock*
841 per ogni lista), possibilmente con un *lock* per oggetto.
843 Qui di seguito un'implementazione con "un lock per oggetto":
889 Inoltre, da notare che ho aggiunto un commento che descrive i dati che sono
902 Esiste un tipo di baco dove un pezzo di codice tenta di trattenere uno
909 Un caso un pochino più complesso; immaginate d'avere una spazio condiviso
910 fra un softirq ed il contesto utente. Se usate :c:func:`spin_lock()` per
911 proteggerlo, il contesto utente potrebbe essere interrotto da un softirq
916 può succedere anche con un solo processore (Ma non sui sistemi
926 Esiste un caso più complesso che è conosciuto come l'abbraccio della morte;
927 questo coinvolge due o più *lock*. Diciamo che avete un vettore di hash in cui
929 stesso hash. In un gestore di interruzioni software, dovete modificare un
930 oggetto e spostarlo su un altro hash; quindi dovrete trattenete lo spinlock
934 Qui abbiamo due problemi. Primo, se il vostro codice prova a spostare un
937 interruzione software su un altro processore sta tentando di spostare
938 un altro oggetto nella direzione opposta, potrebbe accadere quanto segue:
951 aspettando che l'altro lo rilasci. Sembra e puzza come un blocco totale.
957 ordine non avrete mai un simile stallo. La pratica vi dirà che questo
958 approccio non funziona all'ingrandirsi del sistema: quando creo un nuovo
965 non tenterà mai di trattenere un altro *lock* quando lo ha già.
970 chiamate mentre trattenete un *lock*, rischiate uno stallo o un abbraccio
976 Gli stalli sono un problema, ma non così terribile come la corruzione dei dati.
977 Un pezzo di codice trattiene un *lock* di lettura, cerca in una lista,
979 trattiene un *lock* di scrittura ed inserisce un oggetto; questo genere di
985 corsa fra temporizzatori: un passatempo del kernel
990 ha un temporizzatore che sta per distruggerlo.
992 Se volete eliminare l'intera collezione (diciamo quando rimuovete un modulo),
1008 Primo o poi, questo esploderà su un sistema multiprocessore perché un
1036 Dato che questo è un problema abbastanza comune con una propensione
1046 la velocità d'esecuzione di un pezzo di codice che necessita di
1048 mentre qualcuno trattiene un *lock*. La seconda è il tempo necessario per
1049 acquisire (senza contese) e rilasciare un *lock*. La terza è di usare meno
1053 La concorrenza dipende da quanto a lungo un *lock* è trattenuto: dovreste
1054 trattenere un *lock* solo il tempo minimo necessario ma non un istante in più.
1059 Il tempo di acquisizione di un *lock* dipende da quanto danno fa
1064 rapidamente. Consideriamo un processore Intel Pentium III a 700Mhz: questo
1065 esegue un'istruzione in 0.7ns, un incremento atomico richiede 58ns, acquisire
1066 un *lock* che è nella memoria cache del processore richiede 160ns, e un
1067 trasferimento dalla memoria cache di un altro processore richiede altri
1071 Questi due obiettivi sono in conflitto: trattenere un *lock* per il minor
1073 parti (come nel nostro ultimo esempio con un *lock* per ogni oggetto),
1075 spesso è che tutto è più lento che con un singolo *lock*. Questo è un altro
1101 Esiste un metodo di sincronizzazione per letture e scritture detto
1106 un'ottimizzazione.
1133 Rimuovere un elemento dalla lista è anche più facile: sostituiamo il puntatore
1155 l'elemento rimosso? Ricordate, un lettore potrebbe aver avuto accesso a questo
1173 dedurre che un qualsiasi lettore che abbia consultato la lista durante la
1175 codice RCU è un po' più ottimizzato di così, ma questa è l'idea di fondo.
1258 che ne abbiamo fatto qui, non ci interessano queste corse critiche perché un
1262 sincronizzazione con le altre funzioni, quindi è veloce su un sistema
1263 multi-processore tanto quanto lo sarebbe su un sistema mono-processore.
1265 Esiste un'ulteriore ottimizzazione possibile: vi ricordate il codice originale
1267 semplicemente tratteneva il *lock* prima di accedere ad un oggetto? Questo è
1268 ancora possibile: se trattenete un *lock* nessuno potrà cancellare l'oggetto,
1272 Ora, dato che il '*lock* di lettura' di un RCU non fa altro che disabilitare
1273 la prelazione, un chiamante che ha sempre la prelazione disabilitata fra le
1290 avere un contatore di qualcosa, potreste utilizzare uno spinlock ed un
1294 dimostrato che lo è devvero), potreste usare un contatore per ogni processore
1304 Da notare che non esiste un modo facile ed affidabile per ottenere il valore
1305 di un simile contatore senza introdurre altri *lock*. In alcuni casi questo
1306 non è un problema.
1317 se i dati vengono occasionalmente utilizzati da un contesto utente o
1318 da un'interruzione software. Il gestore d'interruzione non utilizza alcun
1329 un altro processore). Lo spinlock, invece, previene accessi simultanei.
1342 dovete necessariamente essere nel contesto utente: chiamarle da un
1352 aspettano d'essere chiamante da un contesto utente e quindi che possono
1371 Comunque, non deve essere usata in un contesto d'interruzione dato
1374 usata in un contesto d'interruzione perché un mutex deve essere rilasciato
1381 contesto, o trattenendo un qualsiasi *lock*.
1423 pulita e aggiunto un po' di stile.
1449 sostituiti dai tasklet. In un dato momento potrà esserci solo un
1457 Il kernel che esegue qualcosa per conto di un particolare processo (per
1458 esempio una chiamata di sistema) o di un thread del kernel. Potete
1464 Richiesta di interruzione hardware. :c:func:`in_irq()` ritorna vero in un
1472 In soldoni, un softirq è uno delle 32 interruzioni software che possono
1477 (Uni-Processor) un solo processore, ovvero non è SMP. (``CONFIG_SMP=n``).
1488 d'essere eseguita solo su un processore alla volta.
1492 (circa) in un determinato momento. Quando è in esecuzione è come un tasklet