Lines Matching refs:un
33 In un normale programma, potete incrementare un contatore nel seguente modo:
84 Questa sovrapposizione, ovvero quando un risultato dipende dal tempo che
92 interrompendo un processo nella sua sezione critica otterremo comunque
97 simultanei, ed utilizzare i *lock* per accertarsi che solo un'istanza
105 Se posso darvi un suggerimento: non dormite mai con qualcuno più pazzo di
106 voi. Ma se dovessi darvi un suggerimento sulla sincronizzazione:
113 pensare a prendervi un cane bello grande.
119 spinlock (``include/asm/spinlock.h``), un semplice *lock* che può essere
120 trattenuto solo da un processo: se non si può trattenere lo spinlock, allora
125 ma potreste bloccarvi trattenendolo. Se non potete trattenere un mutex
129 permettervi di sospendere un processo (vedere
140 gli spinlock non esistono. Questa è un'ottima scelta di progettazione:
142 non c'è la necessità di avere un *lock*.
147 la prelazione equivalente ad un sistema multi-processore senza preoccuparci
151 ``CONFIG_PREEMPT`` abilitate, anche quando non avete un sistema
162 allora, per proteggerla, potete utilizzare un semplice mutex
181 Se un softirq condivide dati col contesto utente, avete due problemi.
182 Primo, il contesto utente corrente potrebbe essere interroto da un softirq,
183 e secondo, la sezione critica potrebbe essere eseguita da un altro
187 l'opposto. (Il suffisso '_bh' è un residuo storico che fa riferimento al
188 "Bottom Halves", il vecchio nome delle interruzioni software. In un mondo
203 Questo caso è uguale al precedente, un tasklet viene eseguito da un softirq.
208 Anche questo caso è uguale al precedente, un timer viene eseguito da un
215 Qualche volta un tasklet od un timer potrebbero condividere i dati con
216 un altro tasklet o timer
221 Dato che un tasklet non viene mai eseguito contemporaneamente su due
228 Se un altro tasklet/timer vuole condividere dati col vostro tasklet o timer,
231 in un tasklet ed avete la garanzia che nessun altro verrà eseguito sullo
237 Spesso un softirq potrebbe condividere dati con se stesso o un tasklet/timer.
242 Lo stesso softirq può essere eseguito su un diverso processore: allo scopo
257 su un diverso processore.
264 Solitamente le interruzioni hardware comunicano con un tasklet o un softirq.
266 preso in carico da un softirq.
271 Se un gestore di interruzioni hardware condivide dati con un softirq, allora
273 un'interruzione hardware, e secondo, la sezione critica potrebbe essere
274 eseguita da un'interruzione hardware su un processore diverso. Questo è il caso
281 hardware è in esecuzione: per questo si può usare spin_lock(), che è un po'
282 più veloce. L'unica eccezione è quando un altro gestore d'interruzioni
294 potrà essere utilizzato in un'interruzione hardware (dove le interruzioni sono
295 già disabilitate) e in un softirq (dove la disabilitazione delle interruzioni
299 da un'interruzione hardware, quindi spin_lock_irq() interrompe
317 - Se siete in un contesto utente (una qualsiasi chiamata di sistema)
321 - Altrimenti (== i dati possono essere manipolati da un'interruzione) usate
333 da un processore per volta, quindi non ci sono requisiti per la
334 sincronizzazione (per esempio, un thread può essere eseguito solo su un
335 processore alla volta, ma se deve condividere dati con un altro thread, allora
339 spin_lock_irqsave(), che è un sovrainsieme di tutte le altre funzioni
376 Ci sono funzioni che provano a trattenere un *lock* solo una volta e
384 se ci riesce al primo colpo ritorna un valore diverso da zero, altrimenti
385 se fallisce ritorna 0. Questa funzione può essere utilizzata in un qualunque
390 ritorna un valore diverso da zero se è possibile trattenere il lock al primo
398 Guardiamo un semplice esempio: una memoria che associa nomi a numeri.
521 essere un timer che elimina oggetti dalla memoria.
589 se erano attive, altrimenti non farà niente (quando siamo già in un contesto
596 questa opzione deve diventare un parametro di cache_add().
603 codice potrebbero avere un puntatore a questi oggetti piuttosto che cercarli
608 rende la sincronizzazione più complicata dato che non avviene più in un unico
611 Il secondo problema è il problema del ciclo di vita: se un'altra struttura
612 mantiene un puntatore ad un oggetto, presumibilmente si aspetta che questo
615 cache_delete() o peggio, aggiungere un oggetto che riutilizza lo
618 Dato che c'è un solo *lock*, non potete trattenerlo a vita: altrimenti
621 La soluzione a questo problema è l'uso di un contatore di riferimenti:
622 chiunque punti ad un oggetto deve incrementare il contatore, e decrementarlo
720 per ogni puntatore ad un oggetto: quindi il contatore di riferimenti è 1
722 non trattiene un riferimento per se, ma diventa più complicato.
728 Ci sono un certo numbero di operazioni atomiche definite
823 trattenere il *lock* prima di modificare il nome di un oggetto.
830 un altro *lock* è necessario per la protezione del nome.
832 Teoricamente, possiamo avere un *lock* per ogni campo e per ogni oggetto.
835 - un *lock* che protegge l'infrastruttura (la lista ``cache`` di questo
838 - un *lock* che protegge l'infrastruttura (inclusi i puntatori alla lista
839 negli oggetti), e un *lock* nell'oggetto per proteggere il resto
842 - *lock* multipli per proteggere l'infrastruttura (per esempio un *lock*
843 per ogni lista), possibilmente con un *lock* per oggetto.
845 Qui di seguito un'implementazione con "un lock per oggetto":
891 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 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
1289 avere un contatore di qualcosa, potreste utilizzare uno spinlock ed un
1293 dimostrato che lo è devvero), potreste usare un contatore per ogni processore
1303 Da notare che non esiste un modo facile ed affidabile per ottenere il valore
1304 di un simile contatore senza introdurre altri *lock*. In alcuni casi questo
1305 non è un problema.
1316 se i dati vengono occasionalmente utilizzati da un contesto utente o
1317 da un'interruzione software. Il gestore d'interruzione non utilizza alcun
1328 un altro processore). Lo spinlock, invece, previene accessi simultanei.
1340 dovete necessariamente essere nel contesto utente: chiamarle da un
1350 aspettano d'essere chiamante da un contesto utente e quindi che possono
1369 Comunque, non deve essere usata in un contesto d'interruzione dato
1372 usata in un contesto d'interruzione perché un mutex deve essere rilasciato
1379 contesto, o trattenendo un qualsiasi *lock*.
1433 pulita e aggiunto un po' di stile.
1459 sostituiti dai tasklet. In un dato momento potrà esserci solo un
1467 Il kernel che esegue qualcosa per conto di un particolare processo (per
1468 esempio una chiamata di sistema) o di un thread del kernel. Potete
1474 Richiesta di interruzione hardware. in_hardirq() ritorna vero in un
1482 In soldoni, un softirq è uno delle 32 interruzioni software che possono
1487 (Uni-Processor) un solo processore, ovvero non è SMP. (``CONFIG_SMP=n``).
1498 d'essere eseguita solo su un processore alla volta.
1502 (circa) in un determinato momento. Quando è in esecuzione è come un tasklet