Qual é a diferença entre um processo e um thread?

https://stackoverflow.com/questions/200469

03-07-2019
|

Pergunta

Qual é a diferença técnica entre um processo e um thread?

Tenho a sensação de que uma palavra como 'processo' é usada em demasia e também existem threads de hardware e software.Que tal processos leves em linguagens como Erlang?Existe uma razão definitiva para usar um termo em vez do outro?

Solução

Tanto os processos quanto os threads são sequências independentes de execução. A diferença típica é que os threads (do mesmo processo) são executados em um espaço de memória compartilhado, enquanto os processos são executados em espaços de memória separados.

Não tenho certeza de quais threads de software "hardware" vs "você pode estar se referindo. Os threads são um recurso de ambiente operacional, em vez de um recurso da CPU (embora a CPU normalmente tenha operações que tornem os threads eficientes).

O Erlang usa o termo "processo" porque não expõe um modelo de multiprogramação de memória compartilhada. Chamá -los de "threads" implicaria que eles compartilharam memória.

Outras dicas

Processo
Cada processo fornece os recursos necessários para executar um programa.Um processo possui um espaço de endereço virtual, código executável, identificadores abertos para objetos do sistema, um contexto de segurança, um identificador de processo exclusivo, variáveis de ambiente, uma classe de prioridade, tamanhos mínimos e máximos de conjuntos de trabalho e pelo menos um thread de execução.Cada processo é iniciado com um único thread, geralmente chamado de thread primário, mas pode criar threads adicionais a partir de qualquer um de seus threads.

Fio
Um thread é uma entidade dentro de um processo que pode ser agendada para execução.Todos os threads de um processo compartilham seu espaço de endereço virtual e recursos do sistema.Além disso, cada thread mantém manipuladores de exceção, uma prioridade de agendamento, armazenamento local de thread, um identificador exclusivo de thread e um conjunto de estruturas que o sistema usará para salvar o contexto do thread até que ele seja agendado.O contexto do thread inclui o conjunto de registros de máquina do thread, a pilha do kernel, um bloco de ambiente do thread e uma pilha do usuário no espaço de endereço do processo do thread.Threads também podem ter seu próprio contexto de segurança, que pode ser usado para representar clientes.

Encontrei isso no MSDN aqui:
Sobre processos e threads

O Microsoft Windows oferece suporte a multitarefa preemptiva, que cria o efeito de execução simultânea de vários threads de vários processos.Em um computador multiprocessador, o sistema pode executar simultaneamente tantos threads quantos forem os processadores no computador.

Processo:

Uma instância de execução de um programa é chamada de processo.
Alguns sistemas operacionais usam o termo 'tarefa' para se referir a um programa que está sendo executado.
Um processo é sempre armazenado na memória principal, também denominada memória primária ou memória de acesso aleatório.
Portanto, um processo é denominado como uma entidade ativa. Ele desaparece se a máquina for reiniciada.
Vários processos podem estar associados a um mesmo programa.
Em um sistema multiprocessador, vários processos podem ser executados em paralelo.
Em um sistema uni-processador, embora o paralelismo verdadeiro não seja alcançado, um algoritmo de agendamento de processos é aplicado e o processador está programado para executar cada processo um de cada vez, produzindo uma ilusão de simultaneidade.
Exemplo: Executando várias instâncias do programa 'calculadora'. Cada uma das instâncias é denominada processo.

Fio:

Um thread é um subconjunto do processo.
Ele é denominado como um 'processo leve', pois é semelhante a um processo real, mas é executado no contexto de um processo e compartilha os mesmos recursos alocados ao processo pelo kernel.
Geralmente, um processo possui apenas um tópico de controle - um conjunto de instruções da máquina executando por vez.
Um processo também pode ser composto de vários threads de execução que executam instruções simultaneamente.
Vários threads de controle podem explorar o verdadeiro paralelismo possível nos sistemas multiprocessadores.
Em um sistema Uni-Processor, um algoritmo de agendamento de threads é aplicado e o processador está programado para executar cada thread um de cada vez.
Todos os threads em execução em um processo compartilham o mesmo espaço de endereço, descritores de arquivos, pilha e outros atributos relacionados ao processo.
Como os threads de um processo compartilham a mesma memória, sincronizando o acesso aos dados compartilhados no processo ganha importância sem precedentes.

Peguei emprestado as informações acima do Quest do conhecimento! blog.

Primeiro, vejamos o aspecto teórico.Você precisa entender o que é conceitualmente um processo para entender a diferença entre um processo e um thread e o que é compartilhado entre eles.

Temos o seguinte da seção 2.2.2 O Modelo Clássico de Rosca em Sistemas operacionais modernos 3e por Tanenbaum:

O modelo de processo é baseado em dois conceitos independentes:recurso agrupamento e execução.Às vezes é útil separá-los;é aqui que entram os tópicos....

Ele continua:

Uma maneira de olhar para um processo é que ele é uma maneira de agrupar recursos relacionados.Um processo tem um espaço de endereço contendo texto e dados do programa, bem como outros recursos.Estes recurso pode incluir arquivos abertos, processos filho, alarmes pendentes, manipuladores de sinais, informações contábeis e muito mais.Colocando-os Juntos, na forma de um processo, eles podem ser gerenciados com mais facilidade.O outro conceito que um processo tem é um fio de execução, geralmente encurtado para apenas fio.O thread tem um contador de programa que mantém Acompanhe qual instrução executar a seguir.Possui registros, que manter suas variáveis de trabalho atuais.Ele tem uma pilha, que contém o histórico de execução, com um quadro para cada procedimento chamado, mas não mas retornou de.Embora um thread deva ser executado em algum processo, o thread e seu processo são conceitos diferentes e podem ser tratados separadamente.Os processos são usados para agrupar recursos;Tópicos são as entidades agendadas para execução na CPU.

Mais abaixo ele fornece a seguinte tabela:

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        |

Vamos lidar com o multithreading de hardware emitir.Classicamente, uma CPU suportaria um único thread de execução, mantendo o estado do thread por meio de um único contador de programa e um conjunto de registros.Mas o que acontece se houver uma falta de cache?Demora muito tempo para buscar dados da memória principal e, enquanto isso acontece, a CPU fica ociosa.Então, alguém teve a ideia de ter basicamente dois conjuntos de estados de thread (registros PC +) para que outro thread (talvez no mesmo processo, talvez em um processo diferente) pudesse trabalhar enquanto o outro thread estava aguardando na memória principal.Existem vários nomes e implementações deste conceito, como HyperThreading e Multithreading simultâneo (SMT para abreviar).

Agora vamos dar uma olhada no lado do software.Existem basicamente três maneiras de implementar threads no lado do software.

Tópicos do espaço do usuário
Tópicos do Kernel
Uma combinação dos dois

Tudo que você precisa para implementar threads é a capacidade de salvar o estado da CPU e manter múltiplas pilhas, o que em muitos casos pode ser feito no espaço do usuário.A vantagem dos threads de espaço do usuário é a troca super rápida de threads, já que você não precisa ficar preso no kernel e tem a capacidade de agendar seus threads da maneira que desejar.A maior desvantagem é a incapacidade de bloquear E/S (o que bloquearia todo o processo e todos os threads do usuário), que é um dos grandes motivos pelos quais usamos threads em primeiro lugar.O bloqueio de E/S usando threads simplifica muito o design do programa em muitos casos.

Threads do kernel têm a vantagem de poder utilizar bloqueio de E/S, além de deixar todas as questões de escalonamento para o SO.Mas cada troca de thread requer captura no kernel, que é potencialmente relativamente lento.No entanto, se você estiver trocando de thread por causa de E/S bloqueada, isso não é realmente um problema, pois a operação de E/S provavelmente já prendeu você no kernel.

Outra abordagem é combinar os dois, com vários threads de kernel, cada um tendo vários threads de usuário.

Então, voltando à sua questão de terminologia, você pode ver que um processo e um thread de execução são dois conceitos diferentes e a escolha de qual termo usar depende do que você está falando.Em relação ao termo "processo leve", pessoalmente não vejo sentido nisso, pois não transmite realmente o que está acontecendo, assim como o termo "thread de execução".

Para explicar mais em relação à programação simultânea

Um processo possui um ambiente de execução independente. Um processo geralmente possui um conjunto completo e privado de recursos básicos de tempo de execução; Em particular, cada processo tem seu próprio espaço de memória.
Existem tópicos dentro de um processo - todo processo tem pelo menos um. Os threads compartilham os recursos do processo, incluindo memória e arquivos abertos. Isso cria uma comunicação eficiente, mas potencialmente problemática.

Manter uma pessoa comum em mente,

No seu computador, abra o Microsoft Word e o Web Browser. Nós chamamos esses dois processos.

No Microsoft Word, você digita algo e ele é salvo automaticamente. Agora, você teria observado edição e economia acontecem em paralelo - edição em um thread e salvando no outro thread.

Um aplicativo consiste em um ou mais processos. Um processo, nos termos mais simples, é um programa de execução. Um ou mais threads são executados no contexto do processo. Um encadeamento é a unidade básica para a qual o sistema operacional aloca tempo do processador. Um encadeamento pode executar qualquer parte do código do processo, incluindo peças atualmente executadas por outro thread. Uma fibra é uma unidade de execução que deve ser agendada manualmente pelo aplicativo. As fibras correm no contexto dos threads que as agendam.

Roubado de aqui.

Um processo é uma coleção de código, memória, dados e outros recursos. Um encadeamento é uma sequência de código que é executada no escopo do processo. Você pode (geralmente) ter vários threads executando simultaneamente dentro do mesmo processo.

Todo processo é um encadeamento (encadeamento primário).
Mas cada thread não é um processo. É uma parte (entidade) de um processo.

Exemplo do mundo real para processo e tópico Isso lhe dará a ideia básica sobre threads e processos

Peguei emprestado as informações acima da resposta de Scott Langham - obrigado

Processo:

O processo é um processo de peso pesado.
O processo é um programa separado que possui memória separada, dados, recursos ect.
O processo é criado usando o método Fork ().
A mudança de contexto entre o processo consome tempo.

Exemplo:
Digamos, abrindo qualquer navegador (Mozilla, Chrome, ou seja). Neste ponto, o novo processo começará a executar.

Tópicos:

Os threads são processos de peso leve. Os dados são incluídos dentro do processo.
Os threads têm uma memória compartilhada, dados, recursos, arquivos etc.
Os threads são criados usando o método clone ().
A mudança de contexto entre os threads não consome muito tempo como processo.

Exemplo:
Abrindo várias guias no navegador.

Tanto threads quanto processos são unidades atômicas de alocação de recursos do sistema operacional (ou seja,existe um modelo de simultaneidade que descreve como o tempo da CPU é dividido entre eles e o modelo de propriedade de outros recursos do sistema operacional).Há uma diferença em:

Recursos compartilhados (threads compartilham memória por definição, eles não possuem nada, exceto pilha e variáveis locais;processos também podem compartilhar memória, mas existe um mecanismo separado para isso, mantido pelo sistema operacional)
Espaço de alocação (espaço do kernel para processos vs.espaço do usuário para threads)

Greg Hewgill acima estava correto sobre o significado Erlang da palavra "processo", e aqui há uma discussão sobre por que Erlang poderia tornar os processos leves.

Tanto os processos quanto os threads são sequências independentes de execução.A diferença típica é que threads (do mesmo processo) são executados em um espaço de memória compartilhada, enquanto os processos são executados em espaços de memória separados.

Processo

É um programa em execução.possui uma seção de texto, ou seja, o código do programa, a atividade atual representada pelo valor do contador do programa e o conteúdo do registro do processador.Ele também inclui a pilha de processos que contém dados temporários (como parâmetros de função, endereçamento de retorno e variáveis locais) e uma seção de dados, que contém variáveis globais.Um processo também pode incluir um heap, que é a memória alocada dinamicamente durante o tempo de execução do processo.

Fio

Um thread é uma unidade básica de utilização da CPU;compreende um ID de thread, um contador de programa, um conjunto de registradores e uma pilha.ele compartilhou com outros threads pertencentes ao mesmo processo sua seção de código, seção de dados e outros recursos do sistema operacional, como arquivos abertos e sinais.

- Retirado do sistema operacional por Galvin

Tentando responder a esta questão relativa ao mundo Java.

Um processo é a execução de um programa, mas um thread é uma única sequência de execução dentro do processo.Um processo pode conter vários threads.Um thread às vezes é chamado de processo leve.

Por exemplo:

Exemplo 1:Uma JVM é executada em um único processo e os threads em uma JVM compartilham o heap pertencente a esse processo.É por isso que vários threads podem acessar o mesmo objeto.Threads compartilham o heap e possuem seu próprio espaço de pilha.É assim que a invocação de um método por um thread e suas variáveis locais são mantidas seguras em relação a outros threads.Mas o heap não é seguro para threads e deve ser sincronizado para segurança de threads.

Exemplo 2:Um programa pode não ser capaz de fazer desenhos lendo as teclas digitadas.O programa deve dar toda a atenção à entrada do teclado e a falta de capacidade de lidar com mais de um evento por vez causará problemas.A solução ideal para este problema é a execução contínua de duas ou mais seções de um programa ao mesmo tempo.Threads nos permite fazer isso.Aqui, desenhar uma imagem é um processo e ler o pressionamento de tecla é um subprocesso (thread).

Diferença entre Thread e Processo?

Um processo é uma instância em execução de um aplicativo e um thread é um caminho de execução dentro de um processo.Além disso, um processo pode conter vários threads. É importante observar que um thread pode fazer qualquer coisa que um processo pode fazer.Mas como um processo pode consistir em vários threads, um thread pode ser considerado um processo “leve”.Assim, a diferença essencial entre um thread e um processo é o trabalho que cada um realiza.Threads são usados para tarefas pequenas, enquanto processos são usados para tarefas mais “pesadas” – basicamente a execução de aplicações.

Outra diferença entre um thread e um processo é que threads dentro do mesmo processo compartilham o mesmo espaço de endereço, enquanto processos diferentes não.Isso permite que threads leiam e gravem nas mesmas estruturas e variáveis de dados e também facilita a comunicação entre threads.A comunicação entre processos – também conhecida como IPC, ou comunicação entre processos – é bastante difícil e consome muitos recursos.

Aqui está um resumo das diferenças entre threads e processos:

Os threads são mais fáceis de criar do que os processos, uma vez que não exigem um espaço de endereço separado.
Multithreading requer programação cuidadosa, uma vez que threads Compartilhar estruturas de dados que só devem ser modificadas por um thread de cada vez.Ao contrário dos threads, os processos não compartilham o mesmo espaço de endereço.
Os fios são considerados leves porque usam muito menos recursos do que processos.
Os processos são independentes uns dos outros.Threads, uma vez que eles compartilhar o mesmo espaço de endereço são interdependentes, portanto, cuidado deve ser tomada para que diferentes tópicos não pisem uns nos outros.
Esta é realmente outra maneira de afirmar o item 2 acima.
Um processo pode consistir em vários threads.

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

Linus Torvalds (torvalds@cs.helsinki.fi)

Ter, 6 de agosto de 1996 12:47:31 +0300 (EET DST)

Mensagens classificadas por: [DATE] [Thread] [Assunto] [Autor

Próxima mensagem: Bernd P. Ziller: "Re: Oops em get_hash_table"

Mensagem anterior: Linus Torvalds: "Re: E/S Pedido de pedido"

Em segunda -feira, 5 de agosto de 1996, Peter P. Eiserloh escreveu:

Precisamos manter claro o conceito de threads. Muitas pessoas parecem confundir um tópico com um processo. A discussão a seguir não reflete o estado atual do Linux, mas é uma tentativa de permanecer em uma discussão de alto nível.

NÃO!

Não há razão para pensar que "threads" e "processos" são entidades separadas. É assim que é tradicionalmente feito, mas eu pessoalmente acho que é um grande erro pensar assim. A única razão para pensar dessa maneira é a bagagem histórica.

Tanto os tópicos quanto os processos são realmente apenas uma coisa: um "contexto de execução". Tentar distinguir artificialmente casos diferentes é apenas autolimitante.

Um "contexto de execução", chamado Coe, é apenas o conglomerado de todo o estado desse COE. Esse estado inclui coisas como o estado da CPU (registros etc.), o estado da MMU (mapeamentos de página), o estado de permissão (UID, GID) e vários "estados de comunicação" (arquivos abertos, manipuladores de sinalização etc.). Tradicionalmente, a diferença entre um "thread" e um "processo" tem sido principalmente que um threads possui estado de CPU (+ possivelmente algum outro estado mínimo), enquanto todo o outro contexto vem do processo. No entanto, isso é apenas 1 maneira de dividir o estado total do Coe, e não há nada que diga que é a maneira certa de fazê -lo. Limitar -se a esse tipo de imagem é simplesmente estúpido.

A maneira como o Linux pensa sobre isso (e a maneira como quero que as coisas funcionem) é que lá é Não há um "processo" ou um "thread". Existe apenas a totalidade do COE (chamado "Tarefa" do Linux). Diferentes Coe's podem compartilhar partes de seu contexto entre si, e um subconjunto Desse compartilhamento, é a configuração tradicional de "thread"/"processo", mas isso deve ser realmente visto como apenas um subconjunto (é um subconjunto importante, mas essa importância não vem do design, mas de padrões: obviamente, queremos executar padrões- programas de threads em conformidade também no topo do Linux).

Em resumo: não projete em torno da maneira de pensar em thread/processo. O kernel deve ser projetado em torno da maneira Coe de pensar, e depois os pthreads biblioteca Pode exportar a interface PTHreads limitada para os usuários que desejam usar essa maneira de olhar para o Coe's.

Apenas como um exemplo do que se torna possível quando você pensa que Coe, em oposição ao Thread/Process:

Você pode fazer um programa "CD" externo, algo tradicionalmente impossível no Unix e/ou Process/Thread (exemplo bobo, mas a idéia é que você possa ter esse tipo de "módulos" que não são limitados ao Unix tradicional /configuração de threads). Fazer a:

clone (clone_vm | clone_fs);

criança: execve ("externo-CD");

/ * O "Execve ()" desassociará a VM, então a única razão pela qual usamos clone_vm foi fazer o ato de clonar mais rápido */

Você pode fazer "vFork ()" naturalmente (ele mede o apoio mínimo do kernel, mas esse suporte se encaixa perfeitamente na maneira de pensar em CUA):

clone (clone_vm);

Criança: continue correndo, eventualmente executa ()

Mãe: Espere por Execve

Você pode fazer "io Deamens" externo:

clone (clone_files);

criança: descritores de arquivos abertos etc

Mãe: Use o FD que a criança abriu e VV.

Todas as opções acima funcionam porque você não está ligado à maneira de pensar em thread/processo. Pense em um servidor da Web, por exemplo, onde os scripts CGI são feitos como "threads de execução". Você não pode fazer isso com tópicos tradicionais, porque os tópicos tradicionais sempre precisam compartilhar todo o espaço de endereço, para que você tenha que vincular tudo o que sempre quis fazer no próprio servidor da web (um "thread" não pode ser executado outro executável).

Pensando nisso como um problema de "contexto de execução", suas tarefas agora podem escolher executar programas externos (= separar o espaço de endereço dos pais) etc. se quiserem, ou, por exemplo, compartilhar tudo com o pai exceto Para os descritores de arquivos (para que os sub- "Threads" possam abrir muitos arquivos sem que os pais precisem se preocupar com eles: eles se fecham automaticamente quando o sub- "Thread" sai e não usa FDs no pai ).

Pense em um "INETD" roscado, por exemplo. Você deseja que o bêbado de baixo custo+EXEC, portanto, com a maneira que você pode, em vez de usar um "Fork ()", você escreve um INETD com vários threads, onde cada thread é criado com apenas clone_vm (espaço de endereço compartilhado, mas não compartilhe arquivo descritores etc). Em seguida, a criança pode executar se fosse um serviço externo (rlogind, por exemplo), ou talvez fosse um dos serviços internos da INETD (Echo, TimeOfday), caso em que apenas faz isso e sai.

Você não pode fazer isso com "Thread"/"Process".

Linus

Do ponto de vista de um entrevistador, há basicamente apenas três coisas principais que eu quero ouvir, além de coisas óbvias como um processo pode ter vários tópicos:

Os threads compartilham o mesmo espaço de memória, o que significa que um encadeamento pode acessar a memória da memória do thread de outros. Processos normalmente não podem.
Recursos. Recursos (memória, alças, soquetes, etc.) são liberação no término do processo, não na terminação do encadeamento.
Segurança. Um processo tem um token de segurança fixo. Um tópico, por outro lado, pode se passar por diferentes usuários/tokens.

Se você quer mais, a resposta de Scott Langham abrange tudo. Tudo isso é da perspectiva de um sistema operacional. Diferentes idiomas podem implementar conceitos diferentes, como tarefas, threads leves e assim por diante, mas são apenas maneiras de usar threads (de fibras no Windows). Não há threads de hardware e software. Existem hardware e software exceções e interrompe, ou modo de usuário e kernel tópicos.

Um fio é executado em um espaço de memória compartilhado, mas um processo é executado em um espaço de memória separado
Um thread é um processo leve, mas um processo é um processo pesado.
Um thread é um subtipo de processo.

A seguir, é o que recebi de um dos artigos em O projeto de código. Eu acho que explica tudo o que é necessário claramente.

Um encadeamento é outro mecanismo para dividir a carga de trabalho em fluxos de execução separados. Um fio é um peso mais leve que um processo. Isso significa que oferece menos flexibilidade do que um processo completo, mas pode ser iniciado mais rapidamente, porque há menos para o sistema operacional configurar. Quando um programa consiste em dois ou mais threads, todos os threads compartilham um único espaço de memória. Os processos recebem espaços de endereço separados. Todos os threads compartilham uma única pilha. Mas cada tópico recebe sua própria pilha.

Basicamente, um thread faz parte de um processo sem thread de processo não seria capaz de funcionar.
Um fio é leve, enquanto o processo é pesado.
A comunicação entre o processo requer algum tempo, enquanto o encadeamento requer menos tempo.
Os tópicos podem compartilhar a mesma área de memória, enquanto o processo vive em separado.

Processo: O programa sob execução é conhecido como processo

Fio: Thread é uma funcionalidade que é executada com a outra parte do programa com base no conceito de "um com outro", então Thread faz parte do processo.

Vindo do mundo incorporado, gostaria de acrescentar que o conceito de processos existe apenas em processadores "grandes" (CPUs de mesa, córtex ARM A-9) que possuem MMU (unidade de gerenciamento de memória) e sistemas operacionais que suportam o uso de MMUs (como Linux). Com pequenos/antigos processadores e microcontroladores e pequeno sistema operacional RTOs (sistema operacional em tempo real), como Freertos, não há suporte para MMU e, portanto, não há processos, mas apenas threads.

Tópicos pode acessar a memória uns dos outros e eles são agendados pelo sistema operacional de maneira intercalada, para que pareçam funcionar em paralelo (ou com vários núcleos que realmente correm em paralelo).

Processos, por outro lado, vivem em sua caixa de areia privada de memória virtual, fornecida e guardada pela MMU. Isso é útil porque permite:

Mantendo o processo de buggy de travar todo o sistema.
Manter a segurança, tornando os dados de outros processos invisíveis e inacessíveis. O trabalho real dentro do processo é resolvido por um ou mais threads.

Ao construir um algoritmo em Python (linguagem interpretada) que incorporava multi-threading, fiquei surpreso ao ver que o tempo de execução não era melhor quando comparado ao algoritmo seqüencial que eu havia construído anteriormente. Em um esforço para entender o motivo desse resultado, fiz algumas leituras e acreditei o que aprendi oferece um contexto interessante para entender melhor as diferenças entre multi-threading e multipocessos.

Os sistemas com vários núcleos podem exercer vários threads de execução e, portanto, o Python deve suportar multi-threading. Mas Python não é uma linguagem compilada e, em vez disso, é uma linguagem interpretada¹. Isso significa que o programa deve ser interpretado para executar e o intérprete não está ciente do programa antes de começar a execução. O que ele sabe, no entanto, são as regras do Python e, em seguida, aplica dinamicamente essas regras. As otimizações no Python devem ser o otimizações principalmente do próprio intérprete, e não o código que deve ser executado. Isso contrasta com idiomas compilados, como C ++, e tem consequências para multi-threading em Python. Especificamente, o Python usa o bloqueio global de intérprete para gerenciar multi-threading.

Por outro lado, uma linguagem compilada é, bem, compilada. O programa é processado "inteiramente", onde primeiro é interpretado de acordo com suas definições sintáticas, depois mapeado para uma representação intermediária agnóstica de idioma e, finalmente, vinculado a um código executável. Esse processo permite que o código seja altamente otimizado porque está disponível no momento da compilação. As várias interações e relacionamentos do programa são definidos no momento em que o executável é criado e decisões robustas sobre otimização podem ser tomadas.

Nos ambientes modernos, o intérprete da Python deve permitir multi-threading, e isso deve ser seguro e eficiente. É aqui que a diferença entre ser uma linguagem interpretada versus uma linguagem compilada entra em cena. O intérprete não deve perturbar os dados compartilhados internamente de diferentes encadeamentos, e ao mesmo tempo otimizar o uso de processadores para cálculos.

Como foi observado nas postagens anteriores, um processo e um thread são execuções seqüenciais independentes, com a diferença primária, sendo que a memória é compartilhada em vários threads de um processo, enquanto os processos isolam seus espaços de memória.

Nos dados do Python, é protegido do acesso simultâneo por diferentes encadeamentos pelo bloqueio global do intérprete. Exige que, em qualquer programa Python, apenas um thread possa ser executado a qualquer momento. Por outro lado, é possível executar vários processos, pois a memória para cada processo é isolada de qualquer outro processo, e os processos podem ser executados em vários núcleos.

¹ Donald Knuth tem uma boa explicação de rotinas interpretativas na arte da programação de computadores: algoritmos fundamentais.

Tentando responder a partir do OS View do Kernel Linux

Um programa se torna um processo quando lançado na memória.Um processo tem seu próprio espaço de endereço, o que significa ter vários segmentos na memória, como segmento .text para armazenar código compilado, .bss para armazenar variáveis estáticas ou globais não inicializadas, etc.Cada processo teria seu próprio contador de programa e espaço de usuário pilha.Dentro do kernel, cada processo teria sua própria pilha de kernel (que é separada da pilha de espaço do usuário por questões de segurança) e uma estrutura chamada task_struct que geralmente é abstraído como o bloco de controle do processo, armazenando todas as informações sobre o processo, como sua prioridade, estado (e muitos outros pedaços).Um processo pode ter vários threads de execução.

Chegando aos threads eles residem dentro de um processo e compartilham o espaço de endereço do processo pai junto com outros recursos que podem ser passados durante a criação do thread como recursos do sistema de arquivos compartilhando sinais pendentes compartilhando dados(variáveis e instruções) tornando os threads leves e permitindo assim uma troca de contexto mais rápida.Dentro do kernel, cada thread tem sua própria pilha de kernel junto com o task_struct estrutura que define o thread.Portanto, o kernel vê threads do mesmo processo como entidades diferentes e é escalonável por si só.Threads no mesmo processo compartilham um ID comum chamado ID do grupo de threads (tgid), eles também têm um ID exclusivo chamado ID do processo (pid).

Para aqueles que se sentem mais confortáveis em aprender por visualização, aqui está um diagrama útil que criei para explicar Processos e Threads.
Usei as informações do MSDN - Sobre processos e threads

Os threads dentro do mesmo processo compartilham a memória, mas cada thread possui sua própria pilha e registros, e os threads armazenam dados específicos de threads na pilha. Os threads nunca são executados de forma independente, portanto a comunicação entre thread é muito mais rápida quando comparada à comunicação entre processos.

Os processos nunca compartilham a mesma memória. Quando um processo infantil cria, duplica a localização da memória do processo pai. A comunicação do processo é feita usando o tubo, a memória compartilhada e a análise de mensagens. A troca de contexto entre roscas é muito lenta.

Melhor resposta

Processo:

O processo é basicamente um programa de execução. É uma entidade ativa. Alguns sistemas operacionais usam o termo 'tarefa' para se referir a um programa que está sendo executado. Um processo é sempre armazenado na memória principal, também denominada memória primária ou memória de acesso aleatório. Portanto, um processo é denominado como uma entidade ativa. Ele desaparece se a máquina for reiniciada. Vários processos podem estar associados a um mesmo programa. Em um sistema multiprocessador, vários processos podem ser executados em paralelo. Em um sistema uni-processador, embora o paralelismo verdadeiro não seja alcançado, um algoritmo de agendamento de processos é aplicado e o processador está programado para executar cada processo um de cada vez, produzindo uma ilusão de simultaneidade. Exemplo: executando várias instâncias do programa 'calculadora'. Cada uma das instâncias é denominada processo.

Fio:

Um thread é um subconjunto do processo. Ele é denominado como um 'processo leve', pois é semelhante a um processo real, mas é executado no contexto de um processo e compartilha os mesmos recursos alocados ao processo pelo kernel. Geralmente, um processo possui apenas um tópico de controle - um conjunto de instruções da máquina executando por vez. Um processo também pode ser composto de vários threads de execução que executam instruções simultaneamente. Vários threads de controle podem explorar o verdadeiro paralelismo possível nos sistemas multiprocessadores. Em um sistema Uni-Processor, um algoritmo de agendamento de threads é aplicado e o processador está programado para executar cada thread um de cada vez. Todos os threads em execução em um processo compartilham o mesmo espaço de endereço, descritores de arquivos, pilha e outros atributos relacionados ao processo. Como os threads de um processo compartilham a mesma memória, sincronizando o acesso aos dados compartilhados com o processo ganha importância sem precedentes.

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

A melhor resposta que encontrei até agora é 'A interface de programação Linux' de Michael Kerrisk:

Em implementações UNIX modernas, cada processo pode ter vários threads de execução.Uma maneira de encarar os threads é como um conjunto de processos que compartilham a mesma memória virtual, bem como uma série de outras Atributos.Cada thread está executando o mesmo código de programa e compartilha a mesma área de dados e heap.No entanto, cada thread tem sua própria pilha contendo variáveis locais e informações de vinculação de chamadas de função.[LPI 2.12]

Este livro é uma fonte de grande clareza;Julia Evans mencionou sua ajuda para esclarecer como os grupos Linux realmente funcionam em Este artigo.

Eles são quase os mesmos ... mas a diferença principal é que um encadeamento é leve e um processo é pesado em termos de comutação de contexto, carga de trabalho e assim por diante.

Considere o processo como uma unidade de propriedade ou quais recursos são necessários para uma tarefa. Um processo pode ter recursos como espaço de memória, entrada/saída específicos, arquivos específicos e prioridade etc.

Um thread é uma unidade de execução despachável ou, em palavras simples, o progresso através de uma sequência de instruções

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow