Risposte:
La principale distinzione tra uno switch di thread e uno di processo è che durante uno switch di thread, lo spazio di memoria virtuale rimane lo stesso, mentre non lo è durante uno switch di processo. Entrambi i tipi prevedono il passaggio del controllo al kernel del sistema operativo per eseguire il cambio di contesto. Il processo di attivazione e disattivazione del kernel del sistema operativo insieme al costo di disattivazione dei registri è il costo fisso maggiore per l'esecuzione di un cambio di contesto.
Un costo più sfocato è che un interruttore di contesto combina i meccanismi di cache dei processori. Fondamentalmente, quando si cambia contesto, tutti gli indirizzi di memoria che il processore "ricorda" nella sua cache diventano effettivamente inutili. L'unica grande distinzione qui è che quando si cambiano gli spazi di memoria virtuale, il Translation Lookaside Buffer (TLB) del processore o equivalente viene svuotato rendendo gli accessi alla memoria molto più costosi per un po '. Ciò non accade durante un cambio di thread.
La commutazione del contesto di processo comporta la commutazione dello spazio degli indirizzi di memoria. Ciò include indirizzi di memoria, mappature, tabelle di pagine e risorse del kernel, un'operazione relativamente costosa. In alcune architetture, significa anche svuotare varie cache del processore che non sono condivisibili negli spazi degli indirizzi. Ad esempio, x86 deve svuotare il TLB e alcuni processori ARM devono svuotare l'intera cache L1!
Il cambio di thread è il cambio di contesto da un thread all'altro nello stesso processo (il passaggio da un thread all'altro tra processi è solo un cambio di processo). Lo stato del processore di commutazione (come il contatore del programma e il contenuto del registro) è generalmente molto efficiente.
Prima di tutto, il sistema operativo porta il thread in uscita in modalità kernel se non è già lì, perché il cambio di thread può essere eseguito solo tra thread, che viene eseguito in modalità kernel. Quindi lo scheduler viene invocato per prendere una decisione sul thread a cui verrà eseguita la commutazione. Dopo aver preso la decisione, il kernel salva parte del contesto del thread che si trova nella CPU (registri della CPU) nella posizione dedicata in memoria (spesso nella parte superiore dello stack del kernel del thread in uscita). Quindi il kernel esegue il passaggio dallo stack del kernel del thread in uscita allo stack del kernel del thread in arrivo. Successivamente, il kernel carica dalla memoria i contesti precedentemente memorizzati del thread in arrivo nei registri della CPU. E infine restituisce il controllo in modalità utente, ma in modalità utente del nuovo thread. Nel caso in cui il sistema operativo abbia determinato l'esecuzione del thread in entrataun altro processo, il kernel esegue un ulteriore passaggio: imposta il nuovo spazio di indirizzi virtuali attivi.
Il costo principale in entrambi gli scenari è legato all'inquinamento da cache. Nella maggior parte dei casi, il working set utilizzato dal thread in uscita differirà in modo significativo dal working set utilizzato dal thread in arrivo. Di conseguenza, il thread in arrivo inizierà la sua vita con una valanga di errori cache, eliminando così i dati vecchi e inutili dalle cache e caricando i nuovi dati dalla memoria. Lo stesso vale per TLB (Translation Look Aside Buffer, che si trova sulla CPU). Nel caso di reimpostazione dello spazio degli indirizzi virtuali (i thread vengono eseguiti in processi diversi) la penalità è ancora peggiore, poiché il ripristino dello spazio degli indirizzi virtuali comporta lo svuotamento dell'intero TLB, anchese il nuovo thread deve effettivamente caricare solo poche nuove voci. Di conseguenza, il nuovo thread inizierà il suo tempo quantico con molti mancati TLB e frequenti camminate di pagina. Anche il costo diretto del cambio thread non è trascurabile (da ~ 250 e fino a ~ 1500-2000 cicli) e dipende dalla complessità della CPU, dagli stati di entrambi i thread e dai set di registri che effettivamente utilizzano.
PS: buon post sull'overhead del cambio di contesto: http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html
In Thread Context Switching, lo spazio di memoria virtuale rimane lo stesso mentre non è nel caso di Process Context Switch. Inoltre, Process Context Switch è più costoso di Thread Context Switch.
Penso che la differenza principale sia quando si chiama switch_mm()
che gestisce i descrittori di memoria di attività vecchie e nuove. Nel caso dei thread, lo spazio degli indirizzi della memoria virtuale è invariato (i thread condividono la memoria virtuale), quindi è necessario fare pochissimo e quindi meno costoso.
Sebbene il cambio di contesto del thread debba cambiare il contesto di esecuzione (registri, puntatori di stack, contatori di programmi), non è necessario modificare lo spazio degli indirizzi come fanno i switch di contesto dei processi. C'è un costo aggiuntivo quando si cambia lo spazio degli indirizzi, più accesso alla memoria (paginazione, segmentazione, ecc.) E si deve scaricare TLB quando si entra o si esce da un nuovo processo ...
In breve, l'interruttore di contesto del thread non assegna un nuovissimo set di memoria e pid, utilizza lo stesso del genitore poiché è in esecuzione nello stesso processo. Un processo genera un nuovo processo e quindi assegna nuovi mem e pid.
C'è un altro loooooot. Ci hanno scritto dei libri.
Per quanto riguarda i costi, un contesto di processo cambia >>>> thread in quanto è necessario reimpostare tutti i contatori di stack ecc.
Supponendo che alla CPU su cui è in esecuzione il sistema operativo siano collegati alcuni dispositivi ad alta latenza,
Ha senso eseguire un altro thread dello spazio degli indirizzi del processo, mentre il dispositivo ad alta latenza risponde.
Ma, se il dispositivo ad alta latenza risponde più rapidamente del tempo necessario, impostare la tabella + traduzione delle memorie da virtuale a fisico per un NUOVO processo, quindi è discutibile se uno switch sia essenziale.
Inoltre, la cache HOT (i dati necessari per eseguire il processo / thread sono raggiungibili in meno tempo) è la scelta migliore.