um estudo sobre memória compartilhada distribuída · projeto do treadmarks teve como objetivo...

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SULINSTITUTO DE INFORMÁTICA

PROGRAMA DE PÓS-GRADUAÇÃO EM COMPUTAÇÃO

Um Estudo sobreMemór ia Compartilhada Distr ibuída

porEDVAR BERGMANN ARAUJO

T.I. 868 PPGC – UFRGS

Trabalho Individual I

Prof. Dr. Cláudio Fernando Resin GeyerOrientador

Porto Alegre, agosto de 1999

CIP – Catalogação na Publicação

Araujo, Edvar BergmannUm Estudo sobre Memória Compartilhada Distribuída / por

Edvar Bergmann Araujo – Porto Alegre: PPGC da UFRGS, 1999.59f.:il . – (TI – 868)

Trabalho orientado pelo Prof. Cláudio Fernando Resin Geyer.

1. Memória compartilhada distribuída. 2. Sistemas distribuídos.I. Geyer, Cláudio Fernando Resin. II. Título.

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

Reitora: Profa. Wrana Panizzi

Pró-Reitor de Pós-graduação: Prof. Franz Rainer Semmelmann

Diretor do instituto de Informática: Prof. Phili ppe Olivier Alexandre Navaux

Coordenadora do PPGC: Profa. Carla Freitas

Bibliotecária-Chefe do Instituto de Informática: Beatriz Haro

Sumár io

Lista de Figuras _______________________________________________________5

Lista de Tabelas _______________________________________________________6

Lista de Abreviaturas___________________________________________________7

Resumo ______________________________________________________________8

Abstract______________________________________________________________9

1 Introdução_________________________________________________________10

1.1 Tema__________________________________________________________10

1.2 Motivação______________________________________________________10

1.3 Objetivos ______________________________________________________11

1.4 Estrutura do Texto ______________________________________________12

2 Memória Compartilhada Distribuída____________________________________13

2.1 Introdução _____________________________________________________13

2.2 Estrutura Geral de Sistemas DSM _________________________________ 13

2.3 Estrutura dos Dados Compartilhados_______________________________14

2.4 Distr ibuição e Coerência dos Dados Compartilhados__________________15

2.5 Funcionamento _________________________________________________16

2.6 Algor itmos _____________________________________________________172.6.1 Algoritmos Único Leitor / Único Escritor (SRSW)___________________182.6.2 Algoritmos Vários Leitores / Único Escritor (MRSW) ________________182.6.3 Algoritmos Vários Leitores / Vários Escritores (MRMW) _____________18

2.7 Responsabil idade do Gerenciamento de DSM ________________________19

2.8 Modelos de Consistência de Memór ia_______________________________192.8.1 Consistência Seqüencial ________________________________________202.8.2 Consistência de Processador ____________________________________212.8.3 Consistência Fraca____________________________________________212.8.4 Consistência de Liberação ______________________________________222.8.5 Consistência de Liberação Preguiçosa_____________________________232.8.6 Consistência de Entrada________________________________________24

2.9 Nível de Implementação do Mecanismo de DSM ______________________252.9.1 Software____________________________________________________252.9.2 Hardware ___________________________________________________26

2.10 Considerações Finais____________________________________________28

3 Orca ______________________________________________________________29

3.1 Modelo de Programação__________________________________________29

3.2 Arquitetura do Sistema___________________________________________30

3.3 Características do Orca __________________________________________313.3.1 Protocolo de Coerência ________________________________________31

3.3.2 Estratégia de Disposição dos Objetos _____________________________333.3.3 Portabili dade ________________________________________________333.3.4 Arquitetura do Software________________________________________34

4 TreadMarks________________________________________________________35


4.2 Protocolo de Múltiplos Escritores __________________________________ 36

4.3 Consistência de Memór ia _________________________________________37

5 Calypso____________________________________________________________40


5.2 Características do Calypso________________________________________40

5.3 Funcionamento do Sistema________________________________________42

6 Milli pede __________________________________________________________46

6.1 Arquitetura do Sistema___________________________________________46


6.3 Características do Milli pede_______________________________________486.3.1 Balanceamento de Carga _______________________________________486.3.2 Gerente de Memória Distribuído_________________________________ 48

6.4 Memór ia Compartilhada Distr ibuída_______________________________49

6.5 Interação entre Jobs Móveis_______________________________________50

7 Comparação________________________________________________________52


7.2 Sistema de Execução_____________________________________________54

8 Conclusão _________________________________________________________56

Bibliografia__________________________________________________________57

5

Lista de Figuras

FIGURA 2.1 – Estrutura geral de um sistema DSM___________________________14FIGURA 2.2 – Exemplo de funcionamento__________________________________ 17FIGURA 2.3 – Segmentos de código de P0 e P1 que compartilham A e B __________20FIGURA 2.4 – Utili zação de sincronização para garantir coerência de A e B ______22FIGURA 2.5 – Ordem parcial estabelecida pelas operações de sincronização______23FIGURA 3.1 – Camadas do Orca_________________________________________30FIGURA 4.1 – Criação de diff ___________________________________________37FIGURA 4.2 – Release vs Lazy Release Consistency__________________________38FIGURA 4.3 – Exemplo de dominância de intervalos _________________________39FIGURA 5.1 – Etapas da execução _______________________________________42FIGURA 5.2 – Funcionamento da etapa paralela ____________________________43FIGURA 6.1 – Estrutura de camadas do Milli pede ___________________________46FIGURA 6.2 – Interface de programação com o Milli pede_____________________47

6

Lista de Tabelas

TABELA 3.1 – Aspectos importantes no projeto do sistema Orca ________________31TABELA 5.1 – Tabela de progresso _______________________________________44TABELA 7.1 – Comparação entre os sistemas_______________________________55

7

Lista de Abreviaturas

API Application Programming Interface

ATM Asynchronous Transfer Mode

CC-NUMA Cache Coherent NoUniform Memory Architectures

COMA Cache-Only Memory Architectures

CPU Central Processing Unit

CSL Calypso Source Language

DSM Distributed Shared Memory

EC Entry Consistency

FIFO First-In-First-Out

LAN Local Area Network

LRC Lazy Release Consistency

MGS M iGration Service

MJEC M illi pede Job Event Control

MRMW Multiple Reader / Multiple Writer

MRSW Multiple Reader / Single Writer

PC Processor Consistency

RC Release Consistency

RMS Reflective Memory Systems

RPC Remote Procedure Call

RTS Run-Time System

SC Sequential Consistency

SMP Symetric Multi -Processor

SRSW Single Reader / Single Writer

VPM Virtual Parallel Machine

WC Weak Consistency

8

Resumo

Este trabalho apresenta um estudo sobre memória compartilhada distribuída(DSM - Distributed Shared Memory). Um sistema DSM oferece a abstração de um es-paço de endereçamento lógico, a que todos os processadores de uma arquitetura distri-buída têm acesso, apesar de, fisicamente, a memória ser local a cada um deles. Imple-mentado tanto em software como em hardware, os sistemas DSM controlam a distribui-ção física dos dados, oferecendo ao programador acesso transparente à memória virtualcompartilhada. O trabalho realiza também uma análise sobre quatro sistemas DSM im-plementados a nível de software.

Orca é uma linguagem para implementação de aplicações concorrentes emsistemas de memória distribuída. Caracteriza-se por permitir que processos em diferen-tes máquinas compartilhem dados, sendo estes dados encapsulados em objetos de dados.O sistema de execução do Orca gerencia a distribuição dos objetos entre as memóriaslocais dos processadores, fornecendo uma memória compartilhada distribuída estrutura-da.

TreadMarks é um software que permite programação concorrente com me-mória compartilhada em arquiteturas de memória distribuída. Caracteriza-se por execu-tar a nível de usuário em redes de estações de trabalho com sistema operacional Unix. Oprojeto do TreadMarks teve como objetivo reduzir a quantidade de comunicação neces-sária para manter a consistência de memória. Para isto utili za um protocolo de múltiplosescritores e o modelo de consistência de liberação preguiçosa.

Calypso é o protótipo de um sistema para escrever e executar programas pa-ralelos em plataformas não dedicadas, utili zando redes de estações de trabalho comerci-ais, sistemas operacionais e compiladores disponíveis. Calypso implementa característi-cas de tolerância à falhas, balanceamento de carga, e utili za modelo de programaçãobaseado em memória compartilhada.

Milli pede é um sistema que integra os recursos e serviços de arquiteturasdistribuídas em uma máquina virtual paralela. Milli pede é uma camada de software paraprogramação utili zando memória compartilhada para arquiteturas de memória distribuí-da. Implementa características como memória compartilhada distribuída, balanceamentodinâmico de carga, suporte para gerência de tarefas e vários métodos embutidos paraotimizar a localidade das referências de memória.

Palavras-chave: memória compartilhada distribuída, sistemas distribuídos.

9

Abstract

This work presents a study on Distributed Shared Memory (DSM). Asystem DSM offers the abstraction of a logical address space, which all the processorsof a distributed architecture have access, in spite of, physically, the memory to be localto each one of them. Implemented so much in software as in hardware, the DSMsystems controls the physical distribution of the data, offering to the programmertransparent access to the shared virtual memory. This work also presents an analysis offour software DSM systems.

Orca is a language for implementing concurrent applications in distributedmemory systems. It is characterized by allowing that processes in different machinesshare data, being these data encapsulated in objects of data. The Orca’s runtime systemmanagement the distribution of the objects among the local memories of the processors,supplying a structured distributed shared memory.

TreadMarks is a software that allows concurrent programming with sharedmemory in architectures of distributed memory. It is characterized by executing user'slevel in network of workstations with operating system Unix. The project ofTreadMarks had as objective to reduce the amount of necessary communication tomaintain the consistency of memory. For this it uses a protocol of multiple writers andthe lazy release consistency model.

Calypso is a prototype software system for writing and executing parallelprograms on non-dedicated platforms, using commercial network of workstations,operating systems, and compilers. Calypso implements characteristics li ke faulttolerance, load balancing, and it uses programming model based on shared memory.

Milli pede is a system that integrates the resources and services of distributedcomputational environments into virtual parallel machines. Milli pede is a software layerfor programming using shared memory for distributed memory architectures. Itimplements characteristics as distributed shared memory, load balancing , support formanagement of tasks and several built -in methods for otimizing the locali ty of thememory references.

Keywords: distributed shared memory, distributed systems

10

1 Introdução

1.1 Tema

O tema deste trabalho é o estudo das características de sistemas de MemóriaCompartilhada Distribuída (DSM – Distributed Shared Memory), e de algumas propos-tas de mecanismos de DSM implementados por software.

1.2 Motivação

As tecnologias de microeletrônica têm permitido uma melhora substancialna velocidade de processamento, mas sempre dentro de limites físicos bem estabeleci-dos. As redes de alta velocidade permitem a conexão de dezenas ou até centenas de má-quinas, com altas taxas de transferência. O resultado da aplicação destas duas tecnologi-as é o fato de hoje ser simples construir sistemas de computação compostos por umgrande número de processadores interligados através de redes de alta velocidade. Por-tanto, a exploração do processamento paralelo e distribuído é uma das formas de ampli-ar os limites de desempenho dos sistemas computacionais [ARA 98].

Nos multiprocessadores (memória compartilhada) duas ou mais CPU’scompartilham uma memória principal comum. Qualquer processo ou processador podeler ou escrever qualquer palavra na memória compartilhada. Ao contrário, nos multi-computadores (memória distribuída) cada CPU tem sua própria memória privada, sendoque a comunicação entre as máquinas é realizada por conexão via rede [TAN 95].

O projeto de máquinas nas quais vários processadores utili zam a mesmamemória física simultaneamente não é uma tarefa trivial, sendo que pode tornar-se bas-tante complexa dependendo do número de processadores. Esta característica limita aescalabili dade deste tipo de arquitetura. Por outro lado, grandes multicomputadores sãosimples de construir [TAN 95].

No que diz respeito ao software paralelo, em geral, o programador devepreocupar-se em estabelecer a interação entre os processos paralelos. Os dois principaisparadigmas de programação paralela são troca de mensagens e memória comparti-lhada.

A programação no paradigma de memória compartilhada é consideradamais simples, pois evita que o programador preocupe-se com a comunicação entre pro-cessos, através de troca explícita de mensagens. Para realizar comunicação, um processoapenas escreve dados na memória para serem lidos por todos os outros. Para sincroniza-ção, seções críticas podem ser usadas, com a utili zação de semáforos ou monitores paragarantir exclusão mútua.

No paradigma de troca de mensagens a comunicação é realizada através deprimitivas que explicitamente controlam o deslocamento dos dados. Troca de mensa-gens apresenta várias dificuldades, entre elas controle de fluxo, mensagens perdidas,controle do buffer (buffering) e bloqueio (blocking). Embora várias soluções tenhamsido propostas, programação com troca de mensagens permanece complicada.

11

Em resumo, multicomputadores são simples de construir mas difíceis deprogramar, sendo os multiprocessadores o oposto, difíceis de construir mas simples deprogramar [TAN 95].

Nos últimos anos tem crescido o interesse por sistemas de memória com-partilhada distribuída. Estes sistemas permitem a integração da escalabili dade de memó-ria distribuída com a maior facili dade de programação de memória compartilhada[AMO 96].

Um sistema DSM oferece a abstração de um espaço de endereçamento lógi-co, a que todos os processadores de uma arquitetura distribuída têm acesso, apesar de,fisicamente, a memória ser local a cada um deles. Implementado tanto em softwarecomo em hardware, os sistemas DSM controlam a distribuição física dos dados, ofere-cendo ao programador acesso transparente a memória virtual compartilhada [ARA 96].Portanto, o objetivo principal dos mecanismos de DSM é ocultar a comunicação doprogramador e fornecer um modelo de programação baseado em dados compartilhadosao invés de troca de mensagens. Além disso, aproveitam a escalabili dade e a relaçãocusto/eficiência inerentes aos sistemas de memória distribuída.

A adoção da abstração de memória compartilhada em arquiteturas distribuí-das implica: localizar e acessar os dados compartilhados; migrar e/ou replicar os dados;manter a consistência dos dados entre os nodos da rede [MAR 96]. Estas característicasdevem ser implementadas pelo ambiente de execução que fornece a abstração de DSM.Portanto, simpli fica a programação de tarefas tais como particionamento de dados edistribuição dinâmica de carga.

Os sistemas DSM permitem que aplicações desenvolvidas para sistemas dememória compartilhada possam ser modificadas de forma relativamente fácil para exe-cutarem em memória distribuída, preservando os investimentos em software. Entretan-to, deve ser observado que nos sistemas DSM a latência de acesso aos dados é maior.

A característica dos modelos DSM de fornecer uma interface transparente eum ambiente de programação conveniente para aplicações paralelas e distribuídas temfeito o assunto foco de numerosas pesquisas nos últimos anos. Atualmente, as pesquisasrealizadas nesta área estão voltadas para o desenvolvimento de propostas para minimi-zar o tempo de acesso aos dados compartilhados enquanto mantém a consistência entreeles.

1.3 Objetivos

O objetivo geral deste trabalho consiste no estudo de características de sis-temas DSM.

Como objetivos específicos podem ser destacados:

1 – Apresentar as características de sistemas DSM;

2 – Estudar propostas de implementação de DSM;

3 – Apresentar algumas das propostas estudadas;

4 – Realizar uma comparação entre as propostas;

5 – Criar um texto com os resultados do trabalho.

12

1.4 Estrutura do Texto

O capítulo dois introduz as características e os conceitos de sistemas dememória compartilhada distribuída, dentre as quais a estrutura geral do sistema, manu-tenção da coerência dos dados, modelos de consistência de memória, nível de imple-mentação do mecanismo. Muitas implementações de DSM têm sido descritas na litera-tura [PRO 98]. Entretanto, a maioria delas não é muito utili zada por executarem emplataformas dedicadas, ao invés de executarem nas arquiteturas e nos sistemas operaci-onais disponíveis. Os capítulos seguintes abordam quatro sistemas DSM implementadosem software que não exigem hardware adicional nem modificações no sistema operaci-onal. Os modelos são o Orca (capítulo três), o TreadMarks (capítulo quatro), o Calypso(capítulo cinco) e o Milli pede (capítulo seis). No capítulo sete, uma breve comparaçãoentre os modelos é apresentada. Finalmente, o capítulo oito conclui o trabalho.

13

2 Memór ia Compar tilhada Distr ibuída

Este capítulo apresenta conceitos de memória compartilhada distribuída. Oobjetivo é estabelecer de forma resumida aspectos importantes de sistemas DSM. Estesconceitos estão organizados de forma a introduzir gradativamente o assunto.

2.1 Introdução

No começo da utili zação dos sistemas distribuídos, assumia-se implicita-mente que processos em máquinas com memória distribuída executavam em espaços deendereçamento disjuntos, sendo a comunicação entre eles vista em termos de troca demensagens. Em 1986, Kai Li [LI 86] propôs um esquema diferente, agora conhecidopor Distributed Shared Memory (DSM). Resumindo, Li e Hudak propuseram uma co-leção de estações de trabalho conectadas por uma LAN (Local Area Network) compar-tilhando um espaço de endereçamento virtual único [LI 89].

Na variação mais simples, cada página está presente exatamente em umamáquina. Qualquer processador pode acessar diretamente qualquer posição do espaçode endereçamento virtual compartilhado. Os gerenciadores de memória do mecanismode DSM implementam o mapeamento entre a memória local e este espaço de endereça-mento. Para estes gerenciadores, a memória local de um processador é consideradacomo uma grande cache do espaço de endereçamento compartilhado.

Referências à páginas locais são resolvidas por hardware, na velocidade damemória, enquanto que, referências à páginas presentes em outras máquinas causamfalha de página (page fault). Então, o sistema DSM responsabili za-se por mandar umamensagem para a máquina remota, a qual encontra a página necessária e a envia para oprocessador destino. Essencialmente, esta proposta é similar ao tradicional sistema dememória virtual, com a diferença de ao invés de buscar as páginas no disco, buscá-lasem outra máquina da rede. Toda comunicação e sincronização pode ser feita através damemória, sem comunicação visível para os processos de usuário.

Memória compartilhada distribuída pode ser intimamente relacionada comarquitetura de computadores, sistemas operacionais, ambientes de execução e lingua-gens de programação.

2.2 Estrutura Geral de Sistemas DSM

A organização básica de um sistema DSM é similar a de um multicomputa-dor que utili za troca de mensagens. Geralmente envolve um conjunto de nodos ou clus-ters conectados por uma rede de interconexão escalável (figura 2.1). Cada cluster podeser um sistema uniprocessador ou multiprocessador, e deve conter um módulo local dememória física, o qual pertence em parte ou inteiramente ao espaço de endereçamentoglobal de DSM. Cada cluster precisa ter também um controlador específico de interco-nexão para interligá-lo ao restante do sistema.

14

FIGURA 2.1 – Estrutura geral de um sistema DSM

O modelo da rede de interconexão é tão importante para estes sistemascomo é para os sistemas que utili zam troca de mensagens. Redes de interconexão devemoferecer uma pequena latência e uma alta banda passante a um custo razoável. Esta re-lação de desempenho por custo depende do número de nodos do sistema. Em sistemascom poucos nodos (poucas dezenas), barramentos e anéis têm sido escolhidos por causado seu baixo custo. Em sistemas com 100 nodos, outras soluções com maior banda pas-sante são necessárias. Devido aos sistemas DSM permitirem centenas de nodos, as redesde interconexão normalmente trocam a complexidade do modelo por maiores latências,limitando a conectividade apenas a poucos nodos adjacentes. No caso de não usar ne-nhum esquema especial de modelo de interconexão, alternativas atrativas com custorazoável também incluem tecnologias LAN, tais como Ethernet e ATM. Estes modelossão bastante utili zados, já que geralmente os sistemas DSM são construídos aproveitan-do as redes de estações de trabalhos ou computadores pessoais em funcionamento [MIL99].

Um dos maiores problemas dos sistemas DSM é o overhead associado àbusca dos dados remotos (latência de memór ia) [PIN 96]. Latência de memória dizrespeito ao intervalo de tempo compreendido entre o momento no qual um processadoriniciou um acesso a um dado compartilhado até que este acesso seja satisfeito. O pro-blema da latência de memória é inerente aos sistemas DSM por causa do grandeoverhead para localização e acesso aos dados em sistemas com memória fisicamentedistribuída. Por este motivo, a rede de interconexão tem influência direta no desempe-nho de sistemas DSM.

2.3 Estrutura dos Dados Compar tilhados

A estrutura dos dados representa a disposição global do espaço de endere-çamento compartilhado, bem como a organização dos dados neste espaço. Estes dadospodem estar organizados de diferentes maneiras. Na variação mais simples, o espaço deendereçamento é dividido em páginas, sendo que cada página está presente na memóriade uma máquina.

Outra proposta é não compartilhar todo o espaço de endereçamento, massomente uma parte dele, apenas aquelas variáveis ou estruturas de dados que precisam

15

ser usadas por mais de um processo. Esta técnica reduz a quantidade de dados que de-vem ser compartilhados.

É possível estruturar ainda mais o espaço de endereçamento. Ao invés deapenas compartilhar variáveis, pode-se encapsular tipos de dados, chamados objetos.Esta proposta difere da proposta de variáveis compartilhadas no ponto em que, cadaobjeto não possui apenas dados, mas também procedimentos (métodos), que atuam so-bre os dados. Processos podem manipular os dados do objeto apenas invocando seusmétodos. Não é permitido acessar diretamente os dados. Restringindo o acesso destaforma, novas otimizações tornam-se possíveis.

Os sistemas DSM dividem o espaço global de endereçamento compartilhadoem blocos, para que os dados compartilhados possam ser manipulados pelo sistema deforma mais eficaz. Esse bloco de dados que é manipulado pelo sistema de DSM é cha-mado de unidade de coerência. Dependendo da estrutura dos dados que fazem parte doespaço de endereçamento compartilhado, este espaço pode ser dividido de diferentesformas. No caso de um sistema DSM no qual o espaço de endereçamento compartilhadoé organizado em páginas, a unidade de coerência é a página. No caso de sistemas DSMbaseados em objetos, a unidade de coerência é o objeto.

A granulosidade da unidade de coerência determina o tamanho do bloco dedados manipulado pelo mecanismo de DSM. Em geral, sistemas de hardware utili zamunidades pequenas (tipicamente blocos de cache), enquanto que soluções de software,baseados em mecanismos de memória virtual, organizam os dados em grandes blocosfísicos (páginas), o que acarreta em compartilhamento de grandes grãos. O uso de gran-des blocos aumenta a probabili dade de que vários processadores irão requisitar acessoao mesmo bloco simultaneamente, mesmo que eles realmente acessem partes indepen-dentes do bloco de dados. Este fenômeno é conhecido como falso compartilhamento(false sharing).

2.4 Distr ibuição e Coerência dos Dados Compar tilhados

Duas estratégias utili zadas para distribuição dos dados compartilhados sãoreplicação e migração. Replicação permite que várias cópias do mesmo item de dadoresidam em diferentes memórias locais. É utili zado principalmente para habilit ar aces-sos simultâneos de diferentes nodos ao mesmo dado, predominantemente quando com-partilhamento de leitura prevalece. Migração implica que somente uma cópia de umitem de dado existe no sistema, portanto, os itens de dados são movidos sob demandapara uso exclusivo. Com o objetivo de diminuir o overhead de gerenciamento de coe-rência, esta estratégia é utili zada quando padrões seqüenciais de compartilhamentos deescrita prevalecem.

A maioria dos sistemas DSM optam por replicar os dados, pois esta pro-posta alcança melhor desempenho para uma grande quantidade de aplicações [STU 98].Além disso, sistemas DSM fazem uso de replicação de dados para permitir acesso con-corrente. No entanto, é fundamental manter estas cópias com a mesma informação, im-pedindo que um nodo acesse dados desatualizados. Existem duas estratégias básicaspara manutenção da coerência de réplicas:

� Protocolo de invalidação: uma escrita em um dado compartilhado cau-sa a invalidação de todas as suas cópias, que passam a inacessíveis.Neste momento, passa a existir apenas uma cópia válida no sistema.

16

Uma vez que as cópias foram invalidadas, as próximas operações de es-crita na cópia válida não irão produzir efeito algum sobre as outras cópi-as. Na próxima operação sobre uma cópia que foi invalidada, irá ocorreruma falha de acesso, sendo que uma cópia válida deverá ser buscada no-vamente para a memória local. Este protocolo é mais recomendadoquando há grande localidade de acessos aos dados por processador, poismenos mensagens de notificação serão enviadas;

� Protocolo de atualização: uma escrita em um dado compartilhado cau-sa a atualização de todas as suas cópias. Neste protocolo, em cada ope-ração de escrita em uma cópia, todas as outras cópias devem receber aatualização que foi realizada. É uma abordagem mais complicada, pois acada operação de escrita um novo valor deve ser enviado ao invés deuma mensagem de notificação. Além disso, mesmo que várias escritasconsecutivas ocorram na mesma cópia, sem a interferência de leiturasnas outras cópias, mesmo assim todas as cópias receberão todas as men-sagens de atualização. Isto costuma gerar muito tráfego na rede.

A escolha da política de coerência está relacionada com a granulosidade doda unidade de coerência. Para grãos muito pequenos, uma mensagem de atualizaçãocusta aproximadamente o mesmo que uma mensagem de invalidação. Por outro lado,sistemas com grãos grandes utili zam invalidação, sendo esta proposta eficiente quandoas seqüências de acessos de leituras e escritas ao mesmo item de dado por vários pro-cessadores são esparsas. O melhor desempenho é alcançado quando a política de coe-rência adapta-se dinamicamente à situação.

2.5 Funcionamento

Esta seção apresenta o funcionamento básico de um sistema DSM. Conside-ra-se para a explicação do funcionamento, um sistema DSM implementado em softwa-re, com página como unidade de coerência e utili zando protocolo de invalidação.

O modelo de programação de memória compartilhada permite que os aces-sos a dados sejam realizados como se todos os dados estivessem presentes na memórialocal dos nodos. Entretanto, sabe-se que nem todos os dados estão presentes localmenteem cada processador. Portanto, quando um dado não está presente na memória local doprocessador, uma falha de página ocorre. O software DSM busca um cópia atualizadada página da memória remota para a memória local e reinicia o processo. Por exemplo,a figura 2.2 mostra a atividade que ocorre como resultado de uma falha de página noprocessador 1, o qual resulta em uma cópia da página necessária sendo enviada da me-mória local do processador 3.

Dependendo da operação a ser realizada no dado compartilhado, leitura ouescrita, o procedimento do mecanismo de DSM é diferente. Com falha de leitura, a pá-gina é replicada com permissão de somente leitura para todas as réplicas. Com falha deescrita, um mensagem de invalidação é enviada para todos os processadores com cópiasda página. Cada processador que recebe esta mensagem invalida sua cópia da página eenvia uma mensagem de confirmação para o escritor. Como resultado, a cópia escrita dapágina torna-se a única cópia.

17

FIGURA 2.2 – Exemplo de funcionamento

Uma vez que as páginas foram invalidadas, em um próximo acesso de leitu-ra a página deverá ser replicada novamente, o que pode ocasionar muita comunicação.Comunicação é um problema importante em redes de estações de trabalho. Enviar umamensagem pode envolver traps no kernel do sistema operacional, interrupções, trocasde contexto e execução nas várias camadas do software de rede. Portanto, o número demensagens e a quantidade de dados trocados deve ser mantido baixo.

2.6 Algor itmos

Os algoritmos para a implementação de DSM tratam com dois problemasbásicos:

� distribuir estática ou dinamicamente os dados compartilhados através dosistema, para minimizar a latência de acesso;

� preservar a coerência dos dados compartilhados, enquanto minimiza ooverhead gerado com o gerenciamento de coerência.

Projetistas de sistema devem escolher o algoritmo de DSM que melhoradapte-se a configuração do sistema e as características de referências de memória emaplicações típicas.

18

2.6.1 Algor itmos Único Leitor / Único Escr itor (SRSW)

Esta classe de algoritmos proíbe replicação, enquanto permite, mas não re-quer migração. O algoritmo de gerenciamento de DSM mais simples é o algoritmo ser-vidor central. A proposta consiste em um único servidor central que controla todas asrequisições de acesso aos dados compartilhados, fisicamente localizados neste nodo. Talorganização implica em não distribuição dos dados compartilhados. Este algoritmo so-fre de problemas de desempenho, pois o servidor central pode tornar-se um gargalo dosistema. Uma possível modificação é a distribuição estática de responsabili dade de par-tes do espaço de endereçamento compartilhado para diferentes servidores. Funções demapeamento simples, como hashing, podem servir para localizar o servidor apropriadode um determinado dado.

Alguns algoritmos SRSW permitem migração. Entretanto, somente uma có-pia de determinado bloco de dados pode existir, sendo que esta cópia pode migrar sobdemanda. Se uma aplicação possui alta localidade na referência de dados, o custo damigração é amortizado por vários acessos. O algoritmo pode apresentar um melhor de-sempenho quando uma longa seqüência de acessos for realizada neste bloco de dadospor um processador sem que outro processador o faça. De qualquer forma, este tipo dealgoritmo é pouco utili zado devido ao seu desempenho ser normalmente baixo.

2.6.2 Algor itmos Vár ios Leitores / Único Escritor (MRSW)

A maior intenção dos algoritmos MRSW (também conhecidos por replica-ção de leitura) é reduzir o custo médio das operações de leitura, contando que compar-tilhamento de leitura é o padrão que prevalece em aplicações paralelas. Com esta finali-dade, eles permitem operações de leitura simultâneas em execuções locais em váriosnodos. Somente um nodo por vez pode receber permissão para atualizar a cópia replica-da. Sendo que uma escrita nesta cópia aumenta o custo desta operação, porque os usuá-rios das outras cópias deste dado devem ser notificados. Os algoritmos MRSW são usu-almente baseados em invalidação.

Os algoritmos nesta classe diferem quanto a alocação de responsabili dadedo gerenciador de DSM. Li e Hudak propuseram vários destes algoritmos, os quais po-dem ser consultados com detalhes em [LI 89].

2.6.3 Algor itmos Vár ios Leitores / Vár ios Escritores (MRMW)

Os algoritmos MRMW (também chamados de replicação total) permitemreplicação dos blocos de dados com permissão de leitura e gravação. Para preservar acoerência, alterações em cada cópia devem ser distribuídas para todas as outras cópiasem nodos remotos, por mensagens multicast (para um grupo selecionado de máquinas)ou broadcast (para todas as máquinas). Devido a estes algoritmos tentarem minimizar ocusto de acesso das escritas, ele é apropriado para compartilhamento de escrita e fre-qüentemente funciona com protocolos de atualização. Estes algoritmos podem produzirtráfego de coerência alto, especialmente quando a freqüência de atualizações e o núme-ro de cópias replicados são altos. Permitir que várias escritas concorrentes possam ocor-rer na página, reduz o impacto de falso compartilhamento.

Um outro problema que deve ser evitado é o efeito ping-pong. Nos algorit-mos MRSW, cada processo pode escrever na página enquanto ela é mantida por outros

19

processos, portanto, a página irá mover-se na rede. Este deslocamento repetido da pági-na é chamado de efeito ping-pong. Nos algoritmos MRMW este efeito é evitado, sendoque isto será melhor compreendido com a explicação do protocolo de múltiplos escrito-res do sistema TreadMarks, apresentado na seção 4.2.

2.7 Responsabil idade do Gerenciamento de DSM

O sistema precisa determinar qual nodo deve realizar ações relacionadascom a gerência da memória compartilhada. Gerenciamento centralizado é fácil de im-plementar, mas pode tornar-se um gargalo. O gerenciamento distribuído pode definir aresponsabili dade de gerenciamento dinâmica ou estaticamente, eliminando o gargalo eaumentando a escalabili dade. Entretanto, implica maiores gastos (overhead) para a ge-rência.

O mecanismo de DSM precisa armazenar informações sobre os blocos dedados do espaço de endereçamento virtual compartilhado, tais como estado e localiza-ção corrente. Para isto, normalmente são utili zadas tabelas de sistema ou diretório. Aorganização do diretório varia de armazenamento totalmente mapeado à diferentes or-ganizações dinâmicas, tais como listas simples ou duplamente encadeadas e árvores. Ocluster pode fornecer armazenamento para o diretório inteiro ou para apenas uma partedele. O sistema de diretório pode ser distribuído através do sistema e estruturado deforma hierárquica. A organização do diretório e a semântica das informações mantidaspor ele, depende do método utili zado para manutenção da consistência de dados.

2.8 Modelos de Consistência de Memór ia

Consistência de memória é a política que determina como e quando mudan-ças na memória feitas por um processador são vistas pelos outros processadores do sis-tema. A escolha do modelo de consistência define o comportamento pretendido do me-canismo de DSM com respeito as operações de leitura e escrita. O modelo mais intuiti-vo de coerência de memória é a consistência rígida, na qual uma operação de leituraretorna sempre o valor de escrita mais recente. Este tipo de coerência é alcançado so-mente quando existe uma noção global de tempo que possa fornecer uma ordem deter-minística para todas as leituras e escritas. Entretanto, “escrita mais recente” é um con-ceito ambíguo em sistemas distribuídos, onde não existe um relógio global. Por estemotivo, e também para aumentar o desempenho, foram desenvolvidos vários modelospara manter a coerência de memória em sistemas DSM [LO 94].

Para escrever um programa correto e eficiente no modelo de memória com-partilhada, o programador deve ter a noção precisa de como o sistema de memória com-porta-se no que diz respeito às operações de leitura e escrita nos dados compartilhadosrealizadas por diferentes processadores. Considere, os segmentos de código da figura2.3. A figura apresenta uma implementação de um algoritmo de Dekker para exclusãomútua de seções críticas, onde dois processos P0 e P1 executam em processadores dis-tintos. Se as escritas são imediatamente observadas pelos outros processadores, é im-possível que os testes dos comandos L0 e L1 sejam verdadeiros ao mesmo tempo. En-tretanto, se o efeito da escrita for atrasado e durante esse atraso, o processador pudercontinuar seu processamento normal, então ambos os processadores podem chegar ao

20

comando if antes de terem visto as escritas às variáveis A e B e, portanto, os testes L0

e L1 podem ser verdadeiros ao mesmo tempo.

P0 P1

A = 0; B = 0; . . . . . .

A = 1; B = 1;

L0: if (B==0)... L1: if (A==0)...

FIGURA 2.3 – Segmentos de código de P0 e P1 que compartilham A e B

Diferentes aplicações paralelas exigem diferentes modelos de consistência.Quanto mais restrito for o modelo de consistência de memória, mais ele influenciará nodesempenho do sistema. Modelos de consistência rígidos, tipicamente aumentam a la-tência de acesso a memória e a exigência de tamanho de banda passante, enquanto sim-pli ficam a programação. Ao contrário, os modelos mais relaxados, permitem reordena-ção de memória, pipelining e overlaping, conseqüentemente aumentando o desempe-nho. Entretanto, exigem alto envolvimento do programador na sincronização dos aces-sos aos dados compartilhados. Portanto, o modelo de consistência de memória tipica-mente envolve a troca entre desempenho e facili dade de programação [ADV 99].

2.8.1 Consistência Seqüencial

O modelo de consistência de memória mais simples e intuitivo é chamadode consistência seqüencial (SC – Sequential Consistency). Este modelo foi definidopor Lamport [LAM 79] : “Um sistema é seqüencialmente consistente se o resultado dequalquer execução paralela é o mesmo que seria obtido se as operações de todos os pro-cessadores fossem executadas em ordem seqüencial, e as operações de cada processadorna ordem descrita pelo programa”. Em outras palavras, em termos de ordenação dosacessos a dados compartilhados, uma máquina paralela seqüencialmente consistentefunciona como se fosse um único processador multiprogramado.

No exemplo da figura 2.3, o uso do modelo SC garante que os dois coman-dos L0 e L1 jamais poderiam retornar verdadeiro ao mesmo tempo. Em todas as possí-veis intercalações dos comandos de P0 e P1, as leituras dos valores A e B completamuma antes da outra, assim a segunda a completar já viu necessariamente a escrita de 1na variável.

Os protocolos do modelo SC têm que assegurar que todos os nodos obser-vam a mesma seqüência de leituras e escritas. Então, o efeito de cada acesso à memóriadeve ser executado globalmente antes que o próximo acesso tenha permissão para exe-cutar. Isto pode ser alcançado serializando todas as leituras e escritas através de um no-do central ou com a utili zação de protocolos mais eficientes. Apesar da consistênciaseqüencial apresentar um modelo de memória simples, ela é bastante restriti va, reduzin-do o paralelismo potencial do sistema. Além disso, este modelo apresenta alguns obstá-culos à implementação de mecanismos de hardware utili zados para otimização [ADV99].

21

2.8.2 Consistência de Processador

O modelo de consistência de processador (PC – Processor Consistency),garante que escritas realizadas por cada processador estão sempre na ordem do progra-ma. Entretanto, a ordem das escritas de dois processadores distintos podem ser observa-das fora da ordem do programa. Em outras palavras, consistência em escritas são obser-vadas em cada processador, mas a ordem de leituras de cada processador não é restrin-gida, contanto que elas não envolvam outros processadores [HWA 93].

O modelo PC é um relaxamento do SC, pois remove algumas restrições emescritas realizadas por diferentes processadores. Duas condições relacionadas com ou-tros processadores são exigidas para garantir a consistência de processador: (i) antes deuma operação de leitura executar, todos os acessos anteriores de leitura devem ter sidocompletados; (ii ) antes de uma operação de escrita executar, todos os acessos anterioresde leitura e escrita devem ter sido completados.

Estas condições permitem que acessos de leitura ultrapassem acessos de es-crita, desde que para posições de memória diferentes. Portanto, a chave do ganho dedesempenho alcançado pelo modelo de consistência de processador comparado com aconsistência seqüencial é que leituras são diferenciadas das escritas.

2.8.3 Consistência Fraca

Uma vez que vários acessos concorrentes são realizados no espaço de ende-reçamento compartilhado, existe a necessidade de sincronizar estes acessos. Sincroniza-ção é uma forma do programador expressar a restrição entre acessos à memória com-partilhada realizado por diferentes processos. Dois acessos à memória compartilhadasão conflitantes se eles são realizados por processos diferentes para a mesma posição dememória e ao menos um deles é uma escrita. Um programa paralelo tem condição decorr ida (data race) se não existe sincronização entre dois acessos conflitantes. Condi-ções de corrida podem ser evitadas introduzindo sincronização.

Quando existe sincronização, não existe a necessidade de refletir qualqueratualização na memória compartilhada realizada por um processo para os outros proces-sos antes que eles sincronizem-se uns com os outros. Isso porque o segundo processonão irá acessar os dados antes da operação de sincronização ser executada.

Levando em conta que nos programas paralelos a sincronização é necessá-ria, é interessante utili zar um modelo de consistência de memória que garanta a consis-tência seqüencial nos pontos de sincronização do programa, de modo a reduzir o núme-ro de mensagens para a manutenção da consistência. Portanto, com a utili zação de sin-cronização permite-se utili zar modelos de consistência relaxados, que mantêm a con-sistência do programa aplicativo somente nos pontos de sincronização (barreiras e se-máforos). Dados compartilhados são transferidos somente durante a sincronização, re-sultando em muito menos overhead. Entre as variáveis de sincronização, a ordem dasoperações de memória não são impostas, enquanto que as variáveis de sincronizaçãotêm que seguir as regras de consistência seqüencial.

O primeiro modelo relaxado de consistência de memória proposto para tirarproveito da sincronização foi o modelo de consistência fraca (WC – Weak Consisten-cy) [ADV 90]. O modelo WC distingue acessos normais (leituras e escritas) de opera-ções especiais de sincronização. Nos pontos de sincronização é que o sistema torna-seglobalmente consistente. Antes que uma operação de sincronização possa executar, to-

22

dos os acessos normais anteriores devem ser completados. Além disso, acessos realiza-dos após a operação de sincronização devem esperar para que todas as operações desincronização sejam finalizadas. Finalmente, acessos de sincronização são garantidoscomo seqüencialmente consistentes. É responsabili dade do programador a consistênciados dados compartilhados através do uso correto de operações de sincronização. A figu-ra 2.4 apresenta um segmento de código com um exemplo genérico de sincronização,realizado através de acessos de leitura e escrita à variável de sincronização s .

Inicialmente s = A = B = 0

P0 P1

A = 1; espere por s = 1;

B = 10; Y = A;

Escreve 1 em s; X = B;

FIGURA 2.4 – Utili zação de sincronização para garantir coerência de A e B

2.8.4 Consistência de L iberação

Consistência de liberação (RC – Release Consistency) é uma extensão domodelo de consistência fraca, que também distingue acessos normais de acessos de sin-cronização. Acessos de sincronização são divididos em operações de obtenção (acquire)e liberação (release). Uma obtenção indica que o processador está iniciando uma opera-ção que pode depender de valores gerados por outro processador. A execução de umaliberação indica que o processador está terminando uma operação que gerou valores dosquais outros processadores podem depender. No exemplo da figura 2.4, o comando“escreve 1 em s ” é classificado como liberação(s) e o comando “esperepor s = 1 ” é classificado como obtém(s) .

Para garantir a coerência dos dados compartilhados segundo o modelo RC, aaplicação deve, portanto, utili zar sincronização explícita através de primitivas do siste-ma. O uso de espera ocupada em um flag, por exemplo, não permite que o sistema de-tecte a existência de operações de sincronização e as classifique como obtenções ouliberações. As primitivas mais comuns fornecidas pelos sistemas DSM para sincroniza-ção são: locks e unlocks para delimitar seções críticas; e barreiras para sincronizaçãoglobal. Segundo [LO 94], um sistema possui consistência de liberação se:

(i) antes que uma operação de liberação tenha sido observada por qualquerprocessador, todos os acessos a dados compartilhados anteriores devemter sido observados por este processador;

(ii ) acessos que seguem uma operação de obtenção numa variável de sin-cronização devem esperar que a obtenção tenha sido executada;

(iii ) acessos à variáveis de sincronização devem ser observados segundo osmodelos SC ou PC.

A ordenação é imposta somente nos pontos de liberação (a execução nãoprocede além do ponto de liberação até que todas as operações de memória à variáveiscompartilhadas sejam executadas). Este modelo assume que acessos conflitantes de lei-

23

tura e atualização à memória são sempre protegidos utili zando mecanismos que garan-tam exclusão mútua, como os semáforos. Em relação ao SC, RC apresenta uma sensívelredução na latência de acesso à memória compartilhada, pois um processador fica para-lisado esperando pela coerência de dados somente em operações de liberação.

2.8.5 Consistência de L iberação Preguiçosa

O trabalho de Keleher et al. [KEL 98] apresenta uma versão “preguiçosa”do modelo RC chamado de consistência de liberação preguiçosa (LRC – Lazy ReleaseConsistency). LRC relaxa as condições de RC, porque não impõe que numa operação deliberação os acessos anteriores estejam globalmente visíveis. LRC exige que os acessosanteriores à liberação estejam visíveis somente no processador que vai executar a obten-ção subseqüente. Em outras palavras, quando p executa a obtenção em s , antes que aobtenção tenha terminado, todos os acessos realizados até a última liberação devemestar visíveis em p.

Para determinar sobre quais modificações devem ser propagadas para umprocessador no momento de uma obtenção, LRC estabelece uma ordem parcial, chama-da happened-before-1 (hb1), dos acessos a dados compartilhados (figura 2.5). A ordemparcial hb1 [ADV 93] é baseada na ordem seqüencial de execução em um processador eno encadeamento das operações de obtenção e liberação realizadas em processadoresdiferentes, mas sobre a mesma variável de sincronização. Dois acessos à memória com-partilhada a1 e a2 são ordenados por hb1, simbolizado por a1 a2, se:

� a1 e a2 são acessos do mesmo processador e a1 ocorre antes de a2;� a1 é uma liberação no processador P1, a2 é uma obtenção na mesma vari-

ável de sincronização em P2 e a2 retorna o valor escrito por a1;� se a1 a2 e a2 a3, então a1 a3.

P0

Acq(a)W(x1)Rel(a)

Acq(b)W(x2)Rel(b)

Acq(c)W(x3)Rel(c)

.

.

.

P1

Acq(d)W(x4)Rel(d)

.

.

.

Acq(e)W(x5)Rel(e)

Acq(c)W(x3)Rel(c)

P2

.

.

.

Acq(f)W(x6)Rel(f)

.

.

.

Acq(c)W(x3)Rel(c)

FIGURA 2.5 – Ordem parcial estabelecida pelas operações de sincronização

hb1

hb1

hb1

hb1 hb1hb1

hb1

hb1

hb1

hb1

hb1

hb1

hb1

24

Por exemplo, considere os segmentos de código da figura 2.5. Quando P2

executa uma obtenção na variável de sincronização c , segundo a ordem parcial hb1(ilustrada pelas setas da figura), ele deve receber as modificações realizadas em x1, x2 ex3 de P0 e as modificações realizadas em x4, x5 e x3 de P1.

2.8.6 Consistência de Entrada

O modelo de consistência de entrada (EC – Entry Consistency), relaxaainda mais as regras que determinam quando um processador deve observar as modifi-cações realizadas nos dados compartilhados. Ele explora a relação entre variável de sin-cronização e o dado compartilhado protegido por ela. EC garante que o dado comparti-lhado está coerente num processador, apenas quando este obtém a variável de sincroni-zação que o protege.

Sendo s uma variável de sincronização que protege o dado Ds, a condiçãopara que um sistema esteja consistente segundo o modelo EC é: antes que uma operaçãode obtenção em s tenha terminado em p, todas as atualizações em Ds devem ter sidoobservadas por p.

O dado compartilhado pode ser associado à variável de sincronização deforma explícita ou implícita. A associação explícita é realizada pelo programador, en-quanto a implícita é realizada pelo compilador (se ele suportar). Através de uma opera-ção especial, o programador indica para cada variável de sincronização quais os dadoscompartilhados protegidos por ela. A associação implícita deixa a cargo do sistemaDSM estabelecer dinamicamente essa relação.

No modelo de consistência EC o ponto de espera pela coerência ocorre, talqual em LRC, nas operações de obtenção. A grande diferença entre os dois modelos estáem determinar sobre quais modificações o processador deve ser notificado. Em LRC,ele deve ser notificado sobre todas as modificações anteriores segundo a ordem parcialhb1. Já o modelo EC baseia-se na idéia de que se a aplicação requer sincronização paraevitar efeitos de condições de corrida em seus resultados, então essa sincronização de-limita não só quando os dados devem estar coerentes, mas também quais dados devemestar coerentes naquele momento. Em outras palavras, se o programador (ou o compila-dor) estabeleceu uma determinada seção crítica s para acessar o dado Ds, então nomomento de uma obtenção em s , o processador deve estar ciente apenas das modifica-ções em Ds.

Segundo o exemplo da figura 2.5, no modelo EC, P2 no momento da obten-ção em c só deve receber informações sobre as modificações em x3 realizadas anterior-mente. Nesse caso, a determinação do que foi realizado anteriormente segue a ordemtotal imposta pelo encadeamento de operações obtenção/liberação.

Para manter o mesmo comportamento do modelo seqüencial, o modelo deprogramação utili zado por EC requer não só que a aplicação seja propriamente sincroni-zada, mas também que os acessos aos dados compartilhados sejam executados conformea associação estabelecida. Assim, o programador deve considerar que um dado compar-tilhado só está visível num processador quando este executa uma operação de obtençãona variável de sincronização que o protege.

25

2.9 Nível de Implementação do Mecanismo de DSM

O nível onde o mecanismo de DSM é implementado é uma das decisõesmais importantes na construção de sistemas DSM, afetando o custo de programação e odesempenho global do sistema [PRO 98].

Para alcançar facili dade de programação, custo/efetividade e escalabili dade,sistemas DSM logicamente implementam o modelo de memória compartilhada em me-mória fisicamente distribuída. Uma vez que sistemas DSM distribuem o espaço de en-dereçamento compartilhado através das memórias locais, pesquisas devem ser executa-das em cada acesso à dados compartilhados, para determinar se o dado requisitado estána memória local. Se não, o sistema deve trazer o dado para a memória local. O sistematambém deve realizar uma ação em acessos de escrita para preservar a coerência dosdados compartilhados. Tanto pesquisas quanto ações podem executar em software, har-dware ou de forma combinada.

A escolha da implementação depende da relação preço/desempenho. Embo-ra tipicamente superior em desempenho, implementações em hardware requerem com-plexidade adicional, a qual somente máquinas de alto desempenho ou de larga escalapodem oferecer. Sistemas como as redes de computadores pessoais, ainda não toleram ocusto do hardware adicional de DSM, o qual limit a-os para implementações de softwa-re. Em alguns sistemas, como em clusters de estações de trabalho, hardware adicionaisde baixo custo podem ser utili zados.

Mesmo em implementações de DSM por hardware, existem característicascontroladas por software, as quais são explicitamente realizadas pelo programador, como objetivo de otimizar as referências à memória. Também várias propostas de DSM porsoftware exigem algum suporte de hardware. Portanto, torna-se natural empregar méto-dos híbridos, com elementos de software e hardware combinados para balancear a rela-ção de custo e complexidade.

2.9.1 Software

A idéia de construir um mecanismo de software que forneça um paradigmade memória compartilhada para o programador, pode ser alcançado a nível do usuário,ambiente de execução, sistema operacional ou linguagem de programação.

Grãos de grande tamanho (na ordem de kbytes) são típicos de soluções desoftware, devido ao gerenciamento de DSM ser usualmente suportado através da memó-ria virtual. Assim, se o dado requisitado está ausente na memória local, a página serábuscada da memória local de outro cluster ou do disco. Páginas com grãos grandes sãovantajosas para aplicações com alta localidade de referências, além de reduzir o espaçonecessário para o armazenamento de diretório.

Soluções de hardware sempre lidam com objetos de dados não estruturados,enquanto que implementações de software tendem a usar itens de dados que represen-tem entidades lógicas, com o objetivo de alcançar as vantagens de localidade inerente asaplicações.

Suporte de DSM por software é geralmente mais flexível do que suporte porhardware e habilit a um melhor condicionamento dos mecanismos de consistência aocomportamento da aplicação. Entretanto, normalmente não podem competir com asimplementações em hardware em termos de desempenho. Uma vez que não utili zam

26

aceleradores de hardware para resolver o problema, projetistas elaboraram modelos deconsistência relaxado, embora isso acarrete em mais trabalho para o programador. De-vido as pesquisas serem realizadas em uma grande quantidade de linguagens de pro-gramação e sistemas operacionais disponíveis, numerosas implementações de DSM porsoftware foram desenvolvidas. Os capítulos seguintes (capítulos 3, 4, 5 e 6) abordamsistemas de DSM implementados por software.

2.9.2 Hardware

Mecanismos de DSM implementados em hardware garantem replicaçãoautomática dos dados compartilhados nas memórias locais e caches de processador,transparentemente as camadas de software. Esta proposta suporta eficientemente ocompartilhamento de grãos pequenos. A unidade física de replicação e coerência é pe-quena, tipicamente uma linha de cache. Conseqüentemente, mecanismo de DSM porhardware normalmente representam uma extensão dos princípios encontrados em es-quemas de coerência de caches das arquiteturas de memória compartilhada. Esta pro-posta reduz consideravelmente as exigências de comunicação, pois com o compartilha-mento de granulosidade fina são minimizados os efeitos de falso compartilhamento edesperdício. Pesquisas e funções de diretório implementadas em hardware são bem maisrápidas do que as implementadas a nível de software. As implementações por hardwaretambém apresentam menor latência de memória. Entretanto, técnicas avançadas de ma-nutenção de coerência e redução da latência podem complicar o projeto. Por isso, DSMpor hardware é utili zado principalmente em máquinas onde desempenho é mais impor-tante do que custo.

A gerência da hierarquia de memória é um aspecto que requer cuidados, nosentido de encontrar algoritmos eficientes para mover os dados dinamicamente entre osdiferentes níveis da memória ou níveis de cache. Um problema é como mapear as es-truturas de dados do espaço de endereçamento lógico compartilhado em módulos dememória fisicamente distribuídos. Porções do espaço de memória lógica são mapeadosna memória física unicamente (uma porção lógica mapeada para uma localização físicade mesmo tamanho) como nas máquinas CC-NUMA. Outra possibili dade é utili zar re-plicação (uma porção lógica mapeada para várias localizações físicas, cada uma domesmo tamanho que a porção lógica) como nas máquinas COMA e máquinas de memó-ria refletida [MIL 99]. Portanto, de acordo com a arquitetura do sistema de memória,três grupos de sistemas de hardware DSM podem ser destacados:

� CC-NUMA – Cache coherent nouniform memory architectures;� COMA – Cache-only memory architectures;� RMS – Reflective memory systems.

Sistemas de DSM CC-NUMA

Um sistema CC-NUMA distribui estaticamente o espaço de endereçamentovirtual compartilhado através da memória local dos clusters. Tanto o processador localcomo processadores de outros clusters do sistema podem acessar este espaço de endere-çamento, embora com diferente latência de acesso. Os processadores de um mesmocluster terão acesso à memória local deste cluster na velocidade do hardware. No en-

27

tanto, acessos provenientes de processadores de outros clusters terão adicionado a latên-cia de acesso à memória a latência de comunicação.

O mecanismo de DSM é normalmente implementado utili zando diretórioscom organização variando de mapeamento completo à diferentes estruturas dinâmicas,como as listas simples ou duplamente encadeadas e as árvores. O principal esforço éalcançar alto desempenho (como em esquemas de mapeamento completo) e boa escala-bili dade fornecida pela redução do overhead de armazenar o diretório. Para minimizar alatência, particionamento estático de dados pode ser feito cuidadosamente, para maxi-mizar a freqüência de acessos locais. Indicadores de desempenho também dependemaltamente da topologia de interconexão. Um mecanismo de invalidação é tipicamenteaplicado para fornecer coerência, enquanto alguns modelos de consistência de memóriarelaxados podem servir como fonte de ganho de desempenho.

Sistemas de DSM COMA

A arquitetura COMA usa a memória local dos clusters como grandes cachespara blocos de dados do espaço de endereçamento virtual compartilhado (memórias deinteresse – attraction memory). Não existe uma localização pré-determinada na memó-ria física para um item de dado em particular, e eles podem ser replicados e migradosnas memórias de interesse sob demanda. Por conseguinte, a distribuição de dados nasmemórias locais adaptam-se dinamicamente ao comportamento da aplicação.

As arquiteturas COMA possuem topologia de rede hierárquica que simpli fi-cam os dois principais problemas deste tipo de sistemas: localizar um bloco de dados esubstituí-lo. Elas são menos sensíveis à distribuição estática de dados do que são as ar-quiteturas NUMA. Devido a organização de suas caches, as memórias de interesse re-duzem o volume e o custo dos conflitos de ausência. Mas, a estrutura hierárquica impõelatências de comunicação e de falhas de dados remotos ligeiramente mais altas. É ine-rente a estas arquiteturas um aumento no overhead de armazenamento para manter in-formações típicas para memórias cache.

Sistemas DSM de Memór ia Refletida

Sistemas de memória refletida têm um mecanismo implementado emhardware para atualização de dados de granulosidade fina. O espaço de endereçamentoglobal compartilhado é formado fora dos segmentos de memória local. Estes segmentossão designados como compartilhados e mapeados para este espaço através de tabelas demapeamento programáveis presentes em cada cluster. Portanto, as partes deste espaçocompartilhado são seletivamente replicadas (refletidas) ao longo de diferentes clusters.Manutenção da coerência das regiões compartilhadas é baseada no algoritmo de replica-ção total (MRMW). Para manter os dados atualizados, cada escrita para um endereçocontido neste espaço de endereçamento compartilhado no cluster propaga-se através deum broadcast ou de um multicast para todos os outros clusters onde o mesmo endereçoestiver mapeado.

O processador não protela escritas nem computações sobrepostas com co-municação. Esta é uma fonte de melhoria de desempenho típica de modelos de consis-tência de memória relaxada. Também não existe contenção e longas latências como emtípicos sistemas de memória compartilhada. Isto deve-se a garantia de acesso irrestrito

28

aos dados compartilhados e aos acessos simultâneos a cópias locais. Mas, todas as leitu-ras de memória compartilhada são locais, com tempo de acesso determinístico. O prin-cípio deste mecanismo de DSM assemelha-se aos protocolos de atualização de coerên-cia de cache.

2.10 Considerações Finais

Os sistemas DSM são alternativas viáveis para o desenvolvimento de pro-gramas paralelos. No entanto, para alcançar desempenhos semelhantes aos sistemas dememória compartilhada, as aplicações que executam em memória distribuída com me-canismos de DSM devem ser desenvolvidas com a utili zação de primitivas, para reduzira comunicação gerada para localização e manutenção da coerência dos dados. Entre-tanto, isto implica no maior envolvimento do programador.

Observa-se que em vários sistemas DSM o desempenho geral do sistemadepende das características da aplicação. Por isso, muitas vezes os sistemas apresentamalto desempenho para determinada classe de aplicações. No entanto, é desejado queestes sistemas apresentem alto desempenho para uma grande quantidade de aplicações.Com este propósito, vários trabalhos têm sido realizado no sentido de adaptar os meca-nismos de DSM as características da aplicação.

Outras características podem levar a uma maior disseminação dos sistemasDSM. Uma delas é que estes sistemas sejam capazes de detectar o paralelismo de formaimplícita, com isto reduzindo o envolvimento do programador com o processo de para-lelização da aplicação. Algumas etapas neste sentido já foram alcançadas por algunssistemas, como a utili zação implícita de sincronização e balanceamento automático decarga. Outra característica que vem recebendo destaque é que os sistemas DSM supor-tem mobil idade.

29

3 Orca

Orca é um sistema para implementação de aplicações concorrentes para ar-quiteturas de memória distribuída. Caracteriza-se por permitir que processos em dife-rentes máquinas compartilhem dados, sendo estes dados encapsulados em objetos dedados. A implementação do Orca cuida da distribuição física dos objetos entre a memó-ria local dos processadores [BAL 92].

3.1 Modelo de Programação

Sistemas com objetos compartilhados caracterizam-se por fornecerem com-partilhamento a nível das estruturas de dados do usuário. São suportados pela lingua-gem, que pode ter características comuns de alto nível como organização hierárquicados dados. Orca é um sistema de memória compartilhada distribuída baseado em obje-tos, cujo sistema de execução gerencia o suporte da distribuição dos objetos, fornecendouma memória compartilhada distribuída estruturada.

Orca encapsula as estruturas de dados compartilhadas em objetos, que sãoinstâncias (var iáveis) dos tipos abstratos de dados (classes) definidos pelo programa-dor. A característica principal do Orca é acessar as estruturas de dados compartilhadasatravés de operações de alto nível. Ao invés de utili zar instruções de baixo nível paraler, escrever e realizar lock nos dados compartilhados, os programadores definem ope-rações (métodos) para manipular as estruturas de dados compartilhadas. Uma caracte-rística importante do modelo Orca é fazer com que cada operação em um objeto sejaatômica, o que dispensa o programador de utili zar locks. Todas as operações em umobjeto são executadas sem interferência das outras. Este modelo de objetos comparti-lhados é suportado pela linguagem Orca, que foi projetada especificamente para pro-gramação paralela em sistemas de memória distribuída [BAL 98].

A definição de um tipo abstrato de dados consiste de duas partes: uma partede especificação e uma parte de implementação. A parte de especificação define as ope-rações aplicáveis aos objetos de um determinado tipo. A parte de implementação con-tém os dados utili zados para representar objetos deste tipo, o código para inicializar osdados das novas variáveis deste tipo e o código das operações implementadas. Portanto,o conteúdo real dos dados no objeto e o código executável das operações são ocultadosna implementação dos tipos abstratos de dados.

O modelo de comunicação do Orca é baseado em objetos de dados compar-tilhados. O paralelismo no Orca é explícito, sendo baseado em dois conceitos ortogo-nais: processos e objetos [TAN 92].

� Processos – processos são entidades ativas que executam programas.Eles podem ser criados e destruídos dinamicamente. O número de pro-cessos não é fixado durante a compilação, é determinado durante a exe-cução;

� Objetos – no Orca os objetos são passivos. Eles não contém processosou outro tipo de elemento ativo. Cada objeto contém algumas estruturasde dados e a definição de uma ou mais operações que usam estas estru-turas de dados. Tecnicamente, a linguagem Orca é baseada em objetos,

30

não orientada a objetos, uma vez que suporta encapsulamento de tiposabstratos de dados, mas não tem herança.

O modelo de consistência de memória do Orca é seqüencialmente consis-tente. Contudo, apresenta semelhanças com consistência de entrada. Operações contí-nuas nos objetos compartilhados são executadas utili zando consistência seqüencial, masleituras e escritas individuais à palavras de memória dentro de uma operação não sãovisíveis para os outros processos até que a operação esteja completa, uma vez que ope-rações são executadas atomicamente. Em termos de acessos individuais à memória, omodelo Orca é similar à consistência de entrada, mas sem a necessidade do programa-dor associar variáveis de lock aos objetos.

A sincronização no Orca é implícita. Tanto exclusão mútua como sincroni-zação de condição são integradas no modelo. Uma importante vantagem é que os pro-gramadores não precisam utili zar primitivas de sincronização, o que simpli fica a pro-gramação. Entretanto, a sincronização implícita é menos flexível que a utili zação explí-cita [BAL 98].

3.2 Arquitetura do Sistema

O sistema Orca é composto de três partes: um compilador, um sistema deexecução e uma máquina virtual chamada Panda.

Compilador

Sistema de Execução

Máquina Virtual (Panda)

Hardware + Sistema Operacional

FIGURA 3.1 – Camadas do Orca

O compilador é responsável por traduzir os programas Orca para ANSI Cacrescido de chamadas para o sistema de execução. O compilador também gera infor-mações sobre quais operações têm atributo somente de leitura e como processos aces-sam os objetos compartilhados. Estas informações serão utili zadas para auxílio na to-mada de decisões como será discutido na seção 3.3.2.

O sistema de execução (RTS – RunTime System) é responsável por gerenci-ar os processos e os objetos do Orca. Inicialmente, um programa Orca é composto porum único processo. Novos processos são criados pelo sistema de execução, a partir dasprimitivas de criação de processos que foram definidas pelo programador no código daaplicação. Estes processos podem acessar os objetos compartilhados. O sistema de exe-cução decide como representar os objetos, possui mecanismos de invocação remota de

31

objetos e migração de objetos, e implementa o protocolo de atualização para objetosreplicados.

Panda fornece ao sistema facili dades necessárias para implementar o RTS.A camada Panda fornece threads, chamada remota de procedimento (RPC – RemoteProcedure Calls) e comunicação de grupo totalmente ordenada. Threads são utili zadaspara implementar os processos Orca; RPC é usado para implementar invocação remotade objetos; e comunicação de grupo serve para o protocolo de atualização.

O versão atual do Orca é altamente portável. Já foi implementada para umagrande variedade de multicomputadores e clusters de estações de trabalho e tem sidoutili zada para várias aplicações paralelas [BAL 98].

3.3 Caracter ísticas do Orca

Os aspectos mais importantes do sistema Orca podem ser observados na ta-bela 3.1.

TABELA 3.1 – Aspectos importantes no projeto do sistema Orca

Característica Decisão de Projeto

Protocolo de coerênciaProtocolo de atualização baseado em expedição de funçãoe comunicação de grupo totalmente ordenada

Disposição dos objetosHeurísticas de compilação e estatísticas de tempo de exe-cução

Portabili dade Proposta baseada em camadas com máquina virtual

Arquitetura do software Implementado em software, utili zado a nível de usuário

As próximas seções abordarão estas características, sendo que para consul-tas mais detalhadas recomenda-se [BAL 98].

3.3.1 Protocolo de Coerência

O sistema Orca replica os objetos compartilhados que são lidos freqüente-mente. A vantagem da replicação é que operações de leitura (as quais são reconhecidaspelo compilador) podem ser executadas localmente, sem a necessidade de comunicação.Entretanto, o problema é como implementar as operações de escrita que modificam osobjetos. Pode-se optar pela utili zação de um protocolo de invalidação ou por um proto-colo de atualização.

O Orca utili za protocolo de atualização para implementar operações de es-crita, ao contrário da maioria dos sistemas DSM que utili zam protocolo de invalidação.Os objetos são atualizados utili zando expedição de função (function shipping), queconsiste em enviar a operação e seus parâmetros para todas as máquinas que contenhamuma cópia deste objeto. Portanto, a operação realizada em um objeto é aplicada a todasas cópias locais, não sendo necessário transmitir o objeto inteiro.

A eficiência do protocolo de atualização do Orca depende do comporta-mento da aplicação. O protocolo torna-se ineficiente se a taxa de leitura/escrita for bai-

32

xa. Em particular, o protocolo apresenta seu pior desempenho se um processador fizermuitas operações de escrita consecutivas no mesmo objeto, sem intervenção de opera-ções de leitura por outros objetos. Entretanto, esta situação não ocorre no Orca, pois namaioria dos casos os programadores combinam tais operações de escrita em uma únicaoperação lógica. Além disso, o sistema replica somente aqueles objetos que tenham umaalta taxa de leitura/escrita.

Para realizar este processo de atualização de forma coerente, a operação éenviada utili zando comunicação de grupo totalmente ordenada. Sua utili zação é justifi-cada uma vez que, mensagens de atualização de diferentes origens poderiam ser entre-gues em ordem diferente nos processadores destino, resultando em inconsistências.Portanto, todas as atualizações são executadas na mesma ordem em todas as máquinas.Esta primitiva é pouco utili zada em sistemas DSM, uma vez que ela pode apresentaralto custo, e porque envia mensagens para todos os processadores. A vantagem destaprimitiva é que simpli fica a implementação do protocolo de atualização. Foram desen-volvidos vários protocolos que fizeram este custo aceitável para o Orca [BAL 98].

Quando uma operação de escrita é solicitada em um objeto replicado, o soli-citante envia um broadcast da operação utili zando comunicação de grupo totalmenteordenada e bloqueia-se até que o sistema de execução tenha processado a mensagem debroadcast (e todas as outras mensagens que ocorreram antes dela). Quando uma mensa-gem de broadcast com uma operação é recebida por um processador, o sistema de exe-cução verifica se existe uma cópia deste objeto na memória local. Se existe, o RTSchama um procedimento que executa a operação. Senão, desconsidera a mensagem.

O protocolo utili za um seqüenciador centralizado para ordenar todas asmensagens. Cada mensagem de broadcast contém um número de seqüência, o qual osreceptores utili zam para ordenar as mensagens e para checar se falta alguma mensagem.Dependendo do ambiente de execução e do tamanho da mensagem, o sistema escolheum entre três diferentes mecanismos para os números de seqüência. Na proposta maissimples o emissor pede ao seqüenciador o próximo número de seqüência (através deduas mensagens pequenas), e envia a mensagem de broadcast com o número de se-qüência. Em outra proposta, o emissor transmite a mensagem completa para o seqüenci-ador, que adiciona o próximo número de seqüência e envia o broadcast da mensagem.Para grandes mensagens, uma terceira proposta consiste no emissor enviar a mensagemde broadcast sem o número de seqüência e o seqüenciador enviar outra (pequena) men-sagem de broadcast contendo o número de seqüência. Detalhes dos protocolos em[KAA 92].

Cada protocolo requer uma ou duas mensagens extras de controle para im-plementar a ordenação total. Um outro problema é que o protocolo utili za um compo-nente centralizado, o qual pode criar contenção. A máquina seqüenciadora precisa serpraticamente dedicada, pois ela pode ter que manipular várias requisições por segundo.Outra desvantagem destes protocolos é que todos os processadores que participam daexecução recebem mensagens, mesmo que não possuam cópias do objeto que foi atuali-zado. Portanto, uma operação de escrita em um objeto replicado irá interromper todas asmáquinas envolvidas na execução. Além disso, programas Orca irão gerar um grandenúmero de mensagens se eles realizarem muitas operações de escrita nos objetos repli-cados. Entretanto, o sistema de execução do Orca evita que os objetos que são princi-palmente escritos sejam replicados, minimizando esse problema.

Para as aplicações Orca analisadas [BAL 98], o overhead de comunicaçãodo protocolo de atualização é baixo, isto devido a taxa de leitura/escrita dos objetos

33

compartilhados ser freqüentemente alta e porque o sistema não replica objetos nos quaisesta taxa é baixa. Portanto, um aspecto chave é determinar quais objetos devem ser re-plicados. Alguns estudos de desempenho mostram que o sistema Orca tem condições detomar boas decisões sobre a replicação de objetos sem nenhum auxílio do programador[BAL 98].

3.3.2 Estratégia de Disposição dos Objetos

Utili zando o protocolo de atualização descrito na seção anterior, operaçõesde leitura em objetos replicados podem ser executadas localmente, mas operações deescritas exigem um broadcast para todas as máquinas. Se a taxa de leitura/escrita doobjeto é baixa, a replicação é ineficiente e é melhor armazenar o objeto em uma únicamáquina. Neste caso, outras máquinas podem acessar o objeto fazendo uma invocaçãoremota de objeto. O sistema Orca suporta tanto replicação quanto objetos com uma úni-ca cópia e permite que objetos troquem dinamicamente de uma estratégia para outra.

Uma questão importante do sistema Orca é a forma com a qual ele determi-na a disposição (localização) para cada objeto. O sistema replica somente os objetos quetenham alta taxa de leitura/escrita, com o objetivo de reduzir o overhead de atualização.Além disso, determina onde armazenar objetos que não são replicados. O programadorpoderia ser responsável por estas decisões, no entanto, isto é indesejável, uma vez que aidéia dos sistemas DSM é esconder a distribuição do programador. Isto também tornariaas soluções dependentes da arquitetura. Por estes motivos, o Orca responsabili za-se peladeterminação da disposição dos objetos, sem o envolvimento do programador.

O compilador calcula expressões regulares (padrões) que contêm uma des-crição de alto nível de como os objetos compartilhados são acessados. O sistema deexecução usa estas informações como uma sugestão sobre como os objetos serão util i-zados. Além disso, são mantidas estatísticas em tempo de execução sobre a utili zaçãodos objetos. Baseado nestas informações, o sistema decide em quais máquinas colocarcópias dos objetos compartilhados.

Portanto, a decisão de quais objetos replicar e onde armazenar os objetosnão replicados é de responsabili dade do sistema de execução. As estatísticas mantidaspelo RTS são essenciais para esta proposta (e mais importante que as informações gera-das pelo compilador), sendo que apresentam um overhead desprezível.

3.3.3 Por tabili dade

O sistema Orca foi projetado para fornecer portabili dade e flexibili dade.Para alcançar portabili dade, foi utili zada uma proposta de camadas (figura 3.1). O sis-tema é formado por três camadas, e as partes dependentes da arquitetura e do sistemaoperacional foram isoladas na camada mais baixa. O principal problema de projeto écomo fazer o sistema portável e eficiente. Em particular, é difícil utili zar propriedadesespecíficas da arquitetura em um sistema portável.

O compilador e o sistema de execução são totalmente independentes da ar-quitetura. O sistema de execução é implementado sobre uma máquina virtual, chamadaPanda. Esta máquina virtual é que fornece as primitivas de comunicação e de multi tare-fa exigidas pelo sistema.

34

Portanto, portar o sistema para novas arquiteturas é alcançado portando aPanda. A camada Panda pode ser configurada estaticamente para combinar com a plata-forma de execução (hardware e sistema operacional). Por exemplo, se o sistema opera-cional ou o hardware fornecerem certas funcionalidades que possam ser interessantes aPanda (comunicação confiável), Panda pode ser configurada para fazer uso delas.

3.3.4 Arquitetura do Software

O sistema Orca é implementado inteiramente em software. A desvantagemdeste tipo de sistema é a perda de desempenho, pois todos os acessos são feitos porsoftware. No entanto, é mais flexível. O sistema explora a flexibili dade para implemen-tar várias otimizações importantes.

O sistema de execução do Orca realiza toda a gerência de objetos e proces-sos por software. Conseqüentemente, todos os acessos a objetos compartilhados sãofeitos em software. Para implementar uma operação de invocação, o sistema de execu-ção tem que verificar o estado atual do objeto para determinar se a operação deve serexecutada usando uma invocação local, uma invocação remota ou um broadcast. Paraisto, o RTS primeiro verifica se o objeto é replicado. Se não, ele verifica se o objeto éarmazenado localmente ou remotamente. A verificação de acesso é protegida por umlock, uma vez que o Orca é multi -thread.

Os testes realizados em [BAL 98] demonstram que o overhead desta opera-ções realizadas por software é desprezível para uma grande quantidade de aplicações.

35

4 TreadMarks

TreadMarks é um software que permite programação concorrente com me-mória compartilhada em arquiteturas de memória distribuída. Caracteriza-se por execu-tar a nível de usuário em redes de estações de trabalho com sistema operacional Unix. Oprojeto do TreadMarks teve como objetivo reduzir a quantidade de comunicação neces-sária para manter a consistência de memória. Para isto utili za um protocolo de múltiplosescritores e o modelo de consistência de liberação preguiçosa.


TreadMarks é implementado inteiramente como biblioteca a nível de usuá-rio. Funciona no sistema operacional Unix sem exigir modificações no kernel, pois asimplementações atuais do Unix fornecem todas as primitivas de comunicação e funçõespara gerenciamento de memória necessárias para a implementação do TreadMarks. Pro-gramas escritos em C, C++ ou Fortran são compilados e ligados com a biblioteca Tre-adMarks utili zando qualquer compilador padrão para estas linguagens. Como resultadoo sistema é relativamente portável.

O ambiente de programação do TreadMarks é simples. Não há a necessida-de de desenvolver toda a aplicação novamente. É permitido que programas seqüenciaispossam ser modificados para executar em paralelo, possibilit ando a reutili zação de có-digo [AMZ 96]. O programador deve incluir as primitivas fornecidas pela API(Application Programming Interface) do TreadMarks para expressar a criação e destrui-ção de processos, realizar sincronização e alocação da memória compartilhada.

Quando a memória compartilhada é acessada por um processador, Tread-Marks determina onde o dado está fisicamente presente, e se necessário transmite odado para o processador sem a intervenção do programador. Quando a memória com-partilhada é modificada por um processador, TreadMarks assegura que outros processa-dores serão notificados da mudança, portanto eles não terão dados obsoletos. Esta noti-ficação não é imediata nem global. Notificação imediata seria realizada freqüentementee notificação global normalmente iria enviar para processadores informações que nãoseriam pertinentes a maioria deles. Ao invés, esta notificação entre processos é realizadaquando eles são sincronizados. Programas livres de condições de corrida produzem omesmo resultado se a notificação for imediata ou postergada até a sincronização, e aacumulação de várias notificações em uma única mensagem no momento da sincroniza-ção reduz o overhead de comunicação entre processos.

Todas as mensagens enviadas pelo TreadMarks são mensagens de requisi-ção ou mensagens de resposta. Mensagens de requisição são enviadas pelo TreadMarkscomo resultado de uma chamada explícita a uma rotina da biblioteca TreadMarks ou poruma falha de acesso. Uma vez que uma máquina tenha enviado uma mensagem de re-quisição, ela bloqueia-se até que chegue a mensagem com a resposta desejada. Se umaresposta não chega dentro de um certo timeout, a requisição original é retransmitida.

36

4.2 Protocolo de Múltiplos Escritores

Os protocolos de vários escritores tratam o problema de falso compartilha-mento. Caracterizam-se por consentir que vários processadores tenham permissão paraescrever na cópia da página ao mesmo tempo. Esta seção aborda o funcionamento doprotocolo de múltiplos escritores implementado pelo TreadMarks. As página comparti-lhadas são inicialmente protegidas para escrita. Quando uma escrita ocorre por um pro-cesso P1, TreadMarks cria uma cópia da página, chamada de twin, e a salva como partedas estruturas de dados do TreadMarks neste processador. O sistema então desprotege aoutra cópia da página, a qual está presente no espaço de endereçamento do processo.Isto possibilit a que as próximas escritas à página possam ocorrer sem a intervenção dosoftware DSM.

No momento em que o processador P1 for realizar uma operação de libera-ção, existem duas cópias da página. A cópia modificada que está no espaço de endere-çamento do processo e a cópia twin, com a versão original (sem modificações) da pági-na. A partir de uma comparação palavra-por-palavra da cópia do processo com a twin, écriada uma estrutura chamada diff , com as modificações realizadas na página (figura4.1). Como os diffs contêm apenas as modificações realizadas na página, seu tamanhovaria de acordo com a quantidade de dados modificados. Uma vez que a diff tenha sidocriada, a twin é descartada. Atualizações nas outras cópias da página presentes no siste-ma podem ser realizadas aplicando a diff sobre estas páginas.

No caso de um processador P2 escrever sobre a mesma página utili zada peloprocessador P1, a mesma seqüência de eventos descritos acima ocorre em P2. É impor-tante ressaltar que esta seqüência completa de eventos é local a cada um dos processa-dores e, portanto, não requerem troca de mensagens. Como parte do protocolo, P1 é in-formado de que P2 modificou a página e vice-versa, sendo que ambos invalidam suascópias da página. Na próxima vez que eles acessarem a página, ocorrerá uma falha deacesso em ambos. O software TreadMarks em P1 sabe que P2 modificou a página, entãoenvia uma mensagem para P2 requisitando a diff, a qual é aplicada na página voltando ater uma cópia válida. Novamente, a mesma seqüência de eventos ocorre no outro pro-cessador.

Com exceção da primeira vez que um processador acessar uma página, suacópia é atualizada exclusivamente aplicando os diffs. Portanto, não é necessário buscarnovamente a página inteira. Esta estratégia reduz os efeitos de falso compartilhamento.Além disso, reduz significativamente a exigência de banda passante, pois os diffs nor-malmente são bem menores do que as páginas.

Uma dúvida pertinente é o que acontece quando dois processos modificamporções sobrepostas de uma página. Por exemplo na figura 4.1, o que aconteceria sealém de P1 modificar a, P2 também o fizesse. Isto corresponde a uma condição de corri-da, pois significa que dois processos escrevem na mesma posição de memória sem aintervenção de sincronização [AMZ 96]. Esse tipo de condição tem que ser controladapelo programador com a utili zação correta das primitivas de sincronização fornecidaspela API do TreadMarks.

Com LRC, a criação de diffs pode freqüentemente ser postergada ou evitada,através de uma técnica chamada de criação preguiçosa de diffs (lazy diff creation).Esta criação preguiçosa de diffs é diferente da versão original do protocolo de múltiplosescritores, onde a cada liberação um diff é criado para cada página modificada e propa-gado para todas as outras cópias da página. A implementação de LRC utili zada pelo

37

TreadMarks permite que a criação de diffs seja adiada até que as modificações sejamrequisitadas. Criação preguiçosa de diffs resulta em menor número de diffs criados e umconseqüente aumento de desempenho [KEL 94].

FIGURA 4.1 – Criação de diff

4.3 Consistência de Memória

Programas escritos para o modelo de consistência memória seqüencial pro-duzem o mesmo resultado que programas escritos para o modelo de consistência deliberação preguiçosa, desde que:

(i) todas as operações de sincronização sejam realizadas utili zando as pri-mitivas fornecidas pelo sistema;

(ii ) existe um par obtenção-liberação entre acessos concorrentes ao mesmodado compartilhado realizado por processadores diferentes [KEL 98].

TreadMarks usa consistência de liberação preguiçosa como modelo de con-sistência de memória, permitindo que alterações a dados compartilhados se tornem visí-veis a outros processadores apenas em determinados pontos de sincronização. Nospontos de aquisição de locks ocorrem as invalidações das páginas alteradas por outrosprocessadores. Entretanto, as modificações dessas páginas só são requeridas na ocorrên-cia de uma falha de acesso. A figura 4.2 ilustra a diferença entre os modelos RC e LRC.

38

FIGURA 4.2 – Release vs Lazy Release Consistency

Em LRC a propagação das modificações é adiada até o momento da obten-ção. Neste momento, o processador que está realizando a obtenção determina quais mo-dificações ele necessita observar de acordo com a definição do modelo. Para fazer isto,LRC divide a execução de cada processo em intervalos, cada um indicado por um índicede intervalo (interval index). Cada vez que um processo executa uma liberação ou umaobtenção, começa um novo intervalo e o índice de intervalo é incrementado. Intervalosde diferentes processos são parcialmente ordenados segundo as regras hb1. Portanto,através de hb1 é possível determinar quais intervalos de outros processadores precedemo intervalo corrente de um processador p. Na prática, a criação de intervalos pode seradiada até que aconteça comunicação com outro processo, evitando overhead se umlock é obtido novamente pelo mesmo processador.

As modificações realizadas nos dados compartilhados são associadas aosintervalos em que elas ocorreram e, assim, numa operação de obtenção ocorrida no in-tervalo i , o processador deve ser notificado sobre todas as modificações associadas aintervalos “anteriores” a i , segundo a ordem parcial hb1.

A notificação sobre as modificações ocorridas nos dados compartilhados érealizada através de avisos de escrita (write-notices). Um aviso de escrita indica queuma determinada página foi modificada, mas não possui o conteúdo das modificações.Cada intervalo contém um aviso de escrita para cada página modificada no segmento detempo correspondente. Quando o processador p executa uma operação de obtenção numintervalo i ele deve receber os avisos de escrita correspondentes a todos os intervalosanteriores a i segundo hb1. Ao receber um aviso de escrita, o processador invalida apágina correspondente. Os diffs relativos às modificações em questão só são recebidosna próxima falha de acesso à página.

Se ocorreu uma falha de acesso em uma página k inválida, estão o sistematem que trazer os diffs relativos às modificações realizadas em k por outros processado-res. Os diffs devem ser buscados dos processadores que enviaram avisos de escrita parak . Uma característica muito importante de TreadMarks é a criação de diffs sob deman-da. Em TreadMarks, um processador só cria o diff relativo às modificações realizadasem uma determinada página quando chega uma requisição para esse diff. Para minimi-zar o número de mensagens necessárias para a busca de diffs, TreadMarks utili za um

39

esquema de “propriedade (dominância)” de intervalos. Um intervalo i domina um in-tervalo j , se j precede i na ordem parcial hb1. Assim as mensagens devem ser envia-das apenas aos processadores cujos intervalos mais recentes não são dominados pelosintervalos mais recentes de outros processadores [SEI 98]. Considere, por exemplo, ossegmentos de código da figura 4.3. Quando P2 executa lock, ele deve requisitar diffsapenas do processador P1, porque o intervalo I2 de P1 domina os intervalos I0 e I1 de P0 eI0 de P1.

FIGURA 4.3 – Exemplo de dominância de intervalos

Existe um processador gerente, determinado estaticamente, associado a cadavariável de sincronização. O gerente armazena qual foi o último processador a requisitaro lock. Toda a aquisição de lock é direcionada ao gerente e, se necessário, encaminhadopara o último processador que requisitou o lock. Numa operação de lock em uma variá-vel de sincronização s , o processador p envia uma mensagem ao processador gerente des (p não sabe qual foi o último processador a acessar s ). O processador gerente, então,avança a mensagem para o último processador que executou uma operação de liberaçãoem s . Este compara seus intervalos com os de p e envia para p os avisos de escrita re-lativos aos intervalos que p ainda não viu. Na chegada da mensagem com os avisos deescrita, p invalida as páginas correspondentes.

40

5 Calypso

Calypso é o protótipo de um sistema para escrever e executar programas pa-ralelos em plataformas não dedicadas, utili zando redes de estações de trabalho comerci-ais, sistemas operacionais e compiladores disponíveis. O Calypso explora os recursosdisponíveis de uma arquitetura distribuída para executar uma aplicação paralela. Alémdisso, trata de fatores como compartilhamento de recursos, comportamento imprevisívelda rede, máquinas com baixo desempenho e sujeitas a falhas. Em geral, é responsabil i-dade do programador controlar este fatores, tarefa que complica ainda mais o desenvol-vimento de programas paralelos para estas arquiteturas.


No Calypso os programas são escritos para multiprocessador com memóriacompartilhada, mas são executados em uma rede de estações de trabalho que podemmudar seu comportamento durante a execução. Em outras palavras, Calypso oferece aoprogramador a ilusão de uma máquina confiável, mas implementa esta máquina confiá-vel em uma rede de computadores não confiáveis.

Calypso utili za uma arquitetura nova para fornecer tolerância à falhas, ba-lanceamento automático de carga e espaço de endereçamento compartilhado, enquantoapresenta baixo overhead de tempo de execução para computação com grãos grossos[BAR 99]. O modelo de programação utili zado pelo Calypso é baseado em memóriacompartilhada e separa o paralelismo físico (determinado em tempo de execução) doparalelismo lógico (como expresso pelo programa) [SKI 98].

O método básico de escrever programas paralelos no Calypso é paralelizaralgumas partes de um programa seqüencial, tipicamente as que possuem computaçãointensiva (por exemplo, paralelizar os loops). Com isso, programas paralelos são estru-turados inserindo tarefas paralelas em programas seqüenciais. A execução de uma tarefaparalela é referenciada como etapa paralela, enquanto a execução de um fragmentoseqüencial entre duas etapas paralelas é referenciado como etapa seqüencial.

O gerenciamento da execução paralela, bem como o suporte para balancea-mento de carga, tolerância à falhas e memória compartilhada, são fornecidas pelo siste-ma de execução. Quando mais trabalhadores unem-se, o speedup tende a aumentar. Setrabalhadores quebram, retiram-se ou tornam-se lentos, eles são automaticamente ex-cluídos (dinamicamente) [MCL 99].

5.2 Caracter ísticas do Calypso

A computação do Calypso utili za um processo gerente centralizado e umconjunto de processos trabalhadores que podem ser alocados dinamicamente. Suasprincipais características são:

� Facili dade de programação – os programas são escritos em uma lingua-gem chamada Calypso Source Language (CSL). CSL é essencialmenteC++, com a adição de construções para expressar o paralelismo (porexemplo, parbegin-parend). É baseada no modelo de memória compar-

41

tilhada e é simples de aprender e usar. Aspectos importantes que contri-buem para facili dade de programação são a eliminação do particiona-mento dos dados e a necessidade de especificar como e quando moverdados entre estações de trabalho;

� Separação do paralelismo lógico do paralelismo físico – o paralelismoexpresso em uma aplicação é o paralelismo lógico e não deve ser depen-dente do paralelismo físico. Portanto, o paralelismo expresso pelo pro-gramador é independente do ambiente de execução, ambiente este quedepende da disponibili dade das estações de trabalho. O mapeamento en-tre o paralelismo do programa e o paralelismo de execução é realizadode forma transparente;

� Tolerância a falhas – execuções do Calypso são resistentes à falhas. Pro-cessos trabalhadores podem falhar, e possivelmente se recuperarem, aqualquer ponto sem afetar a coerência da computação. Diferente de ou-tros sistemas tolerantes à falhas, não há custo adicional significativo as-sociado a esta característica – na ausência de falhas o desempenho doCalypso é semelhante a um sistema não tolerante à falhas;

� Balanceamento dinâmico de carga – Calypso automaticamente distribuia carga de trabalho dinamicamente entre as máquinas participantes. Oresultado é que trabalhadores mais rápidos realizam mais trabalho doque os trabalhadores mais lentos. Além de não haver custo associado aesta característica, ela realmente aumenta o speedup da computação,pois trabalhadores rápidos nunca ficam bloqueados esperando pelosmais lentos para finalizar suas atribuições – eles ultrapassam os maislentos;

� Alto desempenho – enquanto fornecem estas características, foram reali-zados alguns experimentos que indicam um pequeno overhead paracomputações de grãos médios a grãos grossos [BAR 99].

Um conjunto unificado de mecanismos é utili zado para fornecer funcionali-dade ao Calypso. Este conjunto de mecanismos é composto por um mecanismo de es-calonamento impaciente (eager scheduling), um mecanismo que analisa a memória ecria o diff (collating differential memory) e uma estratégia idempotent de execução deduas fases (TIES – Two-phase Idempotent Execution Strategy) [BAR 95].

Escalonamento impaciente fornece a habili dade de dinamicamente exploraro poder computacional de um conjunto variável de máquinas. Estas máquinas podemtornar-se lentas, carregadas ou terem dinamicamente modificadas suas propriedades decarga. O algoritmo de escalonamento atribui tarefas executáveis concorrentemente paramáquinas disponíveis até que todas as tarefas sejam finalizadas. A mesma tarefa podeser atribuída a mais de uma máquina (se todas as tarefas tiverem sido atribuídas e algu-mas ainda não tiverem sido completadas). Como conseqüência, máquinas livres ou maisrápidas realizam mais trabalho que as carregadas e lentas. Isto resulta no balanceamentode carga automático do sistema. Em segundo lugar, computações não ficam estagnadasenquanto o sistema comporta-se assincronamente ou sob falhas. Em terceiro lugar, no-vas máquinas disponíveis podem ser transparentemente assimiladas para o ambiente deexecução. Finalmente, qualquer máquina trabalhadora pode falhar ou ficar lenta a qual-quer momento sem interferir no resultado final.

42

O mecanismo que analisa a memória e cria os diffs fornece coerência lógicae sincronização, enquanto evita o falso compartilhamento. Atualizações na memória sãoanalisadas para garantir uma execução lógica correta. Uma vez que existe a possibili da-de de múltiplas execuções, é utili zado o mecanismo TIES para garantir que os resulta-dos da execução tenham uma semântica correta.

O sistema conta com estes três mecanismos para assegurar que máquinasdisponíveis serão utili zadas onde elas forem mais necessárias. Uma máquina partici-pante é utili zada para mascarar falhas e/ou aumentar o paralelismo, dependendo do es-tado do sistema. Portanto, o conjunto unificado de mecanismos fornece processamentoparalelo e tolerância à falhas.

5.3 Funcionamento do Sistema

Uma aplicação começa como um programa seqüencial, executando a pri-meira etapa seqüencial. Quando uma etapa paralela é alcançada, um conjunto de threadssão inicializadas. Estas threads compartilham a mesma memória. Após todas as threadscompletarem sua execução, encerra a etapa paralela e começa a próxima etapa seqüen-cial (figura 5.1).

FIGURA 5.1 – Etapas da execução

A computação do Calypso é executada por um gerente e por um conjunto deprocessos trabalhadores que podem mudar de quantidade dinamicamente. Na imple-mentação atual, assume-se que o gerente deve ser um processo confiável (não pode fa-

43

lhar). Os trabalhadores podem ser liberados dinamicamente e ocupados novamente, tra-balhar rápido ou devagar, que não irão afetar o resultado da computação.

Todas as etapas seqüenciais são executadas pelo processo gerente, enquantoque as threads da etapa paralela são executadas pelos processos trabalhadores e contro-ladas pelo gerente. O número de threads em uma etapa paralela é determinado pela apli-cação. Entretanto, o número de trabalhadores usados para executar estas threads depen-dem do ambiente de execução. A atribuição de threads para trabalhadores é realizadapelo gerente em tempo de execução.

Durante a etapa paralela, cada um dos trabalhadores disponíveis contata ogerente e obtém uma atribuição de trabalho, isto é, uma thread não finalizada. Ele entãoprocede para executá-la. Uma vez finalizada, o trabalhador reporta os resultados para ogerente e requisita outra atribuição. Cabe ressaltar que podem existir vários trabalhado-res em um mesmo processador, mas um trabalhador não pode executar mais de umathread simultaneamente. A figura 5.2 apresenta o funcionamento do sistema.

FIGURA 5.2 – Funcionamento da etapa paralela

Quando uma requisição de trabalho é recebida, o gerente atribui uma tarefaque é selecionada seguindo os critérios:

1. A tarefa ainda não foi atribuída a nenhum trabalhador;

2. A tarefa já foi atribuída para um ou mais trabalhadores, mas ainda nãofoi finalizada e foi atribuída para o menor número de trabalhadores.

Estes dois critérios definem de forma simples a estratégia de escalonamentoimpaciente.

O gerente mantém controle sobre as threads que foram atribuídas, as que fo-ram completadas e as que ainda serão atribuídas. Além disso, tem a responsabili dade deatribuir mais tarefas aos trabalhadores. Primeiramente, o gerente prefere atribuir threadsque não tenham sido atribuídas ainda para nenhum trabalhador. No entanto, escalona-

44

mento impaciente caracteriza-se por, se existe trabalho que não foi finalizado, e existeum trabalhador li vre, então o trabalho pode ser novamente atribuído. Isto ocorre no casode haver um número de trabalhadores disponíveis maior do que o número de threads, ouquando todas as threads tiverem sido atribuídas mas não finalizadas, e existirem traba-lhadores impacientes por trabalho. O gerente simplesmente atribui trabalho utili zandoescalonamento impaciente até que todas as threads estejam completas, e neste pontoesta etapa paralela é considerada finalizada. Além de executar a computação que lhe foiatribuída, o trabalhador deve executar operações nas estruturas de dados do gerente, eretornar os resultados ao gerente.

No momento em que a etapa paralela é inicializada, o gerente constrói umatabela de progresso. A tabela de progresso contém as informações necessárias paraexecutar os trabalhadores, e escalonar os trabalhadores com o objetivo de completar aexecução da etapa paralela. A tabela 5.1 apresenta um exemplo de tabela de progresso.

TABELA 5.1 - Tabela de progresso

Etapa End. da função Nº de instâncias Id Inicializada Finalizada

1 0X0AAA 4 0 1 YES

1 0X0AAA 4 1 2 NO

1 0X0AAA 4 2 1 NO

1 0X0AAA 4 3 1 NO

Cada linha da tabela representa uma única thread da etapa paralela. Porexemplo, a última linha indica que a etapa paralela é a primeira, que a thread irá execu-tar determinada função (esta coluna contém o endereço real da função). A terceira colu-na indica o número de cópias (irmãs) que esta thread possui e a quarta coluna seu núme-ro de instância, o número id. A quinta coluna mostra se a thread já foi atribuída paraalgum trabalhador enquanto a sexta controla se a thread já foi finalizada.

O espaço de endereçamento de um programa Calypso é particionado em du-as áreas distintas: privada e compartilhada. A memória privada é propriedade de cadathread. A memória compartilhada é um segmento especial que é visível a todas as par-tes de uma aplicação distribuída, e deve ser declarada e inicializada no começo do pro-grama. Dentro de uma etapa paralela, o acesso global aos dados é realizado de formasimilar ao protocolo de múltiplos escritores utili zado pelo TreadMarks (seção 4.2).

O trabalhador recebe do gerente o endereço da função que deve executar eseus parâmetros. Durante a execução, na primeira vez que um trabalhador acessa umavariável compartilhada protegida, a página correspondente é buscada no gerente, insta-lada no espaço de endereçamento do trabalhador e desprotegida para ser utili zada. Entãoa computação procede. Quando a tarefa termina, o trabalhador cria o diff e envia para ogerente. Então protege suas páginas compartilhadas novamente e contata o gerente paraoutra atribuição.

Dentro de uma etapa paralela, itens de dados podem ser lidos por qualquernúmero de threads e escritos por uma. Neste ponto, o Calypso apresenta funcionamentosemelhante ao TreadMarks onde processos concorrentes podem acessar os mesmos da-

45

dos de uma página para leitura, mas apenas uma delas pode atualizar cada parte da pá-gina. Semanticamente, todas as threads lêem as variáveis compartilhadas no começo daetapa paralela, e escrevem atomicamente no final da etapa paralela.

O gerente aceita a primeira execução completa de cada thread e descarta assubseqüentes. O gerente armazena em um buffer os diffs até o encerramento da etapaparalela corrente, momento no qual todas as atualizações são realizadas. Diferentespartes de uma página podem ser atualizadas por diferentes trabalhadores. Cabe ressaltarque esta condição é um aspecto do projeto lógico do programa. O gerente não controlase uma mesma parte da página está sendo atualizada por mais de um trabalhador. Por-tanto, o programador deve programar a etapa paralela com cuidado para que não existacondição de corrida.

Durante a etapa paralela, os valores lidos pelos trabalhadores são aquelesexistentes no início da etapa, e as atualizações estarão visíveis somente no começo dapróxima etapa. A memória compartilhada é sempre logicamente coerente na medida emque o programa foi implementado.

Páginas que estejam na memória de um trabalhador são mantidas válidasenquanto for possível. Para isto, o gerente sabe em qual etapa a página foi modificadapela última vez. Por exemplo, se uma página foi modificada pela última vez na etapa 4,foi li da por algum trabalhador na etapa 6 e o trabalhador está trabalhando em uma thre-ad na etapa 8, o trabalhador não precisa buscar a página, acessa a cópia que está na suacache. Páginas compartilhadas modificadas são buscadas novamente somente quandonecessárias. Requisições de invalidação são enviadas na mensagem de atribuição detrabalho e causam custo adicional muito pequeno.

46

6 Milli pede

Milli pede é um sistema que integra os recursos e serviços de arquiteturasdistribuídas em uma Máquina Vir tual Paralela (VPM – Virtual Parallel Machine). Oambiente virtual escolhido pelo Milli pede assemelha-se ao ambiente multi thread dosmultiprocessadores simétricos (SMP – Symetric Multi -Processor). Isto permite que pro-gramas paralelos utili zados em SMP possam ser facilmente adaptados. Além disso, oMilli pede permite a implementação de uma grande variedade de linguagens de progra-mação paralela, bem como vários paradigmas de comunicação e sincronização.

6.1 Arquitetura do Sistema

Milli pede é uma camada de software portável para programação utili zandomemória compartilhada para arquiteturas de memória distribuída compostas por clustersde estações de trabalho ou computadores pessoais. Possui características como memóriacompartilhada distribuída, balanceamento dinâmico de carga, uma camada de suportepara gerência de tarefas e vários métodos embutidos para otimizar a localidade das refe-rências de memória. A estrutura de camadas de um sistema executando o Milli pede éapresentado na figura 6.1.

FIGURA 6.1 – Estrutura de camadas do Milli pede

As cópias de uma aplicação compartilham um espaço virtual único, comuni-cam-se independente de sua localização através do mecanismo de DSM e sincronizam-se utili zando primitivas do serviço de migração (MGS – Migration Service).

A força do Milli pede deriva de seus mecanismos embutidos. O mapeamentodas páginas de memória e as atividades em execução dependem de dois parâmetros:capacidades do hardware e as exigências de comunicação e computação do programa.Devido a flexibili dade do sistema, é natural para o Milli pede controlar dinamicamente opadrão de execução de acordo com estes parâmetros. Portanto, o programador fica libe-rado de tarefas como balanceamento de carga e distribuição de tarefas. O programadorpode então, preocupar-se em alcançar o maior nível de paralelismo que seja possível ao

Linguagens de Programação

Mill ipedeMigration Services

(MGS) DSM

Serviços do Sistema Operacional

47

código e em manter os serviços exigidos para executar o programa corretamente [FRI97].


A programação com o Mil lipede pode ser feita de várias formas e com vári-as camadas de abstração. Milli pede exporta um conjunto de APIs que podem ser util i-zadas diretamente pelo programador como chamadas externas de sistema, ou podemsuportar a implementação de outras linguagens de programação sobre o Milli pede. Por-tanto, o Milli pede não reescreve os serviços existentes do sistema operacional, mas es-tende estas capacidade provendo APIs adicionais.

A figura 6.2 ilustra os diferentes padrões de interface que podem ser utili za-dos para executar uma aplicação no Milli pede. Os padrões podem variar de programa-ção direta no sistema operacional a programação através de linguagens paralelas de altonível. Milli pede foi planejado para ser utili zado em ambientes não dedicados com recur-sos computacionais disponíveis. Os recursos nestes sistemas podem ser liberados dina-micamente e ocupados novamente, e portanto, o Milli pede deve fornecer este tipo deflexibili dade. O sistema não causa nenhum distúrbio nas outras aplicações existentes nosistema, embora leve em consideração a utili zação destes recursos no momento de deci-dir sobre a distribuição de carga. Várias aplicações podem ser controladas pelo Milli pe-de simultaneamente no ambiente de execução, sendo que o sistema tentará distribuí-lasde forma a otimizar o tempo de execução da aplicação e o desempenho global do siste-ma [ITZ 97].

FIGURA 6.2 – Interface de programação com o Milli pede

48

6.3 Caracter ísticas do Millipede

Esta seção apresenta características importantes do sistema Milli pede, o ba-lanceamento de carga e a gerência da memória.

6.3.1 Balanceamento de Carga

O objetivo do sistema é suportar vários protocolos de balanceamento decarga, cada qual com suas estratégias e otimizações. Inicialmente foram implementadospelo Milli pede dois protocolos simples de balanceamento de carga: esquema de rodízio(round-robin) e esquema de fila central (central queue). No esquema de rodízio, novastarefas são simplesmente atribuídas para processadores conforme o rodízio, sem consi-derar suas cargas. Naturalmente, este esquema pode apresentar problemas de desempe-nho, pois não considera a carga do sistema nem a granulosidade das tarefas. No entanto,sua principal vantagem é a simplicidade, o que garante uma atribuição bastante rápidadas tarefas.

No esquema de fila centralizada, um processo de gerência de fila é iniciali-zado em uma das máquinas. Quando novas tarefas forem criadas, elas são primeiro en-viadas para o gerente da fila, o qual armazena estas tarefas em uma fila FIFO (First-In-First-Out). Cada máquina tem um gerente de carga local, o qual controla o número detarefas do Milli pede executadas por este processador. Se este número estiver abaixo deum determinado nível, o gerente de carga local envia uma requisição de mais tarefaspara o gerente central. Quando o gerente central recebe tal requisição, ele remove a pri-meira tarefa da fila e a envia para a máquina que fez a requisição. Se não existirem tare-fas na fila quando chegar uma requisição, então esta requisição é armazenada em umbuffer até que alguma tarefa seja enviada para a fila. Se existirem várias requisições detarefas pendentes quando uma tarefa for recebida pelo gerente central, então ele escolheuma delas de acordo com alguma política.

Esta proposta deve comportar-se melhor do que o esquema de rodízio, umavez que leva em consideração a carga das máquinas. Por outro lado, permanece longe deuma solução ótima, pois não considera a carga da máquina que não seja resultado detarefas do Milli pede. Além disso, este esquema não dá importância ao número de aces-sos remotos causados por colocar uma tarefa em uma máquina e não colocar em outra.Pesquisas para desenvolver esquemas que considerem estas características estão sendodesenvolvidos [DUB 98].

6.3.2 Gerente de Memór ia Distr ibuído

Um dos principais objetivos de desenvolver um gerente de memória distri-buído é evitar a centralização do mecanismo de gerência de memória. No gerente dememória distribuído o espaço global de memória compartilhada é dividido em segmen-tos de mesmo tamanho. Esta divisão é realizada de acordo com a previsão do númeromáximo de máquinas que farão parte da execução da aplicação. Cada máquina passa agerenciar uma parte da memória global.

No momento em que ocorre um acesso a dados que não estejam disponíveislocalmente, uma requisição de acesso deve ser enviada para a máquina que mantémestes itens de dados. O gerenciador de memória desta máquina irá providenciar estes

49

dados. Quando trata-se de um grande número de variáveis, alocadas em tempo de exe-cução para várias máquinas diferentes, esta proposta alcança o efeito desejado, pois acarga resultante de referências externas de memória não são concentradas em um ge-rente central, mas divididas entre os processadores.

Além disso, toda requisição para alocação de memória compartilhada é su-prida em parte do segmento de memória compartilhada que é controlado localmente.Neste sentido, se várias requisições de alocação de memória são realizadas concorren-temente, elas serão satisfeitas simultaneamente, e portanto, alcançando alto grau de pa-ralelismo. Isto também serve para aumentar o paralelismo e a localidade de referência,quando as tarefas que requisitaram memória adicional começarem a utili zá-la. Caberessaltar que, uma tarefa compartilha a memória alocada com seus descendentes (fi-lhos), desde que estes não tenham migrado para alguma máquina remota, portanto alocalidade é mantida neste ponto também.

6.4 Memór ia Compar tilhada Distr ibuída

Milli pede suporta memória compartilhada distribuída com vários modelosde consistência de memória. Além disso, exporta chamadas de funções para alocação damemória compartilhada e para manipular acessos a estas posições de memória.

A biblioteca de DSM do Milli pede é uma implementação baseada em pági-na de memória compartilhada distribuída. As estruturas de dados de controle e os algo-ritmos para localizar as cópias das páginas e manter suas capacidades de acesso são dis-tribuídas e não utili zam broadcast e nem diretório centralizado. O método utili zadoconsiste que todas as máquinas mantenham uma tabela de página que contenha infor-mações a respeito da localização das cópias das páginas.

Uma requisição de alocação é executada através de uma chamada a API doMilli pede, especificando o tamanho necessário para a alocação e o modelo de consis-tência de memória correspondente a esta alocação. Com o objetivo de eliminar o falsocompartilhamento, Milli pede pode preencher com uma alocação o tamanho de uma pá-gina inteira, ou seja, a alocação não irá compartilhar a página com outras alocações.Alocações podem ser realizadas a qualquer momento durante a execução. O ponteirorecebido pode ser utili zado tão logo a alocação seja finalizada. Alocações com diferen-tes modelos de consistência são mapeadas em diferentes páginas, portanto, o protocolode consistência é forçado por página. Cada página é marcada com “sua consistência”,sendo que em uma falha de acesso de leitura/escrita a marca é verificada e o protocoloapropriado é ativado.

Em modelos de consistência de memória relaxados as cópias da página queestão distribuídas entre várias máquinas, podem assumir consistência somente se méto-dos explícitos de sincronização são ativados. O método de consistência é determinadopelo tipo de consistência que é marcado nas propriedades da página. Uma vez que alo-cações de diferentes modelos de consistência vão para páginas separadas, sincronizaruma variável pode causar que aquela página seja sincronizada sem perder a correção.Sincronização em modelos de consistência relaxado freqüentemente exigem uma gran-de quantidade de comunicação para realizar a invalidação de cópias não locais e outrasoperações que consomem tempo como a criação de diffs das páginas e a composição deseus conteúdos.

50

Milli pede implementa DSM baseado em página anexando um gerente defalha de acesso para as tarefas ativas e mantendo a proteção da página. Uma tarefa quedeseje utili zar a memória compartilhada é registrada pelo gerente de acessos para pro-pósitos de DSM. Uma falha de leitura ou escrita a região compartilhada causa uma falhade acesso, então é requisitada uma cópia da página (de acordo com o protocolo de con-sistência da página). Cada máquina possui uma tabela de página que mantém informa-ções relacionadas com a localização das cópias de todas as páginas, seus modelos deconsistência, e mais algumas informações por página. O gerenciamento das páginas e alocalização das mesmas no sistema é realizada de maneira distribuída de acordo com oalgoritmo descrito em [ITZ 97].

Os modelos de consistência de memória que são suportados na implementa-ção corrente [ITZ 99] incluem: consistência seqüencial, onde somente uma única cópiada página é permitida no sistema; outro protocolo de consistência seqüencial que per-mite uma única página com permissão de escrita ou várias páginas com permissão deleitura; e um protocolo de consistência fraca que permite várias cópias com permissãode leitura e apenas uma com permissão de escrita.

Além desses modelos, existe um modelo de consistência relaxado de múlti-plos escritores, chamado de Sync Consistency. Este modelo permite vários escritorespara a mesma página (e para a mesma posição de memória). A consistência é garantidapor chamadas explícitas aos métodos de sincronização, o qual propaga os diffs entre asmáquinas e resolve as ambigüidades. Existe ainda um outro modelo de consistência,chamado de Commom Sync Consistency, que é uma variação do Sync Consistency.Neste modelo a granulosidade das operações de leitura e escrita são pré-determinadas, eescritas concorrentes ao mesmo endereço são permitidas (com alguma política para re-solver as ambigüidades).

6.5 Interação entre Jobs Móveis

O Milli pede estende o termo thread/processo, adicionando um atributo demobili dade. O sistema utili za o termo job para fazer referência a thread que é capaz demover-se entre as máquinas. O Milli pede determina em tempo de execução onde equando mover os jobs com o objetivo de otimizar a utili zação dos recursos disponíveis.

Diferentes paradigmas de programação de alto-nível apresentam diferençasna semântica das primitivas de comunicação e sincronização. Com o objetivo de supor-tar vários paradigmas de programação, o Milli pede foi projetado para incorporar novosesquemas de comunicação e sincronização como procedimentos comuns. Devido a na-tureza dinâmica do Milli pede, que permite mobili dade, uma característica importante éque jobs podem comunicarem-se independente de sua localização.

O sistema fornece um mecanismo para comunicação entre jobs móveis,chamado Milli pede Job Event Control (MJEC). MJEC é robusto e flexível para permi-tir a implementação de uma variedade de métodos de sincronização (variáveis de condi-ção, monitores, semáforos, barreiras, locks, ...). Geralmente, isto é feito por um mapea-mento ativo (active mapping) de procedimentos e operações complicadas para os meca-nismos do MJEC.

Sempre que um job é criado é atribuído a ele um número de identificaçãoúnico chamado de uj id. O ujid é universal (por aplicação) e não muda quando um job

51

migra de uma máquina para outra. O Milli pede suporta comunicação entre jobs móveisatravés de mailboxes de eventos. Essencialmente, um evento é uma mensagem que podeser enviada para qualquer job. O endereçamento da mensagem é feito utili zando o ujid,independente da localização corrente do job no sistema. Mensagens enviadas são rotea-das de forma confiável pelo Milli pede para o job destino, desde que este job ainda existano momento que a mensagem chegue. Um evento recebido pelo job destino é enfileira-do numa fila de eventos. Dependendo do seu estado, o job destino é notificado da che-gada do evento ou não, e neste caso, o evento é armazenado na fila até que seja explici-tamente recuperado. A fila de eventos faz parte do job, portanto, sempre que um jobmigra sua fila de eventos o acompanha.

52

7 Comparação

Este capítulo tem como objetivo apresentar as diferenças e semelhanças en-tre as implementações de sistemas DSM apresentados nos capítulos anteriores (3, 4, 5 e6).


Todas as implementações caracterizam-se por permitir que processos em di-ferentes processadores compartilhem dados de forma transparente. Caracterizam-setambém por buscarem algum nível de portabili dade. A diferença é que o sistema Orcaalcança portabili dade com a utili zação de uma máquina virtual. Nenhuma requer modi-ficações no sistema operacional nem hardware adicional.

Existem sistemas que administram o processamento paralelo de forma ex-plícita (paralelismo explícito), por meio de construções específicas para tal fim. Nestessistemas o programador é responsável por paralelizar a aplicação. Em contraste, existemsistemas que controlam o paralelismo de maneira implícita (paralelismo implícito), ouseja, o compilador e o sistema de execução tratam do paralelismo. Entretanto, é difícilencontrar sistemas que implementem totalmente estas características de forma eficiente.

Em todos os sistemas apresentados neste trabalho o paralelismo é explícito,pois fica a cargo do programador definir quais tarefas serão executadas concorrente-mente. Uma vez que o paralelismo é explícito, o programador precisa expressar a con-corrência. Para isto, o sistema deve fornecer uma nova linguagem ou uma biblioteca defunções que possa ser utili zada em linguagens já existentes. Orca é uma linguagem quefoi projetada especificamente para implementação de aplicações concorrentes em siste-mas de memória distribuída. Em contraste, os outros sistemas fornecem APIs com pri-mitivas de programação paralela e memória compartilhada que funcionam em lingua-gens seqüenciais existentes.

Visto que o TreadMarks, o Calypso e o Milli pede fornecem APIs, é possívela reutili zação de código de programas de memória compartilhada (multiprocessadores)com pouca modificação, desde que, estes programas tenham sido desenvolvidos emlinguagens que sejam suportadas pelos sistemas. No caso de uma aplicação seqüencial,o problema deve ser paralelizado utili zando as primitivas da biblioteca do sistema.Além disso, é necessário indicar quais estruturas de dados são compartilhadas. No Orcaa aplicação deve ser completamente desenvolvida em uma nova linguagem. Uma vanta-gem de utili zar uma linguagem própria é que a implementação pode beneficiar-se desuporte de compilação. A desvantagem de utili zar uma nova linguagem é que é difícilreutili zar código existente escrito em outras linguagens.

A unidade de coerência do Orca é o objeto. No Orca as estruturas de dadoscompartilhadas são encapsuladas em objetos. Uma vantagem desta propriedade é que orisco de falso compartilhamento é reduzido (mas não eliminado), pois normalmentesomente dados logicamente relacionados são armazenados no mesmo objeto. Comodesvantagem, uma vez que somente objetos podem ser compartilhados, programas dememória compartilhada existentes devem ser reestruturados antes de serem utili zadosno modelo Orca. A característica principal do Orca é acessar as estruturas de dadoscompartilhadas através de operações de alto nível. Para isto, os programadores definemoperações (métodos) para manipular as estruturas de dados compartilhadas. Em con-

53

traste, os outros sistemas utili zam instruções de baixo nível para ler, escrever e realizarlock nos dados compartilhados. A unidade de coerência dos outros sistemas é a página.Com DSM baseado em páginas, dados não relacionados podem ser armazenados namesma página, resultando em falso compartilhamento. Entretanto, isto é evitado com autili zação de protocolos de múltiplos escritores.

O Orca utili za os algoritmos SRSW e MRSW. Para os objetos que o sistemaopta por não replicar, o algoritmo de acesso é SRSW. Para os objetos replicados o com-portamento assemelha-se ao algoritmo MRSW, pois determinados métodos (aquelesque não realizem atualizações) podem executar concorrentemente nas réplicas, no en-tanto, no momento que um método que atualize o objeto esteja executando, todas asréplicas do objeto ficam bloqueadas. O TreadMarks e o Calypso utili zam o algoritmoMRMW. No Millipede, o algoritmo util izado depende do modelo de consistência dememória associado a determinada página.

No Calypso a sincronização é implícita. A API do sistema não fornece pri-mitivas de sincronização. É responsabili dade do programador controlar para que nãoocorram acessos de escrita concorrentes à mesma posição de memória. A sincronizaçãoé imposta pelo sistema no final de cada etapa paralela. O final da etapa paralela corres-ponde a primitiva de barreira, pois todos os processos devem ter sido finalizados antesque seja permitido que comece uma nova etapa seqüencial.

No Orca a sincronização é implícita. O modelo de objetos compartilhadosassemelha-se à utili zação de monitores. Em ambos, a exclusão mútua é realizada pelosistema ao invés do programador. A sincronização de condição do Orca utili za um me-canismo de alto nível baseado nos comandos de guarda de Dijkstra [BAL 98]. A vanta-gem é a simplicidade de programação, pois o programador não precisa utili zar primiti-vas de sincronização. Entretanto, a sincronização implícita é menos flexível.

O TreadMarks utili za primitivas que explicitamente realizam a sincroniza-ção. O modelo fornece primitivas de obtenção e liberação de locks e barreiras. No Mi-lli pede a sincronização também é explícita. Este sistema suporta a implementação deuma variedade de métodos de sincronização através do mecanismo MJEC.

O modelo de consistência de memória do Orca é seqüencialmente consis-tente. Contudo, apresenta semelhanças com a consistência de entrada. Operações contí-nuas nos objetos compartilhados são executadas conforme o modelo de consistênciaseqüencial, mas leituras e escritas individuais a palavras de memória dentro de uma ope-ração não são visíveis para os outros processos até que a operação esteja completa, umavez que operações são executadas atomicamente. Em termos de acessos individuais amemória, o modelo Orca é similar a consistência de entrada, mas sem a necessidade doprogramador associar variáveis de lock com os objetos.

O TreadMarks utili za o modelo de consistência de liberação preguiçosa. OMilli pede suporta vários modelos de consistência de memória. O Calypso força a con-sistência no final das etapas paralelas. Escritas realizadas durante a etapa paralela nãosão observadas pelos outros processadores até que termine a etapa paralela em execu-ção. Este esquema assemelha-se à consistência de liberação.

54

7.2 Sistema de Execução

Quando a memória compartilhada é modificada por um processador, o sis-tema de DSM deve assegurar que outros processadores serão notificados da mudança,para que não tenham dados obsoletos. No TreadMarks, no Calypso e no Mili pede estanotificação não é imediata nem global. Notificação imediata seria realizada freqüente-mente e notificação global normalmente iria enviar para processadores informações quenão seriam pertinentes a maioria deles. Ao invés, esta notificação entre dois processos érealizada quando eles são sincronizados. Programas livres de condições de corrida pro-duzem o mesmo resultado se a notificação for imediata ou postergada até a sincroniza-ção, e a acumulação de várias notificações em uma única mensagem no momento dasincronização reduz o overhead de comunicação entre processos. No Orca acontece ocontrário, a notificação é global e imediata. Entretanto, as análises de desempenho reali-zadas por [BAL 98] demonstram que utili zando as estatísticas de tempo de execução, osistema é capaz de decidir como os objetos estarão distribuídos entre os processadores econseqüentemente como estas notificações serão realizadas, não ocasionando altooverhead.

Em todos os sistemas a criação de processos (Orca e TreadMarks), threads(Calypso) e jobs (Milli pede) é realizada dinamicamente (em tempo de execução) masexige que sejam especificados pelo programador (criação explícita).

O sistema de execução é responsável por gerenciar a concorrência e a me-mória compartilhada. Todos os sistemas fazem distinção entre memória compartilhada enão compartilhada. Implementam as características de migração e replicação e o proto-colo de coerência para as cópias replicadas.

Nos três sistemas baseados em páginas apresentados, uma vez que determi-nada página é utili zada por vários processadores, tantas cópias quanto forem necessáriassão replicadas no sistema. No Orca, o sistema de execução é que determina quais obje-tos serão replicados, quais serão migrados, dependendo do comportamento da aplicação.Tudo é realizado de forma implícita.

O sistema de execução do Orca é responsável pela distribuição física dosobjetos entre a memória física dos processadores. O compilador do Orca além de tradu-zir os programas gera informações que serão utili zadas pelo sistema de execução paraque este decida quais dados compartilhados devem ser replicados, em qual processadora cópia ou cópias destes dados devem estar fisicamente presentes. Além destas informa-ções estáticas (criadas pelo compilador), o sistema utili za estatísticas sobre o compor-tamento dos objetos para tomar estas decisões.

Orca utili za protocolo de atualização baseado em expedição de função ecomunicação de grupo totalmente ordenado, enquanto os outros modelos utili zam pro-tocolo de invalidação que utili zam o sistema de diffs. O TreadMarks permite que a cria-ção de diffs seja adiada até que as modificações sejam requisitadas – criação preguiçosade diffs.

O balanceamento de carga no Orca e no TreadMarks fica a cargo do pro-gramador (explícito), enquanto que no Calypso e no Milli pede o sistema de execução éque controla o balanceamento de carga entre os processadores. Isto permite que os re-cursos nestes sistemas possam ser liberados dinamicamente e ocupados novamente,sendo que o sistema fornece este tipo de flexibili dade. Portanto, o número de máquinasque participam da execução pode variar dinamicamente.

55

O Calypso e o Milli pede separam o paralelismo lógico do paralelismo físi-co. Nas primitivas que expressam a concorrência não existe o processador onde deter-minada tarefa deve executa. No Orca e no TreadMarks deve ser indicado em qual pro-cessador determinado processo deve executar, caso contrário a execução será no mesmoprocessador do processo pai.

Outras características que merecem destaque é suporte à mobili dade e tole-rância à falhas. O sistema Milli pede é o único que tem suporte à mobili dade. O sistemade execução do Calypso implementa características de tolerância à falhas.

A tabela 7.1 apresenta algumas das características comparadas neste capí-tulo.

TABELA 7.1 - Comparação entre os sistemas

SistemaCaracterística

Orca TreadMarks Calypso Milli pede

Suporte à programação Linguagem API API API

Utilização de máquina virtual�

Unidade de coerência Objeto Página Página Página

Acesso aos dados compartilhados Métodos Direto Direto Direto

Algoritmos

SRSW� �

MRSW� �

MRMW� � �

Sincronização Implícita Explícita Implícita Explícita

Consistência de memória

Seqüencial (SC)� �

Processador (PC)

Fraca (WC)�

Liberação (RC)� �

Liberação Preguiçosa (LRC)�

Entrada (EC)�

Protocolo de coerência

Protocolo de atualização�

Protocolo de invalidação� � �

Expressão da concorrência Processos Processos Threads Jobs

Balanceamento de carga� �

Suporte à mobilidade�

Tolerância à falhas�

56

8 Conclusão

Devido às vantagens combinadas dos sistemas de memória compartilhada edistribuída, propostas de DSM aparecem como sendo uma solução viável tanto parasistemas em larga escala e de alto desempenho como para serem aplicados em redes deestações de trabalho. Entretanto, o custo de desenvolvimento do software paralelo per-manece praticamente o mesmo.

Inúmeras pesquisas têm sido realizadas tanto pela comunidade científicacomo pelo meio empresarial, no sentido de viabili zar a utili zação de sistemas DSM.Considera-se que grandes melhorias poderão ser alcançadas também com avanços naárea de arquitetura de computadores, mais especificamente nas características de memó-ria e topologias de interconexão.

Este trabalho apresentou vários conceitos e características de sistemas DSM.Inicialmente, foi realizada uma introdução com alguns aspectos históricos do desenvol-vimento destes sistemas, para então seguir em temas como a estrutura arquitetural, aestrutura e a distribuição dos dados e como manter a coerência entre eles, um exemplogenérico de funcionamento e os algoritmos. Posteriormente, foi abordado o problema degerenciamento do mecanismo de DSM, os modelos de consistência de memória e o ní-vel de implementação do mecanismo de DSM. Finalmente, as considerações finais indi-caram alguns aspectos importantes e que continuam foco de pesquisa. O restante dotrabalho analisou quatro implementações de sistemas DSM por software e realizou umacomparação entre eles.

Várias propostas de DSM que integram mecanismos implementados emhardware com mecanismo implementados em software têm sido desenvolvidas. Issopara alcançar um melhor desempenho (característica inerente as implementações porhardware) com maior flexibili dade e um custo aceitável (característica das implementa-ções por software).

Os sistemas de DSM implementados por software possuem a grande vanta-gem de funcionarem sem a necessidade de modificação nas redes de computadores ins-taladas. No entanto, estas propostas precisam ser providas de mecanismos para que pos-sam alcançar desempenho semelhante às implementações por hardware. Melhorias naspropostas de software têm sido foco de várias pesquisas. Muitas destas pesquisas temcomo objetivo reduzir a latência de memória para alcançar um conseqüente aumento dedesempenho. Pode-se ressaltar como pesquisas promissoras: melhorar os algoritmos emecanismos de DSM e adaptá-los às características das aplicações e configurações desistemas; integrar os paradigmas de troca de mensagens e memória compartilhada;combinar vários modelos de consistência.

Como trabalho futuro, os sistemas de DSM apresentados neste trabalho po-deriam ser instalados no Instituto de Informática para serem realizados testes de facil i-dade de programação e análise de desempenho.

57

Bibliografia

[ADV 90] ADVE, Sarita V. ; HILL, M. D. Weak Ordering – A New Definition. InANNUAL INTERNATIONAL SYMPOSIUM ON COMPUTERARCHITECTURE , ISCA, 17., 1990. Proceedings..., 1990.

[ADV 93] ADVE, Sarita V. ; HILL, M. D. A Unified Formalization of Four Shared-Memory Models. IEEE Transactions on Parallel and Distr ibutedSystems, New York, v. 4, n. 6, p. 613-624, June 1993.

[ADV 99] ADVE, Sarita V. et al. Recent Advances in Memory Consistency Modelsfor Hardware Shared Memory Systems. Proceedings of the IEEE,Special Issue on Distr ibuted Shared Memory, New York, v. 87, n.3, p. 445-455, Mar 1999.

[AMO 96] AMORIM, C. L. et al. A Segunda Geração de Computadores de Alto De-sempenho da COPPE/UFRJ. In: SIMPÓSIO BRASILEIRO DE AR-QUITETURA DE COMPUTADORES E PROCESSAMENTO DEALTO DESEMPENHO, 8., 1996, Recife. Anais... Recife: SBAC-PAD, 1996. 245p. p. 87-98.

[AMZ 96] AMZA, Cristiana et al. TreadMarks: Shared Memory Computing onNetwork of Workstations. IEEE Computer, New York, v. 29, n. 2, p.18-28, Feb. 1996.

[ARA 96] ARANTES, Luciana B. ; SATO, Liria M. Um Sistema de ProgramaçãoParalela com Variáveis Compartilhadas para Arquiteturas Distribuí-das. In: SIMPÓSIO BRASILEIRO DE ARQUITETURA DE COM-PUTADORES E PROCESSAMENTO DE ALTO DESEMPENHO,8., 1996, Recife. Anais... Recife: SBAC-PAD, 1996. 245p. p. 109-118.

[ARA 98] ARAUJO, Edvar B. LPECS - Logic Programming EnvironmentConfigurator for Schedulli ng. Pelotas: UCPel, 1998, 86p. Projeto deConclusão de Curso.

[BAL 92] BAL, Henri E. et al. Orca: A Language for Parallel Programming ofDistributed Systems. IEEE Transactions on Software Engineering,New York, v. 18, n. 3, p. 190-205, Mar 1992.

[BAL 98] BAL, Henri E. et al. Performance Evaluation of the Orca Shared ObjectSystem. ACM Transactions on Computer Systems, New York, v.16, n. 1, Feb. 1998.

[BAR 95] BARATLOO, Arash et al. CALYPSO: A Novel Software System forFault-Tolerant Parallel Processing on Distributed Plataforms. In: IEEEINTERNATIONAL SYMPOSIUM ON HIGH PERFORMANCEDISTRIBUTED COMPUTING, HPDC, 4., 1995 Proceedings...,1995, p. 122-129, Aug. 1995.

58

[BAR 99] BARATLOO, Arash et al. Calypso: An Environment for ReliableParallel Computing. Disponível por WWW emhttp://www.cs.nyu.edu/milan/publications/msd97/index.html (23 maio1999).

[DUB 98] DUBROVSKI, Alex et al. Load Balancing in Distributed Shared MemorySystems. International Journal of Applied Software Technology, v.3, p. 167-202, Mar. 1998.

[FRI 97] FRIEDMAN, Roy et al. MILLIPEDE: Easy Parallel Programming inAvailable Distributed Environments. Software - Practice andExper ience, v. 27, n. 8, p. 925-965. Aug. 1997.

[HWA 93] HWANG, Kai. Advanced Computer Architecture. Paralelism,Scalabili ty, Programmabili ty. McGraw-Hill , 1993.

[ITZ 97] ITZKOVITZ, Ayal et al. Supporting Multiple Parallel ProgrammingParadigms On Top Of The Milli pede Virtual Parallel Machine. In:INTERNATIONAL WORKSHOP ON HIGH LEVE PRO-GRAMMING MODELS AND SUPPORTIVE ENVIRONMENTS,HIPS, 1997. Proceedings..., 1997, p. 25-34.

[ITZ 99] ITZKOVITZ, Ayal et al. The Milli pede Vir tual Parallel Machine forNT/PC Clusters. Disponível por WWW emhttp://dsl.cs.technion.ac.il/Milli pede/milli pede_publications.html (02junho 1999).

[KAA 92] KAA SHOED, M. F. Group Communication in Distr ibuted ComputerSystems. Amsterdan: Vrije University, 1992. Ph.D. Thesis.

[KEL 94] KELEHER, Pete et al. TreadMarks: Distributed Shared Memory onStandard Workstations and Operating Systems. In: WINTER USENIXCONFERENCE, 1994. Proceedings..., 1994, p. 115-131.

[KEL 98] KELEHER, Pete et al. Lazy Release Consistency for Software DistributedShared Memory. In: PROTIC, Jelica et al. Distr ibuted SharedMemory: Concepts and Systems. Los Alamitos, Cali fornia: IEEEComputer Society Press, 1998, p. 96-104.

[LAM 79] LAMPORT, L. How to Make a Multiprocessor Computer that CorrectlyExecutes Multiprocess Programs. IEEE Transactions onComputers, v. 28, n. 9, p. 690-691, Sept. 1979.

[LI 86] LI, KAI. Shared Vir tual Memory on Loosely CoupledMultiprocessors. New Haven, Conn.: Dept. of Computer Science,Yale University, 1986. Ph.D. dissertation.

[LI 89] LI, Kai ; HUDAK, Paul. Memory Coherence in Shared Virtual MemorySystems. ACM Transactions on Computer Systems, New York, v.7, n. 4, p. 321-359, Nov. 1989.

59

[LO 94] LO, Virginia. Operating Systems Enhancements for Distributed SharedMemory. Advances in Computer. Academic Press, San Diego, v. 39,p. 191-237, 1994.

[MAR 96] MARINO, Mario D. et al. O Efeito da Compressão de Páginas no sistemaDSM PULSAR. In: SIMPÓSIO BRASILEIRO DE ARQUITETURADE COMPUTADORES E PROCESSAMENTO DE ALTO DESEM-PENHO, 8., 1996, Recife. Anais... Recife: SBAC-PAD, 1996. 245p.p. 139-149.

[MCL 99] MCLAUGHLIN, Donald et al. Calypso NT: Reliable, Eff icient ParallelProcessing on Windows NT Networks. Disponível por WWW emhttp://www.cs.nyu.edu/milan/publications/msd97/index.html no dia23/05/1999.

[MIL 99] MILUINOVIC, V. & STENSTRÖN, P. Scanning the Issue: Special Issueon Distributed Shared Memory Systems. Proceedings of the IEEE,Special Issue on Distr ibuted Shared Memory, New York, v. 87, n.3, p. 399-403, Mar. 1999.

[PIN 96] PINTO, Raquel G. et al. Avaliando Técnicas de Prefetching para SoftwareDSMs. In: SIMPÓSIO BRASILEIRO DE ARQUITETURA DECOMPUTADORES E PROCESSAMENTO DE ALTO DESEMPE-NHO, 8., 1996, Recife. Anais... Recife: SBAC-PAD, 1996. 245p. p.57-66.

[PRO 98] PROTIC, Jelica et al. Distr ibuted Shared Memory: Concepts andSystems. Los Alamitos, Cali fornia: IEEE Computer Society Press,1998.

[SEI 98] SEIDEL, Cristiana B. A Técnica Lock Acquirer Prediction e sua Apli-cação em Sistemas de Memór ia Compartilhada Distr ibuída. Riode Janeiro: COPPE, 1998. Tese de Doutorado.

[SKI 98] SKILLICORN, David B. & TALIA, Domenico. Models and Languagesfor Parallel Computation. ACM Computing Surveys, New York, v.30, n. 2, p. 123-169, June 1998.

[STU 98] STUMM, Michael & ZHOU, Songnian. Algorithms ImplementingDistributed Shared Memory. In: PROTIC, Jelica et al. Distr ibutedShared Memory: Concepts and Systems. Los Alamitos, Cali fornia:IEEE Computer Society Press, 1998, p. 54-64.

[TAN 92] TANENBAUM, Andrew S. et al. Parallel Programming using SharedObjects and Broadcasting. IEEE Computer, New York, v. 25, n. 8, p.10-19, Aug. 1992.

[TAN 95] TANENBAUM, A. S. Distr ibuted Operating Systems. Prentice Hall ,New Jersey, 1995.

um estudo sobre memória compartilhada distribuída · projeto do treadmarks teve como objetivo...

Documents