Computação distribuída versus threads

Question

Quão semelhantes são a computação distribuída e o threading?Encontrei dois artigos chegando a conclusões bastante opostas:

"Multi-Threading é mais fácil que rede.Como o threading é fácil e semelhante ao código de rede"

http://software.intel.com/file/14723

(isso me dá a impressão de que são tão semelhantes que, após o encapsulamento, essas duas abordagens poderiam ser feitas com o mesmo código - mas talvez eu esteja errado)

"Uma nota sobre computação distribuída"

http://research.sun.com/techrep/1994/abstract-29.html

(e isso coloca uma forte distinção)

Tenho certeza de que a verdade está em algum lugar no meio.Qual é o meio-termo?Existem tecnologias que unificam esses dois paradigmas?Ou será que tais tentativas falharam devido a diferenças fundamentais entre rede e simultaneidade?

Answer 1

Eu nunca os achei muito parecidos. Deixe -me definir para os fins deste post um "nó" como um thread de hardware em execução em uma máquina. Portanto, uma máquina quad core é quatro nós, assim como um cluster de quatro caixas de processador único.

Cada nó normalmente executa algum processamento e precisará haver algum tipo de comunicação entre nós. Geralmente, a primeira instância desta comunicação está dizendo ao nó o que fazer. Para esta comunicação, posso usar memória compartilhada, semáforos, arquivos compartilhados, tubos nomeados, soquetes, chamadas de procedimentos remotos, com com, etc., mas os mais fáceis de usar, memória compartilhada e semáforos, normalmente não estão disponíveis em uma rede. Os arquivos compartilhados podem estar disponíveis, mas o desempenho é normalmente ruim. Os soquetes tendem a ser a escolha mais comum e mais flexível em relação a uma rede, em vez dos mecanismos mais sofisticados. Nesse ponto, você deve lidar com os detalhes da arquitetura de rede, incluindo latência, largura de banda, perda de pacotes, topologia de rede e muito mais.

Se você começar com uma fila de trabalho, os nós na mesma máquina poderão usar a memória compartilhada simples para fazer as coisas fazer. Você pode até escrever sem bloqueio e funcionará perfeitamente. Com nós sobre uma rede, onde você coloca a fila? Se você centralizá -lo, essa máquina pode sofrer custos de largura de banda muito altos. Tente distribuí -lo e as coisas ficam muito complicadas muito rapidamente.

O que eu descobri, em geral, é que as pessoas que enfrentam esse tipo de arquitetura paralela tendem a escolher problemas embaraçosamente paralelos para resolver. Raytracing vem à mente. Não há muita comunicação cruzada necessária, além da distribuição de empregos. Existem muitos problemas como esse, com certeza, mas acho um pouco falso sugerir que a computação distribuída é essencialmente a mesma que o encadeamento.

Agora, se você for escrever um threading que se comporta de forma idêntica a um sistema distribuído, usando a passagem de mensagens pura e não assumindo que nenhum thread seja o "principal" e tal, então sim, eles serão muito semelhantes. Mas o que você fez é fingir que tem uma arquitetura distribuída e a implementou em threads. O fato é que o encadeamento é um caso muito mais simples de paralelismo do que a computação distribuída verdadeira. Você pode abstrair os dois em um único problema, mas escolhendo a versão mais difícil e aderindo a ele estritamente. E os resultados não serão tão bons quanto poderiam ser quando todos os nós são locais para uma máquina. Você não está aproveitando o caso especial.

Answer 2

A distribuição de computação é feita em várias máquinas independentes diferentes, geralmente com os operacionais operacionais às vezes especializados. É mais difícil porque a interconectividade das máquinas é muito menor e, portanto, os problemas que exigem muito acesso aleatório e rápido a todo o conjunto de dados são muito difíceis de resolver.

De um modo geral, você precisa de bibliotecas especializadas para realizar problemas de computação distribuídos que descobrem como atribuir nós a problemas e transportar os dados.

Eu realmente me pergunto se eles estão chegando a conclusões diferentes porque estão tentando resolver os problemas errados em cada plataforma. Alguns problemas aderem muito bem a máquinas altamente interconectadas e podem se beneficiar de supercomputadores de poder. Outros problemas podem ser tratados em modelos simplesmente distribuídos. Em geral, os supercomputadores podem resolver uma gama mais ampla de problemas, mas são muito, muito mais especializados e caros.

Answer 3

A diferença parece voltar ao estado de compartilhamento de Threads, Processos passam mensagens.

Você precisa decidir como deseja manter o estado do seu aplicativo antes de escolher um.

O estado de compartilhamento é fácil de começar, todos os dados e variáveis ​​estão lá.Mas uma vez que os impasses/condições de corrida entram, é difícil modificar/escalar.

A passagem de mensagens (por exemplo, Erlang) requer uma abordagem diferente de design, você tem que pensar nas oportunidades de simultaneidade desde o início, mas o estado de cada processo distribuído é isolado, tornando mais fácil lidar com problemas de bloqueio/corrida.

Answer 4

Eu acho que é muito mais útil comparar processos com abordagens de computação distribuídas do que comparar threads com ele. Os threads existem dentro de um único processo e compartilham os mesmos dados e a mesma memória. Isso não é possível em várias máquinas. Os processos, por outro lado, têm sua própria memória, embora em alguns casos contenha exatamente os mesmos dados que outro processo (após um garfo (), por exemplo). Isso pode ser alcançado em uma rede.

Algo que adiciona peso extra a essa analogia é o fato de que muitas ferramentas usadas para comunicação entre processos são transparentes em rede. Um bom exemplo seria o Unix Sockets, que usa a mesma interface que os soquetes de rede (exceto o código de conexão).

Answer 5

Sim, no momento do desenvolvimento, a abordagem é muito semelhante, mas o uso de cada um é muito diferente. Não fico muito claro sua ideia, deixe-me saber se estou errado: ao falar sobre computação distribuída, estamos assumindo mais de um código de processamento de computador ou servidor no mesmo aplicativo, mas quando estamos falando de multi-threading nós estão falando sobre o processamento de diferentes encadeamentos do aplicativo ao mesmo tempo no mesmo computador. Você pode pensar como um exemplo de computação distribuída, em um aplicativo acessando um serviço da Web localizado na Internet. Existem dois computadores diferentes trabalhando no mesmo aplicativo.

Se você deseja um exemplo de multi-threading, pense em um aplicativo tentando encontrar um grande número principal. Se você não usar multi-threading nele, não poderá ver ou fazer mais nada no aplicativo no momento em que está calculando o próximo número primo (pode ser um tempo de vida ou mais) porque o aplicativo não é responsivo enquanto está trabalhando no cálculo.

Você também pode misturá-los: como um exemplo mais complexo, você sempre pode usar o multi-threading para acessar diferentes serviços da Web ao mesmo tempo pelo mesmo aplicativo, para que seu aplicativo seja responsivo, mesmo que não esteja se conectando quando um dos os servidores.

Answer 6

Eu acho que esses dois documentos não podem ser facilmente comparados. O documento da Intel é uma espécie de introdução ao encadeamento, e eles tentam explicar isso encontrando analogias à computação de rede, o que é um pouco estranho e enganoso para mim. Não sei por que eles escolheram essa maneira de apresentar rosqueamento, talvez eles visassem pessoas familiarizadas com as redes, o que provavelmente é mais conhecido ou pelo menos reconhecido do que a rosca.

O documento da Sun, por outro lado, é um artigo sério, representando todas as dificuldades relacionadas à programação distribuída. Tudo o que posso fazer é simplesmente confirmar o que eles dizem.

Na minha opinião, uma abstração que tenta esconder o fato de um objeto ser remoto é prejudicial, pois geralmente leva a um desempenho muito ruim. O programador deve estar ciente do afastamento de um objeto para poder invocá -lo de maneira eficiente.