context switch tra thread

[soalle]

Se è la sezione sbagliata spostatemi pure...
Mi chiedevo di preciso cosa succede nel context switching tra thread...
Tra processi si salva (e si carica) PC, registri e PSW... Tra threads solo un sottoinsieme (tipo PC, SP e PSW) ???

Grazie e ciao...

[cionci]

Fra thread si dovrebbe fare allo stesso modo di come si fa fra i processi...
L'unica differenza dovrebbe stare nel fatto che non si invalidano i dati presenti in cache...

[soalle]

Anch'io pensavo qualcosa di simile ma.... il fatto che condividano segmento dati e segmento codice magari fa sì che non debbano essere caricati il registro base e limite per questi due segmenti....

[cionci]

A parte che la segmentazione con i processori a 32 bit non viene più usata, ma in ogni caso l'indirizzo di un registro segmento potrebbe venire cambiato da uno dei thread del processo e quindi andrebbe comunque salvato e ricaricato...

[soalle]

Originally posted by "cionci"

A parte che la segmentazione con i processori a 32 bit non viene più usata

Come???
Non so nulla a riguardo spiegati meglio...

[soalle]

Originally posted by "cionci"

ma in ogni caso l'indirizzo di un registro segmento potrebbe venire cambiato da uno dei thread del processo e quindi andrebbe comunque salvato e ricaricato...

Domanda: per modificare la base di un segmento non bisogna essere in kernel mode???

[ilsensine]

Originally posted by "cionci"


L'unica differenza dovrebbe stare nel fatto che non si invalidano i dati presenti in cache...

mmm no, la cache _può_ anche contenere pagine di altri _processi_ (non thread), se l'accesso in memoria del thread corrente non si "succhia" tutta la cache. Ovviamente c'è una maggiore possibilità che due thread trovino in cache la stessa cacheline di memoria alla quale ambedue stanno accedendo, ma questa non è sempre una buona cosa (*)
La vera grande differenza è che più thread condividono le stesse tabelle di paginazione, e...ti sembra poco



(*) Nei sistemi SMP, l'accesso in scrittura su una cacheline da parte di un processore forza gli altri a invalidare una eventuale memoria in cache coincidente fisicamente con la cacheline toccata. Anche se le variabili cui accedono i diversi thread sono diverse tra loro, è buona norma allinearle alla dimensione della cacheline, per lo stesso motivo.

[soalle]

Originally posted by "ilsensine"


La vera grande differenza è che più thread condividono le stesse tabelle di paginazione, e...ti sembra poco

Solo il segmento stack è diverso per i thread?
Il fatto che condividano le stesse tabelle di paginazione, significa che il vantaggio sta appunto nella presenza in cache delle stesse tabelle o altro?

[ilsensine]

Originally posted by "soalle"


Solo il segmento stack è diverso per i thread?

No è lo stesso, solo esp punta a due zone differenti. Un thread può accedere alla zona di memoria stack dell'altro, senza alcun problema.

Il fatto che condividano le stesse tabelle di paginazione, significa che il vantaggio sta appunto nella presenza in cache delle stesse tabelle o altro?

Caricare le tabelle di paginazione è una operazione molto costosa, che implica il flush del tlb, cambio del tss e altre cose. Molto più rapido e "indolore" passare da un thread all'altro, principalmente devi solo salvarti lo "stato" (registri) di ogni singolo thread (ci sono altre operazioni, ma non costose come il cambio delle tabelle).

[soalle]

Originally posted by "ilsensine"


No è lo stesso, solo esp punta a due zone differenti. Un thread può accedere alla zona di memoria stack dell'altro, senza alcun problema.

Ma allora cosa mi garantisce che lo stack di un thread non vada ad invadere lo stack di un altro thread (involontariamente intendo... tipo un sacco di chiamate innestate o la richiesta di molta memoria allocata dinamicamente)

(ci sono altre operazioni, ma non costose come il cambio delle tabelle).

Cosa intendi???

[ilsensine]

Originally posted by "soalle"


Ma allora cosa mi garantisce che lo stack di un thread non vada ad invadere lo stack di un altro thread (involontariamente intendo... tipo un sacco di chiamate innestate o la richiesta di molta memoria allocata dinamicamente)

Infatti c'è una dimensione massima che gli stack possono allocare

Cosa intendi???

Ad es. in linux ogni thread ha un "contesto" differente dagli altri (signal handler, ecc.) che deve comunque essere cambiato quando passi da un thread all'altro.

[cionci]

Originally posted by "ilsensine"

Caricare le tabelle di paginazione è una operazione molto costosa, che implica il flush del tlb, cambio del tss e altre cose. Molto più rapido e "indolore" passare da un thread all'altro, principalmente devi solo salvarti lo "stato" (registri) di ogni singolo thread (ci sono altre operazioni, ma non costose come il cambio delle tabelle).

Chiaro, ma io credevo che volesse parlare solo dello stato del processore, non dele tabelle del sistema operativo... E' chiaro che due thread facendo parte dello stesso processo ne condividono parte delle informazioni all'interno del sistema operativo...ed in particolar modo le tabelle della paginazione...

[ilsensine]

Infatti cr0 (che contiene la base per le tabelle di paginazione) fa parte dello stato del processore

[cionci]

Originally posted by "ilsensine"

Infatti cr0 (che contiene la base per le tabelle di paginazione) fa parte dello stato del processore

Mmmmhh... E' un rigestro della CPU ?

[ilsensine]

Sì, controlla varie cose, tra cui la base della page directory

[ilsensine]

(...errata corrige: cr3)

[cionci]

Bene a sapersi...

[soalle]

Originally posted by "cionci"

A parte che la segmentazione con i processori a 32 bit non viene più usata

Cosa intendevi con questo???
Che usano segmentazione paginata o altro???

[cionci]

Che di fatto i programmi vedono l'intera memoria a 32 bit come se fosse lineare...anche se in realtà c'è la paginazione...

[soalle]

Ma allora il cosidetto "segmentation fault" che viene fuori nei miei programmi sotto linux che signifaicato ha???