Prof.

Luiz Fernando Bi1encourt IC - UNICAMP

MC714
Sistemas Distribuídos
1° semestre, 2017
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Troca de mensagem, memória

compartilhada, PRAM, LogP
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Memória compartilhada
•  Paradigmas de programação para sistemas paralelos tem
uma forte correspondência com políMcas de acesso à
memória em mulMprocessadores.
•  Diferença fundamental: uso de memória comparMlhada
ou programação usando troca de mensagens.
•  Memória comparMlhada: cada processador tem acesso
total à memória comparMlhada; comunicação entre
processos se dá através da memória (acesso
concorrente necessita sincronização explícita).
•  Troca de mensagens: comunicação entre
processadores feita de forma explícita através de
comandos send e receive.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Memória compartilhada
•  Tem espaço de endereçamento comum no sistema.
•  Comunicação através de variáveis comparMlhadas.
•  Variáveis de controle para sincronização entre processos (p.ex.
semáforos e monitores).
•  Paradigma de programação (memória comparMlhada ou troca de
mensagem) nem sempre corresponde à organização de memória do
sistema alvo.
•  Troca de mensagem pode ser usada tanto em arquiteturas de memória
comparMlhada quanto de troca de mensagens.
•  Em memória comparMlhada, uma troca de mensagem pode ser
implementada como uma simples cópia de memória.
•  Memória comparMlhada distribuída pode ser emulada através de uma
camada de so]ware adicional em arquitetura de troca de mensagens.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Modelos PRAM e LogP

•  Modelos para projeto e análise de complexidade de
algoritmos paralelos.
•  Descrever/projetar algoritmos independente da máquina
uMlizada
•  Modelos que abstraem detalhes
•  Foco em aspectos importantes
•  Esconde detalhes “desnecessários”

•  Modelos podem ser simulados

Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Modelos PRAM e LogP

•  PRAM – Parallel Random Access Machine
•  Máquina ideal com memória centralizada e comparMlhada,
processadores síncronos.
•  Acesso a uma célula: admite modelar acesso exclusivo ou
concorrente.
•  Células diferentes podem ser acessadas concorrentemente.
•  Simples, porém não considera custos de comunicação
entre processadores.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Modelos PRAM e LogP

•  Modelo PRAM irreal, especialmente em sistemas distribuídos,
devido à suposição de comunicação sem custo entre
processadores.
•  LogP
•  Considera custo de comunicação entre processadores.
•  L: limite superior no atraso em uma troca de mensagem.
•  o: overhead – tempo que um processador gasta enviando ou
recebendo uma mensagem, durante o qual não efetua outra operação.
•  g: Gap – tempo mínimo entre transmissões ou recepções consecuMvas
de mensagens (1/BW). ⇠ ⇡
L
•  Limita número de mensagens simultâneas a
g
•  Modelo assíncrono.
•  Fig 13 + exemplo
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Modelos PRAM e LogP

•  Sugestão de melhoria no desempenho do exemplo?
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Acoplamento, paralelismo,
concorrência e granularidade
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Acoplamento
•  Grau de acoplamento (hardware ou so]ware):
interdependência e “amarração” e/ou homogeneidade
entre módulos.
•  Fortemente acoplados (SIMD, MISD / relógio comum)
ou fracamente acoplados.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Acoplamento
•  Ex MIMD:
•  MulMprocessadores fortemente acoplados (com memória
comparMlhada Uniform Memory Access). Bus (Sequent, Encore) ou
switch (NYU)
•  MulMprocessadores/computadores fortemente acoplados (com
memória comparMlhada Non-Uniform Memory Access – SGI Origin
2000, Sun Ultra HPC – ou troca de mensagens – hipercubo, torus).
•  MulMcomputadores (sem memória comparMlhada ou relógio
comum) fracamente acoplados fisicamente próximos. Bus (NOW +
LAN ou Myrinet), ou usando uma rede genérica, processadores
podem ser heterogêneos. Sistema distribuído (sem memória
comparMlhada ou relógio comum) com caracterísMca de sistema
paralelo (processadores próximos). Abordagens diferentes de redes
de longa distância.
•  MulMcomputadores fracamente acoplados, fisicamente distantes.
Noção convencional de sistemas distribuídos.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo / speedup em um
sistema especíAico
•  Speedup relaMvo de um programa em uma dada
máquina específica.
•  Depende do número de processadores e
mapeamento do código nesses processadores.
•  Razão entre o tempo de execução T(1) em um
único processador e tempo T(n) com n
processadores.
 Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo em um programa
paralelo/distribuído
•  Medida agregada da porcentagem de tempo que
todos os processadores estão executando instruções
de CPU ao invés de aguardar comunicação, seja por
memória comparMlhada ou troca de mensagens.
•  Se a medida agregada é somente em função do
código, paralelismo é independente de arquitetura.
•  Caso contrário, definição de paralelismo se
assemelha à de speedup.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Concorrência de um programa
•  Termo mais amplo
•  Usado no contexto de sistemas distribuídos
•  Razão entre o número de operações locais (sem
comunicação / memória comparMlhada) e o
número total de operações.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Paralelismo: condição que aparece quando pelo menos duas
threads estão executando simultaneamente.
•  Concorrência: condição existente quando pelo menos duas
threads estão progredindo.
•  Paralelismo: programação para execução de computação
simultânea (possivelmente relacionada).
•  Concorrência: programação como composição de processos
(no termo amplo) executando independentemente.
•  Paralelismo: quando tarefas executam ao mesmo tempo.
•  Concorrência: quando tarefas podem começar, executar, e
terminar em intervalos de tempo sobrepostos. Não significa
necessariamente que executarão ao mesmo tempo (e.g.,
mul4tasking em processadores de núcleo único).
 Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Problema: mover uma pilha de manuais de linguagens obsoletas
para uma fornalha.

•  Apenas 1 roedor demora muito.

•  h1p://concur.rspace.googlecode.com/hg/talk/concur.html
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Mais roedores.

•  Não ajuda, precisamos de mais carrinhos.

Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Mais roedores e mais carrinhos.

•  Mais rápido, mas há gargalos na pilha e na fornalha.

•  Necessidade de sincronizar os roedores: uma mensagem
(comunicação entre roedores) pode resolver.

Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Dobrar tudo

•  Remover gargalo, tornando-os independentes.

•  Consome entrada duas vezes mais rápido.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Projeto não é automaMcamente paralelo.
•  E se somente um roedor move-se em um dado instante de
tempo?
•  ConMnua sendo concorrente (i.e., o projeto), mas não
paralelo.
•  Entretanto, é automaMcamente paralelizável.
•  Essa composição concorrente habilita outros modelos.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Outro projeto.

•  Três roedores em ação, mas provavelmente com atrasos.

•  Cada roedores é um procedimento independente, mais a
coordenação (comunicação).
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Adicionar novo roedor para carregar os carrinhos vazios.

•  Organizando tudo corretamente (não trivial), é quatro vezes
mais rápido que o projeto original de 1 roedor.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Quatro procedimentos disMntos:
•  Carregar manuais no carrinho
•  Mover carrinho até a fornalha
•  Descarregar carrinho na fornalha
•  Retornar o carrinho vazio

•  Diferentes projetos concorrentes permitem diferentes

maneiras de paralelização.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Mais paralelização:
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Ou nenhuma paralelização (se cada um trabalha em determinado
intervalo de tempo diferente dos outros), mas conMnua sendo uma
solução concorrente.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Outro projeto
•  Pilha adicional
•  100 pilhas: melhora?
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Paralelizando da maneira usual
•  Executar mais procedimentos concorrentes para aumentar vazão
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Ou ainda...
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Usando todas as técnicas: 16 roedores trabalhando.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Paralelismo vs. Concorrência

•  Existem muitas formas de quebrar um processo em pedaços
menores: projeto concorrente.
•  Paralelização pode ser implementada de forma que sua
corretude é “fácil”.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Granularidade de um programa
•  Razão entre quanMdade de computação e quanMdade de
comunicação do programa paralelo/concorrente.
•  Consequência da forma de quebrar o programa: grãos de
computação menores podem ter mais comunicação.
•  Granularidade alta (baixa): relaMvamente mais (menos)
instruções produMvas de CPU comparadas ao número de
vezes que os processadores comunicam-se.
•  Baixa granularidade: se encaixa melhor em sistemas
fortemente acoplados.
•  Latência pode degradar vazão.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas de troca de mensagem

versus sistemas de memória
compartilhada
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Troca de mensagens e
memória compartilhada
•  Sistemas de memória comparMlhada: espaço de endereço
comum comparMlhado no sistema.
•  Comunicação se dá através de variáveis comparMlhadas
•  Variáveis de controle para sincronização entre processadores
(semáforos, monitores).
•  Sistemas de mulMcomputadores que não têm espaço de
endereçamento comum fornecido pela arquitetura/hardware
necessariamente comunicam-se por troca de mensagens.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Troca de mensagens e
memória compartilhada
•  Conceitualmente mais fácil programar/depurar memória
comparMlhada que troca de mensagens.
•  A abstração chamada “memória comparMlhada” é algumas
vezes uMlizada para simular um espaço de endereçamento
comum.
•  Em sistema distribuído: memória comparMlhada distribuída.
•  Implementá-la tem certo custo, mas simplifica tarefa de
programação.
•  Comunicação por troca de mensagem pode ser simulada por
comunicação via memória comparMlhada (e vice-versa).
•  Os dois paradigmas são equivalentes.
 Prof. Luiz Fernando Bi1encourt IC - UNICAMP

TM à MC
•  Emular troca de mensagem em sistema de memória
comparMlhada (TM à MC).
•  Espaço de endereçamento comparMlhado pode ser
parMcionado em conjuntos disjuntos, com uma parte para
cada processador.
•  Operações send e receive podem ser implementadas pela
escrita e leitura do espaço de endereçamento do
desMnatário/remetente.
•  Especificamente, um espaço separado pode ser reservado
como “caixa de correio”.
•  Uma troca de mensagem Pi-Pj pode ser emulada por uma
escrita de Pi na caixa de correio, e então uma leitura de Pj.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

TM à MC
•  No caso mais simples, assume-se que essas caixas de
correio têm tamanho ilimitado.
•  As operação de escrita/leitura precisam ser controladas
uMlizando primiMvas de sincronização para informar
desMnatário/remetente após o envio/recebimento dos
dados.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

MC à TM
•  Emular memória comparMlhada em sistema de troca de
mensagem (MC à TM).
•  Envolve o uso de operações de send e receive para realizar
operações de escrita e leitura.
•  Cada local comparMlhado pode ser modelado como um
processo separado.
•  A escrita em um local comparMlhado é emulada pelo envio
de uma mensagem de atualização para o processo dono
daquele espaço.
•  A leitura de um local comparMlhado é emulada pelo envio
de uma mensagem de query para o dono do processo.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

MC à TM
•  Acessar memória de outro processador é caro (requer
send/receive).
•  Emular memória comparMlhada pode ser atraente do
ponto de vista do programador, mas deve ser
considerado que é apenas uma abstração em sistemas
distribuídos.
•  Latências envolvidas nas operações de leitura/escrita
podem ser altas mesmo usando emulação de memória
comparMlhada, pois, por baixo dos panos, ocorre
comunicação através de uma rede.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Troca de mensagens e
memória compartilhada
•  Aplicações podem combinar memória comparMlhada e troca de
mensagens.
•  Em um mulMcomputador MIMD, cada “processador” pode ser
por si só um sistema mulMprocessado fortemente acoplado com
memória comparMlhada.
•  No sistema mulMprocessado, processadores comunicam-se via
memória comparMlhada.
•  No sistema de mulMcomputadores, comunicam-se via troca de
mensagens.

•  Sistemas de troca de mensagem são mais comuns e mais

adequados para sistemas distribuídos amplos, e portanto mais
extensivamente estudados em sistemas distribuídos.