Perché non è permesso "dormire" mentre si tiene uno spinlock?

Question

Eventuali duplicati:
Why can't you sleep while holding spinlock?

Per quanto ne so, spinlocks deve essere usato in breve durata, e sono solo scelte nel codice, come gestore di interrupt dove dormire (prelazione) è non autorizzato.

Tuttavia, non so perché ci sia una "regola" che NON DOVREBBE non dormire affatto tenendo uno spinlock. So che non è una pratica raccomandata (dal momento che è dannosa per le prestazioni), ma non vedo ragioni per cui il sonno NON DEVE essere permesso negli spinlock.

Non si può tenere un blocco di selezione mentre si acquisiscono un semaforo, perché si potrebbe avere a dormire in attesa che il semaforo, e non si può dormire mentre si tiene un blocco di selezione (da "Linux Kernel Development" di Robert Love) . Non

L'unico motivo che posso vedere è per ragioni di portabilità, perché in un unico processore, spinlocks sono implementati come disabilitazione interrupt, e da interrupt invalidanti, dormire è naturalmente consentito (ma dormire non si romperà codice in sistemi SMP) .

Ma mi chiedo se il mio ragionamento è corretto o se ci sono altri motivi.

Answer 1

Ci sono diversi motivi per cui, almeno in Linux, dormendo in spinlocks non è consentito:

1. Se thread A dorme in uno spinlock, e filo B tenta quindi di acquisire la stessa spinlock, un sistema monoprocessore si bloccherà. Il thread B non andrà mai a dormire (perché gli spinlock non hanno la lista d'attesa necessaria per risvegliare B quando A è terminato), e il thread A non avrà mai la possibilità di svegliarsi.
2. Gli spinlocks sono usati sopra i semafori proprio perché sono più efficienti - fornito non si contende a lungo. Permettere di dormire significa che avrai lunghi periodi di contesa, cancellando tutti i benefici dell'uso di uno spinlock. Il tuo sistema sarebbe più veloce semplicemente usando un semaforo in questo caso.
3. Gli spinlock vengono spesso utilizzati per la sincronizzazione con i gestori di interrupt, per in aggiunta agli interrupt di disattivazione. Questo caso d'uso non è possibile se si dorme (una volta inserito il gestore di interrupt, non è possibile tornare al thread per farlo sveglie e terminare la sua sezione critica di spinlock).

Usa lo strumento giusto per il lavoro giusto - se hai bisogno di dormire, i semafori e i mutex sono i tuoi amici.

Answer 2

• In realtà, è possibile sonno con gli interrupt disabilitati o qualche altro tipo di esclusione attiva. Se non lo fai, la condizione per cui stai dormendo potrebbe cambiare stato a causa di un'interruzione e quindi non ti sveglierai mai. Normalmente il codice di sospensione non viene mai immesso senza una priorità elevata o qualche altra sezione critica che racchiuda il percorso di esecuzione tra la decisione di sospensione e lo switch di contesto.

• Ma per gli spinlock, il sonno è un disastro, poiché il blocco rimane impostato.Gli altri fili gireranno quando lo colpiscono e non smetteranno di ruotare finché non ti sveglierai dal sonno. Potrebbe essere un'eternità rispetto alla manciata di spin prevista nel peggiore dei casi in uno spinlock, perché gli spinlock esistono solo per sincronizzare l'accesso alle posizioni di memoria, non dovrebbero interagire con il meccanismo di cambio di contesto.
  
  (Del resto, ogni altro thread potrebbe eventualmente colpire lo spinlock e poi si sarebbe incastrato ogni thread di ogni nucleo di tutto il sistema.)

Answer 3

Non è possibile quando si utilizza un blocco di selezione in quanto è pensato per essere usato. I blocchi di rotazione vengono utilizzati laddove veramente necessario per proteggere le regioni critiche e le strutture di dati condivise. Se ne acquisisci uno mentre si tiene anche un semaforo, si blocca l'accesso a qualsiasi area critica (ad esempio) a cui è collegato il blocco (in genere è un membro di una specifica struttura di dati più grande), consentendo al tempo stesso di mettere a riposo questo processo. Se, per esempio, un IRQ viene generato mentre questo processo dorme, e il gestore IRQ ha bisogno di accedere all'area critica ancora bloccata, è bloccato, il che non può mai accadere con gli IRQ. Ovviamente, potresti creare degli esempi in cui il tuo spin lock non è usato nel modo in cui dovrebbe essere (un ipotetico spin lock collegato a un loop nop, ad esempio); ma questo non è semplicemente un vero spin lock trovato nei kernel di Linux.