Un thread è "leggero" perché la maggior parte del sovraccarico è già stata eseguita attraverso la creazione del suo processo.Perché i thread si chiamano processi leggeri?
Ho trovato questo in una delle esercitazioni.
Qualcuno può elaborare cosa significa esattamente?
L'affermazione che i thread sono "leggeri" è - a seconda della piattaforma - non necessariamente affidabile.
Una thread del sistema operativo deve supportare l'esecuzione di codice nativo, ad es. scritto in C. Quindi deve fornire uno stack di dimensioni decenti, di solito misurato in megabyte. Quindi, se avessi avviato 1000 thread (forse nel tentativo di supportare 1000 connessioni simultanee al tuo server) avresti un requisito di memoria di 1 GB nel tuo processo prima ancora che tu possa iniziare a fare del vero lavoro.
Questo è un problema reale nei server altamente scalabili, quindi non utilizzano thread come se fossero leggeri. Li trattano come risorse pesanti. Potrebbero invece creare un numero limitato di thread in un pool e lasciare che prendano oggetti di lavoro da una coda.
Poiché ciò significa che i thread sono longevi e di numero ridotto, potrebbe essere preferibile utilizzare invece i processi. In questo modo si ottiene l'isolamento dello spazio degli indirizzi e non c'è davvero un problema con l'esaurimento delle risorse.
In breve: diffidare delle dichiarazioni di "marketing" fatte per conto dei thread. L'elaborazione parallela è ottima (sarà sempre più essenziale), ma i thread sono solo un modo per raggiungerlo.
+1 Spot on - Non avrei potuto metterlo meglio me stesso – zebrabox
Mi piace il riassunto. Tendo a preferire l'utilizzo di più processi a thread singolo e io * odio * quando fan-fan del multi-threading mi accusano di non riuscire a sfruttare il semplice parallelismo multi-core perché non intralciano l'idea di più processi. –
Grazie. Ci sono molte ragioni per cui il processo a volte può essere migliore dei thread. Uno che mi ha sorpreso è che potresti ottenere un aumento di prestazioni gratuito! Il motivo è che i processi separati hanno heap di memoria C separati. In una libreria standard thread-safe, tutte le chiamate 'malloc' /' free' devono essere sincronizzate, il che potrebbe significare un sacco di blocchi in base all'utilizzo della memoria. Ho visto un'app che utilizza thread che si bloccano su 4 core, ma se passati a processi separati si ridimensiona a 8 (e probabilmente di più, non aveva più core da testare). Minore è la memoria che condividi, meno devi sincronizzare. –
La creazione del processo è "costosa", perché deve impostare un nuovo spazio di memoria virtuale completo per il processo con il proprio spazio di indirizzamento. "costoso" significa molto tempo di CPU.
I thread non hanno bisogno di fare questo, basta cambiare alcuni puntatori in giro, quindi è molto più "economico" rispetto alla creazione di un processo. Il motivo per cui i thread non richiedono questo è perché vengono eseguiti nello spazio degli indirizzi e nella memoria virtuale del processo principale.
Ogni processo deve contenere almeno un thread. Quindi, se ci pensi, creare un processo significa creare il processo E creare un thread. Ovviamente, la creazione di un solo thread richiederà meno tempo e lavoro da parte del computer.
Inoltre, i thread sono "leggeri" perché i thread possono interagire senza la necessità di comunicazioni tra processi. Passare da un thread all'altro è "più economico" che passare da un processo all'altro (di nuovo, spostando semplicemente alcuni puntatori). E la comunicazione tra processi richiede comunicazioni più costose dei thread.
I thread all'interno di un processo condividono lo stesso spazio di memoria virtuale ma ognuno ha uno stack separato e, eventualmente, "storage locale thread" se implementato. Sono lightweight perché un cambio di contesto è semplicemente un caso di commutazione del puntatore dello stack e del contatore del programma e ripristino di altri registri, mentre uno switch di contesto processo comporta anche il passaggio del contesto MMU.
Inoltre, la comunicazione tra i thread all'interno di un processo è leggera perché condividono uno spazio indirizzo.
Non è leggero se si dispone di un sistema mulit-core che deve sincronizzare i dati tra le cache L1 per i thread multipli - in realtà è tutto tranne il leggero – zebrabox
@zebrabox: Senza dubbio vero. Come sempre tali termini diventano irrilevanti nel tempo. La maggior parte del mio lavoro è su sistemi embedded single core con kernel RTOS, quindi raramente si sono verificate tali complessità - tutto è un thread - anche quando protetto da una MMU (contraddicendo ciò che ho detto prima!). – Clifford
Sì, so da dove vieni. Ovviamente è molto meno un problema su un singolo core - specialmente se si ha accesso ad un paio di thread hardware :) – zebrabox
processo:
discussione:
Un processo contiene uno o più thread in esso e un filo può fare tutto ciò che un processo può fare. Anche i thread all'interno di un processo condividono lo stesso spazio di indirizzi a causa del quale il costo della comunicazione tra i thread è basso poiché utilizza la stessa sezione di codice, la sezione dati e le risorse del sistema operativo, quindi tutte queste funzionalità del thread ne fanno un "processo leggero".
Continuare a binging per "la creazione di processi" e il sistema operativo e vedrete quanta overhead ci sia dentro per creare un processo. –
@ No rimborsi n. Resi: E scoprirai che si differenzia notevolmente tra i sistemi operativi. –
@No Rimborsi non restituiti - qual è l'overheard della sincronizzazione della cache tra i thread su un computer multi-core o il sovraccarico del cambio di contesto e il salvataggio dello stack e del set di registri? – zebrabox