it_IT/kernel-hacking/locking.rst

99 funzioni a questo scopo. E poi ci sono quelle meno buone, ma farò finta
120 ma potreste bloccarvi trattenendolo. Se non potete trattenere un mutex
139 Se il kernel è compilato senza ``CONFIG_SMP`` ma con ``CONFIG_PREEMPT``,
161 ma questa dovrebbe essere evitata perché non ritorna in caso di segnali.
302 Condividere dati fra due gestori di interruzione hardware è molto raro, ma se
330 processore alla volta, ma se deve condividere dati con un altro thread, allora
381 contesto, ma come spin_lock(): dovete disabilitare i contesti che
717 non trattiene un riferimento per se, ma diventa più complicato.
911 può succedere anche con un solo processore (Ma non sui sistemi
971 Gli stalli sono un problema, ma non così terribile come la corruzione dei dati.
1049 trattenere un *lock* solo il tempo minimo necessario ma non un istante in più.
1059 rapidamente. Consideriamo un processore Intel Pentium III a 700Mhz: questo
1069 ma questo aumenta il numero di acquisizioni di *lock*, ed il risultato
1082 Se state solo leggendo i dati, potete acquisire il *lock* di lettura, ma
1084 il *lock* di lettura, ma solo uno scrittore alla volta può trattenere
1142 troppo presto, ma non accorgersi che il contenuto caricato è sbagliato quando
1160 Ma come fa l'RCU a sapere quando i lettori sono finiti? Il meccanismo è
1170 codice RCU è un po' più ottimizzato di così, ma questa è l'idea di fondo.
1252 potrebbe essere quella di rendere la variabile ``atomic_t``, ma per l'uso
1287 Se questo dovesse essere troppo lento (solitamente non lo è, ma se avete
1341 Le più comuni sono elencate qui di seguito, ma solitamente dovete leggere
1419    è davvero ottima (non è scritta per Linux, ma approssimativamente si adatta
1420    a tutte le situazioni). Il libro è costoso, ma vale ogni singolo spicciolo