Cambio di contesto

Il tempo della CPU come risorsa condivisa

I moderni sistemi operativi si destreggiano tra decine o centinaia di thread attivi.
Esistono solo pochi core della CPU, quindi la maggior parte dei thread attende in coda mentre un piccolo sottoinsieme viene eseguito.

A commutazione del contesto consente allo scheduler di mettere in pausa un thread in esecuzione e di riprenderne un altro.
Questa rapida commutazione crea l'illusione del parallelismo e modella anche ciò che si vede in seguito nei crash dump.

All'interno del contesto di esecuzione di un thread

Ogni thread non trasporta solo codice e dati.
Ha anche un contesto di esecuzione completo che il kernel deve salvare e ripristinare correttamente.

Tale contesto comprende:

• Registri e flag di uso generale della CPU

• Puntatore all'istruzione e puntatore allo stack

• Registri di segmento e registri di controllo, se pertinenti.

• Stack del kernel e dell'utente, oltre ad alcuni metadati di scheduler

Quando il kernel si allontana da un thread, deve registrare questo stato.
Quando lo scheduler ritorna allo stesso thread, ripristina tutto, in modo che l'esecuzione continui come se nulla fosse stato messo in pausa.

Passi del kernel durante un cambio di contesto

A basso livello, un cambio di contesto segue una sequenza prevedibile.
I dettagli cambiano da un'architettura all'altra, ma le azioni fondamentali rimangono simili.

1. Il thread in esecuzione raggiunge un punto di schedulazione, come un interrupt del timer o una chiamata di sistema bloccante.

2. Il kernel salva i registri della CPU, i puntatori allo stack e alcune informazioni di controllo nello stack del kernel o nel blocco di controllo del thread.

3. Lo scheduler sceglie il prossimo thread eseguibile in base a priorità, equità e affinità del processore.

4. Il kernel carica il contesto salvato per il thread successivo, compresi i registri e i puntatori allo stack.

5. Il controllo ritorna alla modalità utente o kernel nel nuovo thread, che continua con il puntatore all'istruzione precedente.

Questa sequenza si verifica milioni di volte al secondo sui sistemi occupati.
Qualsiasi errore in questi passaggi può causare corruzione dei dati, blocchi o un arresto anomalo che produce un file di dump.

Trigger che causano il cambio di contesto

I cambi di contesto non avvengono in modo casuale.
Essi derivano da eventi ben definiti all'interno del sistema operativo e dell'hardware.

Fattori scatenanti comuni:

• Il thread in esecuzione si blocca su I/O, un blocco o un oggetto wait

• Un interrupt del timer hardware indica che il thread ha utilizzato la sua fetta di tempo.

• Un thread a priorità più alta diventa pronto per l'esecuzione

• Lo scheduler riceve un segnale per riequilibrare il lavoro tra i core

I crash dump catturano qualsiasi thread sia stato eseguito quando si è verificata una condizione fatale o quando il kernel ha rilevato una grave incongruenza durante una di queste transizioni.

Crash dump e stati dei thread

Quando Windows si imbatte in un controllo di bug, blocca la programmazione e scrive un'istantanea della memoria su disco.
Questa istantanea di solito include dettagli su diversi thread e sui contesti che hanno causato o rilevato l'errore.

I crash dump di solito registrano:

• Il thread attivo su ciascuna CPU al momento del guasto

• Stack del kernel che mostrano quali funzioni sono state eseguite poco prima dell'arresto anomalo.

• Strutture che descrivono code pronte e stati di attesa

Esaminando questi thread e i loro ultimi eventi di cambio di contesto, gli analisti deducono quale driver, chiamata di sistema o azione dell'utente ha contribuito al guasto.

Considerazioni su prestazioni e affidabilità

La commutazione di contesto consente il multitasking, ma comporta un overhead.
Il kernel deve passare da un livello di privilegio all'altro, scaricare o ricaricare alcuni stati della CPU e disturbare il contenuto della cache.

Troppi cambi di contesto possono farlo:

• Aumentare il tempo di CPU trascorso nello scheduler

• Lesione della cache e della località TLB

• Riduzione del throughput per le applicazioni ad alta intensità di I/O

Instabile autisti o processi utente che si comportano male possono creare schemi di commutazione estremi, che a volte appaiono nei crash dump come lunghe pile di operazioni di wait e wake.
Nei casi più gravi, i bug durante queste transizioni causano corruzione della memoria o deadlock.

Uso pratico delle informazioni di contesto nell'analisi delle discariche