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 dovessi darvi un suggerimento sulla sincronizzazione: **mantenetela
114 spinlock (``include/asm/spinlock.h``), un semplice *lock* che può essere
115 trattenuto solo da un processo: se non si può trattenere lo spinlock, allora
120 ma potreste bloccarvi trattenendolo. Se non potete trattenere un mutex
124 permettervi di sospendere un processo (vedere
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
157 allora, per proteggerla, potete utilizzare un semplice mutex
176 Se un softirq condivide dati col contesto utente, avete due problemi.
177 Primo, il contesto utente corrente potrebbe essere interroto da un softirq,
178 e secondo, la sezione critica potrebbe essere eseguita da un altro
182 l'opposto. (Il suffisso '_bh' è un residuo storico che fa riferimento al
183 "Bottom Halves", il vecchio nome delle interruzioni software. In un mondo
198 Questo caso è uguale al precedente, un tasklet viene eseguito da un softirq.
203 Anche questo caso è uguale al precedente, un timer viene eseguito da un
210 Qualche volta un tasklet od un timer potrebbero condividere i dati con
211 un altro tasklet o timer
216 Dato che un tasklet non viene mai eseguito contemporaneamente su due
223 Se un altro tasklet/timer vuole condividere dati col vostro tasklet o timer,
226 in un tasklet ed avete la garanzia che nessun altro verrà eseguito sullo
232 Spesso un softirq potrebbe condividere dati con se stesso o un tasklet/timer.
237 Lo stesso softirq può essere eseguito su un diverso processore: allo scopo
252 su un diverso processore.
259 Solitamente le interruzioni hardware comunicano con un tasklet o un softirq.
261 preso in carico da un softirq.
266 Se un gestore di interruzioni hardware condivide dati con un softirq, allora
268 un'interruzione hardware, e secondo, la sezione critica potrebbe essere
269 eseguita da un'interruzione hardware su un processore diverso. Questo è il caso
276 hardware è in esecuzione: per questo si può usare spin_lock(), che è un po'
277 più veloce. L'unica eccezione è quando un altro gestore d'interruzioni
289 potrà essere utilizzato in un'interruzione hardware (dove le interruzioni sono
290 già disabilitate) e in un softirq (dove la disabilitazione delle interruzioni
294 da un'interruzione hardware, quindi spin_lock_irq() interrompe
312 - Se siete in un contesto utente (una qualsiasi chiamata di sistema)
316 - Altrimenti (== i dati possono essere manipolati da un'interruzione) usate
328 da un processore per volta, quindi non ci sono requisiti per la
329 sincronizzazione (per esempio, un thread può essere eseguito solo su un
330 processore alla volta, ma se deve condividere dati con un altro thread, allora
334 spin_lock_irqsave(), che è un sovrainsieme di tutte le altre funzioni
371 Ci sono funzioni che provano a trattenere un *lock* solo una volta e
379 se ci riesce al primo colpo ritorna un valore diverso da zero, altrimenti
380 se fallisce ritorna 0. Questa funzione può essere utilizzata in un qualunque
385 ritorna un valore diverso da zero se è possibile trattenere il lock al primo
393 Guardiamo un semplice esempio: una memoria che associa nomi a numeri.
516 essere un timer che elimina oggetti dalla memoria.
584 se erano attive, altrimenti non farà niente (quando siamo già in un contesto
591 questa opzione deve diventare un parametro di cache_add().
598 codice potrebbero avere un puntatore a questi oggetti piuttosto che cercarli
603 rende la sincronizzazione più complicata dato che non avviene più in un unico
606 Il secondo problema è il problema del ciclo di vita: se un'altra struttura
607 mantiene un puntatore ad un oggetto, presumibilmente si aspetta che questo
610 cache_delete() o peggio, aggiungere un oggetto che riutilizza lo
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:
617 chiunque punti ad un oggetto deve incrementare il contatore, e decrementarlo
715 per ogni puntatore ad un oggetto: quindi il contatore di riferimenti è 1
717 non trattiene un riferimento per se, ma diventa più complicato.
723 Ci sono un certo numbero di operazioni atomiche definite
818 trattenere il *lock* prima di modificare il nome di un oggetto.
825 un altro *lock* è necessario per la protezione del nome.
827 Teoricamente, possiamo avere un *lock* per ogni campo e per ogni oggetto.
830 - un *lock* che protegge l'infrastruttura (la lista ``cache`` di questo
833 - un *lock* che protegge l'infrastruttura (inclusi i puntatori alla lista
834 negli oggetti), e un *lock* nell'oggetto per proteggere il resto
837 - *lock* multipli per proteggere l'infrastruttura (per esempio un *lock*
838 per ogni lista), possibilmente con un *lock* per oggetto.
840 Qui di seguito un'implementazione con "un lock per oggetto":
886 Inoltre, da notare che ho aggiunto un commento che descrive i dati che sono
897 Esiste un tipo di baco dove un pezzo di codice tenta di trattenere uno
904 Un caso un pochino più complesso; immaginate d'avere una spazio condiviso
905 fra un softirq ed il contesto utente. Se usate spin_lock() per
906 proteggerlo, il contesto utente potrebbe essere interrotto da un softirq
911 può succedere anche con un solo processore (Ma non sui sistemi
921 Esiste un caso più complesso che è conosciuto come l'abbraccio della morte;
922 questo coinvolge due o più *lock*. Diciamo che avete un vettore di hash in cui
924 stesso hash. In un gestore di interruzioni software, dovete modificare un
925 oggetto e spostarlo su un altro hash; quindi dovrete trattenete lo spinlock
929 Qui abbiamo due problemi. Primo, se il vostro codice prova a spostare un
932 interruzione software su un altro processore sta tentando di spostare
933 un altro oggetto nella direzione opposta, potrebbe accadere quanto segue:
946 aspettando che l'altro lo rilasci. Sembra e puzza come un blocco totale.
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
960 non tenterà mai di trattenere un altro *lock* quando lo ha già.
965 chiamate mentre trattenete un *lock*, rischiate uno stallo o un abbraccio
971 Gli stalli sono un problema, ma non così terribile come la corruzione dei dati.
972 Un pezzo di codice trattiene un *lock* di lettura, cerca in una lista,
974 trattiene un *lock* di scrittura ed inserisce un oggetto; questo genere di
977 corsa fra temporizzatori: un passatempo del kernel
982 ha un temporizzatore che sta per distruggerlo.
984 Se volete eliminare l'intera collezione (diciamo quando rimuovete un modulo),
1000 Primo o poi, questo esploderà su un sistema multiprocessore perché un
1028 Dato che questo è un problema abbastanza comune con una propensione
1032 Prima di rilasciare un temporizzatore dovreste chiamare la funzione
1041 la velocità d'esecuzione di un pezzo di codice che necessita di
1043 mentre qualcuno trattiene un *lock*. La seconda è il tempo necessario per
1044 acquisire (senza contese) e rilasciare un *lock*. La terza è di usare meno
1048 La concorrenza dipende da quanto a lungo un *lock* è trattenuto: dovreste
1049 trattenere un *lock* solo il tempo minimo necessario ma non un istante in più.
1054 Il tempo di acquisizione di un *lock* dipende da quanto danno fa
1059 rapidamente. Consideriamo un processore Intel Pentium III a 700Mhz: questo
1060 esegue un'istruzione in 0.7ns, un incremento atomico richiede 58ns, acquisire
1061 un *lock* che è nella memoria cache del processore richiede 160ns, e un
1062 trasferimento dalla memoria cache di un altro processore richiede altri
1066 Questi due obiettivi sono in conflitto: trattenere un *lock* per il minor
1068 parti (come nel nostro ultimo esempio con un *lock* per ogni oggetto),
1070 spesso è che tutto è più lento che con un singolo *lock*. Questo è un altro
1096 Esiste un metodo di sincronizzazione per letture e scritture detto
1101 un'ottimizzazione.
1128 Rimuovere un elemento dalla lista è anche più facile: sostituiamo il puntatore
1150 l'elemento rimosso? Ricordate, un lettore potrebbe aver avuto accesso a questo
1168 dedurre che un qualsiasi lettore che abbia consultato la lista durante la
1170 codice RCU è un po' più ottimizzato di così, ma questa è l'idea di fondo.
1253 che ne abbiamo fatto qui, non ci interessano queste corse critiche perché un
1257 sincronizzazione con le altre funzioni, quindi è veloce su un sistema
1258 multi-processore tanto quanto lo sarebbe su un sistema mono-processore.
1260 Esiste un'ulteriore ottimizzazione possibile: vi ricordate il codice originale
1262 semplicemente tratteneva il *lock* prima di accedere ad un oggetto? Questo è
1263 ancora possibile: se trattenete un *lock* nessuno potrà cancellare l'oggetto,
1267 Ora, dato che il '*lock* di lettura' di un RCU non fa altro che disabilitare
1268 la prelazione, un chiamante che ha sempre la prelazione disabilitata fra le
1284 avere un contatore di qualcosa, potreste utilizzare uno spinlock ed un
1288 dimostrato che lo è devvero), potreste usare un contatore per ogni processore
1298 Da notare che non esiste un modo facile ed affidabile per ottenere il valore
1299 di un simile contatore senza introdurre altri *lock*. In alcuni casi questo
1300 non è un problema.
1311 se i dati vengono occasionalmente utilizzati da un contesto utente o
1312 da un'interruzione software. Il gestore d'interruzione non utilizza alcun
1323 un altro processore). Lo spinlock, invece, previene accessi simultanei.
1335 dovete necessariamente essere nel contesto utente: chiamarle da un
1345 aspettano d'essere chiamante da un contesto utente e quindi che possono
1364 Comunque, non deve essere usata in un contesto d'interruzione dato
1367 usata in un contesto d'interruzione perché un mutex deve essere rilasciato
1374 contesto, o trattenendo un qualsiasi *lock*.
1428 pulita e aggiunto un po' di stile.
1454 sostituiti dai tasklet. In un dato momento potrà esserci solo un
1462 Il kernel che esegue qualcosa per conto di un particolare processo (per
1463 esempio una chiamata di sistema) o di un thread del kernel. Potete
1469 Richiesta di interruzione hardware. in_hardirq() ritorna vero in un
1477 In soldoni, un softirq è uno delle 32 interruzioni software che possono
1482 (Uni-Processor) un solo processore, ovvero non è SMP. (``CONFIG_SMP=n``).
1493 d'essere eseguita solo su un processore alla volta.
1497 (circa) in un determinato momento. Quando è in esecuzione è come un tasklet