Correggetemi se ho torto, ma se ho un sistema operativo che fa un cambio di contesto, allora quell'interruttore di contesto è in pratica un passaggio da un thread all'altro, in cui un thread eseguiva un'attività e poi passava a un'altra attività e il motivo per cui i thread richiedono uno stack è quello di salvare le variabili dell'attività per poter tornare al suo stato salvato.
La mia comprensione è corretta su cosa fa un interruttore di contesto o ho frainteso?
Lo stack non ha nulla a che fare con il multi-threading. Lo stack salva informazioni su una subroutine. Quando dico sub-routine, non sto parlando di alcuna lingua particolare, ma il processo di effettuare una chiamata in un'altra area dello spazio del programma, e di tornare da quell'area al termine. Quando si effettua la chiamata, la routine attualmente in esecuzione potrebbe utilizzare registri. Questi valori di registro devono essere salvati in uno stack, in modo che la routine chiamata possa usare quei registri. Questo è molto semplificato, ma l'idea generale è che lo stack salva il contesto del chiamante e lo stack diventa più grande man mano che la catena di chiamata diventa più profonda.
Se hai più thread, ognuno ha bisogno di uno stack, poiché sono tutti in esecuzione allo stesso tempo. L'interruttore di contesto consente di avere più thread rispetto ai core della CPU. Consente a più thread di condividere un core anticipando l'esecuzione di un thread e avviando un altro thread.
Sei principalmente sulla strada giusta. Lo scopo dello stack in generale è quello di aggrapparsi ai dati di cui avrai bisogno in seguito. La maggior parte delle volte, ciò avviene quando si chiamano le subroutine, almeno per salvare l'indirizzo di ritorno, ma anche per salvare qualsiasi stato che potrebbe essere distrutto in altro modo e come meccanismo per memorizzare le variabili locali e per passare i parametri. Nella maggior parte dei sistemi multitasking, ogni contesto di esecuzione ha il proprio stack per tali scopi.
Molti sistemi usano anche lo stack del contesto quando si passa da uno all'altro.
Quando un contesto si arresta, è necessario conservare tutto ciò che stava succedendo. Lo stack ne terrà già la maggior parte, ma lo stato dei registri del processore deve essere raccolto e archiviato.
Queste informazioni potrebbero essere memorizzate in una struttura dati assegnata specificamente per fare quel lavoro, magari come parte di un blocco di controllo del processo. La cosa su questo approccio è che ne avresti bisogno per contesto, e le strutture occuperebbero spazio inutilmente mentre il contesto è in esecuzione.
Come succede, c'è già un blocco di memoria scratchpad di uso generale disponibile: lo stack. Una volta che il controllo è stato strappato dal contesto, non ci sono possibilità che spinga qualcos'altro lì. Ciò rende sicuro al supervisore di spingere lo stato del processore lì, e tutto ciò che deve ricordare per dopo è il puntatore dello stack del contesto. Poiché il contesto non verrà eseguito fino a quando il supervisore non gli darà l'ok, le ultime cose messe in pila saranno sempre state lo stato del processore. Quando il contesto deve essere riavviato, il supervisore ripristina il puntatore dello stack salvato, apre il resto dello stato del processore dallo stack, salta all'indirizzo in cui si trovava il contatore del programma quando il contesto veniva interrotto (anch'esso memorizzato nello stack). Quindi il contesto continua a funzionare come se nulla fosse accaduto.
Leggi altre domande sui tag operating-systems multithreading