Qual è la differenza tra un processo e un thread?

https://stackoverflow.com/questions/200469

03-07-2019
|

Domanda

Qual è la differenza tecnica tra un processo e un thread?

Ho la sensazione che una parola come "processo" sia abusata e ci sono anche thread hardware e software. Che ne dite di processi leggeri in lingue come Erlang ? C'è un motivo definitivo per usare un termine rispetto all'altro?

Soluzione

Sia i processi che i thread sono sequenze di esecuzione indipendenti. La differenza tipica è che i thread (dello stesso processo) vengono eseguiti in uno spazio di memoria condiviso, mentre i processi vengono eseguiti in spazi di memoria separati.

Non sono sicuro di quale "hardware" sia vs "software" discussioni a cui potresti riferirti. I thread sono una funzionalità dell'ambiente operativo, piuttosto che una funzione della CPU (sebbene la CPU abbia in genere operazioni che rendono efficienti i thread).

Erlang usa il termine "processo" perché non espone un modello multiprogrammazione di memoria condivisa. Chiamandoli " discussioni " implicherebbe che hanno condiviso la memoria.

Altri suggerimenti

Processo
Ogni processo fornisce le risorse necessarie per eseguire un programma. Un processo ha uno spazio di indirizzi virtuale, codice eseguibile, handle aperti per oggetti di sistema, un contesto di sicurezza, un identificatore di processo univoco, variabili di ambiente, una classe di priorità, dimensioni minime e massime del set di lavoro e almeno un thread di esecuzione. Ogni processo viene avviato con un singolo thread, spesso chiamato thread primario, ma può creare thread aggiuntivi da qualsiasi thread.

Discussione
Un thread è un'entità all'interno di un processo che può essere pianificato per l'esecuzione. Tutti i thread di un processo condividono lo spazio degli indirizzi virtuali e le risorse di sistema. Inoltre, ogni thread mantiene gestori di eccezioni, una priorità di pianificazione, memoria locale del thread, un identificatore di thread univoco e un insieme di strutture che il sistema utilizzerà per salvare il contesto del thread fino a quando non viene pianificato. Il contesto del thread include il set di registri della macchina del thread, lo stack del kernel, un blocco di ambiente del thread e uno stack dell'utente nello spazio degli indirizzi del processo del thread. I thread possono anche avere un proprio contesto di sicurezza, che può essere utilizzato per impersonare i client.

Trovato qui su MSDN:
Informazioni su processi e thread

Microsoft Windows supporta il multitasking preventivo, che crea l'effetto dell'esecuzione simultanea di più thread da più processi. Su un computer multiprocessore, il sistema può eseguire contemporaneamente tutti i thread quanti sono i processori sul computer.

Processo:

Un'istanza in esecuzione di un programma è chiamata processo.
Alcuni sistemi operativi usano il termine "task" per fare riferimento a un programma in esecuzione.
Un processo viene sempre archiviato nella memoria principale anche definita come memoria principale o memoria ad accesso casuale.
Pertanto, un processo è definito come entità attiva. Scompare se la macchina viene riavviata.
Diversi processi possono essere associati a uno stesso programma.
Su un sistema multiprocessore, è possibile eseguire più processi in parallelo.
Su un sistema uni-processor, sebbene non si realizzi un vero parallelismo, viene applicato un algoritmo di schedulazione del processo e il processore è programmato per eseguire ogni processo uno alla volta producendo un'illusione di concorrenza.
Esempio: esecuzione di più istanze del programma "Calcolatrice". Ognuna delle istanze è definita come un processo.

Discussione:

Un thread è un sottoinsieme del processo.
È definito "processo leggero", poiché è simile a un processo reale ma viene eseguito nel contesto di un processo e condivide le stesse risorse assegnate al processo dal kernel.
Di solito, un processo ha un solo thread di controllo: un insieme di istruzioni macchina in esecuzione alla volta.
Un processo può anche essere composto da più thread di esecuzione che eseguono istruzioni contemporaneamente.
Più thread di controllo possono sfruttare il vero parallelismo possibile sui sistemi multiprocessore.
Su un sistema uni-processor, viene applicato un algoritmo di pianificazione thread e il processore è programmato per eseguire ogni thread uno alla volta.
Tutti i thread in esecuzione all'interno di un processo condividono lo stesso spazio indirizzo, descrittori di file, stack e altri attributi relativi al processo.
Poiché i thread di un processo condividono la stessa memoria, la sincronizzazione dell'accesso ai dati condivisi all'interno del processo acquisisce un'importanza senza precedenti.

Ho preso in prestito le informazioni di cui sopra dal Quest di conoscenza! blog .

Innanzitutto, diamo un'occhiata all'aspetto teorico. È necessario comprendere cosa sia un processo concettualmente per comprendere la differenza tra un processo e un thread e cosa è condiviso tra loro.

Dalla sezione 2.2.2 abbiamo il seguente modello di thread classico in Modern Operating Systems 3e di Tanenbaum:

Il modello di processo si basa su due concetti indipendenti: risorsa raggruppamento ed esecuzione. A volte è utile per separarli; è qui che entrano in gioco le discussioni ....

Continua:

Un modo di vedere un processo è che è un modo per farlo raggruppare le risorse correlate insieme. Un processo ha uno spazio degli indirizzi contenente testo e dati del programma, nonché altre risorse. Questi la risorsa può includere file aperti, processi figlio, allarmi in sospeso, gestori di segnali, informazioni contabili e altro ancora. Mettendoli insieme sotto forma di un processo, possono essere gestiti più facilmente. L'altro concetto di un processo è di solito un thread di esecuzione abbreviato in solo thread. Il thread ha un contatore di programmi che mantiene traccia di quale istruzione eseguire successivamente. Ha registri, che mantenere le sue attuali variabili di lavoro. Ha una pila, che contiene il file cronologia di esecuzione, con un fotogramma per ogni processo chiamato, ma non chiamato ma tornato da. Sebbene un thread debba essere eseguito in qualche processo, il thread e il suo processo sono concetti diversi e possono essere trattati sepa & # 173; tamente. I processi vengono utilizzati per raggruppare le risorse; discussioni sono le entità pianificate per l'esecuzione sulla CPU.

Più in basso fornisce la seguente tabella:

Per process items             | Per thread items
------------------------------|-----------------
Address space                 | Program counter
Global variables              | Registers
Open files                    | Stack
Child processes               | State
Pending alarms                |
Signals and signal handlers   |
Accounting information        |

Affrontiamo il problema multithreading hardware . Classicamente, una CPU supporta un singolo thread di esecuzione, mantenendo lo stato del thread tramite un singolo contatore di programmi e un set di registri. Ma cosa succede se manca una cache? Ci vuole molto tempo per recuperare i dati dalla memoria principale e, mentre ciò accade, la CPU rimane inattiva. Quindi qualcuno ha avuto l'idea di avere fondamentalmente due serie di stati del thread (registri PC +) in modo che un altro thread (forse nello stesso processo, forse in un processo diverso) possa fare il lavoro mentre l'altro thread è in attesa nella memoria principale. Esistono più nomi e implementazioni di questo concetto, come HyperThreading e Multithreading simultaneo (SMT in breve) .

Ora diamo un'occhiata al lato software. Esistono sostanzialmente tre modi in cui i thread possono essere implementati dal lato software.

Discussioni spazio utenti
Discussioni del kernel
Una combinazione dei due

Tutto ciò che serve per implementare i thread è la possibilità di salvare lo stato della CPU e mantenere più stack, cosa che in molti casi può essere eseguita nello spazio utente. Il vantaggio dei thread dello spazio utente è la commutazione dei thread super veloce poiché non è necessario intercettare il kernel e la possibilità di pianificare i thread nel modo desiderato. Lo svantaggio maggiore è l'incapacità di bloccare l'I / O (che bloccherebbe l'intero processo e tutti i suoi thread utente), che è uno dei motivi principali per cui utilizziamo i thread in primo luogo. Il blocco degli I / O mediante i thread semplifica notevolmente la progettazione del programma in molti casi.

I thread del kernel hanno il vantaggio di poter usare l'I / O di blocco, oltre a lasciare tutti i problemi di pianificazione al sistema operativo. Ma ogni switch di thread richiede il trapping nel kernel che è potenzialmente relativamente lento. Tuttavia, se stai cambiando thread a causa dell'I / O bloccato, questo non è davvero un problema poiché l'operazione di I / O probabilmente ti ha già intrappolato nel kernel.

Un altro approccio è quello di combinare i due, con più thread del kernel ciascuno con più thread utente.

Quindi, tornando alla tua domanda di terminologia, puoi vedere che un processo e un filo di esecuzione sono due concetti diversi e la tua scelta del termine da usare dipende da cosa stai parlando. Per quanto riguarda il termine "processo leggero", non vedo personalmente il punto in quanto non trasmette realmente ciò che sta accadendo, nonché il termine "thread di esecuzione".

Spiegare di più riguardo alla programmazione concorrente

Un processo ha un ambiente di esecuzione autonomo. Un processo ha generalmente un set completo e privato di risorse di runtime di base; in particolare, ogni processo ha il suo spazio di memoria.
I thread esistono all'interno di un processo & # 8212; ogni processo ne ha almeno uno. I thread condividono le risorse del processo, tra cui memoria e file aperti. Questo rende la comunicazione efficiente, ma potenzialmente problematica.

Tenendo presente la persona media,

Sul tuo computer, apri Microsoft Word e il browser web. Chiamiamo questi due processi .

In Microsoft Word, digiti qualcosa e viene automaticamente salvato. Ora, avresti osservato che la modifica e il salvataggio avvengono in parallelo: modifica su un thread e salvataggio sull'altro thread.

Un'applicazione è costituita da uno o più processi. Un processo, in parole povere, è un programma in esecuzione. Uno o più thread vengono eseguiti nel contesto del processo. Un thread è l'unità di base a cui il sistema operativo assegna il tempo del processore. Un thread può eseguire qualsiasi parte del codice di processo, comprese le parti attualmente in esecuzione da un altro thread. Una fibra è un'unità di esecuzione che deve essere pianificata manualmente dall'applicazione. Le fibre vengono eseguite nel contesto dei thread che le pianificano.

Rubato da qui .

Un processo è una raccolta di codice, memoria, dati e altre risorse. Un thread è una sequenza di codice che viene eseguita nell'ambito del processo. Puoi (di solito) eseguire più thread contemporaneamente nello stesso processo.

Ogni processo è un thread (thread primario).
Ma ogni thread non è un processo. È una parte (entità) di un processo.

Esempio reale per Process and Thread Questo ti darà l'idea di base su thread e processo

Ho preso in prestito le informazioni di cui sopra dalla risposta di Scott Langham - grazie

Processo:

Il processo è un processo pesante.
Il processo è un programma separato che ha memoria, dati, risorse ect separati.
I processi vengono creati utilizzando il metodo fork ().
Il cambio di contesto tra il processo richiede tempo.

Esempio:
Ad esempio, aprendo qualsiasi browser (Mozilla, Chrome, IE). A questo punto inizierà l'esecuzione di un nuovo processo.

Discussioni:

I thread sono processi leggeri. I thread sono raggruppati all'interno del processo.
I thread hanno una memoria, dati, risorse, file condivisi ecc.
I thread sono creati usando il metodo clone ().
Il cambio di contesto tra i thread non richiede molto tempo come Processo.

Esempio:
Apertura di più schede nel browser.

Sia i thread che i processi sono unità atomiche di allocazione delle risorse del sistema operativo (ovvero esiste un modello di concorrenza che descrive come il tempo di CPU è diviso tra di loro e il modello di possesso di altre risorse del sistema operativo). C'è una differenza in:

Risorse condivise (i thread condividono la memoria per definizione, non possiedono nulla tranne lo stack e le variabili locali; i processi potrebbero anche condividere la memoria, ma esiste un meccanismo separato, gestito dal sistema operativo)
Spazio allocazione (spazio kernel per processi vs. spazio utente per thread)

Greg Hewgill sopra aveva ragione sul significato di Erlang della parola "processo", e qui c'è una discussione sul perché Erlang potrebbe eseguire processi leggeri.

Processo

È un programma in esecuzione. ha una sezione di testo, cioè il codice del programma, l'attività corrente come rappresentato dal valore del contatore del programma e amp; contenuto del registro dei processori. Include anche lo stack di processo che contiene dati temporanei (come parametri di funzione, ritorno indirizzato e variabili locali) e una sezione di dati che contiene variabili globali. Un processo può anche includere un heap, che è memoria allocata dinamicamente durante il tempo di esecuzione del processo.

Discussione

Un thread è un'unità base di utilizzo della CPU; comprende un ID thread, un contatore di programmi, un set di registri e uno stack. ha condiviso con altri thread appartenenti allo stesso processo la sua sezione di codice, sezione di dati e altre risorse del sistema operativo come file e segnali aperti.

- Tratto dal sistema operativo di Galvin

Prova di rispondere a questa domanda relativa al mondo Java.

Un processo è un'esecuzione di un programma ma un thread è una singola sequenza di esecuzione all'interno del processo. Un processo può contenere più thread. A volte un thread viene chiamato processo leggero .

Ad esempio:

Esempio 1: Una JVM viene eseguita in un singolo processo e i thread in una JVM condividono l'heap appartenente a quel processo. Ecco perché diversi thread possono accedere allo stesso oggetto. I thread condividono l'heap e hanno il loro spazio di stack. Questo è il modo in cui l'invocazione di un thread di un metodo e le sue variabili locali sono al sicuro dagli altri thread. Ma l'heap non è thread-safe e deve essere sincronizzato per la sicurezza dei thread.

Esempio 2: Un programma potrebbe non essere in grado di disegnare immagini leggendo i tasti. Il programma deve prestare tutta la sua attenzione all'input da tastiera e la mancanza della capacità di gestire più di un evento alla volta porterà a problemi. La soluzione ideale a questo problema è la perfetta esecuzione di due o più sezioni di un programma contemporaneamente. Le discussioni ci permettono di farlo. Qui Disegnare un'immagine è un processo e leggere la sequenza di tasti è un processo secondario (thread).

Differenza tra thread e processo?

Un processo è un'istanza in esecuzione di un'applicazione e Un thread è un percorso di esecuzione all'interno di un processo. Inoltre, un processo può contenere più thread. È importante notare che un thread può fare tutto ciò che un processo può fare. Ma poiché un processo può essere composto da più thread, un thread potrebbe essere considerato un processo "leggero". Pertanto, la differenza essenziale tra un thread e un processo è il lavoro che ciascuno viene utilizzato per eseguire. I thread vengono utilizzati per attività di piccole dimensioni, mentre i processi vengono utilizzati per attività più "pesanti", fondamentalmente l'esecuzione di applicazioni.

Un'altra differenza tra un thread e un processo è che i thread all'interno dello stesso processo condividono lo stesso spazio di indirizzi, mentre processi diversi no. Ciò consente ai thread di leggere e scrivere sulle stesse strutture e variabili di dati e facilita anche la comunicazione tra i thread. La comunicazione tra processi, nota anche come IPC, o comunicazione tra processi, è piuttosto difficile e dispendiosa in termini di risorse.

Ecco un riepilogo delle differenze tra thread e processi:

I thread sono più facili da creare rispetto ai processi poiché non richiede uno spazio di indirizzi separato.
Il multithreading richiede un'attenta programmazione poiché i thread condividere strutture di dati che dovrebbero essere modificate da un solo thread Al tempo. A differenza dei thread, i processi non condividono lo stesso spazio degli indirizzi.
Le discussioni sono considerate leggere perché usano lontano meno risorse rispetto ai processi.
I processi sono indipendenti l'uno dall'altro. Discussioni, dal momento che loro condividere lo stesso spazio degli indirizzi sono interdipendenti, quindi attenzione deve essere preso in modo che fili diversi non si incrocino.
Questo è davvero un altro modo per dichiarare il numero 2 sopra.
Un processo può consistere in più thread.

http://lkml.iu.edu/hypermail/linux/ kernel / 9608 / 0191.html

Linus Torvalds (torvalds@cs.helsinki.fi)

Martedì 6 agosto 1996 12:47:31 +0300 (EET DST)

Messaggi ordinati per: [data] [thread] [oggetto] [autore]

Messaggio successivo: Bernd P. Ziller: " Ri: Oops in get_hash_table "

Messaggio precedente: Linus Torvalds: " Re: ordinazione richiesta I / O "

Il 5 agosto 1996, Peter P. Eiserloh ha scritto:


Dobbiamo mantenere chiaro il concetto di thread. Troppa gente     sembra confondere un thread con un processo. La seguente discussione     non riflette lo stato attuale di Linux, ma piuttosto è un     tenta di rimanere in una discussione di alto livello.


NO!

NON c'è motivo di pensare che "discussioni" e "processi" siamo   entità separate. È così che viene fatto tradizionalmente, ma io   personalmente penso che sia un grave errore pensare in quel modo. Il solo   motivo di pensare in quel modo è il bagaglio storico.

Sia i thread che i processi sono in realtà solo una cosa: un contesto di   esecuzione " ;. Cercare di distinguere artificialmente casi diversi è giusto   autolimitante.

Un "contesto di esecuzione", qui chiamato COE, è solo il conglomerato   di tutto lo stato di quel COE. Questo stato include cose come la CPU   stato (registri ecc.), stato MMU (mappatura pagine), stato autorizzazione   (uid, gid) e vari "stati di comunicazione" (file aperti, segnale   gestori ecc.). Tradizionalmente, la differenza tra un "thread" e a   & Quot; processo " è stato principalmente che un thread ha stato CPU (+ possibilmente   qualche altro stato minimo), mentre tutti gli altri contesti provengono dal   processi. Tuttavia, questo è solo    un modo di dividere lo stato totale del COE, e non c'è nulla che dica che è il modo giusto di farlo. Limitare te stesso   per quel tipo di immagine è semplicemente stupido.

Il modo in cui Linux ci pensa (e il modo in cui voglio che le cose funzionino) è   che non è non esiste un "processo" o una "discussione". C'è   solo la totalità del COE (chiamato "task" da Linux). Diversi COE   possono condividere parti del loro contesto tra loro e un sottoinsieme di   quella condivisione è il tradizionale processo "thread" / "processo". installazione, ma quello   dovrebbe davvero essere visto come SOLO un sottoinsieme (è un sottoinsieme importante, ma   quell'importanza non viene dal design, ma dagli standard: noi ovviamente   desidera eseguire programmi di thread conformi agli standard su Linux   pure).

In breve: NON progettare attorno al modo di pensare il thread / processo. Il   il kernel dovrebbe essere progettato attorno al modo di pensare COE, e quindi il   La libreria pthreads può esportare l'interfaccia pthreads limitata per gli utenti   che vogliono usare quel modo di guardare i COE.

Proprio come un esempio di ciò che diventa possibile quando pensi a COE come   al contrario di thread / processo:


Puoi eseguire un " cd " esterno programma, qualcosa che è tradizionalmente impossibile in UNIX e / o process / thread (esempio sciocco, ma l'idea   è che puoi avere questo tipo di " moduli " che non si limitano a   la tradizionale configurazione UNIX / thread). Fai un:


clone (CLONE_VM | CLONE_FS);

child: execve (" external-cd ");

/ * il " execve () " disassoceremo la VM, quindi l'unica ragione per cui   usato CLONE_VM era per rendere più veloce l'atto di clonazione * /


Puoi fare " vfork () " naturalmente (soddisfa il supporto minimo del kernel, ma quel supporto si adatta perfettamente al modo di pensare CUA):


clone (CLONE_VM);

figlio: continua a funzionare, eventualmente execve ()

madre: attendi l'esecuzione


puoi fare "demoni IO" esterni " ;:


clone (CLONE_FILES);

figlio: apri descrittori di file ecc.

madre: usa le fd che il bambino ha aperto e vv.

Tutto quanto sopra funziona perché non sei legato al thread / processo   modo di pensare. Pensa ad un web server per esempio, dove il CGI   gli script vengono eseguiti come "thread di esecuzione". Non puoi farlo con   thread tradizionali, perché i thread tradizionali devono sempre condividere   l'intero spazio degli indirizzi, quindi dovresti collegarti a tutto ciò che mai   volevo fare sul server web stesso (un "thread" non può eseguirne un altro   eseguibile).

Considerandolo come un "contesto di esecuzione" problema invece, tuo   le attività possono ora scegliere di eseguire programmi esterni (= separare il file   spazio di indirizzamento dal genitore) ecc. se lo desiderano o possono farlo   esempio condividi tutto con il genitore tranne per il file   descrittori (in modo che il sub "thread" possa aprire molti file senza   i genitori devono preoccuparsi di loro: si chiudono automaticamente quando   il sottopunto "thread" viene chiuso e non utilizza i FD nel genitore).

Pensa ad un thread "inetd", ad esempio. Vuoi bassi costi generali   fork + exec, quindi con il modo Linux puoi invece di usare un " fork () "   scrivi un inetd multi-thread in cui viene creato ogni thread   solo CLONE_VM (condividi lo spazio degli indirizzi, ma non condividi i descrittori di file   eccetera). Quindi il bambino può eseguire se fosse un servizio esterno (rlogind,   per esempio), o forse era uno dei servizi interni inetd   (eco, timeofday) nel qual caso fa semplicemente la cosa ed esce.

Non puoi farlo con " thread " / " process " ;.

Linus

Dal punto di vista di un intervistatore, ci sono fondamentalmente solo 3 cose principali che voglio sentire, oltre a cose ovvie come un processo può avere più thread:

I thread condividono lo stesso spazio di memoria, il che significa che un thread può accedere alla memoria dalla memoria di altri thread. I processi normalmente non possono.
Risorse. Le risorse (memoria, handle, socket, ecc.) Vengono rilasciate al termine del processo, non al termine del thread.
Sicurezza. Un processo ha un token di sicurezza fisso. Un thread, d'altra parte, può impersonare diversi utenti / token.

Se vuoi di più, la risposta di Scott Langham copre praticamente tutto. Tutti questi sono dal punto di vista di un sistema operativo. Lingue diverse possono implementare concetti diversi, come attività, thread leggeri e così via, ma sono solo modi di usare thread (di fibre su Windows). Non ci sono thread hardware e software. Esistono eccezioni hardware e software e interruzioni , oppure thread in modalità utente e kernel .

Un thread viene eseguito in uno spazio di memoria condiviso, ma un processo viene eseguito in uno spazio di memoria separato
Un thread è un processo leggero, ma un processo è un processo pesante.
Un thread è un sottotipo di processo.

Quanto segue è quello che ho ottenuto da uno degli articoli su The Code Project . Immagino che spieghi chiaramente tutto il necessario.

Un thread è un altro meccanismo per dividere il carico di lavoro in separato flussi di esecuzione. Un filo ha un peso più leggero di un processo. Questo significa, offre meno flessibilità di un processo completo, ma può essere avviato più rapidamente perché è inferiore a quello per il sistema operativo impostare. Quando un programma è composto da due o più thread, tutti i file i thread condividono un singolo spazio di memoria. Ai processi vengono assegnati spazi di indirizzi separati. tutti i thread condividono un singolo heap. Ma a ogni thread viene assegnato il proprio stack.

Fondamentalmente, un thread fa parte di un processo senza che il thread di processo non sia in grado di funzionare.
Un filo è leggero mentre il processo è pesante.
la comunicazione tra processo richiede del tempo, mentre il thread richiede meno tempo.
I thread possono condividere la stessa area di memoria mentre il processo vive in modo separato.

Processo : il programma in esecuzione è noto come processo

Thread : il thread è una funzionalità che viene eseguita con l'altra parte del programma in base al concetto di "uno con l'altro", quindi il thread fa parte del processo ..

Provenendo dal mondo incorporato, vorrei aggiungere che il concetto di processi esiste solo in "grande". processori ( CPU desktop, ARM Cortex A-9 ) con MMU (unità di gestione della memoria) e sistemi operativi che supportano l'utilizzo di MMU (come Linux ). Con processori e microcontrollori piccoli / vecchi e piccolo sistema operativo RTOS ( sistema operativo in tempo reale ), come freeRTOS, non esiste supporto MMU e quindi nessun processo ma solo thread.

I thread possono accedere alla memoria degli altri e sono programmati dal sistema operativo in modo intercalato in modo che sembrino funzionare in parallelo (o con multi-core funzionano davvero in parallelo).

Processi , invece, vivono nella loro sandbox privata di memoria virtuale, fornita e protetta da MMU. Questo è utile perché abilita:

impedendo al processo difettoso di arrestare l'intero sistema.
Mantenere la sicurezza rendendo invisibili altri dati di processi e irraggiungibile. Il lavoro effettivo all'interno del processo è curato da uno o più thread.

Durante la creazione di un algoritmo in Python (linguaggio interpretato) che incorporava il multi-threading, sono rimasto sorpreso nel vedere che il tempo di esecuzione non era migliore rispetto all'algoritmo sequenziale che avevo precedentemente creato. Nel tentativo di comprendere il motivo di questo risultato, ho fatto alcune letture e credo che ciò che ho appreso offra un contesto interessante da cui comprendere meglio le differenze tra multi-threading e multi-processi.

I sistemi multi-core possono esercitare più thread di esecuzione, quindi Python dovrebbe supportare il multi-threading. Ma Python non è un linguaggio compilato e invece è un linguaggio interpretato ¹. Ciò significa che il programma deve essere interpretato per essere eseguito e l'interprete non è a conoscenza del programma prima che inizi l'esecuzione. Ciò che sa, tuttavia, sono le regole di Python e quindi applica dinamicamente tali regole. Le ottimizzazioni in Python devono quindi essere principalmente ottimizzazioni dell'interprete stesso e non del codice che deve essere eseguito. Ciò è in contrasto con i linguaggi compilati come C ++ e ha conseguenze per il multi-threading in Python. In particolare, Python utilizza il Global Interpreter Lock per gestire il multi-threading.

D'altra parte, un linguaggio compilato è, beh, compilato. Il programma viene elaborato "interamente", dove prima viene interpretato secondo le sue definizioni sintattiche, quindi mappato su una rappresentazione intermedia agnostica del linguaggio e infine collegato in un codice eseguibile. Questo processo consente al codice di essere altamente ottimizzato perché è tutto disponibile al momento della compilazione. Le varie interazioni e relazioni del programma sono definite al momento della creazione dell'eseguibile e possono essere prese solide decisioni sull'ottimizzazione.

Negli ambienti moderni, l'interprete di Python deve consentire il multi-threading, e questo deve essere sicuro ed efficiente. È qui che entra in gioco la differenza tra l'essere una lingua interpretata e una lingua compilata. L'interprete non deve disturbare i dati condivisi internamente da thread diversi, ottimizzando allo stesso tempo l'uso dei processori per i calcoli.

Come è stato notato nei post precedenti, sia un processo che un thread sono esecuzioni sequenziali indipendenti con la differenza principale che la memoria è condivisa su più thread di un processo, mentre i processi isolano i loro spazi di memoria.

In Python i dati sono protetti dall'accesso simultaneo di thread diversi da parte del Global Interpreter Lock. Richiede che in qualsiasi programma Python sia possibile eseguire un solo thread alla volta. D'altra parte è possibile eseguire più processi poiché la memoria per ciascun processo è isolata da qualsiasi altro processo e i processi possono essere eseguiti su più core.

¹ Donald Knuth ha una buona spiegazione delle routine interpretative in The Art of Computer Programming: Fundamental Algorithms.

Cercando di rispondere dalla vista del SO del kernel Linux

Un programma diventa un processo quando viene avviato in memoria. Un processo ha il suo spazio di indirizzamento che significa avere vari segmenti in memoria come .text segement per la memorizzazione di codice compilato, .bss per la memorizzazione di variabili statiche o globali non inizializzate, ecc. Ogni processo avrebbe il proprio contatore di programmi e user-spcae pila . All'interno del kernel, ogni processo avrebbe il proprio stack del kernel (che è separato dallo stack dello spazio utente per problemi di sicurezza) e una struttura chiamata task_struct che viene generalmente astratta come blocco di controllo del processo, memorizzando tutte le informazioni riguardanti il processo come la sua priorità, lo stato (e molti altri pezzi). Un processo può avere più thread di esecuzione.

Arrivando ai thread, risiedono all'interno di un processo e condividono lo spazio degli indirizzi del processo padre insieme ad altre risorse che possono essere passate durante la creazione di thread come risorse del filesystem, condivisione di segnali in sospeso, condivisione di dati (variabili e istruzioni) fili leggeri e quindi consentendo un cambio di contesto più veloce. All'interno del kernel, ogni thread ha il proprio stack del kernel insieme alla struttura task_struct che definisce il thread. Pertanto il kernel visualizza i thread dello stesso processo di entità diverse e sono programmabili in se stessi. I thread nello stesso processo condividono un ID comune chiamato come ID gruppo thread ( tgid ), inoltre hanno un ID univoco chiamato come ID processo ( pid ).

Per coloro che sono più a loro agio con l'apprendimento visualizzando, ecco un pratico diagramma che ho creato per spiegare Process e Thread.
Ho usato le informazioni da MSDN - Informazioni su processi e thread

I thread all'interno dello stesso processo condividono la memoria, ma ogni thread ha il proprio stack e i propri registri e i thread memorizzano i dati specifici del thread nell'heap. I thread non vengono mai eseguiti in modo indipendente, quindi la comunicazione tra thread è molto più veloce rispetto alla comunicazione tra processi.

I processi non condividono mai la stessa memoria. Quando un processo figlio lo crea, duplica la posizione di memoria del processo padre. La comunicazione di processo viene eseguita utilizzando pipe, memoria condivisa e analisi dei messaggi. Il cambio di contesto tra thread è molto lento.

Migliore risposta

Processo:

Il processo è sostanzialmente un programma in esecuzione. È un'entità attiva. Alcuni sistemi operativi usano il termine & # 8216; task & # 8216; per fare riferimento a un programma in esecuzione. Un processo viene sempre archiviato nella memoria principale anche definita come memoria principale o memoria ad accesso casuale. Pertanto, un processo è definito come entità attiva. Scompare se la macchina viene riavviata. Diversi processi possono essere associati a uno stesso programma. Su un sistema multiprocessore, è possibile eseguire più processi in parallelo. Su un sistema uni-processor, sebbene non si realizzi un vero parallelismo, viene applicato un algoritmo di schedulazione del processo e il processore è programmato per eseguire ogni processo uno alla volta dando l'illusione della concorrenza. Esempio: esecuzione di più istanze della calcolatrice & # 8216; & # 8217; programma. Ciascuna delle istanze è definita come un processo.

Discussione:

Un thread è un sottoinsieme del processo. È definito come un "processo leggero", poiché è simile a un processo reale ma viene eseguito nel contesto di un processo e condivide le stesse risorse assegnate al processo dal kernel. Di solito, un processo ha solo un thread di controllo & # 8211; un set di istruzioni macchina in esecuzione alla volta. Un processo può anche essere costituito da più thread di esecuzione che eseguono istruzioni contemporaneamente. Più thread di controllo possono sfruttare il vero parallelismo possibile sui sistemi multiprocessore. Su un sistema uni-processor, viene applicato un algoritmo di pianificazione dei thread e il processore è programmato per eseguire ogni thread uno alla volta. Tutti i thread in esecuzione all'interno di un processo condividono lo stesso spazio indirizzo, descrittori di file, stack e altri attributi relativi al processo. Poiché i thread di un processo condividono la stessa memoria, la sincronizzazione dell'accesso ai dati condivisi con il processo acquisisce un'importanza senza precedenti.

ref- https://practice.geeksforgeeks.org/problems / differenza-tra-processo-e-filo

La migliore risposta che ho trovato finora è L'interfaccia di programmazione Linux di Michael Kerrisk ':

Nelle moderne implementazioni UNIX, ogni processo può avere più thread di esecuzione. Un modo di prevedere i thread è come un insieme di processi che condividono la stessa memoria virtuale, nonché una gamma di altri attributi. Ogni thread sta eseguendo lo stesso codice programma e condivisioni stessa area dati e heap. Tuttavia, ogni thread ha il proprio stack contenente variabili locali e informazioni sul collegamento delle chiamate di funzione. [LPI 2.12]

Questo libro è una fonte di grande chiarezza; Julia Evans ha menzionato il suo aiuto per chiarire come funzionano veramente i gruppi Linux in questo articolo .

Sono quasi uguali ... Ma la differenza fondamentale è che un thread è leggero e un processo è pesante in termini di cambio di contesto, carico di lavoro e così via.

Esempio 1: una JVM viene eseguita in un singolo processo e i thread in una JVM condividono l'heap appartenente a quel processo. Ecco perché diversi thread possono accedere allo stesso oggetto. I thread condividono l'heap e hanno il loro spazio di stack. Questo è il modo in cui un invocazione di un metodo di un metodo e le sue variabili locali sono al sicuro dagli altri thread. Ma l'heap non è thread-safe e deve essere sincronizzato per la sicurezza dei thread.

Considerare il processo come un'unità di proprietà o quali risorse sono necessarie per un'attività. Un processo può avere risorse come spazio di memoria, input / output specifici, file specifici e priorità ecc.

Un thread è un'unità di esecuzione dispacciabile o in parole semplici l'avanzamento attraverso una sequenza di istruzioni

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow