Qual è la differenza tra un processo e un thread?

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?

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 quali thread "hardware" vs "software" ti potrebbero riferire. I thread sono una funzione 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. Chiamarli "thread" significherebbe che hanno una memoria condivisa.

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.

Thread
Un thread è un'entità all'interno di un processo che può essere programmata 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 dell'ambiente thread e uno stack utente nello spazio degli indirizzi del processo del thread. I thread possono anche avere un proprio contesto di sicurezza, che può essere utilizzato per rappresentare i client.

Queste informazioni sono state trovate su Microsoft Docs qui: 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.

Processi:

• Un'istanza di esecuzione di un programma è chiamata processo.
• Alcuni sistemi operativi utilizzano 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 processo.

Filo:

• 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 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 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 dalla Knowledge Quest! 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 ciò che è condiviso tra loro.

Abbiamo quanto segue dalla sezione 2.2.2 Il modello di thread classico nei moderni sistemi operativi 3e di Tanenbaum:

Il modello di processo si basa su due concetti indipendenti: raggruppamento ed esecuzione delle risorse. A volte è utile separarli; qui entra in gioco il thread ....

Lui continua:

Un modo di vedere un processo è che è un modo per raggruppare le risorse correlate. Un processo ha uno spazio degli indirizzi contenente testo e dati del programma, nonché altre risorse. Queste risorse possono includere file aperti, processi secondari, allarmi in sospeso, gestori di segnali, informazioni contabili e altro. Mettendoli insieme sotto forma di un processo, possono essere gestiti più facilmente. L'altro concetto che un processo ha è un thread di esecuzione, generalmente abbreviato in solo thread. Il thread ha un contatore di programmi che tiene traccia delle istruzioni da eseguire successivamente. Ha registri che contengono le sue attuali variabili di lavoro. Ha uno stack, che contiene la cronologia di esecuzione, con un frame per ogni procedura chiamata ma non ancora restituita. Sebbene un thread debba essere eseguito in alcuni processi, il thread e il suo processo sono concetti diversi e possono essere trattati separatamente. I processi vengono utilizzati per raggruppare le risorse; i thread 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 del 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 Simultaneous Multithreading (abbreviato in SMT).

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

1. Discussioni spazio utenti
2. Discussioni del kernel
3. Una combinazione dei due

Tutto ciò che serve per implementare i thread è la capacità 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. Il più grande svantaggio è l'incapacità di bloccare l'I / O (che bloccherebbe l'intero processo e tutti i suoi thread utente), che è uno dei principali motivi 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 utilizzare 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 è un problema dato che 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 utilizzare dipende da cosa stai parlando. Per quanto riguarda il termine "processo leggero", non vedo personalmente il punto in esso poiché non trasmette realmente ciò che sta accadendo, nonché il termine "filo dell'esecuzione".

Spiegare di più riguardo alla programmazione concorrente

1. 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.

2. I thread esistono all'interno di un processo - 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 salvato automaticamente. 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, incluse 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) avere più thread in esecuzione contemporaneamente nello stesso processo.

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

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

Processi:

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

Esempio:
dire, aprendo qualsiasi browser (Mozilla, Chrome, IE). A questo punto inizierà l'esecuzione del nuovo processo.

discussioni:

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

Esempio:
apertura di più schede nel browser.

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

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 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 di allocazione (spazio del kernel per processi vs. spazio utente per i 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.

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.

Processi

È un programma in esecuzione. ha una sezione di testo, ad esempio il codice del programma, l'attività corrente come rappresentato dal valore del contatore del programma e il 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 in modo dinamico durante il runtime del processo.

Filo

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 dati e altre risorse del sistema operativo come file e segnali aperti.

- Tratto da sistema operativo da Galvin

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] [discussione] [oggetto] [autore]

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

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

Il lunedì 5 agosto 1996, Peter P. Eiserloh scrisse:

Dobbiamo mantenere chiaro il concetto di thread. Troppe persone sembrano confondere un thread con un processo. La seguente discussione non riflette lo stato attuale di Linux, ma piuttosto è un tentativo di rimanere su una discussione di alto livello.

NO!

Non c'è motivo di pensare che "thread" e "processi" siano entità separate. È così che viene fatto tradizionalmente, ma personalmente penso che sia un grosso errore pensare in quel modo. L'unico motivo per 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 è auto-limitante.

Un "contesto di esecuzione", qui denominato COE, è solo il conglomerato di tutto lo stato di quel COE. Tale stato include elementi quali stato della CPU (registri, ecc.), Stato della MMU (mappatura delle pagine), stato delle autorizzazioni (uid, gid) e vari "stati di comunicazione" (file aperti, gestori di segnali, ecc.). Tradizionalmente, la differenza tra un "thread" e un "processo" è stata principalmente che un thread ha stato CPU (+ forse qualche altro stato minimo), mentre tutto il resto del contesto deriva dal processo. Tuttavia, questo è solo un modo per dividere lo stato totale del COE, e non c'è nulla che dica che è il modo giusto di farlo. Limitare te stesso a quel tipo di immagine è semplicemente stupido.

Il modo in cui Linux pensa questo (e il modo in cui voglio le cose al lavoro) è che non v'è alcuna cosa come un "processo" o di un "filo". Esiste solo la totalità del COE (chiamato "task" da Linux). Diversi COE possono condividere parti del loro contesto l'una con l'altra e un sottoinsieme di quella condivisione è la tradizionale configurazione "thread" / "processo", ma questo dovrebbe davvero essere visto SOLO come un sottoinsieme (è un sottoinsieme importante, ma quell'importanza viene non dal design, ma dagli standard: vogliamo ovviamente eseguire programmi di thread conformi agli standard anche su Linux).

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

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

• Puoi fare un programma "cd" esterno, qualcosa che è tradizionalmente impossibile in UNIX e / o process / thread (esempio sciocco, ma l'idea è che puoi avere questo tipo di "moduli" che non sono limitati al tradizionale UNIX / thread setup). Fai un:

clone (CLONE_VM | CLONE_FS);

child: execve ("cd-esterno");

/ * "execve ()" disassocerà la VM, quindi l'unica ragione per cui abbiamo usato CLONE_VM è stata quella di rendere più veloce l'atto di clonazione * /

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

clone (CLONE_VM);

figlio: continua a funzionare, eventualmente execve ()

madre: aspetta l'esecuzione

• puoi fare "IO deamon" esterni:

clone (CLONE_FILES);

figlio: descrittori di file aperti ecc

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

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

Considerando invece questo come un problema di "contesto di esecuzione", le attività possono ora scegliere di eseguire programmi esterni (= separare lo spazio degli indirizzi dal genitore) ecc., Se lo desiderano, oppure possono ad esempio condividere tutto con il genitore ad eccezione di i descrittori di file (in modo che i "thread" secondari possano aprire molti file senza che il genitore debba preoccuparsi di loro: si chiudono automaticamente quando il sottotitolo "thread" viene chiuso e non utilizza i file fd nel genitore) .

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

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

Linus

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 il .textsegmento per l'archiviazione di codice compilato, .bssper l'archiviazione di variabili statiche o globali non inizializzate, ecc.
Ogni processo avrebbe il proprio contatore di programmi e stack di spazio utente .

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 denominata task_structche viene generalmente astratta come blocco di controllo del processo, memorizzando tutte le informazioni relative al processo come priorità, stato , (e molti altri pezzi).
Un processo può avere più thread di esecuzione.

Arrivati ​​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 del thread come risorse del filesystem, condivisione dei segnali in sospeso, condivisione dei dati (variabili e istruzioni) rendendo quindi i thread leggeri e consentendo quindi un cambio di contesto più rapido.

All'interno del kernel, ogni thread ha il proprio stack del kernel insieme alla task_structstruttura 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 id gruppo di thread ( tgid), inoltre hanno un ID univoco chiamato come ID processo ( pid).

Cercando 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 a processo leggero .

Per 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 metodo a un metodo e le sue variabili locali sono mantenute al sicuro dagli altri thread. Ma l'heap non è thread-safe e deve essere sincronizzato per la sicurezza del 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 piccole attività, mentre i processi vengono utilizzati per attività più "pesanti", in sostanza 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 degli 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:

1. I thread sono più facili da creare rispetto ai processi poiché non richiedono uno spazio di indirizzi separato.

2. Il multithreading richiede un'attenta programmazione poiché i thread condividono strutture di dati che dovrebbero essere modificate da un solo thread alla volta. A differenza dei thread, i processi non condividono lo stesso spazio degli indirizzi.

3. I thread sono considerati leggeri perché utilizzano molte meno risorse rispetto ai processi.

4. I processi sono indipendenti l'uno dall'altro. I thread, poiché condividono lo stesso spazio degli indirizzi, sono interdipendenti, quindi è necessario prestare attenzione in modo che thread diversi non si incrocino l'un l'altro.
   Questo è davvero un altro modo di affermare il numero 2 sopra.

5. Un processo può essere composto da più thread.

Quello che segue è quello che ho ottenuto da uno degli articoli su The Code Project . Immagino che spieghi chiaramente tutto ciò che serve.

Un thread è un altro meccanismo per suddividere il carico di lavoro in flussi di esecuzione separati. Un filo ha un peso più leggero di un processo. Ciò significa che offre una minore flessibilità rispetto a un processo completo, ma può essere avviato più rapidamente perché il sistema operativo ha una configurazione inferiore. Quando un programma è composto da due o più thread, tutti 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.

Processi:

Il processo è sostanzialmente un programma in esecuzione. È un'entità attiva. Alcuni sistemi operativi utilizzano 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 processo.

Filo:

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 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,

ref- https://practice.geeksforgeeks.org/problems/difference-between-process-and-thread

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:

1. 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.
2. Risorse. Le risorse (memoria, handle, socket, ecc.) Vengono rilasciate al termine del processo, non alla terminazione del thread.
3. 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 e interruzioni hardware e software o thread in modalità utente e kernel .

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

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

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

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

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

1. mantenendo il processo errato da crash dell'intero sistema.
2. Mantenere la sicurezza rendendo invisibili e irraggiungibili i dati di altri processi. Il lavoro effettivo all'interno del processo è curato da uno o più thread.

1. Fondamentalmente, un thread fa parte di un processo senza che il thread di processo non sia in grado di funzionare.
2. Un filo è leggero mentre il processo è pesante.
3. la comunicazione tra processo richiede un po 'di tempo, mentre il thread richiede meno tempo.
4. 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 : 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.

Ho sfogliato quasi tutte le risposte lì, ahimè, come studente universitario che frequenta un corso di OS al momento non riesco a comprendere a fondo i due concetti. Voglio dire, la maggior parte dei ragazzi legge da alcuni libri del sistema operativo le differenze, cioè i thread sono in grado di accedere alle variabili globali nell'unità di transazione poiché fanno uso dello spazio degli indirizzi del loro processo. Tuttavia, sorge la nuova domanda sul perché ci siano processi, consapevolmente sappiamo già che i thread sono più leggeri rispetto ai processi. Diamo un'occhiata al seguente esempio facendo uso dell'immagine estratta da una delle risposte precedenti ,

Abbiamo 3 thread che lavorano contemporaneamente su un documento Word, ad esempio Libre Office . Il primo fa il controllo ortografico sottolineando se la parola è errata. Il secondo prende e stampa lettere dalla tastiera. E l'ultimo salva il documento in ogni breve tempo per non perdere il documento su cui ha funzionato se qualcosa va storto. In questo caso, i 3 thread non possono essere 3 processi poiché condividono una memoria comune che è lo spazio degli indirizzi del loro processo e quindi tutti hanno accesso al documento in fase di modifica. Quindi, la strada è la parola documento insieme a due bulldozer che sono i fili sebbene uno di questi sia la mancanza nell'immagine.

Mentre costruivo un algoritmo in Python (linguaggio interpretato) che incorporava il multi-threading, fui sorpreso di vedere che il tempo di esecuzione non era migliore rispetto all'algoritmo sequenziale che avevo precedentemente costruito. 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 a 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.

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.

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 serie di altri attributi. Ogni thread esegue lo stesso codice programma e condivide la stessa area dati e lo stesso 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 i gruppi Linux funzionano davvero in questo articolo .

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 del thread.

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.