Abstrações de simultaneidade estão simulando processos UNIX?


8

OK, eu estava pensando nisso hoje e vim pedir opiniões completamente subjetivas e tendenciosas sobre isso. Paradoxalmente, apesar disso, também não acho que seja forragem de guerra. Acho que há espaço para uma conversa perfeitamente civilizada - dificilmente é Vim vs Emacs.

Eu usei muitas abstrações de simultaneidade, especificamente aquelas criadas sobre tópicos. Há uma grande tendência entre elas, seja a transmissão de mensagens, imutável por padrão, ou thread local por padrão ou outras.

A tendência é que todos eles invertam a ideia de threads, tornando o compartilhamento de dados explícito e não implícito. Ou seja, todos os dados não são compartilhados, a menos que seja especificado de outra forma, o que é o oposto do encadeamento tradicional encontrado em linguagens como Java. (Eu sei que o Java suporta suas próprias abstrações de simultaneidade de nível superior.) Por exemplo, você passa mensagens explicitamente. Você declara explicitamente quais variáveis ​​são locais de encadeamento. Você declara explicitamente quais variáveis ​​são mutáveis. Estes são apenas alguns exemplos encontrados em alguns idiomas.

Eu pensei que esse estilo fácil de concorrência era um conceito moderno. Eu estava errado. Comecei a brincar com brinquedos UNIX como fork () e pipe () recentemente, e fiquei chocado ao descobrir que mecanismos de concorrência explícitos e sem esforço existem desde o início do UNIX.

Há algo um pouco estranho em perceber que o C + UNIX dos anos 70 facilita a concorrência muito mais do que muitos mecanismos modernos de encadeamento na moda.

Então, aqui está o que eu estou pensando ... essas abstrações de encadeamentos modernos estão simplesmente tentando imitar processos no estilo UNIX sobre encadeamentos, com todos os seus traços explícitos e não compartilhados por padrão? Sei que alguns mecanismos como o STM oferecem coisas como transações no estilo DB, que são genuinamente uma solução moderna e inovadora para simultaneidade, mas a maioria parece apenas novas maneiras de fazer o que os codificadores UNIX estavam fazendo há muito tempo.

Só para dizer, eu não sou um fanboy do UNIX, nem por qualquer imaginação. Estou ciente de que os processos são muito mais lentos do que os threads para inicializar em muitas plataformas, mas estou falando sobre isso de uma base conceitual.


Não é uma pergunta ruim, mas seu problema é: "Acho que há espaço para [...] conversas".

Acrescentei que por isso não foi fechado imediatamente como sendo subjetiva / opinativo :) Eu estou realmente interessado em ouvir os pensamentos das pessoas sobre isso ...

boa pergunta. Acho que você está perdendo um público maior para a pergunta, deixando de fora uma tag de linguagem de programação (embora eu entenda por que você faz isso). Você pode obter algum feedback adicional incluindo uma tag como desempenho, teste ou marca de nível. Pode haver outras tags que não conheço que ampliariam suas respostas (alguém?). Boa sorte!
shellter 17/07/11

eu recomendaria remover a tag unix, pois sua pergunta claramente não está restrita ao domínio unix. muitas pessoas têm sistemas operacionais específicos em suas etiquetas de ignição (como eu no OS-X).
Bernd Elkemann 17/07/11

Eu acho que é mais provável que abstrações de simultaneidade são "emulando" (mais precisamente, são baseados em) Comunicação processos seqüenciais teoria
mosquito

Respostas:


1

Boa observação, há definitivamente uma tendência para o compartilhamento explícito (seja através de linguagens funcionais ou convenções). O comentário sobre os processos serem mais lentos eu me adaptaria um pouco: eles são mais pesados , o que significa que não são mais lentos na execução do desempenho bruto, mas cada alternância entre eles leva muito mais tempo do que a alternância entre threads. Você já reconheceu que existem outras formas de simultaneidade e reconhece o STM . Gostaria apenas de acrescentar que existe (além do compartilhamento explícito e do STM) também uma tendência crescente para o pool de threads (tarefa paralela; atribua tarefas a threads de trabalho que foram iniciadas anteriormente e recicle-as): Definitivamente, o caminho a seguir em termos de desempenho e, curiosamente, uma abordagem diferente ao compartilhamento explícito, porque os threads em pool geralmente estão em um único processo.


Alterei a linha de desempenho para se adequar ao que você disse. Curiosamente, às vezes eu uso ProcessPool em Python, que é como um pool de threads, exceto que é um pool de processos, não threads. Mesmo no Windows, parece funcionar sem problemas. Então, novamente, eu não tenho exatamente esticado demais. Imagino que os pools de processos sejam uma maneira elegante de fazer simultaneidade em idiomas com tempos de execução que não têm a menor esperança de serem multithread tão cedo ( tosse GIL tosse ).

É estranho que um pool de threads geralmente use um processo - eu pensaria que eles o dividiriam em tantos processos quantos os núcleos da CPU.

1
@ Louis: cada thread pode ser executado em um núcleo diferente.
Ninjalj 17/07

@ninjalj: Desculpe, um momento de morte cerebral de mim lá. Acho que ainda pensava inconscientemente nos pools de processos.

Dado que esta resposta fornece toneladas de informações, vou marcá-las como aceitas. Afirmando uma resposta é 'aceita' em um contexto subjetivo se sente um pouco estranho, mas eu sinto que é justificado :)

2

Eu acho que é menos uma questão de X emular Y, do que tentar encontrar um equilíbrio.

Processos completamente separados mantêm a vida relativamente simples. Eles facilitam bastante a criação de coisas como pipelines de processos que tiram pelo menos alguma vantagem de vários processadores. No entanto, existem algumas desvantagens bastante óbvias - particularmente falta de flexibilidade e um pouco de sobrecarga.

Um único processo com vários encadeamentos de execução compartilhando essencialmente todos os recursos basicamente os reverte: menor sobrecarga e muita flexibilidade, à custa de ser mais difícil projetar e / ou manter-se estável.

Na maioria das vezes, o que está acontecendo é que as pessoas estão trabalhando para encontrar um meio termo que ofereça quase a flexibilidade e a velocidade dos encadeamentos, com um design mais simples e um resultado mais estável de processos separados (e, acho que eles estão conseguindo, em grande parte, pelo menos algum grau).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.