Lines Matching full:non
100 che non esistano.
105 Se posso darvi un suggerimento: non dormite mai con qualcuno più pazzo di
120 trattenuto solo da un processo: se non si può trattenere lo spinlock, allora
121 rimane in attesa attiva (in inglese *spinning*) finché non ci riesce.
125 ma potreste bloccarvi trattenendolo. Se non potete trattenere un mutex
128 mentre il vostro processo è in attesa. Esistono molti casi in cui non potete
140 gli spinlock non esistono. Questa è un'ottima scelta di progettazione:
142 non c'è la necessità di avere un *lock*.
151 ``CONFIG_PREEMPT`` abilitate, anche quando non avete un sistema
166 ma questa dovrebbe essere evitata perché non ritorna in caso di segnali.
172 o scaricato (e durante l'avvio del sistema, qui non abbiamo concorrenza),
221 Dato che un tasklet non viene mai eseguito contemporaneamente su due
222 processori, non dovete preoccuparvi che sia rientrante (ovvero eseguito
279 Il gestore d'interruzione hardware non ha bisogno di usare spin_lock_irq()
280 perché i softirq non possono essere eseguiti quando il gestore d'interruzione
333 da un processore per volta, quindi non ci sono requisiti per la
378 dell'operazione. Posso essere usate quando non serve accedere ai dati
383 La funzione spin_trylock() non ritenta di acquisire il *lock*,
391 colpo, altrimenti se fallisce ritorna 0. Nonostante non dorma, questa funzione
392 non può essere usata in modo sicuro in contesti di interruzione hardware o
508 caso è semplice dato che copiamo i dati dall'utente e non permettiamo
513 sicuro perché nessun altro potrà accedervi finché non lo inseriremo
589 se erano attive, altrimenti non farà niente (quando siamo già in un contesto
601 Se i vostri oggetti contengono più informazioni, potrebbe non essere
608 rende la sincronizzazione più complicata dato che non avviene più in un unico
618 Dato che c'è un solo *lock*, non potete trattenerlo a vita: altrimenti
623 quando il puntatore non viene più usato. Quando il contatore raggiunge lo zero
624 significa che non è più usato e l'oggetto può essere rimosso.
722 non trattiene un riferimento per se, ma diventa più complicato.
730 processore del sistema, quindi non sono necessari i *lock*. In questo caso è
732 sia più elegante per casi non banali. Le funzioni atomic_inc() e
734 incremento e decremento, e i *lock* non sono più necessari per proteggere il
819 di riferimenti) non cambino mai dopo la loro creazione. Se vogliamo permettere
883 in __cache_add(), non ho bisogno di trattenere il *lock* di ogni
886 Ho anche deciso che il campo id è immutabile, quindi non ho bisogno di
906 il *lock* venga rilasciato (in Linux spinlocks, rwlocks e mutex non sono
908 Questo è facile da diagnosticare: non è uno di quei problemi che ti tengono
918 può succedere anche con un solo processore (Ma non sui sistemi
959 ordine non avrete mai un simile stallo. La pratica vi dirà che questo
960 approccio non funziona all'ingrandirsi del sistema: quando creo un nuovo
961 *lock* non ne capisco abbastanza del kernel per dire in quale dei 5000 *lock*
964 I *lock* migliori sono quelli incapsulati: non vengono esposti nei file di
965 intestazione, e non vengono mai trattenuti fuori dallo stesso file. Potete
966 rileggere questo codice e vedere che non ci sarà mai uno stallo perché
967 non tenterà mai di trattenere un altro *lock* quando lo ha già.
968 Le persone che usano il vostro codice non devono nemmeno sapere che voi
978 Gli stalli sono un problema, ma non così terribile come la corruzione dei dati.
984 Se non riuscite a capire il perché, per favore state alla larga dal mio
1053 altrimenti, non sareste interessati all'efficienza.
1056 trattenere un *lock* solo il tempo minimo necessario ma non un istante in più.
1098 nella pratica l'uso di ``rwlock_t`` non ne vale la pena.
1127 se non vengono istruiti altrimenti: vogliamo che i lettori non vedano
1144 questo (la versione normale corrompe il vecchio oggetto, e non vogliamo che
1149 troppo presto, ma non accorgersi che il contenuto caricato è sbagliato quando
1153 list_for_each_entry() dato che non ci possono essere due scrittori
1165 non terminano di ispezionare la lista.
1170 prelazione così che i lettori non vengano sospesi mentre stanno leggendo
1173 Poi, l'RCU aspetta finché tutti i processori non abbiano dormito almeno
1174 una volta; a questo punto, dato che i lettori non possono dormire, possiamo
1258 __cache_find(), e ora non trattiene alcun *lock*. Una soluzione
1260 che ne abbiamo fatto qui, non ci interessano queste corse critiche perché un
1261 risultato approssimativo è comunque accettabile, quindi non l'ho cambiato.
1263 Il risultato è che la funzione cache_find() non ha bisogno di alcuna
1268 della nostra memoria dove non c'erano contatori di riferimenti e il chiamante
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
1276 chiamate cache_find() e object_put() non necessita
1278 esporre la funzione __cache_find() dichiarandola non-static,
1282 viene scritto: l'oggetto non viene alterato in alcun modo e quindi diventa
1295 Se questo dovesse essere troppo lento (solitamente non lo è, ma se avete
1297 e quindi non sarebbe più necessaria la mutua esclusione. Vedere
1306 Da notare che non esiste un modo facile ed affidabile per ottenere il valore
1308 non è un problema.
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
1320 da un'interruzione software. Il gestore d'interruzione non utilizza alcun
1342 direttamente od indirettamente: non potete chiamarle se trattenere uno
1372 C'è anche mutex_trylock() che però non dorme.
1373 Comunque, non deve essere usata in un contesto d'interruzione dato
1374 che la sua implementazione non è sicura in quel contesto.
1375 Anche mutex_unlock() non dorme mai. Non può comunque essere
1379 Alcune funzioni che non dormono
1416 è davvero ottima (non è scritta per Linux, ma approssimativamente si adatta
1432 Grazie alla congrega per non aver avuto alcuna influenza su questo documento.
1438 Prima del kernel 2.5, o quando ``CONFIG_PREEMPT`` non è impostato, i processi
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
1479 (Uni-Processor) un solo processore, ovvero non è SMP. (``CONFIG_SMP=n``).