Um Estudo sobre Memória Compartilhada Distribuída

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM COMPUTAÇÃO Um Estudo sobre Memória Compartilhada Distribuída por EDVAR BERGMANN ARAUJO T.I. 868 PPGC UFRGS Trabalho Individual I Prof. Dr. Cláudio Fernando Resin Geyer Orientador Porto Alegre, agosto de 1999

2 CIP Catalogação na Publicação Araujo, Edvar Bergmann Um Estudo sobre Memória Compartilhada Distribuída / por Edvar Bergmann Araujo Porto Alegre: PPGC da UFRGS, f.: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. Philippe Olivier Alexandre Navaux Coordenadora do PPGC: Profa. Carla Freitas Bibliotecária-Chefe do Instituto de Informática: Beatriz Haro

3 Sumário Lista de Figuras 5 Lista de Tabelas 6 Lista de Abreviaturas 7 Resumo 8 Abstract 9 1 Introdução Tema Motivação Objetivos Estrutura do Texto 12 2 Memória Compartilhada Distribuída Introdução Estrutura Geral de Sistemas DSM Estrutura dos Dados Compartilhados Distribuição e Coerência dos Dados Compartilhados Funcionamento Algoritmos Algoritmos Único Leitor / Único Escritor (SRSW) Algoritmos Vários Leitores / Único Escritor (MRSW) Algoritmos Vários Leitores / Vários Escritores (MRMW) Responsabilidade do Gerenciamento de DSM Modelos de Consistência de Memória Consistência Seqüencial Consistência de Processador Consistência Fraca Consistência de Liberação Consistência de Liberação Preguiçosa Consistência de Entrada Nível de Implementação do Mecanismo de DSM Software Hardware Considerações Finais 28 3 Orca Modelo de Programação Arquitetura do Sistema Características do Orca Protocolo de Coerência 31

4 3.3.2 Estratégia de Disposição dos Objetos Portabilidade Arquitetura do Software 34 4 TreadMarks Modelo de Programação Protocolo de Múltiplos Escritores Consistência de Memória 37 5 Calypso Modelo de Programação Características do Calypso Funcionamento do Sistema 42 6 Millipede Arquitetura do Sistema Modelo de Programação Características do Millipede Balanceamento de Carga Gerente de Memória Distribuído Memória Compartilhada Distribuída Interação entre Jobs Móveis 50 7 Comparação Modelo de Programação Sistema de Execução 54 8 Conclusão 56 Bibliografia 57

5 5 Lista de Figuras FIGURA 2.1 Estrutura geral de um sistema DSM 14 FIGURA 2.2 Exemplo de funcionamento 17 FIGURA 2.3 Segmentos de código de P 0 e P 1 que compartilham A e B 20 FIGURA 2.4 Utilização de sincronização para garantir coerência de A e B 22 FIGURA 2.5 Ordem parcial estabelecida pelas operações de sincronização 23 FIGURA 3.1 Camadas do Orca 30 FIGURA 4.1 Criação de diff 37 FIGURA 4.2 Release vs Lazy Release Consistency 38 FIGURA 4.3 Exemplo de dominância de intervalos 39 FIGURA 5.1 Etapas da execução 42 FIGURA 5.2 Funcionamento da etapa paralela 43 FIGURA 6.1 Estrutura de camadas do Millipede 46 FIGURA 6.2 Interface de programação com o Millipede 47

6 6 Lista de Tabelas TABELA 3.1 Aspectos importantes no projeto do sistema Orca 31 TABELA 5.1 Tabela de progresso 44 TABELA 7.1 Comparação entre os sistemas 55

7 7 Lista de Abreviaturas API ATM CC-NUMA COMA CPU CSL DSM EC FIFO LAN LRC MGS MJEC MRMW MRSW PC RC RMS RPC RTS SC SMP SRSW VPM WC Application Programming Interface Asynchronous Transfer Mode Cache Coherent NoUniform Memory Architectures Cache-Only Memory Architectures Central Processing Unit Calypso Source Language Distributed Shared Memory Entry Consistency First-In-First-Out Local Area Network Lazy Release Consistency MiGration Service Millipede Job Event Control Multiple Reader / Multiple Writer Multiple Reader / Single Writer Processor Consistency Release Consistency Reflective Memory Systems Remote Procedure Call Run-Time System Sequential Consistency Symetric Multi-Processor Single Reader / Single Writer Virtual Parallel Machine Weak Consistency

8 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 espaço de endereçamento lógico, 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 software como em hardware, os sistemas DSM controlam a distribuição física dos dados, oferecendo ao programador acesso transparente à memória virtual compartilhada. O trabalho realiza também uma análise sobre quatro sistemas DSM implementados a nível de software. Orca é uma linguagem para implementação de aplicações concorrentes em sistemas de memória distribuída. Caracteriza-se por permitir que processos em diferentes 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órias locais dos processadores, fornecendo uma memória compartilhada distribuída estruturada. TreadMarks é um software que permite programação concorrente com memória compartilhada em arquiteturas de memória distribuída. Caracteriza-se por executar a nível de usuário em redes de estações de trabalho com sistema operacional Unix. O projeto do TreadMarks teve como objetivo reduzir a quantidade de comunicação necessária para manter a consistência de memória. Para isto utiliza um protocolo de múltiplos escritores e o modelo de consistência de liberação preguiçosa. Calypso é o protótipo de um sistema para escrever e executar programas paralelos em plataformas não dedicadas, utilizando redes de estações de trabalho comerciais, sistemas operacionais e compiladores disponíveis. Calypso implementa características de tolerância à falhas, balanceamento de carga, e utiliza modelo de programação baseado em memória compartilhada. Millipede é um sistema que integra os recursos e serviços de arquiteturas distribuídas em uma máquina virtual paralela. Millipede é uma camada de software para programação utilizando memória compartilhada para arquiteturas de memória distribuída. Implementa características como memória compartilhada distribuída, balanceamento dinâmico de carga, suporte para gerência de tarefas e vários métodos embutidos para otimizar a localidade das referências de memória. Palavras-chave: memória compartilhada distribuída, sistemas distribuídos.

9 9 Abstract This work presents a study on Distributed Shared Memory (DSM). A system DSM offers the abstraction of a logical address space, which all the processors of a distributed architecture have access, in spite of, physically, the memory to be local to each one of them. Implemented so much in software as in hardware, the DSM systems controls the physical distribution of the data, offering to the programmer transparent access to the shared virtual memory. This work also presents an analysis of four software DSM systems. Orca is a language for implementing concurrent applications in distributed memory systems. It is characterized by allowing that processes in different machines share data, being these data encapsulated in objects of data. The Orca s runtime system management 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 shared memory in architectures of distributed memory. It is characterized by executing user's level in network of workstations with operating system Unix. The project of TreadMarks had as objective to reduce the amount of necessary communication to maintain the consistency of memory. For this it uses a protocol of multiple writers and the lazy release consistency model. Calypso is a prototype software system for writing and executing parallel programs on non-dedicated platforms, using commercial network of workstations, operating systems, and compilers. Calypso implements characteristics like fault tolerance, load balancing, and it uses programming model based on shared memory. Millipede is a system that integrates the resources and services of distributed computational environments into virtual parallel machines. Millipede is a software layer for programming using shared memory for distributed memory architectures. It implements characteristics as distributed shared memory, load balancing, support for management of tasks and several built-in methods for otimizing the locality of the memory references. Keywords: distributed shared memory, distributed systems

10 10 1 Introdução 1.1 Tema O tema deste trabalho é o estudo das características de sistemas de Memória Compartilhada Distribuída (DSM Distributed Shared Memory), e de algumas propostas de mecanismos de DSM implementados por software. 1.2 Motivação As tecnologias de microeletrônica têm permitido uma melhora substancial na velocidade de processamento, mas sempre dentro de limites físicos bem estabelecidos. 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 tecnologias é o fato de hoje ser simples construir sistemas de computação compostos por um grande número de processadores interligados através de redes de alta velocidade. Portanto, a exploração do processamento paralelo e distribuído é uma das formas de ampliar os limites de desempenho dos sistemas computacionais [ARA 98]. Nos multiprocessadores (memória compartilhada) duas ou mais CPU s compartilham uma memória principal comum. Qualquer processo ou processador pode ler ou escrever qualquer palavra na memória compartilhada. Ao contrário, nos multicomputadores (memória distribuída) cada CPU tem sua própria memória privada, sendo que 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 utilizam a mesma memória física simultaneamente não é uma tarefa trivial, sendo que pode tornar-se bastante complexa dependendo do número de processadores. Esta característica limita a escalabilidade deste tipo de arquitetura. Por outro lado, grandes multicomputadores são simples de construir [TAN 95]. No que diz respeito ao software paralelo, em geral, o programador deve preocupar-se em estabelecer a interação entre os processos paralelos. Os dois principais paradigmas de programação paralela são troca de mensagens e memória compartilhada. A programação no paradigma de memória compartilhada é considerada mais simples, pois evita que o programador preocupe-se com a comunicação entre processos, através de troca explícita de mensagens. Para realizar comunicação, um processo apenas escreve dados na memória para serem lidos por todos os outros. Para sincronização, seções críticas podem ser usadas, com a utilização de semáforos ou monitores para garantir exclusão mútua. No paradigma de troca de mensagens a comunicação é realizada através de primitivas que explicitamente controlam o deslocamento dos dados. Troca de mensagens apresenta várias dificuldades, entre elas controle de fluxo, mensagens perdidas, controle do buffer (buffering) e bloqueio (blocking). Embora várias soluções tenham sido propostas, programação com troca de mensagens permanece complicada.

11 11 Em resumo, multicomputadores são simples de construir mas difíceis de programar, sendo os multiprocessadores o oposto, difíceis de construir mas simples de programar [TAN 95]. Nos últimos anos tem crescido o interesse por sistemas de memória compartilhada distribuída. Estes sistemas permitem a integração da escalabilidade de memória distribuída com a maior facilidade de programação de memória compartilhada [AMO 96]. Um sistema DSM oferece a abstração de um espaço de endereçamento lógico, 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 software como em hardware, os sistemas DSM controlam a distribuição física dos dados, oferecendo ao programador acesso transparente a memória virtual compartilhada [ARA 96]. Portanto, o objetivo principal dos mecanismos de DSM é ocultar a comunicação do programador e fornecer um modelo de programação baseado em dados compartilhados ao invés de troca de mensagens. Além disso, aproveitam a escalabilidade e a relação custo/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ísticas devem ser implementadas pelo ambiente de execução que fornece a abstração de DSM. Portanto, simplifica a programação de tarefas tais como particionamento de dados e distribuição dinâmica de carga. Os sistemas DSM permitem que aplicações desenvolvidas para sistemas de memória compartilhada possam ser modificadas de forma relativamente fácil para executarem em memória distribuída, preservando os investimentos em software. Entretanto, 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 e um ambiente de programação conveniente para aplicações paralelas e distribuídas tem feito o assunto foco de numerosas pesquisas nos últimos anos. Atualmente, as pesquisas realizadas nesta área estão voltadas para o desenvolvimento de propostas para minimizar o tempo de acesso aos dados compartilhados enquanto mantém a consistência entre eles. 1.3 Objetivos O objetivo geral deste trabalho consiste no estudo de características de sistemas 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 Estrutura do Texto O capítulo dois introduz as características e os conceitos de sistemas de memória compartilhada distribuída, dentre as quais a estrutura geral do sistema, manutenção da coerência dos dados, modelos de consistência de memória, nível de implementação do mecanismo. Muitas implementações de DSM têm sido descritas na literatura [PRO 98]. Entretanto, a maioria delas não é muito utilizada por executarem em plataformas dedicadas, ao invés de executarem nas arquiteturas e nos sistemas operacionais disponíveis. Os capítulos seguintes abordam quatro sistemas DSM implementados em software que não exigem hardware adicional nem modificações no sistema operacional. Os modelos são o Orca (capítulo três), o TreadMarks (capítulo quatro), o Calypso (capítulo cinco) e o Millipede (capítulo seis). No capítulo sete, uma breve comparação entre os modelos é apresentada. Finalmente, o capítulo oito conclui o trabalho.

13 13 2 Memória Compartilhada Distribuída Este capítulo apresenta conceitos de memória compartilhada distribuída. O objetivo é estabelecer de forma resumida aspectos importantes de sistemas DSM. Estes conceitos estão organizados de forma a introduzir gradativamente o assunto. 2.1 Introdução No começo da utilização dos sistemas distribuídos, assumia-se implicitamente que processos em máquinas com memória distribuída executavam em espaços de endereçamento disjuntos, sendo a comunicação entre eles vista em termos de troca de mensagens. Em 1986, Kai Li [LI 86] propôs um esquema diferente, agora conhecido por Distributed Shared Memory (DSM). Resumindo, Li e Hudak propuseram uma coleção de estações de trabalho conectadas por uma LAN (Local Area Network) compartilhando um espaço de endereçamento virtual único [LI 89]. Na variação mais simples, cada página está presente exatamente em uma máquina. Qualquer processador pode acessar diretamente qualquer posição do espaço de endereçamento virtual compartilhado. Os gerenciadores de memória do mecanismo de DSM implementam o mapeamento entre a memória local e este espaço de endereçamento. Para estes gerenciadores, a memória local de um processador é considerada como uma grande cache do espaço de endereçamento compartilhado. Referências à páginas locais são resolvidas por hardware, na velocidade da memória, enquanto que, referências à páginas presentes em outras máquinas causam falha de página (page fault). Então, o sistema DSM responsabiliza-se por mandar uma mensagem para a máquina remota, a qual encontra a página necessária e a envia para o processador destino. Essencialmente, esta proposta é similar ao tradicional sistema de memória virtual, com a diferença de ao invés de buscar as páginas no disco, buscá-las em outra máquina da rede. Toda comunicação e sincronização pode ser feita através da memória, sem comunicação visível para os processos de usuário. Memória compartilhada distribuída pode ser intimamente relacionada com arquitetura de computadores, sistemas operacionais, ambientes de execução e linguagens de programação. 2.2 Estrutura Geral de Sistemas DSM A organização básica de um sistema DSM é similar a de um multicomputador que utiliza troca de mensagens. Geralmente envolve um conjunto de nodos ou clusters conectados por uma rede de interconexão escalável (figura 2.1). Cada cluster pode ser um sistema uniprocessador ou multiprocessador, e deve conter um módulo local de memória física, o qual pertence em parte ou inteiramente ao espaço de endereçamento global de DSM. Cada cluster precisa ter também um controlador específico de interconexão para interligá-lo ao restante do sistema.

14 14 FIGURA 2.1 Estrutura geral de um sistema DSM O modelo da rede de interconexão é tão importante para estes sistemas como é para os sistemas que utilizam troca de mensagens. Redes de interconexão devem oferecer uma pequena latência e uma alta banda passante a um custo razoável. Esta relação de desempenho por custo depende do número de nodos do sistema. Em sistemas com poucos nodos (poucas dezenas), barramentos e anéis têm sido escolhidos por causa do seu baixo custo. Em sistemas com 100 nodos, outras soluções com maior banda passante são necessárias. Devido aos sistemas DSM permitirem centenas de nodos, as redes de 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 nenhum esquema especial de modelo de interconexão, alternativas atrativas com custo razoável também incluem tecnologias LAN, tais como Ethernet e ATM. Estes modelos são bastante utilizados, já que geralmente os sistemas DSM são construídos aproveitando as redes de estações de trabalhos ou computadores pessoais em funcionamento [MIL 99]. Um dos maiores problemas dos sistemas DSM é o overhead associado à busca dos dados remotos (latência de memória) [PIN 96]. Latência de memória diz respeito ao intervalo de tempo compreendido entre o momento no qual um processador iniciou um acesso a um dado compartilhado até que este acesso seja satisfeito. O problema da latência de memória é inerente aos sistemas DSM por causa do grande overhead para localização e acesso aos dados em sistemas com memória fisicamente distribuída. Por este motivo, a rede de interconexão tem influência direta no desempenho de sistemas DSM. 2.3 Estrutura dos Dados Compartilhados 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 dados podem estar organizados de diferentes maneiras. Na variação mais simples, o espaço de endereçamento é dividido em páginas, sendo que cada página está presente na memória de uma máquina. Outra proposta é não compartilhar todo o espaço de endereçamento, mas somente uma parte dele, apenas aquelas variáveis ou estruturas de dados que precisam

15 15 ser usadas por mais de um processo. Esta técnica reduz a quantidade de dados que devem ser compartilhados. É possível estruturar ainda mais o espaço de endereçamento. Ao invés de apenas compartilhar variáveis, pode-se encapsular tipos de dados, chamados objetos. Esta proposta difere da proposta de variáveis compartilhadas no ponto em que, cada objeto não possui apenas dados, mas também procedimentos (métodos), que atuam sobre os dados. Processos podem manipular os dados do objeto apenas invocando seus métodos. Não é permitido acessar diretamente os dados. Restringindo o acesso desta forma, novas otimizações tornam-se possíveis. Os sistemas DSM dividem o espaço global de endereçamento compartilhado em blocos, para que os dados compartilhados possam ser manipulados pelo sistema de forma mais eficaz. Esse bloco de dados que é manipulado pelo sistema de DSM é chamado de unidade de coerência. Dependendo da estrutura dos dados que fazem parte do espaço de endereçamento compartilhado, este espaço pode ser dividido de diferentes formas. 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 DSM baseados em objetos, a unidade de coerência é o objeto. A granulosidade da unidade de coerência determina o tamanho do bloco de dados manipulado pelo mecanismo de DSM. Em geral, sistemas de hardware utilizam unidades pequenas (tipicamente blocos de cache), enquanto que soluções de software, baseados em mecanismos de memória virtual, organizam os dados em grandes blocos físicos (páginas), o que acarreta em compartilhamento de grandes grãos. O uso de grandes blocos aumenta a probabilidade de que vários processadores irão requisitar acesso ao mesmo bloco simultaneamente, mesmo que eles realmente acessem partes independentes do bloco de dados. Este fenômeno é conhecido como falso compartilhamento (false sharing). 2.4 Distribuição e Coerência dos Dados Compartilhados Duas estratégias utilizadas para distribuição dos dados compartilhados são replicação e migração. Replicação permite que várias cópias do mesmo item de dado residam em diferentes memórias locais. É utilizado principalmente para habilitar acessos simultâneos de diferentes nodos ao mesmo dado, predominantemente quando compartilhamento de leitura prevalece. Migração implica que somente uma cópia de um item de dado existe no sistema, portanto, os itens de dados são movidos sob demanda para uso exclusivo. Com o objetivo de diminuir o overhead de gerenciamento de coerência, esta estratégia é utilizada quando padrões seqüenciais de compartilhamentos de escrita prevalecem. A maioria dos sistemas DSM optam por replicar os dados, pois esta proposta 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 concorrente. No entanto, é fundamental manter estas cópias com a mesma informação, impedindo que um nodo acesse dados desatualizados. Existem duas estratégias básicas para manutenção da coerência de réplicas: Protocolo de invalidação: uma escrita em um dado compartilhado causa 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 16 Uma vez que as cópias foram invalidadas, as próximas operações de escrita na cópia válida não irão produzir efeito algum sobre as outras cópias. Na próxima operação sobre uma cópia que foi invalidada, irá ocorrer uma falha de acesso, sendo que uma cópia válida deverá ser buscada novamente para a memória local. Este protocolo é mais recomendado quando há grande localidade de acessos aos dados por processador, pois menos mensagens de notificação serão enviadas; Protocolo de atualização: uma escrita em um dado compartilhado causa a atualização de todas as suas cópias. Neste protocolo, em cada operação de escrita em uma cópia, todas as outras cópias devem receber a atualização que foi realizada. É uma abordagem mais complicada, pois a cada operação de escrita um novo valor deve ser enviado ao invés de uma mensagem de notificação. Além disso, mesmo que várias escritas consecutivas ocorram na mesma cópia, sem a interferência de leituras nas outras cópias, mesmo assim todas as cópias receberão todas as mensagens de atualização. Isto costuma gerar muito tráfego na rede. A escolha da política de coerência está relacionada com a granulosidade do da unidade de coerência. Para grãos muito pequenos, uma mensagem de atualização custa aproximadamente o mesmo que uma mensagem de invalidação. Por outro lado, sistemas com grãos grandes utilizam invalidação, sendo esta proposta eficiente quando as seqüências de acessos de leituras e escritas ao mesmo item de dado por vários processadores são esparsas. O melhor desempenho é alcançado quando a política de coerência adapta-se dinamicamente à situação. 2.5 Funcionamento Esta seção apresenta o funcionamento básico de um sistema DSM. Considera-se para a explicação do funcionamento, um sistema DSM implementado em software, com página como unidade de coerência e utilizando protocolo de invalidação. O modelo de programação de memória compartilhada permite que os acessos a dados sejam realizados como se todos os dados estivessem presentes na memória local dos nodos. Entretanto, sabe-se que nem todos os dados estão presentes localmente em cada processador. Portanto, quando um dado não está presente na memória local do processador, uma falha de página ocorre. O software DSM busca um cópia atualizada da 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 no processador 1, o qual resulta em uma cópia da página necessária sendo enviada da memória local do processador 3. Dependendo da operação a ser realizada no dado compartilhado, leitura ou escrita, 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 de escrita, um mensagem de invalidação é enviada para todos os processadores com cópias da página. Cada processador que recebe esta mensagem invalida sua cópia da página e envia uma mensagem de confirmação para o escritor. Como resultado, a cópia escrita da página torna-se a única cópia.

17 17 FIGURA 2.2 Exemplo de funcionamento Uma vez que as páginas foram invalidadas, em um próximo acesso de leitura 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 uma mensagem pode envolver traps no kernel do sistema operacional, interrupções, trocas de contexto e execução nas várias camadas do software de rede. Portanto, o número de mensagens e a quantidade de dados trocados deve ser mantido baixo. 2.6 Algoritmos básicos: Os algoritmos para a implementação de DSM tratam com dois problemas distribuir estática ou dinamicamente os dados compartilhados através do sistema, para minimizar a latência de acesso; preservar a coerência dos dados compartilhados, enquanto minimiza o overhead gerado com o gerenciamento de coerência. Projetistas de sistema devem escolher o algoritmo de DSM que melhor adapte-se a configuração do sistema e as características de referências de memória em aplicações típicas.

18 Algoritmos Único Leitor / Único Escritor (SRSW) Esta classe de algoritmos proíbe replicação, enquanto permite, mas não requer migração. O algoritmo de gerenciamento de DSM mais simples é o algoritmo servidor central. A proposta consiste em um único servidor central que controla todas as requisições de acesso aos dados compartilhados, fisicamente localizados neste nodo. Tal organização implica em não distribuição dos dados compartilhados. Este algoritmo sofre de problemas de desempenho, pois o servidor central pode tornar-se um gargalo do sistema. Uma possível modificação é a distribuição estática de responsabilidade de partes do espaço de endereçamento compartilhado para diferentes servidores. Funções de mapeamento simples, como hashing, podem servir para localizar o servidor apropriado de 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 sob demanda. Se uma aplicação possui alta localidade na referência de dados, o custo da migração é amortizado por vários acessos. O algoritmo pode apresentar um melhor desempenho quando uma longa seqüência de acessos for realizada neste bloco de dados por um processador sem que outro processador o faça. De qualquer forma, este tipo de algoritmo é pouco utilizado devido ao seu desempenho ser normalmente baixo Algoritmos Vários 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 compartilhamento de leitura é o padrão que prevalece em aplicações paralelas. Com esta finalidade, eles permitem operações de leitura simultâneas em execuções locais em vários nodos. Somente um nodo por vez pode receber permissão para atualizar a cópia replicada. 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 usualmente baseados em invalidação. Os algoritmos nesta classe diferem quanto a alocação de responsabilidade do gerenciador de DSM. Li e Hudak propuseram vários destes algoritmos, os quais podem ser consultados com detalhes em [LI 89] Algoritmos Vários Leitores / Vários Escritores (MRMW) Os algoritmos MRMW (também chamados de replicação total) permitem replicação dos blocos de dados com permissão de leitura e gravação. Para preservar a coerência, alterações em cada cópia devem ser distribuídas para todas as outras cópias em 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 o custo de acesso das escritas, ele é apropriado para compartilhamento de escrita e freqüentemente funciona com protocolos de atualização. Estes algoritmos podem produzir tráfego de coerência alto, especialmente quando a freqüência de atualizações e o número de cópias replicados são altos. Permitir que várias escritas concorrentes possam ocorrer na página, reduz o impacto de falso compartilhamento. Um outro problema que deve ser evitado é o efeito ping-pong. Nos algoritmos MRSW, cada processo pode escrever na página enquanto ela é mantida por outros

19 19 processos, portanto, a página irá mover-se na rede. Este deslocamento repetido da página é chamado de efeito ping-pong. Nos algoritmos MRMW este efeito é evitado, sendo que isto será melhor compreendido com a explicação do protocolo de múltiplos escritores do sistema TreadMarks, apresentado na seção Responsabilidade do Gerenciamento de DSM O sistema precisa determinar qual nodo deve realizar ações relacionadas com a gerência da memória compartilhada. Gerenciamento centralizado é fácil de implementar, mas pode tornar-se um gargalo. O gerenciamento distribuído pode definir a responsabilidade de gerenciamento dinâmica ou estaticamente, eliminando o gargalo e aumentando a escalabilidade. Entretanto, implica maiores gastos (overhead) para a gerência. O mecanismo de DSM precisa armazenar informações sobre os blocos de dados do espaço de endereçamento virtual compartilhado, tais como estado e localização corrente. Para isto, normalmente são utilizadas tabelas de sistema ou diretório. A organização do diretório varia de armazenamento totalmente mapeado à diferentes organizações dinâmicas, tais como listas simples ou duplamente encadeadas e árvores. O cluster pode fornecer armazenamento para o diretório inteiro ou para apenas uma parte dele. O sistema de diretório pode ser distribuído através do sistema e estruturado de forma hierárquica. A organização do diretório e a semântica das informações mantidas por ele, depende do método utilizado para manutenção da consistência de dados. 2.8 Modelos de Consistência de Memória 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 sistema. A escolha do modelo de consistência define o comportamento pretendido do mecanismo de DSM com respeito as operações de leitura e escrita. O modelo mais intuitivo de coerência de memória é a consistência rígida, na qual uma operação de leitura retorna sempre o valor de escrita mais recente. Este tipo de coerência é alcançado somente quando existe uma noção global de tempo que possa fornecer uma ordem determinística para todas as leituras e escritas. Entretanto, escrita mais recente é um conceito ambíguo em sistemas distribuídos, onde não existe um relógio global. Por este motivo, e também para aumentar o desempenho, foram desenvolvidos vários modelos para manter a coerência de memória em sistemas DSM [LO 94]. Para escrever um programa correto e eficiente no modelo de memória compartilhada, o programador deve ter a noção precisa de como o sistema de memória comporta-se no que diz respeito às operações de leitura e escrita nos dados compartilhados realizadas por diferentes processadores. Considere, os segmentos de código da figura 2.3. A figura apresenta uma implementação de um algoritmo de Dekker para exclusão mútua de seções críticas, onde dois processos P 0 e P 1 executam em processadores distintos. Se as escritas são imediatamente observadas pelos outros processadores, é impossível que os testes dos comandos L 0 e L 1 sejam verdadeiros ao mesmo tempo. Entretanto, se o efeito da escrita for atrasado e durante esse atraso, o processador puder continuar seu processamento normal, então ambos os processadores podem chegar ao

20 20 comando if antes de terem visto as escritas às variáveis A e B e, portanto, os testes L 0 e L 1 podem ser verdadeiros ao mesmo tempo. P 0 P 1 A = 0; B = 0;.. A = 1; B = 1; L 0 : if (B==0)... L 1 : if (A==0)... FIGURA 2.3 Segmentos de código de P 0 e P 1 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á no desempenho do sistema. Modelos de consistência rígidos, tipicamente aumentam a latência de acesso a memória e a exigência de tamanho de banda passante, enquanto simplificam a programação. Ao contrário, os modelos mais relaxados, permitem reordenação de memória, pipelining e overlaping, conseqüentemente aumentando o desempenho. Entretanto, exigem alto envolvimento do programador na sincronização dos acessos aos dados compartilhados. Portanto, o modelo de consistência de memória tipicamente envolve a troca entre desempenho e facilidade de programação [ADV 99] Consistência Seqüencial O modelo de consistência de memória mais simples e intuitivo é chamado de consistência seqüencial (SC Sequential Consistency). Este modelo foi definido por Lamport [LAM 79] : Um sistema é seqüencialmente consistente se o resultado de qualquer execução paralela é o mesmo que seria obtido se as operações de todos os processadores fossem executadas em ordem seqüencial, e as operações de cada processador na ordem descrita pelo programa. Em outras palavras, em termos de ordenação dos acessos a dados compartilhados, uma máquina paralela seqüencialmente consistente funciona como se fosse um único processador multiprogramado. No exemplo da figura 2.3, o uso do modelo SC garante que os dois comandos L 0 e L 1 jamais poderiam retornar verdadeiro ao mesmo tempo. Em todas as possíveis intercalações dos comandos de P 0 e P 1, as leituras dos valores A e B completam uma antes da outra, assim a segunda a completar já viu necessariamente a escrita de 1 na variável. Os protocolos do modelo SC têm que assegurar que todos os nodos observam a mesma seqüência de leituras e escritas. Então, o efeito de cada acesso à memória deve ser executado globalmente antes que o próximo acesso tenha permissão para executar. Isto pode ser alcançado serializando todas as leituras e escritas através de um nodo central ou com a utilização de protocolos mais eficientes. Apesar da consistência seqüencial apresentar um modelo de memória simples, ela é bastante restritiva, reduzindo o paralelismo potencial do sistema. Além disso, este modelo apresenta alguns obstáculos à implementação de mecanismos de hardware utilizados para otimização [ADV 99].

21 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 programa. Entretanto, a ordem das escritas de dois processadores distintos podem ser observadas fora da ordem do programa. Em outras palavras, consistência em escritas são observadas em cada processador, mas a ordem de leituras de cada processador não é restringida, contanto que elas não envolvam outros processadores [HWA 93]. O modelo PC é um relaxamento do SC, pois remove algumas restrições em escritas realizadas por diferentes processadores. Duas condições relacionadas com outros processadores são exigidas para garantir a consistência de processador: (i) antes de uma operação de leitura executar, todos os acessos anteriores de leitura devem ter sido completados; (ii) antes de uma operação de escrita executar, todos os acessos anteriores de leitura e escrita devem ter sido completados. Estas condições permitem que acessos de leitura ultrapassem acessos de escrita, desde que para posições de memória diferentes. Portanto, a chave do ganho de desempenho alcançado pelo modelo de consistência de processador comparado com a consistência seqüencial é que leituras são diferenciadas das escritas Consistência Fraca Uma vez que vários acessos concorrentes são realizados no espaço de endereçamento compartilhado, existe a necessidade de sincronizar estes acessos. Sincronização é uma forma do programador expressar a restrição entre acessos à memória compartilhada realizado por diferentes processos. Dois acessos à memória compartilhada são conflitantes se eles são realizados por processos diferentes para a mesma posição de memória e ao menos um deles é uma escrita. Um programa paralelo tem condição de corrida (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 qualquer atualização na memória compartilhada realizada por um processo para os outros processos antes que eles sincronizem-se uns com os outros. Isso porque o segundo processo nã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 utilizar um modelo de consistência de memória que garanta a consistência seqüencial nos pontos de sincronização do programa, de modo a reduzir o número de mensagens para a manutenção da consistência. Portanto, com a utilização de sincronização permite-se utilizar modelos de consistência relaxados, que mantêm a consistência do programa aplicativo somente nos pontos de sincronização (barreiras e semáforos). Dados compartilhados são transferidos somente durante a sincronização, resultando em muito menos overhead. Entre as variáveis de sincronização, a ordem das operações de memória não são impostas, enquanto que as variáveis de sincronização têm que seguir as regras de consistência seqüencial. O primeiro modelo relaxado de consistência de memória proposto para tirar proveito da sincronização foi o modelo de consistência fraca (WC Weak Consistency) [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-se globalmente consistente. Antes que uma operação de sincronização possa executar, to-

22 22 dos os acessos normais anteriores devem ser completados. Além disso, acessos realizados após a operação de sincronização devem esperar para que todas as operações de sincronização sejam finalizadas. Finalmente, acessos de sincronização são garantidos como seqüencialmente consistentes. É responsabilidade do programador a consistência dos dados compartilhados através do uso correto de operações de sincronização. A figura 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 P 0 P 1 A = 1; espere por s = 1; B = 10; Y = A; Escreve 1 em s; X = B; FIGURA 2.4 Utilização de sincronização para garantir coerência de A e B Consistência de Liberação Consistência de liberação (RC Release Consistency) é uma extensão do modelo de consistência fraca, que também distingue acessos normais de acessos de sincronizaçã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 uma liberação indica que o processador está terminando uma operação que gerou valores dos quais outros processadores podem depender. No exemplo da figura 2.4, o comando escreve 1 em s é classificado como liberação(s) e o comando espere por s = 1 é classificado como obtém(s). Para garantir a coerência dos dados compartilhados segundo o modelo RC, a aplicação deve, portanto, utilizar sincronização explícita através de primitivas do sistema. O uso de espera ocupada em um flag, por exemplo, não permite que o sistema detecte a existência de operações de sincronização e as classifique como obtenções ou liberaçõ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ção global. 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 qualquer processador, todos os acessos a dados compartilhados anteriores devem ter sido observados por este processador; (ii) acessos que seguem uma operação de obtenção numa variável de sincronização devem esperar que a obtenção tenha sido executada; (iii) acessos à variáveis de sincronização devem ser observados segundo os modelos SC ou PC. A ordenação é imposta somente nos pontos de liberação (a execução não procede além do ponto de liberação até que todas as operações de memória à variáveis compartilhadas sejam executadas). Este modelo assume que acessos conflitantes de lei-

23 23 tura e atualização à memória são sempre protegidos utilizando mecanismos que garantam exclusão mútua, como os semáforos. Em relação ao SC, RC apresenta uma sensível redução na latência de acesso à memória compartilhada, pois um processador fica paralisado esperando pela coerência de dados somente em operações de liberação Consistência de Liberaçã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 Release Consistency). LRC relaxa as condições de RC, porque não impõe que numa operação de liberação os acessos anteriores estejam globalmente visíveis. LRC exige que os acessos anteriores à 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 a obtenção tenha terminado, todos os acessos realizados até a última liberação devem estar visíveis em p. Para determinar sobre quais modificações devem ser propagadas para um processador no momento de uma obtenção, LRC estabelece uma ordem parcial, chamada happened-before-1 (hb1), dos acessos a dados compartilhados (figura 2.5). A ordem parcial hb1 [ADV 93] é baseada na ordem seqüencial de execução em um processador e no encadeamento das operações de obtenção e liberação realizadas em processadores diferentes, mas sobre a mesma variável de sincronização. Dois acessos à memória compartilhada a 1 e a 2 são ordenados por hb1, simbolizado por a 1 a 2, hb1 se: a 1 e a 2 são acessos do mesmo processador e a 1 ocorre antes de a 2 ; a 1 é uma liberação no processador P 1, a 2 é uma obtenção na mesma variável de sincronização em P 2 e a 2 retorna o valor escrito por a 1 ; hb1 hb1 hb1 se a 1 a 2 e a 2 a 3, então a 1 a 3. P 0 P 1 P 2 Acq(a) W(x 1 ) Rel(a) Acq(d) W(x 4 ) Rel(d).. Acq(b) W(x 2 ) Rel(b) Acq(c) W(x 3 ) Rel(c)... hb1 hb1 hb1.. Acq(e) W(x 5 ) Rel(e) Acq(c) W(x 3 ) Rel(c) hb1 hb1 hb1 Acq(f) W(x 6 ) Rel(f).. Acq(c) W(x 3 ) Rel(c) hb1 hb1 hb1 FIGURA 2.5 Ordem parcial estabelecida pelas operações de sincronização

24 24 Por exemplo, considere os segmentos de código da figura 2.5. Quando P 2 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 x 1, x 2 e x 3 de P 0 e as modificações realizadas em x 4, x 5 e x 3 de P Consistência de Entrada O modelo de consistência de entrada (EC Entry Consistency), relaxa ainda mais as regras que determinam quando um processador deve observar as modificações realizadas nos dados compartilhados. Ele explora a relação entre variável de sincronização e o dado compartilhado protegido por ela. EC garante que o dado compartilhado está coerente num processador, apenas quando este obtém a variável de sincronização que o protege. Sendo s uma variável de sincronização que protege o dado Ds, a condição para que um sistema esteja consistente segundo o modelo EC é: antes que uma operação de obtenção em s tenha terminado em p, todas as atualizações em Ds devem ter sido observadas por p. O dado compartilhado pode ser associado à variável de sincronização de forma explícita ou implícita. A associação explícita é realizada pelo programador, enquanto 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 dados compartilhados protegidos por ela. A associação implícita deixa a cargo do sistema DSM estabelecer dinamicamente essa relação. No modelo de consistência EC o ponto de espera pela coerência ocorre, tal qual 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 parcial hb1. Já o modelo EC baseia-se na idéia de que se a aplicação requer sincronização para evitar efeitos de condições de corrida em seus resultados, então essa sincronização delimita não só quando os dados devem estar coerentes, mas também quais dados devem estar coerentes naquele momento. Em outras palavras, se o programador (ou o compilador) estabeleceu uma determinada seção crítica s para acessar o dado Ds, então no momento 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, P 2 no momento da obtenção em c só deve receber informações sobre as modificações em x 3 realizadas anteriormente. Nesse caso, a determinação do que foi realizado anteriormente segue a ordem total imposta pelo encadeamento de operações obtenção/liberação. Para manter o mesmo comportamento do modelo seqüencial, o modelo de programação utilizado por EC requer não só que a aplicação seja propriamente sincronizada, mas também que os acessos aos dados compartilhados sejam executados conforme a associação estabelecida. Assim, o programador deve considerar que um dado compartilhado só está visível num processador quando este executa uma operação de obtenção na variável de sincronização que o protege.

25 Nível de Implementação do Mecanismo de DSM O nível onde o mecanismo de DSM é implementado é uma das decisões mais importantes na construção de sistemas DSM, afetando o custo de programação e o desempenho global do sistema [PRO 98]. Para alcançar facilidade de programação, custo/efetividade e escalabilidade, sistemas DSM logicamente implementam o modelo de memória compartilhada em memória fisicamente distribuída. Uma vez que sistemas DSM distribuem o espaço de endereçamento compartilhado através das memórias locais, pesquisas devem ser executadas 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 sistema também deve realizar uma ação em acessos de escrita para preservar a coerência dos dados compartilhados. Tanto pesquisas quanto ações podem executar em software, hardware ou de forma combinada. A escolha da implementação depende da relação preço/desempenho. Embora tipicamente superior em desempenho, implementações em hardware requerem complexidade adicional, a qual somente máquinas de alto desempenho ou de larga escala podem oferecer. Sistemas como as redes de computadores pessoais, ainda não toleram o custo do hardware adicional de DSM, o qual limita-os para implementações de software. Em alguns sistemas, como em clusters de estações de trabalho, hardware adicionais de baixo custo podem ser utilizados. Mesmo em implementações de DSM por hardware, existem características controladas por software, as quais são explicitamente realizadas pelo programador, com o objetivo de otimizar as referências à memória. Também várias propostas de DSM por software exigem algum suporte de hardware. Portanto, torna-se natural empregar métodos híbridos, com elementos de software e hardware combinados para balancear a relação de custo e complexidade Software A idéia de construir um mecanismo de software que forneça um paradigma de 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 de software, 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ão vantajosas para aplicações com alta localidade de referências, além de reduzir o espaço necessá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 representem entidades lógicas, com o objetivo de alcançar as vantagens de localidade inerente as aplicações. Suporte de DSM por software é geralmente mais flexível do que suporte por hardware e habilita um melhor condicionamento dos mecanismos de consistência ao comportamento da aplicação. Entretanto, normalmente não podem competir com as implementações em hardware em termos de desempenho. Uma vez que não utilizam

26 26 aceleradores de hardware para resolver o problema, projetistas elaboraram modelos de consistência relaxado, embora isso acarrete em mais trabalho para o programador. Devido as pesquisas serem realizadas em uma grande quantidade de linguagens de programação e sistemas operacionais disponíveis, numerosas implementações de DSM por software foram desenvolvidas. Os capítulos seguintes (capítulos 3, 4, 5 e 6) abordam sistemas de DSM implementados por software Hardware Mecanismos de DSM implementados em hardware garantem replicação automática dos dados compartilhados nas memórias locais e caches de processador, transparentemente as camadas de software. Esta proposta suporta eficientemente o compartilhamento de grãos pequenos. A unidade física de replicação e coerência é pequena, tipicamente uma linha de cache. Conseqüentemente, mecanismo de DSM por hardware normalmente representam uma extensão dos princípios encontrados em esquemas de coerência de caches das arquiteturas de memória compartilhada. Esta proposta reduz consideravelmente as exigências de comunicação, pois com o compartilhamento de granulosidade fina são minimizados os efeitos de falso compartilhamento e desperdício. Pesquisas e funções de diretório implementadas em hardware são bem mais rápidas do que as implementadas a nível de software. As implementações por hardware também apresentam menor latência de memória. Entretanto, técnicas avançadas de manutenção de coerência e redução da latência podem complicar o projeto. Por isso, DSM por hardware é utilizado principalmente em máquinas onde desempenho é mais importante do que custo. A gerência da hierarquia de memória é um aspecto que requer cuidados, no sentido de encontrar algoritmos eficientes para mover os dados dinamicamente entre os diferentes níveis da memória ou níveis de cache. Um problema é como mapear as estruturas de dados do espaço de endereçamento lógico compartilhado em módulos de memória fisicamente distribuídos. Porções do espaço de memória lógica são mapeados na memória física unicamente (uma porção lógica mapeada para uma localização física de mesmo tamanho) como nas máquinas CC-NUMA. Outra possibilidade é utilizar replicação (uma porção lógica mapeada para várias localizações físicas, cada uma do mesmo 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çamento virtual compartilhado através da memória local dos clusters. Tanto o processador local como 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 mesmo cluster terão acesso à memória local deste cluster na velocidade do hardware. No en-

27 27 tanto, acessos provenientes de processadores de outros clusters terão adicionado a latência de acesso à memória a latência de comunicação. O mecanismo de DSM é normalmente implementado utilizando diretórios com 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 escalabilidade fornecida pela redução do overhead de armazenar o diretório. Para minimizar a latência, particionamento estático de dados pode ser feito cuidadosamente, para maximizar a freqüência de acessos locais. Indicadores de desempenho também dependem altamente da topologia de interconexão. Um mecanismo de invalidação é tipicamente aplicado para fornecer coerência, enquanto alguns modelos de consistência de memória relaxados podem servir como fonte de ganho de desempenho. Sistemas de DSM COMA A arquitetura COMA usa a memória local dos clusters como grandes caches para blocos de dados do espaço de endereçamento virtual compartilhado (memórias de interesse 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 migrados nas memórias de interesse sob demanda. Por conseguinte, a distribuição de dados nas memórias locais adaptam-se dinamicamente ao comportamento da aplicação. As arquiteturas COMA possuem topologia de rede hierárquica que simplificam os dois principais problemas deste tipo de sistemas: localizar um bloco de dados e substituí-lo. Elas são menos sensíveis à distribuição estática de dados do que são as arquiteturas NUMA. Devido a organização de suas caches, as memórias de interesse reduzem o volume e o custo dos conflitos de ausência. Mas, a estrutura hierárquica impõe latências de comunicação e de falhas de dados remotos ligeiramente mais altas. É inerente a estas arquiteturas um aumento no overhead de armazenamento para manter informações típicas para memórias cache. Sistemas DSM de Memória Refletida Sistemas de memória refletida têm um mecanismo implementado em hardware para atualização de dados de granulosidade fina. O espaço de endereçamento global compartilhado é formado fora dos segmentos de memória local. Estes segmentos são designados como compartilhados e mapeados para este espaço através de tabelas de mapeamento programáveis presentes em cada cluster. Portanto, as partes deste espaço compartilhado 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ço contido neste espaço de endereçamento compartilhado no cluster propaga-se através de um broadcast ou de um multicast para todos os outros clusters onde o mesmo endereço estiver mapeado. O processador não protela escritas nem computações sobrepostas com comunicação. Esta é uma fonte de melhoria de desempenho típica de modelos de consistência de memória relaxada. Também não existe contenção e longas latências como em típicos sistemas de memória compartilhada. Isto deve-se a garantia de acesso irrestrito

28 28 aos dados compartilhados e aos acessos simultâneos a cópias locais. Mas, todas as leituras de memória compartilhada são locais, com tempo de acesso determinístico. O princípio deste mecanismo de DSM assemelha-se aos protocolos de atualização de coerência de cache Considerações Finais Os sistemas DSM são alternativas viáveis para o desenvolvimento de programas paralelos. No entanto, para alcançar desempenhos semelhantes aos sistemas de memória compartilhada, as aplicações que executam em memória distribuída com mecanismos de DSM devem ser desenvolvidas com a utilização de primitivas, para reduzir a comunicação gerada para localização e manutenção da coerência dos dados. Entretanto, isto implica no maior envolvimento do programador. Observa-se que em vários sistemas DSM o desempenho geral do sistema depende das características da aplicação. Por isso, muitas vezes os sistemas apresentam alto desempenho para determinada classe de aplicações. No entanto, é desejado que estes 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 mecanismos de DSM as características da aplicação. Outras características podem levar a uma maior disseminação dos sistemas DSM. Uma delas é que estes sistemas sejam capazes de detectar o paralelismo de forma implícita, com isto reduzindo o envolvimento do programador com o processo de paralelização da aplicação. Algumas etapas neste sentido já foram alcançadas por alguns sistemas, como a utilização implícita de sincronização e balanceamento automático de carga. Outra característica que vem recebendo destaque é que os sistemas DSM suportem mobilidade.

29 29 3 Orca Orca é um sistema para implementação de aplicações concorrentes para arquiteturas de memória distribuída. Caracteriza-se por permitir que processos em diferentes máquinas compartilhem dados, sendo estes dados encapsulados em objetos de dados. 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 compartilhamento a nível das estruturas de dados do usuário. São suportados pela linguagem, que pode ter características comuns de alto nível como organização hierárquica dos dados. Orca é um sistema de memória compartilhada distribuída baseado em objetos, cujo sistema de execução gerencia o suporte da distribuição dos objetos, fornecendo uma memória compartilhada distribuída estruturada. Orca encapsula as estruturas de dados compartilhadas em objetos, que são instâncias (variáveis) dos tipos abstratos de dados (classes) definidos pelo programador. A característica principal do Orca é acessar as estruturas de dados compartilhadas através de operações de alto nível. Ao invés de utilizar instruções de baixo nível para ler, escrever e realizar lock nos dados compartilhados, os programadores definem operações (métodos) para manipular as estruturas de dados compartilhadas. Uma característica importante do modelo Orca é fazer com que cada operação em um objeto seja atômica, o que dispensa o programador de utilizar locks. Todas as operações em um objeto são executadas sem interferência das outras. Este modelo de objetos compartilhados é suportado pela linguagem Orca, que foi projetada especificamente para programaçã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 parte de especificação e uma parte de implementação. A parte de especificação define as operações aplicáveis aos objetos de um determinado tipo. A parte de implementação contém os dados utilizados para representar objetos deste tipo, o código para inicializar os dados 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 ocultados na implementação dos tipos abstratos de dados. O modelo de comunicação do Orca é baseado em objetos de dados compartilhados. O paralelismo no Orca é explícito, sendo baseado em dois conceitos ortogonais: 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 processos não é fixado durante a compilação, é determinado durante a execução; Objetos no Orca os objetos são passivos. Eles não contém processos ou outro tipo de elemento ativo. Cada objeto contém algumas estruturas de dados e a definição de uma ou mais operações que usam estas estruturas de dados. Tecnicamente, a linguagem Orca é baseada em objetos,

30 30 não orientada a objetos, uma vez que suporta encapsulamento de tipos abstratos de dados, mas não tem herança. O modelo de consistência de memória do Orca é seqüencialmente consistente. Contudo, apresenta semelhanças com consistência de entrada. Operações contínuas nos objetos compartilhados são executadas utilizando consistência seqüencial, mas leituras e escritas individuais à palavras de memória dentro de uma operação não são visíveis para os outros processos até que a operação esteja completa, uma vez que operações são executadas atomicamente. Em termos de acessos individuais à memória, o modelo Orca é similar à consistência de entrada, mas sem a necessidade do programador associar variáveis de lock aos objetos. A sincronização no Orca é implícita. Tanto exclusão mútua como sincronização de condição são integradas no modelo. Uma importante vantagem é que os programadores não precisam utilizar primitivas de sincronização, o que simplifica a programação. Entretanto, a sincronização implícita é menos flexível que a utilização explícita [BAL 98]. 3.2 Arquitetura do Sistema O sistema Orca é composto de três partes: um compilador, um sistema de execuçã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 C acrescido de chamadas para o sistema de execução. O compilador também gera informações sobre quais operações têm atributo somente de leitura e como processos acessam os objetos compartilhados. Estas informações serão utilizadas para auxílio na tomada de decisões como será discutido na seção O sistema de execução (RTS RunTime System) é responsável por gerenciar os processos e os objetos do Orca. Inicialmente, um programa Orca é composto por um único processo. Novos processos são criados pelo sistema de execução, a partir das primitivas de criação de processos que foram definidas pelo programador no código da aplicação. Estes processos podem acessar os objetos compartilhados. O sistema de execução decide como representar os objetos, possui mecanismos de invocação remota de

31 31 objetos e migração de objetos, e implementa o protocolo de atualização para objetos replicados. Panda fornece ao sistema facilidades necessárias para implementar o RTS. A camada Panda fornece threads, chamada remota de procedimento (RPC Remote Procedure Calls) e comunicação de grupo totalmente ordenada. Threads são utilizadas para implementar os processos Orca; RPC é usado para implementar invocação remota de 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 uma grande variedade de multicomputadores e clusters de estações de trabalho e tem sido utilizada 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 tabela 3.1. TABELA 3.1 Aspectos importantes no projeto do sistema Orca Característica Protocolo de coerência Disposição dos objetos Portabilidade Arquitetura do software Decisão de Projeto Protocolo de atualização baseado em expedição de função e comunicação de grupo totalmente ordenada Heurísticas de compilação e estatísticas de tempo de execução Proposta baseada em camadas com máquina virtual Implementado em software, utilizado a nível de usuário As próximas seções abordarão estas características, sendo que para consultas mais detalhadas recomenda-se [BAL 98] Protocolo de Coerência O sistema Orca replica os objetos compartilhados que são lidos freqüentemente. A vantagem da replicação é que operações de leitura (as quais são reconhecidas pelo compilador) podem ser executadas localmente, sem a necessidade de comunicação. Entretanto, o problema é como implementar as operações de escrita que modificam os objetos. Pode-se optar pela utilização de um protocolo de invalidação ou por um protocolo de atualização. O Orca utiliza protocolo de atualização para implementar operações de escrita, ao contrário da maioria dos sistemas DSM que utilizam protocolo de invalidação. Os objetos são atualizados utilizando expedição de função (function shipping), que consiste em enviar a operação e seus parâmetros para todas as máquinas que contenham uma cópia deste objeto. Portanto, a operação realizada em um objeto é aplicada a todas as cópias locais, não sendo necessário transmitir o objeto inteiro. A eficiência do protocolo de atualização do Orca depende do comportamento da aplicação. O protocolo torna-se ineficiente se a taxa de leitura/escrita for bai-

32 32 xa. Em particular, o protocolo apresenta seu pior desempenho se um processador fizer muitas 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 na maioria dos casos os programadores combinam tais operações de escrita em uma única operação lógica. Além disso, o sistema replica somente aqueles objetos que tenham uma alta taxa de leitura/escrita. Para realizar este processo de atualização de forma coerente, a operação é enviada utilizando comunicação de grupo totalmente ordenada. Sua utilização é justificada uma vez que, mensagens de atualização de diferentes origens poderiam ser entregues 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 utilizada em sistemas DSM, uma vez que ela pode apresentar alto custo, e porque envia mensagens para todos os processadores. A vantagem desta primitiva é que simplifica a implementação do protocolo de atualização. Foram desenvolvidos 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 solicitante envia um broadcast da operação utilizando comunicação de grupo totalmente ordenada e bloqueia-se até que o sistema de execução tenha processado a mensagem de broadcast (e todas as outras mensagens que ocorreram antes dela). Quando uma mensagem de broadcast com uma operação é recebida por um processador, o sistema de execução verifica se existe uma cópia deste objeto na memória local. Se existe, o RTS chama um procedimento que executa a operação. Senão, desconsidera a mensagem. O protocolo utiliza um seqüenciador centralizado para ordenar todas as mensagens. Cada mensagem de broadcast contém um número de seqüência, o qual os receptores utilizam para ordenar as mensagens e para checar se falta alguma mensagem. Dependendo do ambiente de execução e do tamanho da mensagem, o sistema escolhe um entre três diferentes mecanismos para os números de seqüência. Na proposta mais simples o emissor pede ao seqüenciador o próximo número de seqüência (através de duas mensagens pequenas), e envia a mensagem de broadcast com o número de seqüência. Em outra proposta, o emissor transmite a mensagem completa para o seqüenciador, 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 mensagem de broadcast sem o número de seqüência e o seqüenciador enviar outra (pequena) mensagem 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 implementar a ordenação total. Um outro problema é que o protocolo utiliza um componente centralizado, o qual pode criar contenção. A máquina seqüenciadora precisa ser praticamente dedicada, pois ela pode ter que manipular várias requisições por segundo. Outra desvantagem destes protocolos é que todos os processadores que participam da execução recebem mensagens, mesmo que não possuam cópias do objeto que foi atualizado. Portanto, uma operação de escrita em um objeto replicado irá interromper todas as máquinas envolvidas na execução. Além disso, programas Orca irão gerar um grande número de mensagens se eles realizarem muitas operações de escrita nos objetos replicados. Entretanto, o sistema de execução do Orca evita que os objetos que são principalmente escritos sejam replicados, minimizando esse problema. Para as aplicações Orca analisadas [BAL 98], o overhead de comunicação do protocolo de atualização é baixo, isto devido a taxa de leitura/escrita dos objetos

33 33 compartilhados ser freqüentemente alta e porque o sistema não replica objetos nos quais esta taxa é baixa. Portanto, um aspecto chave é determinar quais objetos devem ser replicados. Alguns estudos de desempenho mostram que o sistema Orca tem condições de tomar boas decisões sobre a replicação de objetos sem nenhum auxílio do programador [BAL 98] Estratégia de Disposição dos Objetos Utilizando o protocolo de atualização descrito na seção anterior, operações de leitura em objetos replicados podem ser executadas localmente, mas operações de escritas exigem um broadcast para todas as máquinas. Se a taxa de leitura/escrita do objeto é baixa, a replicação é ineficiente e é melhor armazenar o objeto em uma única máquina. Neste caso, outras máquinas podem acessar o objeto fazendo uma invocação remota de objeto. O sistema Orca suporta tanto replicação quanto objetos com uma única 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 determina a disposição (localização) para cada objeto. O sistema replica somente os objetos que tenham 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 programador poderia ser responsável por estas decisões, no entanto, isto é indesejável, uma vez que a idéia dos sistemas DSM é esconder a distribuição do programador. Isto também tornaria as soluções dependentes da arquitetura. Por estes motivos, o Orca responsabiliza-se pela determinação da disposição dos objetos, sem o envolvimento do programador. O compilador calcula expressões regulares (padrões) que contêm uma descrição de alto nível de como os objetos compartilhados são acessados. O sistema de execução usa estas informações como uma sugestão sobre como os objetos serão utilizados. Além disso, são mantidas estatísticas em tempo de execução sobre a utilização dos objetos. Baseado nestas informações, o sistema decide em quais máquinas colocar cópias dos objetos compartilhados. Portanto, a decisão de quais objetos replicar e onde armazenar os objetos não replicados é de responsabilidade do sistema de execução. As estatísticas mantidas pelo RTS são essenciais para esta proposta (e mais importante que as informações geradas pelo compilador), sendo que apresentam um overhead desprezível Portabilidade O sistema Orca foi projetado para fornecer portabilidade e flexibilidade. Para alcançar portabilidade, foi utilizada uma proposta de camadas (figura 3.1). O sistema é formado por três camadas, e as partes dependentes da arquitetura e do sistema operacional foram isoladas na camada mais baixa. O principal problema de projeto é como fazer o sistema portável e eficiente. Em particular, é difícil utilizar propriedades específicas da arquitetura em um sistema portável. O compilador e o sistema de execução são totalmente independentes da arquitetura. O sistema de execução é implementado sobre uma máquina virtual, chamada Panda. Esta máquina virtual é que fornece as primitivas de comunicação e de multi tarefa exigidas pelo sistema.

34 34 Portanto, portar o sistema para novas arquiteturas é alcançado portando a Panda. A camada Panda pode ser configurada estaticamente para combinar com a plataforma de execução (hardware e sistema operacional). Por exemplo, se o sistema operacional ou o hardware fornecerem certas funcionalidades que possam ser interessantes a Panda (comunicação confiável), Panda pode ser configurada para fazer uso delas Arquitetura do Software O sistema Orca é implementado inteiramente em software. A desvantagem deste tipo de sistema é a perda de desempenho, pois todos os acessos são feitos por software. No entanto, é mais flexível. O sistema explora a flexibilidade para implementar várias otimizações importantes. O sistema de execução do Orca realiza toda a gerência de objetos e processos por software. Conseqüentemente, todos os acessos a objetos compartilhados são feitos 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 ser executada usando uma invocação local, uma invocação remota ou um broadcast. Para isto, 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 um lock, 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 35 4 TreadMarks TreadMarks é um software que permite programação concorrente com memória compartilhada em arquiteturas de memória distribuída. Caracteriza-se por executar a nível de usuário em redes de estações de trabalho com sistema operacional Unix. O projeto do TreadMarks teve como objetivo reduzir a quantidade de comunicação necessária para manter a consistência de memória. Para isto utiliza um protocolo de múltiplos escritores e o modelo de consistência de liberação preguiçosa. 4.1 Modelo de Programação TreadMarks é implementado inteiramente como biblioteca a nível de usuário. Funciona no sistema operacional Unix sem exigir modificações no kernel, pois as implementações atuais do Unix fornecem todas as primitivas de comunicação e funções para gerenciamento de memória necessárias para a implementação do TreadMarks. Programas escritos em C, C++ ou Fortran são compilados e ligados com a biblioteca TreadMarks utilizando qualquer compilador padrão para estas linguagens. Como resultado o sistema é relativamente portável. O ambiente de programação do TreadMarks é simples. Não há a necessidade de desenvolver toda a aplicação novamente. É permitido que programas seqüenciais possam ser modificados para executar em paralelo, possibilitando a reutilizaçã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 o dado para o processador sem a intervenção do programador. Quando a memória compartilhada é modificada por um processador, TreadMarks assegura que outros processadores serão notificados da mudança, portanto eles não terão dados obsoletos. Esta notificação não é imediata nem global. Notificação imediata seria realizada freqüentemente e notificação global normalmente iria enviar para processadores informações que não seriam pertinentes a maioria deles. Ao invés, esta notificação entre processos é realizada quando eles são sincronizados. Programas livres de condições de corrida produzem 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 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 TreadMarks como resultado de uma chamada explícita a uma rotina da biblioteca TreadMarks ou por uma falha de acesso. Uma vez que uma máquina tenha enviado uma mensagem de requisição, ela bloqueia-se até que chegue a mensagem com a resposta desejada. Se uma resposta não chega dentro de um certo timeout, a requisição original é retransmitida.

36 Protocolo de Múltiplos Escritores Os protocolos de vários escritores tratam o problema de falso compartilhamento. Caracterizam-se por consentir que vários processadores tenham permissão para escrever na cópia da página ao mesmo tempo. Esta seção aborda o funcionamento do protocolo de múltiplos escritores implementado pelo TreadMarks. As página compartilhadas são inicialmente protegidas para escrita. Quando uma escrita ocorre por um processo P 1, TreadMarks cria uma cópia da página, chamada de twin, e a salva como parte das estruturas de dados do TreadMarks neste processador. O sistema então desprotege a outra cópia da página, a qual está presente no espaço de endereçamento do processo. Isto possibilita que as próximas escritas à página possam ocorrer sem a intervenção do software DSM. No momento em que o processador P 1 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ágina. 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 (figura 4.1). Como os diffs contêm apenas as modificações realizadas na página, seu tamanho varia de acordo com a quantidade de dados modificados. Uma vez que a diff tenha sido criada, a twin é descartada. Atualizações nas outras cópias da página presentes no sistema podem ser realizadas aplicando a diff sobre estas páginas. No caso de um processador P 2 escrever sobre a mesma página utilizada pelo processador P 1, a mesma seqüência de eventos descritos acima ocorre em P 2. É importante ressaltar que esta seqüência completa de eventos é local a cada um dos processadores e, portanto, não requerem troca de mensagens. Como parte do protocolo, P 1 é informado de que P 2 modificou a página e vice-versa, sendo que ambos invalidam suas cópias da página. Na próxima vez que eles acessarem a página, ocorrerá uma falha de acesso em ambos. O software TreadMarks em P 1 sabe que P 2 modificou a página, então envia uma mensagem para P 2 requisitando a diff, a qual é aplicada na página voltando a ter uma cópia válida. Novamente, a mesma seqüência de eventos ocorre no outro processador. Com exceção da primeira vez que um processador acessar uma página, sua cópia é atualizada exclusivamente aplicando os diffs. Portanto, não é necessário buscar novamente 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 normalmente são bem menores do que as páginas. Uma dúvida pertinente é o que acontece quando dois processos modificam porções sobrepostas de uma página. Por exemplo na figura 4.1, o que aconteceria se além de P 1 modificar a, P 2 também o fizesse. Isto corresponde a uma condição de corrida, pois significa que dois processos escrevem na mesma posição de memória sem a intervenção de sincronização [AMZ 96]. Esse tipo de condição tem que ser controlada pelo programador com a utilização correta das primitivas de sincronização fornecidas pela 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últiplos escritores, onde a cada liberação um diff é criado para cada página modificada e propagado para todas as outras cópias da página. A implementação de LRC utilizada pelo

37 37 TreadMarks permite que a criação de diffs seja adiada até que as modificações sejam requisitadas. Criação preguiçosa de diffs resulta em menor número de diffs criados e um conseqü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 produzem o mesmo resultado que programas escritos para o modelo de consistência de liberação preguiçosa, desde que: (i) todas as operações de sincronização sejam realizadas utilizando as primitivas fornecidas pelo sistema; (ii) existe um par obtenção-liberação entre acessos concorrentes ao mesmo dado compartilhado realizado por processadores diferentes [KEL 98]. TreadMarks usa consistência de liberação preguiçosa como modelo de consistê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. Nos pontos de aquisição de locks ocorrem as invalidações das páginas alteradas por outros processadores. Entretanto, as modificações dessas páginas só são requeridas na ocorrência de uma falha de acesso. A figura 4.2 ilustra a diferença entre os modelos RC e LRC.

38 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 modificaçõ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 índice de intervalo (interval index). Cada vez que um processo executa uma liberação ou uma obtenção, começa um novo intervalo e o índice de intervalo é incrementado. Intervalos de diferentes processos são parcialmente ordenados segundo as regras hb1. Portanto, através de hb1 é possível determinar quais intervalos de outros processadores precedem o intervalo corrente de um processador p. Na prática, a criação de intervalos pode ser adiada até que aconteça comunicação com outro processo, evitando overhead se um lock é obtido novamente pelo mesmo processador. As modificações realizadas nos dados compartilhados são associadas aos intervalos em que elas ocorreram e, assim, numa operação de obtenção ocorrida no intervalo i, o processador deve ser notificado sobre todas as modificações associadas a intervalos 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 que uma 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 de tempo correspondente. Quando o processador p executa uma operação de obtenção num intervalo i ele deve receber os avisos de escrita correspondentes a todos os intervalos anteriores a i segundo hb1. Ao receber um aviso de escrita, o processador invalida a página correspondente. Os diffs relativos às modificações em questão só são recebidos na próxima falha de acesso à página. Se ocorreu uma falha de acesso em uma página k inválida, estão o sistema tem que trazer os diffs relativos às modificações realizadas em k por outros processadores. Os diffs devem ser buscados dos processadores que enviaram avisos de escrita para k. Uma característica muito importante de TreadMarks é a criação de diffs sob demanda. Em TreadMarks, um processador só cria o diff relativo às modificações realizadas em uma determinada página quando chega uma requisição para esse diff. Para minimizar o número de mensagens necessárias para a busca de diffs, TreadMarks utiliza um

39 39 esquema de propriedade (dominância) de intervalos. Um intervalo i domina um intervalo j, se j precede i na ordem parcial hb1. Assim as mensagens devem ser enviadas apenas aos processadores cujos intervalos mais recentes não são dominados pelos intervalos mais recentes de outros processadores [SEI 98]. Considere, por exemplo, os segmentos de código da figura 4.3. Quando P 2 executa lock, ele deve requisitar diffs apenas do processador P 1, porque o intervalo I 2 de P 1 domina os intervalos I 0 e I 1 de P 0 e I 0 de P 1. FIGURA 4.3 Exemplo de dominância de intervalos Existe um processador gerente, determinado estaticamente, associado a cada variável de sincronização. O gerente armazena qual foi o último processador a requisitar o lock. Toda a aquisição de lock é direcionada ao gerente e, se necessário, encaminhado para 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 de s (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ção em s. Este compara seus intervalos com os de p e envia para p os avisos de escrita relativos aos intervalos que p ainda não viu. Na chegada da mensagem com os avisos de escrita, p invalida as páginas correspondentes.

40 40 5 Calypso Calypso é o protótipo de um sistema para escrever e executar programas paralelos em plataformas não dedicadas, utilizando redes de estações de trabalho comerciais, sistemas operacionais e compiladores disponíveis. O Calypso explora os recursos disponíveis de uma arquitetura distribuída para executar uma aplicação paralela. Além disso, trata de fatores como compartilhamento de recursos, comportamento imprevisível da rede, máquinas com baixo desempenho e sujeitas a falhas. Em geral, é responsabilidade do programador controlar este fatores, tarefa que complica ainda mais o desenvolvimento de programas paralelos para estas arquiteturas. 5.1 Modelo de Programação No Calypso os programas são escritos para multiprocessador com memória compartilhada, mas são executados em uma rede de estações de trabalho que podem mudar seu comportamento durante a execução. Em outras palavras, Calypso oferece ao programador 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 utiliza uma arquitetura nova para fornecer tolerância à falhas, balanceamento automático de carga e espaço de endereçamento compartilhado, enquanto apresenta baixo overhead de tempo de execução para computação com grãos grossos [BAR 99]. O modelo de programação utilizado pelo Calypso é baseado em memória compartilhada e separa o paralelismo físico (determinado em tempo de execução) do paralelismo lógico (como expresso pelo programa) [SKI 98]. O método básico de escrever programas paralelos no Calypso é paralelizar algumas partes de um programa seqüencial, tipicamente as que possuem computação intensiva (por exemplo, paralelizar os loops). Com isso, programas paralelos são estruturados inserindo tarefas paralelas em programas seqüenciais. A execução de uma tarefa paralela é referenciada como etapa paralela, enquanto a execução de um fragmento seqüencial entre duas etapas paralelas é referenciado como etapa seqüencial. O gerenciamento da execução paralela, bem como o suporte para balanceamento de carga, tolerância à falhas e memória compartilhada, são fornecidas pelo sistema de execução. Quando mais trabalhadores unem-se, o speedup tende a aumentar. Se trabalhadores quebram, retiram-se ou tornam-se lentos, eles são automaticamente excluídos (dinamicamente) [MCL 99]. 5.2 Características do Calypso A computação do Calypso utiliza um processo gerente centralizado e um conjunto de processos trabalhadores que podem ser alocados dinamicamente. Suas principais características são: Facilidade de programação os programas são escritos em uma linguagem chamada Calypso Source Language (CSL). CSL é essencialmente C++, com a adição de construções para expressar o paralelismo (por exemplo, parbegin-parend). É baseada no modelo de memória compar-

41 41 tilhada e é simples de aprender e usar. Aspectos importantes que contribuem para facilidade de programação são a eliminação do particionamento dos dados e a necessidade de especificar como e quando mover dados entre estações de trabalho; Separação do paralelismo lógico do paralelismo físico o paralelismo expresso em uma aplicação é o paralelismo lógico e não deve ser dependente do paralelismo físico. Portanto, o paralelismo expresso pelo programador é independente do ambiente de execução, ambiente este que depende da disponibilidade das estações de trabalho. O mapeamento entre o paralelismo do programa e o paralelismo de execução é realizado de forma transparente; Tolerância a falhas execuções do Calypso são resistentes à falhas. Processos trabalhadores podem falhar, e possivelmente se recuperarem, a qualquer ponto sem afetar a coerência da computação. Diferente de outros sistemas tolerantes à falhas, não há custo adicional significativo associado a esta característica na ausência de falhas o desempenho do Calypso é semelhante a um sistema não tolerante à falhas; Balanceamento dinâmico de carga Calypso automaticamente distribui a carga de trabalho dinamicamente entre as máquinas participantes. O resultado é que trabalhadores mais rápidos realizam mais trabalho do que os trabalhadores mais lentos. Além de não haver custo associado a esta característica, ela realmente aumenta o speedup da computação, pois trabalhadores rápidos nunca ficam bloqueados esperando pelos mais lentos para finalizar suas atribuições eles ultrapassam os mais lentos; Alto desempenho enquanto fornecem estas características, foram realizados alguns experimentos que indicam um pequeno overhead para computações de grãos médios a grãos grossos [BAR 99]. Um conjunto unificado de mecanismos é utilizado para fornecer funcionalidade ao Calypso. Este conjunto de mecanismos é composto por um mecanismo de escalonamento impaciente (eager scheduling), um mecanismo que analisa a memória e cria o diff (collating differential memory) e uma estratégia idempotent de execução de duas fases (TIES Two-phase Idempotent Execution Strategy) [BAR 95]. Escalonamento impaciente fornece a habilidade de dinamicamente explorar o poder computacional de um conjunto variável de máquinas. Estas máquinas podem tornar-se lentas, carregadas ou terem dinamicamente modificadas suas propriedades de carga. O algoritmo de escalonamento atribui tarefas executáveis concorrentemente para máquinas disponíveis até que todas as tarefas sejam finalizadas. A mesma tarefa pode ser atribuída a mais de uma máquina (se todas as tarefas tiverem sido atribuídas e algumas ainda não tiverem sido completadas). Como conseqüência, máquinas livres ou mais rápidas realizam mais trabalho que as carregadas e lentas. Isto resulta no balanceamento de carga automático do sistema. Em segundo lugar, computações não ficam estagnadas enquanto o sistema comporta-se assincronamente ou sob falhas. Em terceiro lugar, novas máquinas disponíveis podem ser transparentemente assimiladas para o ambiente de execução. Finalmente, qualquer máquina trabalhadora pode falhar ou ficar lenta a qualquer momento sem interferir no resultado final.

42 42 O mecanismo que analisa a memória e cria os diffs fornece coerência lógica e sincronização, enquanto evita o falso compartilhamento. Atualizações na memória são analisadas para garantir uma execução lógica correta. Uma vez que existe a possibilidade de múltiplas execuções, é utilizado o mecanismo TIES para garantir que os resultados da execução tenham uma semântica correta. O sistema conta com estes três mecanismos para assegurar que máquinas disponíveis serão utilizadas onde elas forem mais necessárias. Uma máquina participante é utilizada para mascarar falhas e/ou aumentar o paralelismo, dependendo do estado do sistema. Portanto, o conjunto unificado de mecanismos fornece processamento paralelo e tolerância à falhas. 5.3 Funcionamento do Sistema Uma aplicação começa como um programa seqüencial, executando a primeira etapa seqüencial. Quando uma etapa paralela é alcançada, um conjunto de threads são inicializadas. Estas threads compartilham a mesma memória. Após todas as threads completarem sua execução, encerra a etapa paralela e começa a próxima etapa seqüencial (figura 5.1). FIGURA 5.1 Etapas da execução A computação do Calypso é executada por um gerente e por um conjunto de processos trabalhadores que podem mudar de quantidade dinamicamente. Na implementação atual, assume-se que o gerente deve ser um processo confiável (não pode fa-

43 43 lhar). Os trabalhadores podem ser liberados dinamicamente e ocupados novamente, trabalhar 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, enquanto que as threads da etapa paralela são executadas pelos processos trabalhadores e controladas pelo gerente. O número de threads em uma etapa paralela é determinado pela aplicação. Entretanto, o número de trabalhadores usados para executar estas threads dependem do ambiente de execução. A atribuição de threads para trabalhadores é realizada pelo gerente em tempo de execução. Durante a etapa paralela, cada um dos trabalhadores disponíveis contata o gerente e obtém uma atribuição de trabalho, isto é, uma thread não finalizada. Ele então procede para executá-la. Uma vez finalizada, o trabalhador reporta os resultados para o gerente e requisita outra atribuição. Cabe ressaltar que podem existir vários trabalhadores em um mesmo processador, mas um trabalhador não pode executar mais de uma thread 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 tarefa que é 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ão foi finalizada e foi atribuída para o menor número de trabalhadores. Estes dois critérios definem de forma simples a estratégia de escalonamento impaciente. O gerente mantém controle sobre as threads que foram atribuídas, as que foram completadas e as que ainda serão atribuídas. Além disso, tem a responsabilidade de atribuir mais tarefas aos trabalhadores. Primeiramente, o gerente prefere atribuir threads que não tenham sido atribuídas ainda para nenhum trabalhador. No entanto, escalona-