Ex de Pesquisa Aplicada PDF

AUGUSTO MENDES GOMES JNIOR
Um Ambiente de Programao e Processamento de Aplicaes

Paralelas para Grades Computacionais
So Paulo
2012

Tese apresentada Escola Politcnica da

Universidade de So Paulo para a obteno
de Ttulo de Doutor em Engenharia Eltrica.
So Paulo
2012

Tese apresentada Escola Politcnica da

Universidade de So Paulo para a obteno
de Ttulo de Doutor em Engenharia Eltrica.
rea de Concentrao:
Sistemas Digitais
Orientadora:
Prof Dr Liria Matsumoto Sato
So Paulo
2012
AGRADECIMENTOS
Deus por ter me presenteado com esta oportunidade nica em minha vida.
professora Liria Matsumoto Sato pela sua ajuda e sugestes que foram
valiosssimas para o direcionamento deste trabalho. Tambm agradeo a sua
amizade e o seu lado humano. A senhora uma pessoa incrvel e agradeo muito a
oportunidade de ser orientado pela senhora.
Aos meus familiares que foram o meu porto seguro: minha me, Margarida
Paiva de Oliveira, meu pai, Augusto Mendes Gomes e minha irm, Mariana Vilha
Gomes, e a todos os familiares que estiveram ao meu lado nesta batalha de cinco
anos.
minha esposa, Jessika de Oliveira Barbosa Gomes, que foi a pessoa que
mais teve pacincia comigo, sendo uma parceira maravilhosa. Ter uma pessoa to
especial ao meu lado me tornou uma pessoa mais forte e mais perseverante na
busca dos meus objetivos. Obrigado por fazer parte da minha vida.
Aos
colegas de
laboratrio
que
me proporcionaram
momentos de
descontrao e de aprendizado. Em especial, agradeo trs irmos que formei

durante o mestrado e o doutorado: Calebe de Paula Bianchini, Fernando Ryoji
Kakugawa e Francisco Isidro Massetto. O doutorado me proporcionou conhecer
pessoas fantsticas como vocs e a nossa amizade algo muito especial para mim.
Um sonho que se sonha s,

apenas um sonho que se sonha s.
Um sonho que se sonha junto,
realidade.
(Raul Seixas)
RESUMO
A execuo de uma aplicao paralela, utilizando grades computacionais, necessita
de um ambiente que permita a sua execuo, alm de realizar o seu gerenciamento,
escalonamento e monitoramento. O ambiente de execuo deve prover um modelo
de processamento, composto pelos modelos de programao e de execuo, no
qual o objetivo a explorao adequada das caractersticas das grades
computacionais. Este trabalho objetiva a proposta de um modelo de processamento
paralelo, baseado em variveis compartilhadas, para grades computacionais, sendo
composto por um modelo de execuo apropriado para grades e pelo modelo de
programao da linguagem paralela CPAR. O ambiente CPAR-Grid foi desenvolvido
para executar aplicaes paralelas em grades computacionais, abstraindo do
usurio todas as caractersticas presentes em uma grade computacional. Os
resultados obtidos mostram que este ambiente uma soluo eficiente para a
execuo de aplicaes paralelas.
Palavras-Chave: Sistemas distribudos. Grades computacionais. Processamento de

alto desempenho. Linguagem de programao paralela.
ABSTRACT
The execution of parallel applications, using grid computing, requires an environment
that enables them to be executed, managed, scheduled and monitored. The
execution environment must provide a processing model, consisting of programming
and execution models, with the objective appropriately exploiting grid computing
characteristics. This paper proposes a parallel processing model, based on shared
variables for grid computing, consisting of an execution model that is appropriate for
the grid and a CPAR parallel language programming model. The CPAR-Grid
environment is designed to execute parallel applications in grid computing, where all
the characteristics present in grid computing are transparent to users. The results
show that this environment is an efficient solution for the execution of parallel
applications.
Key-Words: Distributed systems. Grid computing. High performance computing.

Parallel programming language.
LISTA DE ILUSTRAES
Figura 2.1 Decomposio da multiplicao de matrizes: (a) Granularidade fina (b)
Granularidade grossa (baseado em [32]) .................................................................. 24
Figura 2.2 Grafo de dependncia de tarefas .......................................................... 25
Figura 2.3 - Abstrao da memria compartilhada distribuda (baseado em [8]) ...... 28
Figura 2.4 Tipos de algoritmos de escalonamento de tarefas para grades
computacionais (baseado em [15]) ........................................................................... 35
Figura 3.1 Modelo do espao de endereamento do ABACUS (extrado de [63]) . 42
Figura 3.2 Compilao e execuo de uma aplicao SATIN (extrado de [51]) ... 48
Figura 3.3 Arquitetura de disparo no MPICH-G2 (extrado de [36]) ....................... 51
Figura 3.4 Grade computacional composta por 2 domnios e 12 processos
(extrado de [36]) ....................................................................................................... 52
Figura 4.1 Modelo de um ambiente de grades computacionais ............................. 57
Figura 4.2 Infraestrutura do sistema....................................................................... 58
Figura 4.3 Exemplo de arquivo de submisso........................................................ 60
Figura 4.4 Arquitetura do LIMA (extrado de [54]) .................................................. 64
Figura 4.5 Arquitetura de funcionamento do Servio de Mensagem ...................... 69
Figura 4.6 Exemplo de arquivo de submisso........................................................ 70
Figura 4.7 Submisso de um Arquivo .................................................................... 70
Figura 5.1 Elementos de construo da linguagem CPAR .................................... 72
Figura 5.2 Sintaxe da Declarao de uma Varivel Compartilhada ....................... 72
Figura 5.3 Sintaxe do Bloco Paralelo ..................................................................... 73
Figura 5.4 Sintaxe: Especificao (a), Corpo (b) e Chamada (c) de uma
Macrotarefa (extrado de [28]) ................................................................................... 74
Figura 5.5 Sintaxe do Comando Forall ................................................................... 75
Figura 5.6 Sintaxe da Construo Parbegin ........................................................... 75
Figura 5.7 Sintaxe de um Macrobloco .................................................................... 75
Figura 5.8 Sintaxe dos Comandos do Semforo (baseado em [28]) ...................... 76
Figura 5.9 Sintaxe dos Comandos do Evento (baseado em [28]) .......................... 77
Figura 5.10 Sintaxe de um Monitor ........................................................................ 78
Figura 6.1 Gerao do cdigo executvel no ambiente ......................................... 81
Figura 6.2 Exemplo de aplicao CPAR ................................................................ 84
Figura 6.3 Exemplo de alocao de processos para uma aplicao exemplo ....... 85
Figura 6.4 Modelo de execuo para grades computacionais ............................... 91
Figura 6.5 Mapeamento das variveis compartilhadas em endereos de memria
.................................................................................................................................. 95
Figura 7.1 Unificao dos processos em um n multiprocessador ...................... 101
Figura 7.2 Primeiro fluxo para o controle do trmino de uma tarefa ou bloco ...... 103
Figura 7.3 Segundo fluxo para o controle do trmino de uma macrotarefa ou
macrobloco .............................................................................................................. 105
Figura 7.4 Regio que compartilha o dado entre o emissor e o executor ............ 106
Figura 7.5 Escrita pelo coordenador na rea compartilhada com o executor ...... 106
Figura 7.6 Pontos de sincronizao do CPAR-Grid ............................................. 109
Figura 7.7 Primeiro acesso a uma varivel compartilhada ................................... 110
Figura 7.8 Atualizao das variveis compartilhadas........................................... 111
Figura 7.9 Fluxograma da estratgia de escalonamento dos macroblocos ......... 113
Figura 7.10 Mensagens enviadas para o escalonamento de um macrobloco ...... 114
Figura 7.11 Fluxograma da estratgia de escalonamento das macrotarefas ....... 116
Figura 7.12 Mensagens enviadas para o escalonamento de uma macrotarefa ... 118
Figura 8.1 Estrutura do algoritmo sinttico ........................................................... 125
Figura 8.2 Estrutura do algoritmo das matrizes utilizando a verso com variveis
locais e a verso completa ...................................................................................... 127
Figura 8.3 Estrutura do algoritmo das matrizes utilizando a verso somente com
macrotarefas ........................................................................................................... 128
Figura 8.4 Grafo com o tempo de comunicao entre os domnios (universidades)
................................................................................................................................ 130
Figura 8.5 Grfico de mensagens internas e externas para o gerenciamento da
aplicao ................................................................................................................. 135
Figura 8.6 Grfico de desempenho da verso com variveis locais .................... 136
Figura 8.7 Grfico com a quantidade de mensagens enviadas internas e externas
................................................................................................................................ 139
Figura 8.8 Grfico com o tempo de execuo das verses somente com tarefas e
completa .................................................................................................................. 140
Figura 8.9 Grfico de desempenho da verso completa ...................................... 143
LISTA DE TABELAS
Tabela 3.1 Anlise comparativa dos ambientes de programao .......................... 55
Tabela 8.1 Tempo de comunicao entre os domnios (universidades) .............. 130
Tabela 8.2 Detalhes das mensagens enviadas na verso com variveis locais .. 134
Tabela 8.3 Tempo de processamento da verso com variveis locais ................ 136
Tabela 8.4 Quantidade de mensagens enviadas na mdia da soma das matrizes
multiplicadas............................................................................................................ 138
Tabela 8.5 Tempo de processamento da verso completa .................................. 142
LISTA DE ABREVIATURAS E SIGLAS

API
Application Program Interface
BNF
Backus Normal Form
CM
Collector Module
CPAR
Linguagem C com construes paralelas
CRS
Cluster-aware Random Stealing
DR
Data Repository
DRMAA
Distributed Resource Managment
DSM
Distributed Shared Memory
DUROC
Dynamically Updated Resource Online Co-Allocator
FTP
File Transfer Protocol
GASS
Global Access to Secondary Storage
GCSE
Grid Cooperative Scheduling Environment
GFS
Grid File System
GRAM
Globus Resource Allocation Manager
GridRPC
Grid Remote Procedure Call
GridCPR
Grid Checkpoint and Recovery
GSI
Grid Security Infrastructure
HTTPS
HyperText Transfer Protocol Secure
JVM
Java Virtual Machine
LAHPC
Laboratory of Architecture and High Perfomance Computing
LIMA
Light-weIght Monitoring Architecture
MDS
Monitoring and Discovery Service
MPI
Message Passing Interface
PRMM
Pool Resource Monitoring Manager
PVM
Parallel Virtual Machine
SOAP
Simple Object Access Protocol
SPMD
Single Program multiple Data
TCP
Transmission Control Protocol
WAN
Wide Area Network
WSDD
Web Service Deployment Descriptor
XML
eXtensible Markup Language
SUMRIO
1. INTRODUO .................................................................................................... 15
1.1 Objetivos .................................................................................................... 16
1.2 Justificativa ................................................................................................ 17
1.3 Metodologia ............................................................................................... 19
1.4 Estrutura do Texto ..................................................................................... 21
2. COMPUTAO PARALELA ............................................................................... 22
2.1 Conceitos de programao paralela .......................................................... 22
2.1.1 Modelos de comunicao .................................................................... 22
2.1.2 Granularidade ...................................................................................... 24
2.1.3 Sincronizao ...................................................................................... 25
2.1.4 Modelos de algoritmos paralelos ......................................................... 26
2.2 Memria compartilhada distribuda ............................................................ 28
2.2.1 Estrutura .............................................................................................. 30
2.2.2 Modelo de consistncia ....................................................................... 31
2.3 Escalonamento de tarefas para grades computacionais ........................... 34
2.3.1 Escalonamento de tarefas independentes ........................................... 35
2.3.2 Escalonamento de tarefas dependentes.............................................. 37
2.4 Consideraes finais .................................................................................. 39
3. AMBIENTES DE PROGRAMAO PARA GRADES COMPUTACIONAIS ........ 40
3.1 ABACUS .................................................................................................... 41
3.2 SAGA ......................................................................................................... 43
3.3 SATIN ........................................................................................................ 46
3.4 MPICH-G2 ................................................................................................. 50
3.5 Anlise Comparativa .................................................................................. 54
3.6 Consideraes Finais ................................................................................ 56
4. INFRAESTRUTURA DA GRADE COMPUTACIONAL DO CPAR-GRID............. 57
4.1 Condor ....................................................................................................... 59
4.1.1 Preparao do Cdigo ......................................................................... 60
4.1.2 Submisso do Job ............................................................................... 60
4.2 Globus........................................................................................................ 61
4.2.1 Gerenciamento e Alocao dos Recursos da Grade (GRAM) ............. 62
4.2.2 Monitoramento e Descoberta dos Servios (MDS) .............................. 62

4.3 GCSE e LIMA ............................................................................................ 63
4.4 Interface MPI.............................................................................................. 65
4.5 Servio de Mensagem ............................................................................... 66
4.5.1 Funcionamento .................................................................................... 67
4.5.2 Arquitetura ........................................................................................... 68
4.6 Consideraes finais .................................................................................. 69
5. A LINGUAGEM CPAR......................................................................................... 71
5.1 Variveis Compartilhadas .......................................................................... 72
5.2 Blocos Paralelos ........................................................................................ 73
5.3 Macrotarefas .............................................................................................. 73
5.4 Microtarefas ............................................................................................... 74
5.5 Macroblocos............................................................................................... 75
5.6 Mecanismos de Sincronizao .................................................................. 76
6. MODELO
DE
PROCESSAMENTO
PARALELO
PARA
GRADES
COMPUTACIONAIS .................................................................................................. 79
6.1 Caractersticas de grades computacionais ................................................ 80
6.2 Ambiente de programao ......................................................................... 80
6.3 Modelo de programao ............................................................................ 82
6.4 Modelo de execuo .................................................................................. 89
6.4.1 Coordenador Mestre ............................................................................ 91
6.4.2 Coordenador Local .............................................................................. 92
6.4.3 Executor ............................................................................................... 93
6.4.4 Emissor ................................................................................................ 94
6.4.5 Fila de execuo .................................................................................. 94
6.4.6 Gerenciador de variveis compartilhadas ............................................ 95
6.4.7 Escalonador ......................................................................................... 96
7. O AMBIENTE DE EXECUO CPAR-GRID ...................................................... 99
7.1 Modelo do CPAR-Grid ............................................................................... 99
7.2 Controle de finalizao das macrotarefas e dos macroblocos ................. 102
7.3 Buffer ....................................................................................................... 105
7.4 Atualizao das variveis compartilhadas ............................................... 108
7.5 Estratgia de escalonamento................................................................... 111

7.5.1 Escalonamento dos macroblocos ...................................................... 112
7.5.2 Escalonamento das macrotarefas...................................................... 115
7.5.3 Escalonamento das microtarefas ....................................................... 119
7.6 Consideraes Finais .............................................................................. 119
8. TESTES E ANLISE DOS RECURSOS OFERECIDOS PELO CPAR-GRID ... 121
8.1 Testes escolhidos .................................................................................... 123
8.1.1 Algoritmo sinttico para o teste de funcionalidade ............................. 124
8.1.2 Mdia da soma de multiplicaes de matrizes .................................. 126
8.2 Configurao do ambiente de teste ......................................................... 129
8.3 Anlise do CPAR-Grid ............................................................................. 131
8.3.1 Funcionalidade das estratgias implementadas ................................ 131
8.3.2 Impacto da comunicao na coordenao e gerenciamento de uma
aplicao paralela ....................................................................................... 133
8.3.3 Escalonamento de macrotarefas e macroblocos ............................... 137
8.3.4 Atualizao das variveis compartilhadas ......................................... 140
8.3.5 Anlise de desempenho .................................................................... 142
8.4 Consideraes Finais .............................................................................. 144
9. CONCLUSO .................................................................................................... 145
9.1 Contribuies ........................................................................................... 146
9.2 Trabalhos futuros ..................................................................................... 147
Referncias ............................................................................................................. 149
Apndice A - Tokens da Linguagem CPAR ............................................................ 156
Apndice B - Gramtica da Linguagem CPAR ........................................................ 162
Apndice C Cdigo fonte dos Testes ................................................................... 178
C.1 Algoritmo sinttico .................................................................................... 178
C.2 Algoritmo que calcula a mdia da soma das matrizes multiplicadas........ 180
C.2.1 Verso com variveis locais .............................................................. 180
C.2.2 Verso completa ............................................................................... 185
C.2.3 Verso somente com macrotarefas .................................................. 189
15
1. INTRODUO
O paradigma de programao paralela [45], geralmente, utiliza variveis

compartilhadas como o mecanismo de comunicao entre processos em uma
mquina. Isso possvel devido aos processos estarem no mesmo local e terem a
memria como uma regio comum. A utilizao de variveis compartilhadas facilita a
programao, pois o usurio no precisa explicitar a comunicao entre os
processos, tornando a programao semelhante programao sequencial
tradicional.
Para a utilizao de uma linguagem paralela baseada em variveis
compartilhadas, em cluster de computadores, necessrio que a memria
compartilhada seja simulada atravs de sistemas DSM (Distributed Shared Memory)
[9].
Algumas
linguagens
paralelas
foram
desenvolvidas
para
cluster
de
computadores, como as linguagens C x C [34] e UPC (Unified Parallel C) [67].

Tambm h sistemas de memria compartilhada distribuda que possuem uma
linguagem de programao acoplada ao sistema, como os sistemas TreadMarks [37]
e Score Omni-OpenMP [6]. Foram implementadas duas verses da linguagem
CPAR para cluster de computadores, CPAR-Cluster [9] e CPAR-WinCluster [28].
Nestas verses, as variveis compartilhadas so alocadas nas memrias locais de
cada n do cluster.
Um sistema de grade computacional pode ser definido como uma
infraestrutura de software capaz de gerenciar diversos recursos computacionais,
possivelmente distribudos por uma grande rea geogrfica, de maneira a oferecer
aos usurios acesso aos recursos de forma transparente [20].
Na maioria dos casos, o recurso disponibilizado por uma grade a
capacidade de processamento. Porm, alguns sistemas podem utilizar outros, como
dispositivos de armazenamento de grande capacidade ou bases de dados de
diferentes fontes.
As grades computacionais so constitudas por domnios distribudos
geograficamente, podendo compor uma estrutura hierrquica de domnios. Um
domnio pode conter ns monoprocessados ou multiprocessados e clusters.
16
Geralmente, os ns internos de um cluster possuem endereamento privado,

inviabilizando a comunicao direta com um processo externo ao cluster.
Uma linguagem paralela, para ser utilizada em aplicaes para grades
computacionais, precisa estar adequada s suas caractersticas, alm da
necessidade de um ambiente que permita a execuo, a comunicao, o
gerenciamento, o escalonamento e o monitoramento das aplicaes paralelas.
O ambiente de execuo deve prover um modelo de processamento, cujo
objetivo a explorao adequada das caractersticas das grades computacionais. O
ambiente de execuo responsvel pelo gerenciamento e escalonamento da
aplicao. Os elementos do modelo de processamento devem atender as
especificaes de um ambiente de grades computacionais.
1.1 Objetivos
O objetivo deste trabalho apresentar a proposta e o desenvolvimento de um
modelo de processamento paralelo, baseado em variveis compartilhadas, para
grades computacionais. Ele composto por um modelo de execuo apropriado
para grades e pelo modelo de programao da linguagem paralela CPAR [56].
O ponto fundamental do modelo, visando a otimizao de desempenho, a
utilizao de estratgias que minimizem a troca de mensagens e apliquem um
mecanismo de escalonamento que privilegie os ns do domnio, objetivando a
diminuio da distncia entre os ns que se comunicam e a utilizao adequada da
estrutura hierrquica das grades computacionais.
A linguagem CPAR foi escolhida devido a prover mltiplos nveis de
paralelismo, atravs de uma estrutura hierrquica, facilitando a explorao da
arquitetura, em geral, hierrquica das grades computacionais.
A utilizao de variveis compartilhadas para a comunicao entre os
processos que so executados por uma aplicao facilita o seu desenvolvimento,
pois no necessrio explicitar a comunicao atravs da troca de mensagens.
Foi implementado o ambiente CPAR-Grid para a execuo de aplicaes
paralelas nas grades computacionais, analisando o comportamento do modelo de
processamento proposto.
O ambiente de execuo deve prover uma infraestrutura que realize as
seguintes tarefas:
17
Submeter a aplicao;
Monitoramento da execuo da aplicao;
Escalonamento dos ns;
Envio da aplicao para os ns remotos da grade;
Disparo e gerenciamento da execuo da aplicao;
Comunicao entre os ns da grade.
Atravs desta infraestrutura, o ambiente possibilita que uma aplicao escrita

na linguagem CPAR seja executada em uma grade computacional. Para minimizar a
quantidade de mensagens trocadas no seu gerenciamento, e para aumentar o
desempenho da execuo da aplicao, as seguintes caractersticas esto
presentes no modelo de processamento:
Oferecimento de mecanismos de sincronizao e de primitivas para

explicitar o paralelismo;
Otimizao no escalonamento de tarefas e blocos para que a estrutura

hierrquica das grades computacionais seja aproveitada;
Estratgia de atualizao das variveis, conforme a utilizao para

minimizar a quantidade de mensagens trocadas;
Explorao
da
rea
de
memria
compartilhada
em
ns
multiprocessadores para minimizar a troca de mensagens.
1.2 Justificativa
Hoje em dia, as aplicaes com alta demanda de processamento esto
utilizando as grades computacionais para a sua execuo [68]. Porm, grande parte
das aplicaes que so executadas em uma grade so aplicaes de workflow [12],
no qual o compartilhamento de informaes ocorre atravs de arquivos, ao invs da
utilizao de memria compartilhada ou troca de mensagens.
As aplicaes paralelas, que so executadas nas grades computacionais
atravs de workflows, so formadas por um conjunto de tarefas, no qual cada tarefa
um programa e a comunicao entre as tarefas ocorre atravs de arquivos de
entrada e sada. Caso duas tarefas estejam executando de maneira simultnea, elas
no se comunicam durante a execuo. Ao final da execuo, uma tarefa gera um
18
arquivo de sada e este arquivo pode servir de entrada para outra tarefa. Atravs dos
arquivos, forma-se a dependncia entre as tarefas, j que uma tarefa que dependa
de alguns arquivos de entrada somente iniciar a sua execuo quando estes
arquivos estiverem disponveis.
A
utilizao
de
uma
linguagem
de
programao
paralela
para
desenvolvimento de aplicaes paralelas, geralmente utiliza memria compartilhada

ou troca de mensagens como o mecanismo de comunicao. Estes mecanismos
facilitam
desenvolvimento
de
aplicaes
para
ambiente
de
grades
computacionais [68], alm de permitir que a comunicao entre duas ou mais tarefas
ocorra durante a sua execuo.
Para a execuo de linguagens paralelas que utilizam rea de memria
compartilhada ou troca de mensagens para o compartilhamento de informaes,
necessrio que exista um ambiente de programao para o gerenciamento das
aplicaes, que seja responsvel pela submisso, escalonamento, monitoramento e
execuo da aplicao.
H poucos ambientes de programao para grades computacionais que no
so baseados em workflow. Os ambientes encontrados na literatura foram: SATIN
[51], SAGA [30] e ABACUS [63]. Estes possuem uma infraestrutura para a execuo
de aplicaes paralelas. Tambm h a biblioteca de passagem de mensagens
MPICH-G2 [36] que utilizada para a comunicao de processos em domnios
distintos. Porm, utilizando MPICH-G2, todos os ns de processamento na grade
computacional precisam ter endereamento pblico. Os ns internos de clusters de
computadores, geralmente, possuem endereamento privado, o que inviabiliza a
execuo de aplicaes paralelas em grades computacionais em que estes estejam
presentes.
O paradigma de programao [58] oferecido pelo SATIN, ABACUS e SAGA
orientado a objetos e com relao ao compartilhamento das informaes, os
ambientes estudados utilizam arquivos [30], servios [63] ou objetos [51].
proposta apresentada nesta tese utiliza variveis compartilhadas para a troca de

informaes entre os processos de uma aplicao. Para garantir a segurana e a
integridade da aplicao, utiliza-se um mecanismo de consistncia para a
atualizao das variveis compartilhadas.
A utilizao de variveis compartilhadas facilita o desenvolvimento de
aplicaes paralelas para o usurio, j que ele no precisa se preocupar com o
19
envio/recebimento de mensagens. Alm disso, a estrutura de uma varivel mais

simples do que objetos ou servios, o que ajuda na comunicao das atualizaes
das variveis compartilhadas, pois o contedo da mensagem enviada ser menor
[9].
Uma dificuldade existente para a utilizao de linguagens paralelas para a
execuo em grades computacionais o processamento das aplicaes paralelas,
seja por troca de mensagens ou por memria compartilhada. Isso ocorre devido ao
custo de comunicao entre os ns da grade computacional. A utilizao da
estrutura hierrquica das grades computacionais na distribuio das tarefas, de
modo a diminuir a distncia entre os ns de processamento que se comunicam,
pode reduzir o problema da comunicao entre os ns da grade.
O paradigma de programao deste trabalho possibilita o desenvolvimento de
aplicaes paralelas a serem executadas em uma grade computacional utilizando
uma estrutura de programao hierrquica.
Para a execuo eficiente das aplicaes paralelas no ambiente de grades,
necessrio que o ambiente possua um modelo de programao que explore a
estrutura hierrquica das grades, incluindo a utilizao dos diferentes domnios e
dos ns internos dos clusters, e um modelo de execuo que minimize a quantidade
de mensagens trocadas e o custo da comunicao, facilitando o gerenciamento das
aplicaes.
A contribuio principal deste trabalho a adequao do modelo de
programao e de execuo propostos e da sua implementao para explorar a
estrutura hierrquica de processamento, presentes em grades computacionais
contendo clusters de computadores, visando reduzir o impacto da comunicao.
O ambiente denominado CPAR-Grid foi desenvolvido utilizando os modelos
de programao e de execuo propostos, cuja finalidade a execuo de
aplicaes paralelas de maneira transparente, objetivando o desempenho na sua
execuo.
1.3 Metodologia
O modelo de processamento do ambiente de execuo teve como base os
trabalhos desenvolvidos por Craveiro [9] e Gomes Jr. [28]. Nestes trabalhos, foram
desenvolvidos
um
ambiente
para
programao
paralela
com
variveis
20
compartilhadas em um sistema distribudo heterogneo (quanto ao nmero de

processadores), para as clusters Linux e Windows, denominados, respectivamente,
CPAR-Cluster e CPAR-WinCluster.
Porm, houve trabalhos anteriores que serviram de apoio para o
desenvolvimento deste trabalho. Em 1989, Sato [56] iniciou o desenvolvimento da
sua Tese de Livre Docncia, no qual foi proposta a linguagem CPAR, implementada
em uma verso do sistema de programao e processamento CPAR para mquinas
paralelas com memria compartilhada.
Um passo posterior foi a implementao de um sistema de programao
oferecendo facilidades para o desenvolvimento de aplicaes em ambientes
distribudos heterogneos, e permitindo a explorao dos recursos computacionais
disponveis em uma rede. Em 1997, Iguma [33] desenvolveu um ambiente
distribudo que oferece a linguagem CPAR e se baseia no sistema PVM [21] para a
comunicao entre os ns monoprocessadores de uma rede.
O trabalho de Craveiro [9] e o trabalho de Gomes Jr. [28] tambm utilizaram a
linguagem CPAR, porm para a comunicao entre os ns da rede foi utilizada a
interface MPI como biblioteca de passagem de mensagens. Os sistemas propostos
incluem ns monoprocessadores e multiprocessadores.
A infraestrutura do ambiente CPAR-Grid foi elaborada com as seguintes
ferramentas: Globus [17], como middleware de gerenciamento e autenticao da
grade; Condor [5], como escalonador local e mecanismo de disparo das aplicaes;
LIMA [54] como mecanismo de monitoramento dos recursos e GCSE [54] como
escalonador global da aplicao, escolhendo os ns que executaro a aplicao.
A comunicao entre os ns da rede foi realizada atravs da interface MPI.
Porm, as implementaes MPI disponveis no realizam a comunicao entre ns
em domnios distintos e com endereamento privado. Para contornar este problema,
foi implementada uma biblioteca MPI no projeto Infraestrutura de grade
computacional para aplicaes de alta performance em projetos de leo & gs, no
contexto da Rede Galileu para realizar esta comunicao, e esta biblioteca
utilizada neste trabalho.
Os
ambientes
existentes
para
grades
computacionais
as
suas
caractersticas foram estudados. Com base neste estudo, o ambiente CPAR-Grid

comeou a ser modelado e os seus principais recursos comearam a ser definidos.
21
O ponto fundamental foi a definio do modelo de processamento, orientado

ao modelo de programao da linguagem CPAR, j que esta possui mltiplos nveis
de paralelismo, facilitando a distribuio e execuo da aplicao no ambiente de
grades computacionais. Foi definida a arquitetura do modelo de execuo, com o
objetivo de aumentar o desempenho das aplicaes paralelas, atravs da
minimizao do tempo gasto com a comunicao entre os processos.
1.4 Estrutura do Texto

O primeiro captulo apresenta o problema, a metodologia, a justificativa e o
objetivo que este trabalho pretende alcanar.
O captulo 2 apresenta conceitos de programao paralela, memria
compartilhada
distribuda
algoritmos
de
escalonamento
para
grades
computacionais.
O captulo 3 faz uma reviso sobre os principais ambientes de programao
para grades computacionais, mostrando as caractersticas de todos os ambientes.
Alm disso, feita uma comparao entre os ambientes, mostrando as suas
vantagens e desvantagens.
O captulo 4 explica a caracterstica e o funcionamento de todas as
ferramentas utilizadas para o desenvolvimento da infraestrutura do ambiente
proposto nesta tese. O captulo tambm mostra como a juno destas ferramentas
para a elaborao do ambiente.
A linguagem CPAR detalhada no captulo 5, pois esta a linguagem na qual
o programador desenvolve aplicaes para serem executadas no ambiente CPARGrid.
O modelo de processamento proposto para a execuo de aplicaes
paralelas em grades computacionais descrito no captulo 6, no qual detalhado o
seu modelo de programao e de execuo. O captulo 7 detalha a implementao
do ambiente CPAR-Grid, mostrando a sua arquitetura e as suas funcionalidades.
O captulo 8 apresenta os testes realizados para analisar o funcionamento do
ambiente de acordo com as estratgias implementadas e o seu desempenho. O
captulo 9 conclui o trabalho, ressaltando as contribuies da tese e trazendo
sugestes de trabalhos futuros.
22
2. COMPUTAO PARALELA
Para o desenvolvimento de um ambiente de grades computacionais que d

suporte execuo de aplicaes paralelas, necessria a utilizao de memria
compartilhada distribuda para simular a rea de memria compartilhada existente
em um computador multiprocessador, assim como a utilizao de um mecanismo de
escalonamento de tarefas entre os computadores da grade.
Este captulo aborda os principais conceitos de programao paralela, alm
da memria compartilhada distribuda e dos algoritmos de escalonamento de tarefas
para grades computacionais.
2.1 Conceitos de programao paralela

A computao paralela tem um grande impacto em uma variedade de reas
que vo desde simulao computacional de aplicaes cientficas e de engenharia,
at aplicaes comerciais em minerao de dados e processamento de transaes
[32]. Para o desenvolvimento de aplicaes paralelas necessrio o estudo dos
modelos de paralelismo e de comunicao existentes, da granularidade e da
sincronizao.
O conceito de tarefas paralelas, utilizado neste captulo, est relacionado a
sequncias de instrues executadas de maneira simultnea e, possivelmente,
concorrente.
2.1.1 Modelos de comunicao

H duas formas de comunicao entre tarefas paralelas, memria
compartilhada e troca de mensagens. A memria compartilhada de uma plataforma
paralela possui um espao de dados comum que acessvel a todos os
processadores, sendo que os processadores interagem atravs da leitura e escrita
de dados na rea de memria compartilhada [32].
A presena de uma rea de memria compartilhada facilita a programao,
pois as interaes de leitura so invisveis ao desenvolvedor, no havendo diferena
23
da programao que realizada em um programa sequencial. Porm, quando h

leitura e escrita, as interaes tornam-se mais difceis de programar do que as
interaes de somente leitura, pois necessitam de operaes de excluso mtua
para acesso concorrente. Os paradigmas de programao que utilizam espao de
endereo compartilhado, como threads [40] ou diretivas [62] realizam o acesso
regio de memria compartilhada atravs de mecanismos de sincronizao [61].
A presena de caches em processadores tambm aumenta a questo de
mltiplas cpias de uma palavra na memria sendo manipulada por dois ou mais
processadores ao mesmo tempo. O suporte de espao de endereamento
compartilhado neste contexto envolve duas tarefas principais: fornecer um
mecanismo de traduo de endereos que localiza a palavra na memria, e garantir
que as operaes simultneas nas mltiplas cpias da mesma palavra na memria
tenham a semntica bem definida. A ltima tarefa conhecida como o mecanismo
de coerncia de cache [32]. A seo 2.2 discute a consistncia dos dados em um
sistema de memria distribuda.
Uma plataforma de passagem de mensagens consiste de p ns de
processamento, cada um com seu prprio espao de endereamento. Os ns de
processamento podem ser monoprocessador ou multiprocessador. O cluster de
computadores um exemplo desta plataforma de passagem de mensagem. As
interaes entre processos executando em diferentes ns devem ser realizadas
atravs de mensagens. Esta troca de mensagens utilizada para transferncia de
dados, carga de trabalho, e para sincronizar as aes entre os processos. O
paradigma de passagem de mensagens suporta a execuo de diferentes
programas em cada um dos p ns.
Como as interaes so realizadas atravs do envio e recebimento de
mensagens, as operaes bsicas neste paradigma de programao so send e
receive. Para a realizao da comunicao, necessrio o endereo do n receptor,
no caso a sua identificao (ID). Para isso, h a operao getRank que retorna o
identificador de um n especfico. Alm disso, h outra operao que utilizada para
completar o conjunto bsico de operaes de passagem de mensagens - numprocs,
que especifica o nmero de processos que participam do processamento de uma
aplicao. Com estas quatro operaes possvel escrever qualquer programa com
passagem de mensagens.
24
2.1.2 Granularidade
O tamanho de uma tarefa est relacionado quantidade de processamento.
Quando uma tarefa pequena significa que ela possui pouco processamento. O
oposto ocorre para as tarefas grandes.
O nmero e o tamanho das tarefas nos quais um problema decomposto,
determina a granularidade da decomposio, sendo que a decomposio em um
grande nmero de pequenas tarefas chamada de granularidade fina. Por outro
lado, a decomposio em um pequeno nmero de grandes tarefas chamada de
granularidade grossa. A decomposio do problema de multiplicao de matrizes
ilustrado na Figura 2.1-a um exemplo de granularidade fina porque h um grande
nmero de tarefas, no qual cada uma executa o clculo de uma clula da matriz
resultante [32].
A Figura 2.1-b ilustra um exemplo de decomposio em granularidade grossa,
no qual o mesmo problema dividido em trs tarefas, sendo que cada uma
processa um tero da matriz resultante.
Um conceito relacionado a granularidade o grau de paralelismo. O nmero
mximo de tarefas que podem ser executadas simultaneamente em um programa
paralelo, em determinado momento conhecido como seu grau mximo de
paralelismo. Na maioria dos casos, o grau mximo menor que o nmero total de
tarefas, devido s dependncias existentes entre as tarefas.
Figura 2.1 Decomposio da multiplicao de matrizes: (a) Granularidade fina (b)

Granularidade grossa (baseado em [32])
25
O grau de concorrncia tambm depende da relao entre as tarefas.

Geralmente, as tarefas podem utilizar os dados produzidos por outras tarefas, sendo
que necessrio que as tarefas terminem a sua execuo para que uma tarefa
dependente delas inicie a sua execuo. Uma abstrao utilizada para expressar a
dependncia entre as tarefas e a sua ordem de execuo conhecida como grafo
de dependncia de tarefas [32]. A Figura 2.2 ilustra um grafo de dependncia de
tarefas, no qual os crculos so as tarefas (tasks) e as setas ilustram as
dependncias. Pode-se visualizar que a tarefa 5 dependente das tarefas 1 e 2, a
tarefa 6 dependente das tarefas 3 e 4 e a tarefa 7 dependente das tarefas 6 e 5.
Figura 2.2 Grafo de dependncia de tarefas
2.1.3 Sincronizao
Em uma aplicao paralela, dois ou mais processos podem, praticamente no
mesmo momento, acessar um dado compartilhado. Neste caso, o resultado final do
processamento depende da ordem em que os acessos ocorreram em uma
execuo. Esta situao, na qual os processos disputam o acesso a um dado
compartilhado, chamada de condio de corrida.
Para evitar a condio de corrida, necessrio implementar a excluso
mtua durante a execuo, ou seja, um mecanismo que garante que no ocorrer
acessos simultneos a um recurso compartilhado. Em uma aplicao paralela,
apenas alguns trechos de cdigo fazem acesso a recursos compartilhados. Desta
forma, utiliza-se um mecanismo de excluso mtua somente nos trechos que
acessam recursos compartilhados, os quais so chamados de regio crtica.
26
A sincronizao realizada no acesso aos trechos de regio crtica da

aplicao. A utilizao de um mecanismo de sincronizao nas regies crticas de
uma aplicao paralela fundamental para a sua consistncia. Os principais
mecanismos de sincronizao utilizados para garantir o acesso exclusivo aos
recursos compartilhados so: semforos, contadores de evento, mutexes, monitores
e troca de mensagens [61].
2.1.4 Modelos de algoritmos paralelos

Um modelo de algoritmo paralelo uma maneira de estruturar um algoritmo
paralelo atravs da seleo de uma tcnica de decomposio e aplicao da
estratgia apropriada para minimizar as comunicaes. Os principais modelos
existentes so: modelo de dados paralelos, modelo de grafo de tarefas, modelo
mestre-escravo e modelo pipeline [32].
Modelo de dados paralelos
Neste modelo as tarefas so estaticamente mapeadas em processos, os

quais realizam operaes similares sobre dados diferentes. A execuo da tarefa
pode ser feita em fases, sendo que os dados operados em cada fase podem ser
diferentes. As fases da computao de dados paralelos so intercaladas com
interaes para sincronizar as tarefas ou para obter os dados atualizados. Como
todas as tarefas realizam clculos semelhantes, a decomposio do problema em
tarefas, geralmente, baseada na diviso dos dados, pois a diviso uniforme de
dados auxilia no balanceamento de carga, desde que os ns sejam homogneos.
Modelo de grafo de tarefas
A execuo de alguns algoritmos paralelos pode ser visualizada atravs de

um grafo de dependncia de tarefas. No modelo de grafo de tarefas, o
relacionamento entre as tarefas utilizado para promover a localidade ou para
reduzir o custo das interaes.
Este modelo utilizado para resolver problemas no qual a quantidade de
dados associados s tarefas maior do que a quantidade de processamento
27
associada a eles. Geralmente, as tarefas so mapeadas estaticamente para otimizar

o custo da movimentao dos dados entre as tarefas. Porm, algumas vezes um
mapeamento dinmico descentralizado pode ser utilizado, mas mesmo assim, este
mapeamento utiliza as informaes do grafo de dependncia das tarefas para
minimizar a sobrecarga de interaes.
Modelo mestre-escravo
Neste modelo um ou mais processos mestre geram a tarefa e a alocam aos

processos escravos. As tarefas podem ser alocadas estaticamente, realizando a
distribuio do processamento entre os escravos de maneira igualitria, ou
dinamicamente, realizando a distribuio de acordo com a demanda de
processamento e capacidade dos ns de execuo.
O modelo mestre-escravo pode ser generalizado para um modelo hierrquico,
no qual o mestre no nvel superior gera grandes tarefas para os mestres do segundo
nvel, que, por sua vez, dividem as tarefas entre seus prprios escravos e ainda
podem realizar parte do processamento.
Deve-se evitar que o mestre seja um gargalo. Geralmente, isso acontece
quando as tarefas geradas so muito pequenas ou quando os escravos tem alto
poder de processamento. A granularidade das tarefas deve ser escolhida de tal
forma que o custo do seu processamento domine a somatria dos seus custos de
transferncia e de sincronizao.
Modelo pipeline
No modelo pipeline, um fluxo de dados passa por sucessivos processos, no

qual cada um deles realiza o processamento de alguma tarefa. Com exceo do
processo que inicia o pipeline, a chegada de novos dados dispara a execuo de
uma nova tarefa por um processo no pipeline.
O pipeline uma cadeia de produtores e consumidores. Cada processo pode
ser visto como o consumidor de uma sequncia de dados do processo anterior, e
como o produtor de dados para o prximo processo. No h a necessidade de o
pipeline ser linear, sendo que ele tambm pode ser um grafo dirigido.
28
Quanto maior a granularidade, mais tempo demorar a completar o pipeline.

No entanto, a granularidade muito fina pode sobrecarregar a aplicao, pois os
processos precisaro interagir para receber dados atualizados aps pouco tempo de
processamento.
2.2 Memria compartilhada distribuda

A memria compartilhada (DSM Distributed Shared Memory) uma
abstrao utilizada para o compartilhamento de dados entre computadores que no
compartilham a memria fsica [8]. Os processos acessam a DSM para efetuar
leituras e escritas como se estivessem acessando a sua prpria regio de memria
fsica. Para garantir o acesso aos dados atualizados, o ambiente que implementa a
DSM realiza a atualizao dos dados para todos os computadores de maneira
transparente, sem que os processos precisem se preocupar. Desta forma, os
processos acessam uma memria compartilhada nica, mas na realidade a memria
fsica distribuda, conforme pode ser visualizado na Figura 2.3.
A DSM elimina a preocupao do desenvolvedor em realizar troca de
mensagens para atualizar as informaes entre os processos em diferentes
computadores. A DSM principalmente utilizada em aplicaes paralelas e
distribudas que possuam dados compartilhados.
Figura 2.3 - Abstrao da memria compartilhada distribuda (baseado em [8])
29
Contudo, o ambiente que implementa a DSM precisa enviar atualizaes dos

dados e isso ocorre atravs de troca de mensagens. Para reduzir o nmero de
mensagens, os sistemas DSM mantm rplicas dos dados compartilhados nos ns
que os acessam. Estas rplicas so atualizadas quando ocorrem alteraes destes
dados.
Os sistemas de DSM gerenciam os dados replicados, sendo que cada
computador possui uma cpia local dos dados armazenados na DSM e acessados
recentemente. Isso realizado para aumentar a velocidade de acesso.
A implementao de uma DSM pode ser realizada atravs de hardware
especializado, memria virtual paginada ou middleware. Os sistemas que utilizam
memria virtual paginada implementam a DSM como uma regio de memria virtual
ocupando o mesmo intervalo de endereos no espao de endereamento de cada
processo participante. Esse tipo de implementao, normalmente, conveniente
apenas para um conjunto de computadores homogneos, com dados e formatos de
pginas comuns.
Na implementao atravs de um middleware, o compartilhamento
realizado atravs da comunicao entre as instncias da camada de suporte. Os
processos fazem chamadas a essa camada quando acessam a DSM. As instncias
dessa camada acessam os dados locais e se comunicam com os demais processos
para manter a consistncia.
A estratgia baseada em paginao tem a vantagem de no impor nenhuma
estrutura em particular para a DSM, que aparece como uma sequncia de bytes. Ela
permite
que
aplicaes
projetadas
para
executar
em
um
computador
multiprocessador de memria compartilhada sejam executadas em computadores

sem memria compartilhada, no havendo a necessidade de uma adaptao para
isso. Em contrapartida, a estratgia baseada em middleware permite o
desenvolvimento de abstraes em um nvel mais alto do que posies de memria
compartilhada [8].
As prximas sees detalham os principais recursos que caracterizam um
sistema DSM, sendo eles a estrutura de dados mantida na DSM e o seu modelo de
consistncia.
30
2.2.1 Estrutura
Um sistema DSM se assemelha muito a um sistema de replicao. Cada
processo visualiza uma abstrao de um conjunto de objetos, sendo que este
conjunto se assemelha a memria. A DSM pode variar de acordo com o que
considerado como objeto e no modo como eles so endereados. H trs estruturas
que podem ser utilizadas em uma DSM: orientada a bytes, orientada a objetos e
dados imutveis [8].
Orientada a bytes
Este tipo de DSM acessado como a memria virtual normal, ou seja, atravs
de um array de bytes adjacentes. Esta estrutura possibilita que as aplicaes
coloquem quaisquer estruturas de dados na memria compartilhada. Os objetos
compartilhados so posies de memria endereveis diretamente. As nicas
operaes possveis sobre estes objetos so a leitura (read) e a escrita (write). Se x
uma posio de memria, ento denota-se as instncias dessas operaes da
seguinte maneira:
R(x)a esta operao l o valor a de uma posio x da memria.
W(x)b esta operao escreve o valor b na posio x da memria.
Orientada a objetos
Este tipo de DSM estrutura a memria compartilhada como um conjunto de

objetos em nvel de linguagem, com semntica de nvel mais alto do que as
variveis read/write simples. O contedo da memria compartilhada alterado
atravs de chamadas a estes objetos e nunca pelo acesso direto s suas variveis
internas. Uma vantagem ao se utilizar esta estrutura que a semntica do objeto
pode ser utilizada para realizar a consistncia.
31
Dados imutveis
Neste tipo de DSM, os dados so imutveis e os processos podem efetuar a

leitura, a insero e a remoo. Os sistemas que utilizam esta estrutura fornecem ao
desenvolvedor colees de tuplas chamadas espao de tuplas, que consistem em
uma sequncia de um ou mais campos de dados tipados, como <teste, 2011> e
<9, 5.4, No>.
Os processos compartilham dados acessando o mesmo espao de tuplas. A
operao de leitura (read) utilizada para ler o contedo de uma tupla. A insero
das tuplas realizada pela operao write. Vale ressaltar que a partir do momento
que uma tupla adicionada ao espao de tuplas, os seus dados no so alterados,
sendo que eles s podem ser lidos ou removidos. A remoo realizada atravs da
operao take. Esta operao retorna o contedo da tupla e a remove do espao de
tuplas.
2.2.2 Modelo de consistncia

Em um sistema DSM, o problema da consistncia surge atravs da replicao
do contedo da memria compartilhada nos computadores que a utilizam. Cada
processo tem um gerenciador de rplica local que contm as rplicas dos objetos
armazenados em cache. Por questo de eficincia, os dados so lidos a partir de
rplicas locais, mas as atualizaes precisam ser propagadas para os outros
gerenciadores de rplica.
O gerenciador de rplica local implementado pelo ambiente que prov a
DSM, sendo que este ambiente realiza a maioria do processamento da DSM, como
a parte que compartilha os dados. Alm de utilizar a cache, a DSM pode armazenar
as atualizaes em buffers para diminuir os custos da comunicao distribuindo-os
por vrias atualizaes.
Um modelo de consistncia de memria [47] especifica as garantias de
consistncia dadas por um sistema de DSM a respeito dos valores que os processos
lem dos objetos. Os principais modelos de consistncia que podem ser realizados
em implementaes de DSM so os modelos de consistncia seqencial e os
modelos baseados em consistncia mais fraca.
32
Consistncia sequencial
A consistncia seqencial busca a linearizao de execuo. Porm, ela

restrita demais para a maioria dos propsitos prticos. Segundo Coulouris (2007), a
consistncia sequencial obtida atravs de alguma interposio da srie de
operaes executadas por todos os processos que satisfaa os dois critrios a
seguir:
1: A sequncia interposta de operaes tal que, se R(x)a ocorre na

sequncia, ento ou a ltima operao de escrita que ocorre anterior a ela
na sequncia interposta W(x)a ou no ocorre nenhuma operao de
escrita anterior a ela e a o valor inicial de x.
2: A ordem das operaes na interposio consistente com a ordem do

programa em que cada cliente individualmente as executou.
Em uma execuo, as operaes de memria podem ser sobrepostas e

algumas atualizaes podem ter ordem diferente em diversos processos, desde que
as restries no sejam violadas. A DSM com consistncia sequencial pode ser
implementada utilizando apenas um servidor para armazenar todos os dados
compartilhados, fazendo com que os processos enviem requisies de leitura e
escrita para o servidor. Desta forma, o servidor pode fazer uma ordenao global
das requisies, gerando a consistncia sequencial. Esta arquitetura ineficiente
para implementar a DSM, pois ela gera uma quantidade alta de comunicao.
Consistncia fraca
Este modelo foi desenvolvido por Dubois, Scheurich e Briggs (1988) e

consiste em uma tentativa de minimizar o custo da consistncia sequencial em
multiprocessadores, mantendo o efeito da consistncia sequencial. O modelo
explora a utilizao de operaes de sincronizao para minimizar a consistncia da
memria, embora parea ao desenvolvedor que a consistncia sequencial.
Se o desenvolvedor utiliza um mecanismo de sincronizao para implementar
uma seo crtica, ento um sistema de DSM pode presumir que nenhum outro
processo acessar os dados utilizados por ele sob excluso mtua. No h a
necessidade do sistema DSM propagar atualizaes nestes itens at que o processo
33
saia da seo crtica, j que enquanto o processo estiver na seo crtica, os demais
processos no utilizaro estes dados simultaneamente.
Desta forma, no escopo da seo crtica, a memria est em um estado
inconsistente, mas para o desenvolvedor isso imperceptvel. Neste modelo, a
garantia dos dados atualizados ocorre antes e depois do acesso a uma regio
crtica.
Consistncia relaxada
O modelo de consistncia relaxada uma extenso do modelo de

consistncia fraca, pois a ideia deste modelo reduzir a comunicao da DSM
explorando o fato que os desenvolvedores utilizam mecanismos de sincronizao
para o acesso a um dado na memria compartilhada distribuda. Um ambiente de
DSM pode utilizar o conhecimento dos acessos a estes mecanismos de
sincronizao para permitir que a memria se torne inconsistente em certos pontos,
enquanto, os mecanismos de sincronizao garantem a consistncia em nvel de
aplicao [39].
Desta forma, a consistncia relaxada mais fraca do que a consistncia
sequencial e computacionalmente mais barata de se implementar, tendo uma
semntica fcil de ser tratada pelos desenvolvedores. A consistncia relaxada difere
da consistncia fraca devido atualizao dos dados da DSM ocorrer sempre que
um mecanismo de sincronizao liberado. J na consistncia fraca, a atualizao
dos dados ocorre tanto na aquisio quanto na liberao do mecanismo de
sincronizao, no havendo distino entre aquisio e liberao.
A operao de aquisio significa a entrada em uma regio crtica, sendo que
neste local ser realizado o acesso regio de memria compartilhada. A operao
de liberao ocorre aps o acesso a esta regio. Os mecanismos de sincronizao
garantem o acesso exclusivo aos dados de uma DSM atravs das operaes de
aquisio e liberao [61].
Gharachorloo et al (1990) definiu o modelo de consistncia relaxada atravs
de 3 regras:
1: antes que uma operao de leitura ou de escrita possa ser executada

com relao a qualquer outro processo, todos os acessos de aquisio
anteriores devem ser realizados.
34
2: antes que uma operao de liberao possa ser executada com

relao a qualquer outro processo, todas as operaes de leitura e de
escrita anteriores devem ser executadas.
3: as operaes de aquisio e de liberao tm consistncia sequencial

uma com relao outra.
As duas primeiras regras garantem que quando houver uma liberao de um

mecanismo de sincronizao, nenhum outro processo que esteja adquirindo o
mesmo mecanismo de sincronizao poder ler verses antigas de dados
modificados pelo processo que realiza a liberao. A terceira regra garante a
consistncia sequencial interna a cada processo, com relao sequncia de
acessos aos mecanismos de sincronizao.
O modelo de consistncia relaxada permite a utilizao de algumas
operaes assncronas. Por exemplo, um processo no precisa ser bloqueado ao
fazer atualizaes no escopo de uma seo crtica. As suas atualizaes somente
devem ser enviadas quando ele liberar a seo crtica. Desta forma, as atualizaes
so enviadas em uma nica mensagem, sendo que somente a ltima atualizao de
cada item de dado deve ser enviada.
2.3 Escalonamento de tarefas para grades computacionais

Nesta seo apresentado o escalonamento de tarefas para grades
computacionais e utiliza-se o termo tarefa para designar o escalonamento de jobs.
Neste contexto, considera-se que as aplicaes paralelas so compostas por um
conjunto de jobs, sendo eles dependentes ou independentes..
Para a execuo de aplicaes paralelas em grades computacionais, um dos
passos realizados o escalonamento das tarefas que compem a aplicao. As
tarefas podem ser dependentes ou independentes das outras tarefas. Uma tarefa
dependente pode ser iniciada somente aps as tarefas das quais ela depende,
tiverem terminado. Neste caso, as tarefas so vistas como um grafo direcionado, no
qual os arcos representam as suas dependncias.
Tarefas independentes entre si podem iniciar a qualquer momento, no
havendo a necessidade de esperar que outras tarefas tenham finalizado. Neste
35
caso, as tarefas podem ser vistas como uma Bag-of-Tasks [3]. A Figura 2.4 mostra
os tipos de algoritmos de escalonamento que podem ser utilizados, de acordo com a
dependncia das tarefas, no qual elas podem ser dependentes ou independentes.
Os algoritmos podem realizar o escalonamento estaticamente ou dinamicamente. As
prximas sees detalham os algoritmos utilizados para o escalonamento de tarefas
dependentes e independentes.
Figura 2.4 Tipos de algoritmos de escalonamento de tarefas para grades

computacionais (baseado em [15])
2.3.1 Escalonamento de tarefas independentes

Assim que solicitada a execuo de uma aplicao paralela com um
conjunto de tarefas independentes, o escalonador aloca os ns de processamento
para a sua execuo, visando minimizar o tempo de execuo da aplicao e otiizar
o desempenho do sistema. Os principais algoritmos de escalonamento para este tipo
de tarefa so: MET, MCT, Min-Min, Max-Min e XSuffrage [15].
O algoritmo MET (Minimum Execution Time) atribui cada tarefa ao
computador com o melhor tempo de execuo esperado para essa tarefa, no se
preocupando se esse computador est disponvel ou no no momento. O objetivo
deste algoritmo dar o melhor computador para cada tarefa. Isso pode causar um
36
grave desbalanceamento de carga entre os computadores, j que os melhores

computadores recebero uma carga muito elevada de processamento e os outros
computadores ficaro praticamente sem processar nada.
A estratgia do algoritmo MCT (Minimum Conclusion Time) atribuir cada
tarefa, em uma ordem arbitrria, para o computador que tiver o tempo de concluso
mnimo esperado para essa tarefa, levando em considerao a carga de
processamento que os computadores possuem. Isso faz com que algumas tarefas
sejam atribudas aos computadores que no tm o tempo de execuo mnimo para
elas.
O algoritmo Min-min inicia um conjunto U contendo todas as tarefas no
alocadas a um processador. Para cada tarefa, pertencente ao conjunto U, encontrase o computador que oferece o menor MCT. Em seguida, a tarefa com o menor MCT
do conjunto U selecionada e atribuda ao computador correspondente. Esta tarefa
removida do conjunto U e o processo repetido novamente at que todas as
tarefas do conjunto sejam alocadas, tornando este conjunto vazio. O algoritmo Minmin baseado no tempo de concluso mnimo, assim como o algoritmo MCT. No
entanto, para tomar uma deciso, o algoritmo Min-min considera todas as tarefas
no alocadas, enquanto o algoritmo MCT considera apenas uma tarefa de cada vez.
O algoritmo Max-min muito semelhante ao algoritmo Min-min, sendo que ele
tambm inicia o conjunto U contendo todas as tarefas no alocadas a um
processador e, para cada tarefa, gera-se o conjunto de menor MCT. Em seguida, a
tarefa com o maior MCT do conjunto U selecionada e atribuda ao computador
correspondente. A tarefa selecionada removida do conjunto U e este processo
repetido at que todas as tarefas sejam alocadas. O algoritmo Max-min tenta
minimizar as penalidades da execuo de tarefas com tempo de execuo elevado.
Suponha, por exemplo, que a aplicao que est sendo mapeada possui muitas
tarefas com tempo de execuo baixo e uma tarefa com um tempo de execuo
elevado.
A estratgia do algoritmo Max-min realizar, inicialmente, o mapeamento da
tarefa com o maior tempo de execuo para o melhor computador. Isso permite que
esta tarefa seja executada simultaneamente com as demais tarefas que possuem
um tempo de execuo baixo. Neste caso, o mapeamento realizado seria melhor do
que o mapeamento do algoritmo Min-min, j que pela estratgia do algoritmo Minmin, as tarefas menores seriam executadas no incio, deixando a tarefa maior ser
37
executada no final e impactando no tempo de processamento, pois esta tarefa seria

executada em um computador e os demais computadores estariam ociosos.
XSuffrage possui uma heurstica de escalonamento baseada no Suffrage [43].
A ideia do Suffrage determinar o quanto uma tarefa seria prejudicada caso ela no
fosse executada no computador com o melhor MCT. O valor do prejuzo definido
pela diferena entre o seu melhor MCT e o segundo melhor MCT, sendo que as
tarefas com os maiores valores de prejuzo tm precedncia de escalonamento. O
algoritmo XSuffrage tambm leva em considerao os dados de entrada de uma
tarefa para realizar o escalonamento. Neste caso, o objetivo minimizar a distncia
entre o local que armazena os dados e o computador que executar a tarefa.
2.3.2 Escalonamento de tarefas dependentes

O escalonamento de tarefas dependentes utiliza um grafo direcionado acclico
para o seu mapeamento e para determinar as suas dependncias. possvel utilizar
os vrtices do grafo para determinar o custo de cada tarefa e os arcos para
determinar o custo da comunicao entre as tarefas.
O grafo de dependncias entre as tarefas chamado de workflow [15]. H
vrias ferramentas que so utilizadas para o mapeamento de tarefas em
computadores atravs de workflow para grades computacionais. DAGMan [10] e
Commodity Grig [38] so exemplos destas ferramentas. H outras ferramentas que
so utilizadas para a gerao do workflow, como Askalon [64], GridFlow [4] e
Pegasus [11]. Maiores detalhes sobre as ferramentas podem ser obtidos em [35].
Os algoritmos estticos utilizados para o escalonamento de tarefas
dependentes so divididos em trs tipos: algoritmos de lista, algoritmos de cluster e
algoritmos baseados em duplicao.
Os algoritmos de lista possuem uma lista ordenada de tarefas, de acordo com
a sua prioridade. A seleo da tarefa a ser processada realizada com base na sua
prioridade, no qual as tarefas prioritrias so escalonadas primeiro. As diferenas
entre as heursticas existentes para este tipo de algoritmo esto, principalmente, na
forma como a prioridade definida e quando uma tarefa considerada pronta para a
execuo. Os algoritmos HEFT (Heterogeneous Earliest Finish Time) e FCP (Fast
Critical Path) so exemplos de algoritmos de lista [15].
38
Uma forma de minimizar o tempo de execuo de uma aplicao duplicar as

tarefas em diferentes computadores. A idia principal no escalonamento baseado
em duplicao utilizar o tempo ocioso dos computadores para duplicar as tarefas
que so predecessoras das tarefas que sero executadas no futuro. Isso evita a
transferncia dos resultados entre o predecessor e o sucessor de uma tarefa, j que
eles esto no mesmo computador, reduzindo o custo de comunicao. Suponha que
a prxima tarefa ser executada no computador X e a tarefa que a precede est
executando no computador Y. O computador X est ocioso no momento e os dados
processados na tarefa predecessora sero enviados para o computador X, pois a
prxima tarefa dependente deles. Para evitar este fluxo de comunicao, a tarefa
predecessora pode ser duplicada, executando no computador X. Desta forma, os
dados no sero enviados j que eles estaro no mesmo computador. Aps a
duplicao, o computador Y no precisar continuar a execuo desta tarefa,
podendo realizar outro processamento.
A diferena entre os algoritmos baseados em duplicao est na estratgia
de seleo da tarefa a ser duplicada. TDS (Task Duplication-based Scheduling
algorithm) e TANH (Task duplication-based scheduling Algorithm for Network of
Heterogeneous systems) so exemplos de algoritmos baseados em duplicao [15].
Algoritmos de cluster uma maneira eficiente de reduzir o atraso da
comunicao nas tarefas dependentes, agrupando no mesmo cluster as tarefas que
se comunicam. Posteriormente, estas tarefas agrupadas so atribudas ao mesmo
computador
ou
computadores
que
estejam
prximos
geograficamente.
Geralmente, os algoritmos de cluster tm duas fases: a fase de agrupamento das

tarefas e a fase de refinamento dos agrupamentos produzidos na fase anterior para
obter o mapa final de alocao de tarefas aos computadores. DSC (Dominant
Sequence Clustering) e CASSII so exemplos de algoritmos de cluster [15].
Em algumas grades computacionais, os computadores podem ser inseridos
ou excludos dinamicamente. Isso faz com que haja a necessidade de um algoritmo
de escalonamento que seja dinmico. O algoritmo DLS (Dynamic Level Scheduling)
um exemplo de algoritmo dinmico [15].
39
2.4 Consideraes finais

Nos ambientes de grades computacionais, o modelo de consistncia relaxada
o mais indicado, pois ele minimiza a quantidade de mensagens trocadas para a
atualizao das variveis compartilhadas, alm de garantir a consistncia sempre
que o recurso de sincronizao, que gerencia a utilizao de uma rea de memria
compartilhada, for liberado.
Grande parte dos algoritmos de escalonamento de tarefas para grades
computacionais necessitam do tempo estimado de durao de cada tarefa para
realizar o escalonamento e consideram uma tarefa como um job. O modelo de
processamento desenvolvido neste trabalho realiza o escalonamento dos elementos
de processamento da linguagem CPAR [56]. No momento da solicitao da
execuo da aplicao, o ambiente no possui o tempo de durao de cada
elemento de processamento.
Isso inviabiliza a utilizao das estratgias apresentadas na seo 2.3 para o
escalonamento dos elementos de processamento da linguagem CPAR para grades
computacionais.
Entre
os
elementos
de
uma
aplicao,
dependncias representadas por um grafo direcionado acclico.
geralmente,
40
3. AMBIENTES DE PROGRAMAO PARA GRADES

COMPUTACIONAIS
Para a execuo de aplicaes paralelas em grades computacionais, hoje em
dia, a maioria dos sistemas utilizam workflows [12]. Um workflow pode ser definido
como a automao de um processo de negcio. Essa automao realizada
atravs de um Sistema de Gerenciamento de Workflow que define, gerencia e
executa workflows atravs de um software, cuja ordem de execuo est baseada
em uma representao lgica do fluxo de trabalho no computador [14]. O usurio
define o workflow da aplicao e o ambiente gerencia a sua execuo. Este trabalho
no utiliza o conceito de workflow para executar aplicaes paralelas. O paralelismo
realizado atravs dos elementos de construo da linguagem. Para possibilitar a
sua execuo, foi criado um ambiente que permite a execuo de uma linguagem
paralela.
Atualmente, pesquisas esto sendo realizadas sobre a implementao de
tecnologias para grades computacionais [51]. Porm, o desenvolvimento de
aplicaes paralelas utilizando o recurso de processamento de uma grade difcil,
pois necessrio que haja uma infraestrutura que suporte a execuo de uma
aplicao paralela neste ambiente.
Grande parte dos ambientes de programao no prov uma abstrao de
servios no nvel de linguagem para a implementao de aplicaes paralelas para
grades computacionais. Com isso, os programadores tm que considerar vrios
detalhes do ambiente quando desenvolvem uma aplicao, como por exemplo, a
distribuio dos recursos na rede, a descoberta dos servios ativos e a realizao da
comunicao entre os processos.
Uma grade computacional pode ser composta por ns monoprocessadores e
multiprocessadores e por clusters. Isso torna o seu ambiente heterogneo com
relao ao hardware e dificulta o desenvolvimento de uma linguagem de
programao e de um sistema de execuo que proporcionem a utilizao dos
recursos da grade computacional de maneira eficiente. Para otimizar a utilizao dos
recursos, uma linguagem deve possuir construes que sejam propcias para a
distribuio do processamento da aplicao. Alm disso, a linguagem deve possuir
41
variveis/objetos
compartilhados
para
que
os
processos
possam
ter
compartilhamento de dados.
As sees a seguir detalham os ambientes de programao para grades
computacionais estudados.
3.1 ABACUS
ABACUS [63] um ambiente de programao orientado a servios para
aplicaes em grades computacionais. Ele abstrai um servio como um elemento de
construo da linguagem, assim como a declarao de um objeto em Java. Desta
forma, ele permite que o usurio se concentre na lgica da aplicao, ao invs de se
preocupar com os detalhes da infraestrutura. O ambiente ABACUS foi desenvolvido
em Java e a sua utilizao ocorre atravs de Web Services.
No ambiente ABACUS, uma grade computacional vista como um
supercomputador, e todos os recursos na grade constituem um espao de
endereamento lgico unificado [42]. Neste espao, cada clula de memria contm
um recurso na forma de servio, sendo que as operaes de escrita e execuo so
permitidas em cada clula.
A Figura 3.1 mostra o modelo do espao de endereamento da grade
computacional [16, 17] utilizada como base para o ambiente do ABACUS. Neste
modelo, uma grade construda em um espao de memria, no qual cada servio
da grade associado a uma clula de memria.
O espao de servio virtual (Virtual Service Space) o local em que os
servios compartilhados so alocados. Em cada n realizado o mapeamento da
rea de um servio virtual para uma rea de armazenamento local, chamada de
espao de servio fsico (Physical Service Space). Cada rea de armazenamento
local exclusiva para o armazenamento de um servio compartilhado.
42
Figura 3.1 Modelo do espao de endereamento do ABACUS (extrado de [63])
O compilador do ABACUS, em tempo de compilao, atribui um

endereamento virtual de 32 bytes para cada servio compartilhado que declarado
nos arquivos fonte do ABACUS. Em tempo de execuo, quando um servio
solicitado, o ambiente, primeiramente, aloca os recursos e atribui, ao servio, um
endereo fsico no espao de servios fsicos. Posteriormente, feito um
mapeamento entre um endereo virtual e o seu correspondente endereo fsico.
Com este mapeamento, outros programas podem localizar e acessar servios fsicos
atravs de seus endereos virtuais.
A linguagem de programao utilizada no ambiente do ABACUS foi
desenvolvida com os seguintes princpios:
Abstrao de servio: O conceito fundamental do ABACUS a abstrao

de servio que representa um objeto na linguagem. A declarao de um
servio composta de uma srie de declaraes de dados e de interfaces.
Gerenciamento de servios: ABACUS prov um modo flexvel para

suportar o gerenciamento do ciclo de vida de um servio, incluindo a sua
criao, a sua solicitao e a sua excluso. No ambiente ABACUS, o valor
armazenado na varivel de um servio o endereo virtual deste servio.
Desta forma, a sua utilizao independente das propriedades fsicas do
servio.
43
Desenvolvimento de aplicaes: um servio declarado consiste em um tipo

de dado na linguagem. Mltiplas variveis podem ser declaradas com o
mesmo tipo de dado para armazenar diferentes instncias de servio. O
ambiente ABACUS suporta, em nvel de linguagem, as operaes de
criao, solicitao e excluso nas variveis de um servio.
A criao do servio dinamicamente o associar em uma clula de memria

da grade, e retornar o seu endereo virtual. Para fazer a chamada de um mtodo, a
sua sintaxe semelhante sintaxe da linguagem Java.
Uma caracterstica importante sobre os servios o seu compartilhamento.
Nesta linguagem, os servios so compartilhados atravs da declarao de variveis
globais e de variveis externas. Estes dois tipos de variveis so declarados fora do
espao de declarao de um servio.
O ambiente de execuo do ABACUS provido pelo Vega Grid Operating
System (Vega GOS) [66]. Ou seja, o Vega GOS possui toda a infraestrutura
necessria para a execuo de uma aplicao ABACUS. O Vega GOS um
middleware para grades computacionais desenvolvido no Instituto de Computao e
Tecnologia da China. A infraestrutura do Vega GOS no faz o acesso aos ns
internos
de
um
cluster,
havendo
necessidade
destes
ns
possurem
endereamento pblico.
Um compilador baseado neste sistema foi implementado para o ABACUS. A
principal caracterstica do Vega GOS, para o ambiente ABACUS, a traduo de
um servio virtual para um servio fsico e o gerenciamento do seu ciclo de vida.
Uma aplicao de grade feita no ABACUS atravs de um ou mais arquivos
de definio de servios. Todos estes arquivos so traduzidos pelo compilador do
ABACUS nos seus respectivos arquivos de execuo (arquivos jar e arquivos
WSDD). Estes arquivos so executados no ambiente do Vega GOS. A infraestrutura
disponibilizada pelo Vega GOS feita atravs de Web Services.
3.2 SAGA
SAGA [30] um ambiente de programao orientado a objetos para grades
computacionais, implementado em C++. Ele abstrai as caractersticas do ambiente
para o usurio, fornecendo uma interface de alto nvel que facilita o desenvolvimento
44
de aplicaes para grades computacionais. Esta interface prov uma sintaxe concisa
para expressar os principais objetivos dos desenvolvedores, como mudar um
arquivo de um ponto para outro, ou acessar arquivos remotos.
O desenvolvimento da API do SAGA foi baseado em uma especificao
independente da linguagem. Tambm foi elaborado um conjunto de vnculos que
abrange as principais linguagens utilizadas no desenvolvimento de aplicaes
cientficas (Fortran, C, C++, Java, Perl e Python).
O ambiente SAGA foi modelado e desenvolvido com o princpio de cobrir as
principais funcionalidades necessrias para as grades computacionais. Ou seja, h
funcionalidades que no so cobertas, porm estas so utilizadas com menor
freqncia. As funcionalidades foram listadas por um grupo de pesquisadores do
Reino Unido, dos Estados Unidos, da Holanda e do Japo.
As principais funcionalidades listadas pelos pesquisadores foram:
Sesses e segurana: segurana essencial para qualquer aplicao de

grades computacionais que so executadas em mltiplos domnios
administrativos. No ambiente, a segurana gerenciada atravs de
objetos de sesso.
Gerenciamento dos dados: um dado pode ser gerenciado de diversas

formas, mas o acesso remoto aos arquivos um requisito muito utilizado
pelas aplicaes de grades computacionais. O ambiente utiliza arquivos
como o mecanismo para compartilhamento de informaes. A equipe
utilizou a estratgia de replicao [22] para minimizar a quantidade de
mensagens trafegadas na rede.
Gerenciamento de jobs: Os jobs so iniciados remotamente atravs de

operaes assncronas.
Comunicao entre processos: O ambiente SAGA suporta a comunicao

entre processos atravs da API de Sockets [60].
Para o controle do ambiente SAGA, utilizou-se o framework Globus [17] como

o middleware de grades computacionais. Alm dele, algumas ferramentas foram
utilizadas para auxiliar o controle do ambiente da execuo da linguagem, sendo
elas:
45
DRMAA-WG: o DRMAA (Distributed Resource Managment) [23] produziu

uma API de especificao para a submisso e controle de jobs para um
ou mais sistemas de gerenciamento de recursos distribudos. O escopo
desta especificao utiliza todas as funcionalidades necessrias para o
gerenciamento de um job, incluindo as operaes comuns em jobs como
trmino ou suspenso. O objetivo facilitar a interface direta das
aplicaes de sistemas distribudos pelos desenvolvedores de aplicaes,
desenvolvedores de portais e vendedores de software [55]. A submisso
e o controle de Jobs no ambiente so realizados atravs do DRMAA API.
GridRPC-WG: a API do GridRPC (Grid Remote Procedure Call) [59]

representa a tentativa de padronizar e implementar um mecanismo
portvel e simples para chamada remota de procedimentos em grades
computacionais. O ambiente SAGA utiliza o GridRPC no acesso remoto a
arquivos e nas chamadas assncronas.
GridCPR-WG: GridCPR (Grid Checkpoint and Recovery) [24] uma

ferramenta que efetua o checkpoint e a recuperao de aplicaes em um
ambiente de grades computacionais. O ambiente SAGA utiliza esta
ferramenta para manter o ambiente mais consistente e como um
mecanismo de tolerncia a falhas.
GFS-WG: O GFS (Grid File System) [25] define uma arquitetura que
integra os sistemas de arquivos fsicos em um sistema nico global, com
um espao de nomes uniforme. O ambiente SAGA utiliza as definies
dos espaos de nomes definidos pelo GFS, alm de suas estruturas de
arquivos e diretrios.
Uma parte essencial do modelo de programao do ambiente SAGA

formada pelo gerenciamento de sesso e pela segurana. Caso nenhum
manipulador de sesso seja especificado, um manipulador padro utilizado.
necessrio iniciar, na implementao de uma aplicao, os tokens de segurana
disponveis, como por exemplo, os certificados do Globus [17].
O gerenciamento e o acesso aos dados remotos so tarefas muito
importantes em um ambiente distribudo. A API do SAGA realiza o gerenciamento
dos dados atravs de espaos de nomes, diretrios e arquivos fsicos, e arquivos
lgicos e catlogo de rplicas.
46
A interface do espao de nomes realiza o gerenciamento dos elementos de

dados como entidades, e prov mtodos para navegar, criar, copiar, alterar,
consultar e remover elementos no seu espao de nomes.
O ambiente define o gerenciamento de arquivos fsicos atravs do espao de
nomes. A representao para arquivos e diretrios remotos permite a navegao em
um sistema de arquivos remoto, alm de gerenciar as entidades remotas. Os objetos
de arquivos permitem o acesso ao contedo dos arquivos remotos para leitura,
escrita e busca.
O gerenciamento e execuo remota de jobs uma das tarefas primordiais
para o desenvolvimento de um ambiente distribudo em grades computacionais. O
ambiente SAGA realiza a submisso simples de um job, e a recuperao dos seus
dados de sada para informar ao usurio.
A API do SAGA fornece apenas suporte limitado para a comunicao entre
processos. Os servios se comunicam atravs de SOAP [29], via http(s). O ambiente
prov um objeto equivalente aos Sockets [60] para a comunicao.
O ambiente no realiza a comunicao entre ns internos de um cluster com
ns externos, havendo a necessidade dos ns internos possurem endereamento
pblico.
3.3 SATIN
SATIN [51] um ambiente de programao orientado a objetos para grades
computacionais, implementado em Java, incluindo o sistema e o protocolo de
comunicao. A linguagem de programao utilizada neste ambiente uma
extenso da linguagem Java. O ambiente utiliza, principalmente, o modelo de
diviso e conquista [7], ou seja, este ambiente procura explorar a estrutura
hierrquica das grades computacionais, realizando a diviso do processamento
entre os diversos domnios que compem a grade. Em cada diviso efetuada, h um
n responsvel por retornar a resposta, aps a juno dos resultados. Esta
estratgia auxilia na distribuio de processamento, explorando as caractersticas
das grades computacionais.
O usurio do SATIN no precisa se preocupar com os mecanismos de
comunicao e sincronizao, com as threads, com o balanceamento de cargas e
com tolerncia a falhas, pois estes so abstrados pelo ambiente.
47
A estrutura hierrquica das grades computacionais e a alta latncia das redes

WAN faz com que o ambiente se preocupe em realizar otimizaes locais. O modelo
de diviso e conquista apropriado para isso, j que um modelo computacional
hierrquico que recursivamente divide a computao em partes menores, sem que
haja a necessidade de um coordenador geral [7].
As aplicaes baseadas no modelo de diviso e conquista tm pelo menos
duas primitivas: uma para gerar trabalho (spawn) e uma para esperar at que o
trabalho gerado seja concludo (sync). A linguagem do ambiente SATIN explora os
mecanismos de herana e interfaces (por exemplo, java.io.Serializable) para
estender Java com as primitivas de diviso e conquista. A operao spawn uma
forma especial de invocao de mtodo, sendo que estes mtodos so definidos
atravs de uma tag na sua interface. Estes mtodos especiais so chamados de
mtodos SATIN. O compilador do SATIN reconhece as tags na interface e gera o
cdigo especfico para os mtodos SATIN.
Uma chamada de um mtodo SATIN a chamada para a operao de
spawn. Nesta operao, conceitualmente uma nova thread iniciada para executar
o mtodo. No entanto, o ambiente elimina completamente a criao da thread. O
mtodo gerado executado concorrentemente com o mtodo que executou o
spawn. A operao de sync espera at que todas as chamadas geradas na
invocao de mtodo sejam finalizadas. Os valores de retorno destas chamadas so
indefinidos at que a ocorra a sincronizao.
A Figura 3.2 mostra como uma aplicao SATIN compilada e executada.
Como o ambiente utiliza somente anotaes na interface [13], uma aplicao pode
ser compilada com qualquer compilador Java. A sada um conjunto de arquivos
com extenso class, que contm os bytecodes que podem ser executados
sequencialmente em qualquer mquina virtual Java. Para executar o cdigo em
paralelo, necessria uma compilao adicional para gerar os bytecodes. O
compilador SATIN, satinc, reescreve os bytecodes seqenciais, inserindo cdigo
para implementar as operaes spawn e sync.
Os bytecodes reescritos podem ser executados em uma grade computacional
com algum middleware de grade, como o Globus [18] ou o Java Grid Application
Toolkit [52]. Para a comunicao, utilizada a camada de comunicao Ibis [50].
48
Figura 3.2 Compilao e execuo de uma aplicao SATIN (extrado de [51])
Quando um programa executa uma invocao de mtodo gerado, o SATIN

redireciona a chamada de mtodo para um stub, sendo que este stub cria um
registro de chamada que descreve o mtodo que ser invocado, os parmetros que
so passados para o mtodo, e um identificador para armazenar o valor de retorno
do mtodo.
O ambiente SATIN utiliza um algoritmo de balanceamento de carga chamado
Cluster-aware Random Stealing (CRS) [51]. Neste algoritmo, cada n pode
diretamente transferir jobs de outros ns remotos, mas somente um job de cada vez.
Sempre que um n fica ocioso, ele tenta transferir jobs de ns remotos. Esta
requisio enviada de forma assncrona, ao invs de ter que esperar pela resposta
da requisio. O n requisitante sinaliza uma flag para cada n que ele tenta
transferir jobs remotos. Isso feito nos ns aleatoriamente at que ele consiga a
transferncia de um job remoto. Quando uma resposta para uma transferncia de
jobs chega, o CRS simplesmente atualiza a flag de solicitao e, se o pedido foi bem
sucedido, coloca o novo job na fila de trabalho.
O ambiente precisa ter uma comunicao eficiente com a flexibilidade de ser
executado dinamicamente em um conjunto de processadores e redes heterogneos.
A plataforma IBIS [50] tem o objetivo de atender a estes requisitos. Assim como o
ambiente SATIN, esta camada desenvolvida em Java e proporciona uma
49
comunicao eficaz combinada com qualquer JVM. Ela um sistema flexvel que
pode fornecer suporte de comunicao para qualquer aplicao de grade, desde
transmisso de vdeo at computao massivamente paralela. A plataforma IBIS
fornece uma estrutura unificada para comunicao confivel e no confivel, unicast
e multicast de dados. Devido a ela ser baseada em Java, possui as vantagens
oriundas do Java, como a portabilidade, o apoio heterogeneidade e segurana.
A plataforma IBIS realiza a comunicao entre ns internos de um cluster com
ns externos, no havendo a necessidade dos ns internos possurem
Aps a reescrita do bytecode da aplicao Java, gera-se o bytecode SATIN e
ele compilado pelo compilador da plataforma IBIS para gerar o cdigo serializado
dos objetos que sero utilizados para a comunicao entre os processos.
O ambiente SATIN utiliza objetos para o compartilhamento das informaes.
A atualizao dos objetos compartilhados realizada atravs do modelo de
consistncia relaxada [26], permitindo uma replicao eficiente dos dados
compartilhados [65].
Todos os dados compartilhados entre processos de uma aplicao so
encapsulados em objetos compartilhados. O ambiente utiliza um protocolo de
replicao baseado em atualizao, uma vez que tem se mostrado eficiente para
linguagens baseadas em objetos [2]. Em tempo de execuo, o SATIN
automaticamente cria cpias dos objetos compartilhados nos processos que podem
acess-los. Com isso, as operaes locais podem utilizar a sua cpia local, sem a
necessidade de troca de mensagens. As operaes globais so aplicadas a todas as
cpias.
Neste modelo de consistncia, o programador pode definir os requisitos de
consistncia das aplicaes, atravs da utilizao de funes especiais associadas
com tarefas de diviso e conquista. Uma funo especial executada antes de cada
tarefa, sendo que ela verifica o estado dos objetos compartilhados acessados pela
tarefa, e retorna "true" se os objetos esto em um estado correto, ou "false", caso
contrrio.
Caso o estado seja avaliado como "false", o ambiente tem que fazer a cpia
local mais consistente. Isso feito atravs da espera por atualizaes, ou pela
busca de uma cpia mais recente.
50
O ambiente SATIN prov tolerncia a falhas, sendo que a idia bsica para
implement-la recalcular o trabalho feito por um processo que est saindo do
ambiente, o que possvel desde que os jobs no tenham dependncias com outros
jobs. O principal problema em executar novamente tarefas no modelo de diviso e
conquista, a possibilidade de rfos [61]: se o trabalho retirado de um n que
deu problema, ele torna-se rfo e, consequentemente, o ambiente no saber o
que deve ser feito com o resultado deste processamento. Para resolver esses
problemas, o ambiente utiliza uma combinao de duas tcnicas: o armazenamento
do trabalho rfo e o checkpoint [61]. Desta forma, o ambiente pode continuar a
execuo das aplicaes, mesmo com a falha inesperada de algum n/processo.
3.4 MPICH-G2
A interface de passagem de mensagem MPICH-G2 [36] no um ambiente
de programao como a proposta deste trabalho, mas uma implementao do
padro MPI [48] para grades computacionais. Esta interface torna possvel a
execuo de aplicaes em C ou em Fortran com MPI em um ambiente distribudo.
A interface oculta aspectos de heterogeneidade utilizando os servios do
Globus [18], como autenticao, autorizao, criao, monitoramento, execuo e
controle de processos, comunicao, redirecionamento de entrada e sada e acesso
remoto a arquivos. Dessa forma, possvel executar programas MPI em diferentes
localidades da mesma maneira e utilizando os mesmos comandos que seriam
utilizados em um computador paralelo.
Para a comunicao entre os ns de um cluster, no qual a verso do MPI a
mesma, a interface MPICH-G2 consegue utilizar as primitivas nativas da verso
MPICH instalada para realizar a comunicao. Caso a comunicao seja externa a
esse cluster, ele realiza a comunicao atravs de primitivas de TCP/IP. Para que
esta comunicao utilizando TCP/IP ocorra, a interface MPICH-G2 obriga que os
ns tenham endereamento pblico.
A interface MPICH-G2 utiliza componentes do Globus que no so
WebServices, como o DUROC e o GRAM, porm tambm faz acesso a servios
web, como o MDS. A Figura 3.3 apresenta o ciclo de submisso e execuo de uma
aplicao MPI.
51
Figura 3.3 Arquitetura de disparo no MPICH-G2 (extrado de [36])
O usurio utiliza o comando mpirun para colocar em execuo sua aplicao

indicando o nmero de processadores. Este comando invoca o Monitoring and
Discovering Service (MDS) [46] para resolver os endereos e alocar os ns descritos
em um script previamente lido.
Neste script, definido e fornecido pelo usurio, esto especificados
parmetros, tais como, os endereos dos ns que participaro do processamento, o
nmero de processadores que sero utilizados em cada n, o caminho dos arquivos
binrios, os parmetros de linha de comando, e os arquivos de redirecionamento,
caso necessrio.
Em seguida executado o utilitrio globusrun (pertencente ao pacote de
softwares do Globus Toolkit) que ativa o Dynnamically-Updated Request Online
Coallocator (DUROC), responsvel por escalonar e disparar as aplicaes dentre os
vrios computadores/domnios especificados. DUROC interage com o Grid Resource
Allocator and Management (GRAM) [31] para disparar e gerenciar os processos em
cada domnio especfico e tambm com o Global Access to Secondary Storage
(GASS), caso haja a necessidade da aplicao redirecionar a entrada/sada
utilizando arquivos especficos. A partir da, os escalonadores dos sistemas
52
operacionais especficos so utilizados para criao, escalonamento e finalizao de

processos.
A comunicao entre os processos nas diversas localidades pode ser feita
atravs da prpria implementao MPI (caso os processos estejam em um mesmo
computador paralelo) ou TCP, caso a comunicao seja entre processos de
localidades diferentes. Cada implementao MPI possui seu prprio comunicador
MPI_COMM_WORLD, assim como nos demais modelos. O MPICH-G2 tambm cria
um comunicador MPI_COMM_WORLD global, que engloba todos os processos
envolvidos. A Figura 3.4 ilustra dois domnios (sites): o primeiro domnio (Site A)
contm um n IBM SP (ranks do MPI_COMM_WORLD de 0 a 3) com quatro
processos, e o segundo domnio (Site B), dois clusters Linux (com ranks 4 a 7 e 8 a
12, respectivamente). Vale observar que o termo cluster em MPICH-G2 no
contempla clusters com Ns front-end, ou seja, necessrio que todos os ns deste
cluster pertenam a um mesmo domnio, porm com endereamento pblico visvel
a partir de qualquer outro n.
Este ponto que obriga todos os ns terem endereo pblico limita a
quantidade de ns que podem participar da execuo em uma grade computacional,
pois geralmente h um n front-end em cada domnio, e os ns internos ao domnio
tem somente endereamento privado.
Figura 3.4 Grade computacional composta por 2 domnios e 12 processos (extrado

de [36])
A comunicao via Sockets TCP/IP notoriamente ineficiente entre ns em

clusters distintos, se comparada com MPI para ns dentro de um mesmo cluster, por
no utilizar recursos de otimizaes de pacotes. Entretanto, para aliviar esta
ineficincia, a interface MPICH-G2 implementa canais bidirecionais TCP/IP para
53
tornar a comunicao mais independente sem que haja conflitos de envio e

recebimento de mensagens.
O recebimento de mensagens pode ser definido com o emissor identificado
ou no. MPICH-G2 possui trs tipos de recebimento para a comunicao ponto a
ponto: Specified, Specified-pending e Multimethod. O recebimento do tipo Specified
define que um processo deve especificar um emissor dentro do prprio n e no h
necessidade de recebimento assncrono. Assim, executada diretamente uma
chamada primitiva MPI_Recv, indicando o emissor.
O tipo Specified-pending pode ser identificado em casos de loops de
recebimentos. O emissor especificado, porm pode haver vrias requisies por
parte de vrios emissores fora de ordem (se o processo 0 necessitasse receber dos
processos 1, 2 e 3 e as mensagens chegassem na ordem 3, 1 e 2). Neste caso,
MPICH-G2 realiza um pooling dentre os vrios emissores para realizar cada um dos
recebimentos, isto , uma fila usada para armazenar cada mensagem recebida. A
eficincia deste processo menor, se comparada com o modo Specified.
Finalmente, o tipo Multimethod utilizado quando o receptor indica como emissor a
constante MPI_ANY_SOURCE. Neste caso, pode haver recebimentos tanto via
TCP/IP quanto via MPI. A interface MPICH-G2 monitora continuamente os dois
canais de comunicao, porm com um custo computacional maior, tornando este
modo o menos eficiente.
As operaes coletivas so implementadas, considerando que alguns
domnios que compem a grade computacional esto conectados por um canal de
WAN (Wide-Area Network) menos veloz do que uma rede local. Desse modo, os
protocolos mais lentos so utilizados primeiro e, em seguida so utilizados os
protocolos mais geis. Cada cluster possui um processo denominado master
process, considerado o processo representativo do cluster. Este processo
responsvel pela disseminao da mensagem (em uma operao MPI_Bcast, por
exemplo) ou concentrao dos resultados (em uma operao MPI_Reduce, por
exemplo) em cada cluster.
A mensagem, ento, propagada entre os diversos master processes,
levando em considerao os canais de comunicao mais lentos como prioritrio.
Isto significa que, se uma mensagem precisa ser enviada para clusters diferentes,
primeiro utiliza-se o canal mais lento (como TCP/IP) e, em seguida, utiliza-se o canal
54
mais eficiente (MPI nativo). Cada implementao MPI utiliza seu prprio algoritmo de
difuso para propagar a mensagem dentro do cluster.
A interface MPICH-G2 no foi projetada para clusters com n front-end, alm
de garantir somente a interoperabilidade entre diferentes implementaes MPICH, e
no qualquer implementao MPI.
3.5 Anlise Comparativa

Todos os ambientes de programao para grades computacionais, estudados
e apresentados neste captulo, possuem uma infraestrutura que permite a execuo
de aplicaes desenvolvidas nestes ambientes. Atravs desta infraestrutura, os
ambientes realizam o escalonamento dos processos, a submisso, o monitoramento
e o gerenciamento da aplicao.
O ambiente ABACUS um ambiente orientado a objetos, implementado em
Java, e possui a sua abstrao baseada em servios. Os servios se assemelham a
um objeto, sendo que ele pode ser compartilhado com outros processos, j que o
seu mapeamento ocorre atravs de um endereamento virtual.
O ambiente SAGA tambm um ambiente orientado a objetos, implementado
em C++, porm com vnculos para outras linguagens, como Java, Perl, C e Python.
Neste ambiente, o compartilhamento de informaes entre os processos ocorre
atravs de arquivos, que podem ser duplicados em outros processos, alm de
suportar as operaes padres como leitura e escrita. Porm, o compartilhamento
de mtodos, objetos e variveis no ocorre.
O ambiente SAGA suporta checkpoint e recuperao de aplicaes em um
ambiente de grades computacionais, sendo tolerante a falhas.
O ambiente SATIN tambm um ambiente orientado a objetos, implementado
em Java. O compartilhamento de informaes ocorre atravs de objetos
compartilhados, sendo que a sua abstrao baseada em chamada de mtodos.
Os mtodos no SATIN podem compartilhar objetos, havendo um mecanismo
para garantir a consistncia das informaes. Ele baseado no modelo de diviso e
conquista, tendo um gerenciamento descentralizado. Alm disso, o ambiente SATIN
oferece um mecanismo de tolerncia a falhas.
A interface MPICH-G2 no um ambiente de programao, e sim uma
interface
de
passagem
de
mensagens
para
grades
computacionais.
55
desenvolvedor pode utilizar esta interface para a comunicao entre processos de

uma aplicao, porm h a restrio de que todos os ns precisam ter
A tabela 3.1 mostra a comparao dos ambientes estudados. Pode-se
perceber que todos os ambientes possuem uma infraestrutura para gerenciar a
execuo das aplicaes. Uma diferena entre os ambientes o mecanismo de
compartilhamento utilizado, em que cada um, com exceo da interface MPICH-G2,
possui um mecanismo de compartilhamento diferente. Os ambientes ABACUS e
SATIN, por serem orientado a objetos, compartilham servios e objetos,
respectivamente. O ambiente SAGA possui vnculos com algumas linguagens de
programao e utiliza arquivos para o compartilhamento de informaes.
Tabela 3.1 Anlise comparativa dos ambientes de programao
Caractersticas
ABACUS
SAGA
SATIN
MPICH-G2
Possui infraestrutura
Sim
Sim
Sim
Sim
Servios
Arquivos
Objetos
No possui
No
No
Sim
No
Mecanismo de
compartilhamento
Acesso a ns internos do
cluster
Linguagem de
programao
Tolerncia a falhas
C, C++,
Abacus
Java, Perl,
Java
C, C++ e
Fortran
etc
No
Sim
Sim
No
Todos os ambientes estudados so orientados a objetos, sendo que o

ambiente SAGA possui vnculos com linguagens estruturadas. Com relao aos ns
internos de um cluster, somente o ambiente SATIN realiza o processamento de
aplicaes paralelas em grades computacionais que possuem clusters, utilizando os
ns
internos
dos
clusters,
sem
haver
necessidade
deles
possurem
endereamento pblico. Esta caracterstica muito importante em um ambiente de

grades computacionais, pois possibilita a utilizao de todos os recursos do
ambiente, aproveitando a sua estrutura hierrquica.
Somente os ambientes SAGA e SATIN possuem mecanismos de tolerncia a
falhas.
56
3.6 Consideraes Finais

Devido s peculiaridades das grades computacionais, uma linguagem de
programao apropriada deve oferecer elementos de construo que facilitem a
distribuio do processamento da aplicao em uma estrutura hierrquica. A
linguagem tambm deve permitir a declarao de variveis compartilhadas entre os
processos da aplicao, alm de possuir um ambiente e uma infraestrutura que
dem suporte a esta linguagem.
Hoje em dia, para contornar este problema, os desenvolvedores criam um
ambiente que possibilita a execuo de programas escritos em linguagens
convencionais, como Java, C e C++. Este ambiente responsvel pela utilizao
dos recursos da grade, porm a sua estrutura hierrquica muitas vezes no
utilizada de maneira adequada.
Nenhum dos ambientes estudados utiliza variveis compartilhadas como o
mecanismo de comunicao e de compartilhamento das informaes entre os
processos. Alm disso, nenhum dos ambientes utiliza uma linguagem de
programao que possua elementos de construo que facilitem a explorao da
De todos os ambientes estudados, o ambiente SATIN o mais promissor,
pois possui uma infraestrutura muito robusta e completa, alm da linguagem
utilizada ser de fcil aprendizado e de possuir um mecanismo de diviso e conquista
[7] que consegue aproveitar todos os recursos de maneira hierrquica.
57
4. INFRAESTRUTURA DA GRADE COMPUTACIONAL DO CPARGRID

O sistema de grade computacional composto por vrios domnios que se
comunicam entre si. Pode-se definir um domnio como sendo um conjunto de
processadores em um nico n (supercomputador) ou em uma organizao de
cluster de computadores. Dessa forma, as tarefas (jobs) podem ser executadas
paralelamente em qualquer processador (ou conjunto de processadores) de todo o
sistema. A Figura 4.1 ilustra o modelo de um ambiente de grades computacionais.
Figura 4.1 Modelo de um ambiente de grades computacionais
Na Figura 4.1, pode-se notar que o sistema multiprocessador ou cluster de

computadores deve ser transparente ao usurio. Entretanto, muitas organizaes de
clusters de computadores fazem uso de ns de processamento com endereamento
privado, em funo da limitao desses endereos. Com isso, apenas um n
visvel para a rede externa e os demais ns do cluster so acessveis somente
atravs deste n (composto de duas placas de rede, uma com endereamento
pblico e outra com endereamento privado), que denominado n front-end.
Como todo acesso e comunicao entre ns internos ao cluster e ns
externos ao cluster devem, obrigatoriamente, passar pelo n front-end, as
58
bibliotecas de comunicao MPI [53] atuais no contemplam esta limitao. Deve-se

ento, fazer uso de um servio que realize o encaminhamento das mensagens MPI
entre ns internos e externos ao cluster. Cada n front-end deve ter um servio de
mensagem instalado para a integrao de clusters.
Para viabilizar a integrao, comunicao, controle de execuo e
gerenciamento dos diversos domnios do sistema necessria a utilizao de uma
infraestrutura que torne o sistema transparente para o usurio. A arquitetura da
infraestrutura utilizada neste trabalho apresentada na Figura 4.2.
Figura 4.2 Infraestrutura do sistema
A infraestrutura ilustrada na Figura 4.2 foi desenvolvida no projeto

Infraestrutura de grade computacional para aplicaes de alta performance em
projetos de leo & gs, no contexto da Rede Galileu. Este projeto props o
desenvolvimento de uma infraestrutura de grade computacional para aplicaes de
alto desempenho em projetos de leo e gs, que permite a execuo de aplicaes
paralelas utilizando a interface MPI. A professora Liria Matsumoto Sato foi a
coordenadora do projeto e Augusto Mendes Gomes Jnior, Calebe de Paula
Bianchini e Francisco Isidro Massetto foram as pessoas responsveis pelo seu
desenvolvimento. A infraestrutura estruturada em diversos nveis, com
funcionalidades especficas:
Jobs: constituem o conjunto de aplicaes paralelas que sero submetidas

execuo no ambiente.
59
Implementao MPI: implementao MPI para comunicao dos diversos

processos, estejam eles alocados em processadores com ns de
endereamento pblico ou privado. A seo 4.4 detalha as primitivas MPI
existentes.
Servio de Mensagem: servio responsvel pelo encaminhamento de

mensagens entre processos de domnios distintos. A seo 4.5 detalha o
funcionamento deste servio.
GCSE e LIMA: estas ferramentas foram desenvolvidas na tese de

doutorado de Paula [54]. Elas realizam o disparo e o controle de execuo
das aplicaes MPI no ambiente de grades computacionais, e tambm,
monitoram os ns que compem o sistema (disponibilidade, ocupao e
caractersticas dos ns, entre outros). A seo 4.3 apresenta o GCSE e o
LIMA.
Globus: o Globus uma infraestrutura de integrao de grades

computacionais que oferece, entre outras funcionalidades, recursos para
alocao de ns e autenticao entre os diversos componentes do
sistema, uma vez que pode haver vrios usurios distintos com
credenciais distintas. Todos os ns do sistema com endereamento
pblico devem ter o Globus instalado. A Seo 4.2 explora maiores
detalhes sobre a arquitetura e servios existentes no Globus.
Condor: responsvel pelo escalonamento, disparo e controle de execuo

em cada ambiente local. A Seo 4.1 explica o funcionamento do Condor.
4.1 Condor
Condor uma ferramenta, desenvolvida pelo Condor Team na Universidade
de Wisconsin-Madison, especializada em sistemas batch para gerenciamento de
jobs de computao intensiva [5]. O Condor prov um mecanismo de fila, uma
poltica de escalonamento com ou sem prioridades, e um esquema de classificao
de recursos.
Para a utilizao do Condor, o usurio submete seu job, o Condor o coloca
em uma fila, posteriormente o executa, e depois informa ao usurio o resultado final.
60
Em um cluster, os ns que foram configurados como recursos para o Condor

formam um Condor Pool. Atravs do comando condor_status possvel determinar
quais so os integrantes ativos de um pool.
4.1.1 Preparao do Cdigo

Para um job ser executado com o Condor, ele deve estar habilitado para
executar como um job batch em background. Um programa que executa em
background no realiza entrada e sada interativa. Porm, o Condor pode
redirecionar a sada do console (stdout e stderr) e a entrada do teclado (stdin) para
arquivos. Caso estes arquivos no existam, a sua criao realizada.
4.1.2 Submisso do Job

O arquivo de descrio de submisso do job controla todos os seus detalhes
de configurao. Este arquivo contm informaes sobre o que ser executado, os
arquivos de entrada utilizados, o tipo de plataforma requisitada para executar o
programa, os arquivos de sada a serem gerados, e como informar a finalizao do
job.
Tambm possvel informar ao Condor quantas vezes um programa ser
executado, e se ser com o mesmo conjunto de dados. A Figura 4.3 mostra um
exemplo de arquivo de submisso. Neste exemplo, o arquivo executvel o
exemplo_grid, o universo o standard, e os demais parmetros so de entrada,
sada, erro e de log. Para enviar o job para a execuo coloca-se a palavra Queue.
Executable
Universe
input
output
error
Log
=
=
=
=
=
=
exemplo_grid
standard
test.data
loop.out
loop.error
loop.log
Queue
Figura 4.3 Exemplo de arquivo de submisso
61
A submisso de um job ocorre atravs do comando condor_submit. Uma vez

submetido, o job pode ser monitorado atravs dos comandos condor_q e
condor_status.
Quando um programa termina, a ferramenta informa o seu status de sada e
as estatsticas de desempenho. A remoo de um job prematuramente da fila pode
ocorrer atravs do comando condor_rm.
4.2 Globus
Globus [19] uma infraestrutura de software que permite as aplicaes
visualizarem recursos computacionais heterogneos e distribudos como um nico
n. Seu elemento central o Globus Toolkit (GT), o qual oferece servios
necessrios para a construo de uma grade computacional [20]. Esse toolkit um
conjunto de componentes organizados em camadas e orientados a servios,
oferecendo servios bsicos como descoberta e gerenciamento de recursos,
movimentao de dados, segurana, entre outros [18].
Todos os servios disponibilizados pelo Globus foram desenvolvidos em
linguagem de programao C, com seu cdigo fonte aberto, possibilitando que
colaboradores reparem erros ou faam qualquer tipo de implementao. Para o
usurio, estes servios acabam se tornando transparentes, pois uma vez instalados
e configurados, so chamados automaticamente com o uso de comandos
especficos do Globus.
A infraestrutura do Globus composta por cinco grupos de servios:
segurana, gerenciamento dos dados, gerenciamento da execuo, informao de
servios e compilao (momento da execuo).
Todos os servios existentes no Globus podem ser utilizados em uma grade
computacional. Mas, para a elaborao do sistema proposto neste trabalho, os
servios mais relevantes so: o gerenciamento da execuo e a informao de
servios. Pois, durante a execuo de uma aplicao, fundamental haver uma
ferramenta que realize o seu gerenciamento, e uma ferramenta que faa o
monitoramento dos servios da grade.
62
4.2.1 Gerenciamento e Alocao dos Recursos da Grade (GRAM)

O servio GRAM o nvel mais baixo da arquitetura de gerncia de recursos
do Globus. Este servio permite executar jobs remotamente, controlar e monitorar
cada job. O servio GRAM encarregado de administrar um conjunto de ns, sejam
eles ns multiprocessadores, cluster ou estaes de trabalho [31].
O servio prov um sistema seguro para submisso dos jobs para vrios tipos
de escalonadores de jobs que os usurios tm acesso, em um ambiente de grade.
A existncia de um proxy vlido necessria para a submisso de jobs.
Todas as opes de submisso de jobs so suportadas atravs de requisies
embutidas no documento de entrada. A iniciao do job feita pela submisso da
aplicao para o servio GRAM, e esta submisso pode ser feita, pelos usurios,
atravs de linha de comando.
A co-alocao de recursos no suportada pelo GRAM. Por exemplo, caso
um job necessite de doze ns para a sua execuo, e o sistema aloque dez, e no
consiga alocar os outros dois, a execuo abortada.
4.2.2 Monitoramento e Descoberta dos Servios (MDS)

Grades computacionais so ambientes extremamente dinmicos, em que os
componentes podem falhar ou podem ser substitudos. Assim, importante existir
um componente que disponibilize informaes sobre a grade.
No Globus, este componente o servio de descoberta e monitoramento
(MDS). O servio MDS armazena informaes sobre vrios aspectos da grade como
sistemas operacionais, memria disponvel, espao em disco, etc [46].
Este servio um conjunto de web-services para monitorar e descobrir
recursos e servios em uma grade. Este sistema permite que os usurios visualizem
quais recursos pertencem a uma organizao virtual, e tambm permite o seu
monitoramento. Os servios provem interfaces para buscas e para detalhamento
de dados dos recursos, e podem ser utilizadas para:
buscas de servios para informao das propriedades dos recursos;
executar um programa para aquisio de dados;
realizar a interface com sistemas de monitoramento.
63
4.3 GCSE e LIMA

O GCSE e o LIMA so sistemas desenvolvidos por de Paula [54]. O GCSE
um escalonador para grades computacionais e o LIMA o sistema de
monitoramento de recursos.
Para que uma grade computacional consiga atingir o objetivo de oferecer e
compartilhar recursos de forma cooperativa e transparente, necessrio um
escalonador eficiente. Porm, diferentemente de outros sistemas distribudos, um
escalonador de grade, ou meta-escalonador, no controla diretamente os recursos.
Ele interage com a infraestrutura de grades existentes e com os gerenciadores de
recursos locais, definindo os recursos e encaminhando as aplicaes para os
gerenciadores locais. Dessa forma, as polticas j estabelecidas so mantidas em
cada domnio administrativo existente na grade.
O sistema LIMA um sistema de monitoramento de recursos, comprometido
com o descobrimento eficiente de recursos de uma grade computacional e com a
sua integrao com o escalonador GCSE.
No LIMA, os ns so organizados em uma federao de pools, no qual cada
pool constitudo por um cluster e/ou por computadores. Alm disso, um pool deve
possuir
um
computador
que
instancia
um
mdulo
de
gerenciamento
monitoramento daquele pool, denominado PRMM (Pool Resource Monitoring

Manager), e onde residem entidades responsveis por coletar e armazenar os
dados,
chamados
de
CM
(Collector
Module)
DR
(Data
Repository),
respectivamente. Os demais computadores do pool funcionam como provedores de

dados ao sistema LIMA. A figura 4.4 ilustra a arquitetura do LIMA e seus principais
componentes.
64
Figura 4.4 Arquitetura do LIMA (extrado de [54])
O sistema est organizado em dois nveis: (i) rede hierrquica composta pelos
PRMMs e (ii) pool composto por um PRMM, vrios CMs e um DR. Esta organizao
em dois nveis facilita o gerenciamento da dinamicidade em uma grade
computacional, uma vez que o controle de entrada e sada dos recursos pode ser
tratado internamente em cada pool pelo PRMM.
O sistema GCSE um escalonador com uma estratgia cooperativa [54] de
alocao de recursos distribudos na grade. Ele permite que aplicaes paralelas
(SPMD) possam ser alocadas em diferentes recursos de uma grade, ou seja,
realizada a alocao em diversos aglomerados de computadores. Alm disso, o
GCSE oferece um conjunto de primitivas para serem integradas em ferramentas
para a construo de aplicaes paralelas SPMD, tais como interfaces MPI e
sistemas Java.
O suporte s informaes necessrias para o GCSE escolher os recursos
realizado pelo sistema LIMA. O uso deste sistema tem como finalidade oferecer
facilidade para monitorar os recursos distribudos.
65
4.4 Interface MPI

Para a utilizao do MPI em grades computacionais com ns de
endereamento privados, foi utilizada uma implementao, denominada MPI_Grid
[27], da interface que em um ambiente de grades computacionais, permite que ns
de domnios distintos, com endereamento pblico, se comuniquem. Atravs desta
interface, possvel criar aplicaes MPI que sejam executadas em mais de um
domnio.
As primitivas MPI foram divididas em categorias, de acordo com a sua
funcionalidade, sendo as seguintes categorias listadas, e consequentemente, as
seguintes primitivas foram implementadas:
Controle de ambiente (MPI_Init, MPI_Init_thread e MPI_Finalize);
Manipulao do comunicador (MPI_Comm_rank e MPI_Comm_size);
Comunicao
ponto-a-ponto
(MPI_Recv,
MPI_Irecv,
MPI_Send,
MPI_Isend, MPI_Bsend, MPI_Ssend, MPI_Test e MPI_Wait);
Comunicao
coletiva
(MPI_Barrier,
MPI_Bcast,
MPI_Reduce,
MPI_Scatter e MPI_Gather);
Manipulao
do
buffer
(MPI_Pack,
MPI_Unpack,
MPI_Pack_size,
MPI_Buffer_attach e MPI_Buffer_detach);
Utilitrias
(MPI_Wtime,
MPI_Get_count,
MPI_Get_processor_name,
MPI_Get_elements e MPI_Probe).
O ambiente de desenvolvimento composto por ns e domnios

administrativos distintos, sendo que o usurio em um terminal solicita o disparo da
aplicao, e o escalonador retorna a lista de ns disponveis para a execuo.
A ferramenta MPI implementada possui a mesma interface que as demais
implementaes MPI, porm a sua implementao foi realizada com o objetivo de
tirar proveito da arquitetura de grades computacionais. Para diminuir a troca de
mensagens entre os processos de domnios distintos, foi utilizado o algoritmo do
hipercubo [60] para o envio das mensagens nas primitivas de comunicao coletiva.
Por exemplo, em um ambiente de execuo composto por 8 processos,
ranqueados de 0 a 7, ao utilizar a primitiva em que os processos efetuam uma
operao de reduo (MPI_Reduce), como a busca do maior elemento, em que o
66
valor encontrado armazenado no processo com rank 0, com a utilizao do

algoritmo do hipercubo ocorre a seguinte sequncia de envio de mensagens:
Instante 1: os processos com rank 4, 5, 6 e 7 enviam uma mensagem

com o seu valor encontrado, respectivamente, para os processos com
rank 0, 1, 2 e 3. Cada processo que recebe a mensagem efetua a
operao de reduo e armazena o valor.
Instante 2: os processos com rank 2 e 3 enviam uma mensagem com o

seu valor encontrado, respectivamente, para os processos com rank 0 e
1. Cada processo que recebe a mensagem efetua a operao de reduo
e armazena o valor.
Instante 3: o processo com rank 1 envia uma mensagem com o seu valor
encontrado para o processo com rank 0. O processo que recebe a
mensagem efetua a operao de reduo e armazena o valor. Neste
momento, o processo com rank 0 possui o valor correto, pois todos os
processos j enviaram o seu valor armazenado.
Com o algoritmo de hipercubo, o tempo gasto no envio das mensagens

logartmico (log2 n) [7], no qual n a quantidade de processos. Caso cada processo
enviasse uma mensagem contendo o seu valor encontrado para o processo com
rank 0 e este processo fosse responsvel por efetuar a operao de reduo, o
tempo gasto no envio das mensagens seria linear, pois em cada instante de tempo
somente um processo poderia enviar a mensagem para o processo com rank 0,
totalizando n-1 instantes de tempo.
A utilizao desta estratgia faz com que o envio de uma mensagem para n
processos, ao invs de ter um tempo linear, tenha um tempo logartmico.
Durante todo o desenvolvimento das primitivas de comunicao, um ponto
fundamental foi o desenvolvimento do servio de encaminhamento de mensagens
entre domnios distintos.
4.5 Servio de Mensagem

O Servio de Mensagem [44] o elo de comunicao entre domnios
distintos. Os diversos processos de uma aplicao paralela que so executados em
67
ns localizados em diversos domnios, necessitam de um encaminhador de

mensagens para estabelecerem comunicao. Este servio deve, obrigatoriamente,
ser executado no n de entrada do domnio, que o n visvel externamente.
4.5.1 Funcionamento
O Servio de Mensagem resolve o problema de comunicao entre ns de
domnios distintos. Durante a fase inicial da execuo (startup dos processos), todos
os
processos
so
carregados
nos
ns
escolhidos
pelo
mecanismo
de
escalonamento, porm a porta utilizada para o canal de comunicao (Sockets) [60]

de cada processo ainda no est determinada.
A interface MPI desta infraestrutura utiliza Sockets [60] para a comunicao
entre os processos, sendo que necessrio que haja uma porta, em cada processo,
para o estabelecimento de conexes e envio de mensagens entre os processos.
Cada processo de um cluster envia suas informaes (nmero do rank,
endereo IP, nome do host, ip interno do n de entrada do domnio e ip externo da
n de entrada do domnio) para o Servio de Mensagem. Neste momento, o Servio
verifica qual porta de comunicao est disponvel para cada processo e envia o
nmero da porta selecionada para cada processo. Essa etapa inicial de configurao
do sistema realizada em conjunto com as primitivas MPI_Init e MPI_Init_thread .
Quando um processo finalizar a sua execuo, o Servio de Mensagem libera
a porta de comunicao alocada ao processo. Isso ocorre quando o processo utiliza
a primitiva MPI_Finalize.
Todos os processos possuem somente a localizao do Servio de
Mensagem de seu respectivo domnio. Quando um processo necessita enviar uma
mensagem para outro processo, duas possibilidades podem ocorrer.
a. Processo receptor no mesmo domnio. Neste caso o emissor envia ao
Servio de Mensagem uma mensagem solicitando o nmero da porta do
processo receptor. O Servio de Mensagem responde com esse nmero
e, consequentemente, emissor e receptor estabelecem comunicao.
b. Processo receptor em um domnio distinto. Neste caso o emissor envia a
mensagem de dados ao Servio de Mensagem que a armazena
temporariamente e envia ao Servio de Mensagem receptor em outro
domnio. O Servio de Mensagem receptor, ento, a encaminha ao
68
respectivo processo. Esta atividade a que mais exige do Servio de

Mensagem, pois, em funo do nmero de processos, a quantidade de
mensagens
pode
aumentar
consideravelmente,
comprometendo
desempenho do sistema. Neste caso, uma abordagem multithreaded [61]

foi desenvolvida para evitar que o Servio de Mensagem envie somente
uma mensagem por vez, aumentando o grau de paralelismo no
encaminhamento de mensagens.
4.5.2 Arquitetura
A arquitetura do Servio de Mensagem [44] foi definida para suportar
conexes simultneas. Essa deciso foi tomada porque o mecanismo de
encaminhamento da mensagem realizado em 3 passos:
1. O Servio de Mensagem recebe um envelope de solicitao de mensagem
(que contm, entre outras informaes, o tipo de dado e a quantidade de
elementos que sero transmitidos).
2. criado dinamicamente um buffer de memria para receber a mensagem
do processo emissor.
3. O buffer , ento, encaminhado ao processo receptor ou a outro Servio
de Mensagem, dependendo da localizao do processo receptor.
Para cada operao de encaminhamento (forwarding), uma nova thread

criada e torna-se responsvel pelos 3 passos anteriormente descritos, como ilustra a
Figura 4.5.
69
Figura 4.5 Arquitetura de funcionamento do Servio de Mensagem
4.6 Consideraes finais

A infraestrutura responsvel pelo gerenciamento e execuo de uma
aplicao paralela. O usurio simplesmente utiliza as primitivas MPI disponibilizadas
pelo ambiente, e no momento de realizar a execuo, ele informa a quantidade de
processos que executaro a aplicao. Caso haja alguma restrio de arquitetura,
sistema operacional ou quantidade de memria, o usurio tambm consegue
informar atravs do arquivo de submisso.
O arquivo de submisso faz parte do escalonador da grade, no caso o GCSE.
A Figura 4.6 ilustra um exemplo de arquivo de submisso. Neste arquivo, o usurio
submete a aplicao teste.i686, informa que o tipo da aplicao paralela
(PARALLEL_C), que 12 processos a executaro, e tambm informa o arquivo de
sada, de erro e de log. Alm disso, necessrio informar a biblioteca de ativao do
GCSE.
70
nilton@hepgrid00:/tmp/myGridSystems> cat app.gcse

GCSE_TYPE = PARALLEL_C
GCSE_EXECUTABLE = GCSE/application_bin/teste.i686
GCSE_CPU_COUNT = 12
GCSE_OUTPUT_FILE = teste.out
GCSE_LOG = teste.log
GCSE_ERROR = teste.err
GCSE_LIB_FILES = bin/manager_activation_C.jar
nilton@hepgrid00:/tmp/myGridSystems>
Figura 4.6 Exemplo de arquivo de submisso
A submisso ocorre atravs do GCSE, sendo que a partir deste ponto, tudo
realizado de maneira automtica. Ou seja, o ambiente escolhe os ns para a
execuo, faz o disparo, a execuo, o gerenciamento, e por fim, realiza a
finalizao da aplicao gerando os arquivos de sada, de log e de erro. A Figura 4.7
mostra um exemplo de submisso do arquivo app.gcse. O Gcse_submit um script
utilizado pelo GCSE para realizar a submisso de uma aplicao.
nilton@hepgrid00:/tmp/myGridSystems>gcse_submit app.gcse
Submitting job.
1 job submitted with Id: 1.
nilton@hepgrid00:/tmp/myGridSystems>
Figura 4.7 Submisso de um Arquivo
A ferramenta GCSE responsvel por gerar o XML para o Globus,

informando quais ns executaro a aplicao. Por sua vez, o Globus ao executar o
XML, envia a aplicao para o gerenciador local (Condor), e o Condor realiza o seu
disparo.
71
5. A LINGUAGEM CPAR
A linguagem CPAR [56] foi desenvolvida na livre docncia de Liria Matsumoto
Sato, e permite a programao de aplicaes paralelas para computadores com
vrios ncleos de processamento. Esta linguagem utilizada como referncia neste
trabalho e as construes e rotinas desenvolvidas neste trabalho esto baseadas na
CPAR.
A linguagem CPAR uma extenso paralela da linguagem C que utilizou
alguns elementos das linguagens Concurrent C e Ada, tal como um modelo de
programao de multitarefas. Ela foi projetada visando oferecer construes simples
para a explorao do paralelismo em mltiplos nveis, permitindo uma melhor
utilizao da localidade de memria. A linguagem CPAR oferece variveis
compartilhadas para o compartilhamento das informaes entre os processos. A
comunicao entre os diversos elementos de processamento ocorre atravs das
variveis compartilhadas.
Uma biblioteca de rotinas e um pr-compilador constituem o sistema de
programao para a linguagem CPAR que foi desenvolvida para computadores
multiprocessadores que possuam uma rea de memria compartilhada. A definio
da sua gramtica est no Apndice B, e a definio dos tokens da linguagem est
no Apndice A [1].
Este modelo de paralelismo oferece suporte para vrios nveis de paralelismo,
que vo desde a granularidade mais grossa at a mais fina. Os elementos
apresentados nas sees a seguir descrevem este modelo.
A Figura 5.1 mostra uma figura com os elementos de construo da
linguagem CPAR. Nesta figura, pode-se visualizar a independncia de cdigo entre
os macroblocos. Isso facilita a explorao da estrutura hierrquica das grades
computacionais, j que cada macrobloco pode ser executado em um domnio
distinto. As microtarefas so a parte paralela das macrotarefas, ou seja, elas so
utilizadas somente no escopo de uma macrotarefa, sendo o trecho de cdigo
paralelo da macrotarefa. Os blocos paralelos possibilitam a gerao de fluxos
paralelos, porm eles so executados no mesmo n.
72
Figura 5.1 Elementos de construo da linguagem CPAR
No decorrer deste captulo, os principais conceitos e construes da

linguagem CPAR so detalhados.
5.1 Variveis Compartilhadas

Para a identificao de uma varivel compartilhada, basta colocar a palavra
reservada shared precedendo a declarao desta varivel. A linguagem CPAR
permite que a varivel seja local ou global, sendo que o seu escopo de declarao
define se ela global ou local. A Figura 5.2 mostra a sintaxe da declarao de uma
varivel compartilhada.
shared <tipo_var> <nome_da_variavel>;
Figura 5.2 Sintaxe da Declarao de uma Varivel Compartilhada
73
Para o programador, a criao, a manipulao e a remoo das variveis

compartilhadas locais e globais so transparentes.
5.2 Blocos Paralelos

Na linguagem CPAR, vrios blocos podem ser executados em paralelo. Os
blocos paralelos so trechos de execuo paralelos, executados no mesmo n, em
que realizado o controle do fluxo e anlise das dependncias. Cada bloco pode
possuir um conjunto de comandos sequenciais, de chamadas de macrotarefas ou de
blocos paralelos aninhados. A Figura 5.3 exemplifica como a sintaxe de um bloco
paralelo.
Dentro de um bloco paralelo no possvel ter declarao de variveis
compartilhadas. Um bloco paralelo pode ser utilizado somente dentro da funo
principal do programa, em um macrobloco ou dentro de outro bloco paralelo.
cobegin
<comandos>
also
. . .
also
<comandos>
coend
Figura 5.3 Sintaxe do Bloco Paralelo
5.3 Macrotarefas
Uma macrotarefa apresenta uma granularidade de paralelismo no nvel de
sub-rotina. As macrotarefas so trechos de execuo paralelos, geralmente,
dependentes do escopo em que foi instanciada. Dentro de uma macrotarefa pode
haver comandos seqenciais, chamadas de microtarefas e declarao de variveis.
Caso haja a declarao de uma varivel compartilhada dentro de uma macrotarefa,
o seu escopo ser local a esta tarefa.
A chamada de uma macrotarefa pode ser feita dentro da funo principal de
um programa, em um bloco paralelo ou no corpo de um macrobloco. As Figuras
74
5.4a, 5.4b e 5.4c apresentam, respectivamente, a especificao, o corpo e a

chamada de uma macrotarefa.
a) task spec <nome_macrotarefa> (<parmetros>)

{ <declaracao_parmetros> }
b) task body <nome_macrotarefa> (<parmteros>)
<declaracao_parmetros>
{
<declaracao_variaveis>
<comandos>
. . .
}
c) main()
{
. . .
create <n_processadores>,<nome_macrotarefa>
(<argumentos>);
. . .
}
Figura 5.4 Sintaxe: Especificao (a), Corpo (b) e Chamada (c) de uma Macrotarefa
(extrado de [28])
5.4 Microtarefas
Uma microtarefa a granularidade mais fina de paralelismo da linguagem
CPAR. Este paralelismo pode ser homogneo, no qual instrues iguais so
executadas sobre dados distintos, ou pode ser heterogneo, no qual instrues
diferentes so executadas. Somente dentro das macrotarefas possvel criar uma
microtarefa, seja homognea ou heterognea. A microtarefa a parte paralela da
macrotarefa.
O paralelismo homogneo feito atravs do comando forall, no qual as
instrues pertencentes ao lao paralelo so executadas pelos processadores
presentes na macrotarefa. As iteraes deste lao so divididas de maneira
uniforme entre os processadores. A Figura 5.5 mostra a sintaxe do forall.
75
forall <contador> = <valor_inicial> to <valor_final>

{
. . .
<comandos>
. . .
}
Figura 5.5 Sintaxe do Comando Forall
Para o paralelismo heterogneo, utiliza-se a construo parbegin, no qual

vrias microtarefas so executadas simultaneamente instrues distintas, ou no. A
sua sintaxe est na Figura 5.6.
parbegin
<comandos>
also
. . .
also
<comandos>
parend
Figura 5.6 Sintaxe da Construo Parbegin
5.5 Macroblocos
Esta estrutura apresenta o nvel de paralelismo mais grosso dentro de um
programa. Os macroblocos so trechos de execuo, geralmente, independentes do
restante da aplicao. Dentro de um macrobloco pode haver outros macroblocos,
blocos paralelos, macrotarefas, comandos seqenciais e declaraes de variveis.
Um macrobloco pode ser referenciado somente no escopo da funo principal do
programa ou em outros macroblocos. A Figura 5.7 ilustra a sintaxe de um
macrobloco.
block <nome_bloco>
{
<comandos>
. . .
}
Figura 5.7 Sintaxe de um Macrobloco
76
5.6 Mecanismos de Sincronizao

Os mecanismos de sincronizao so utilizados para permitir que dados
compartilhados por diferentes processos sejam utilizados de maneira exclusiva, ou
seja, enquanto um processo est acessando estes dados, os outros processos no
podem acess-lo.
Estes recursos de sincronizao, geralmente, so empregados em trechos do
cdigo para prover a execuo mutuamente exclusiva. Os principais recursos
existentes na CPAR para a sincronizao so: Semforos, Eventos e Monitores,
sendo que eles so especificados a seguir.
Semforos
Um semforo um tipo de dado abstrato que consiste em um nmero inteiro

contador e em uma fila que armazena descritores de tarefas. O conceito de
semforos consiste na colocao de bloqueios em torno do cdigo que acessa esta
estrutura para oferecer acesso exclusivo a um recurso compartilhado [58]. O
semforo utilizado de maneira atmica atravs das operaes de lock e unlock.
Quando o contador estiver em zero, todos os processos que tentarem acess-lo
sero bloqueados at o recurso ser liberado e o contador incrementado. O semforo
pode ser utilizado em qualquer parte do programa do usurio. A Figura 5.8 mostra a
sintaxe dos comandos que a linguagem CPAR utiliza para a declarao, criao,
remoo, acesso e liberao do semforo.
semaph <nome_sem>; // declarao

create_sem(&<nome_sem>,<valor_inicial>); // criao e
inicializao
lock(&<nome_sem>); // acesso
unlock(&<nome_sem>); // liberao
rem_sem(&<nome_sem>); // remoo
Figura 5.8 Sintaxe dos Comandos do Semforo (baseado em [28])
77
Eventos
Um evento um tipo de dado abstrato que indica para os demais processos a

ocorrncia de uma determinada condio, que estava sendo aguardada. O evento
pode ser utilizado em qualquer parte do programa do usurio. A linguagem oferece
primitivas para a declarao, criao, remoo e manipulao. A Figura 5.9 ilustra a
sintaxe destas primitivas.
event <nome_evento>; // declarao

create_ev(&<nome_evento>); // criao
rem_ev(&<nome_evento>); // remoo
set_ev(&<nome_evento>); // ativao
reset_ev(&<nome_evento>); // desativao
wait_ev(&<nome_evento>); // espera pela
ativao
read_ev(&<nome_evento>); // retorno do
valor do evento
Funes para
manipulao
Figura 5.9 Sintaxe dos Comandos do Evento (baseado em [28])
Monitores
Um monitor um conjunto de procedimentos, variveis e estruturas de dados,

todas agrupadas em um mdulo especial [61]. A linguagem CPAR oferece monitores
como um mecanismo de sincronizao. A sua principal caracterstica a existncia
de um conjunto de estrutura de dados e de funes que operam estes dados. Um
monitor s pode ser utilizado por um nico processo de cada vez. Desta forma, h a
garantia da exclusividade de acesso a recursos compartilhados. As variveis
declaradas no monitor so visveis somente no seu escopo. O monitor pode ser
utilizado em qualquer parte do programa do usurio. A Figura 5.10 mostra como a
sintaxe de um monitor.
78
monitor <nome_monitor>
{
<funcao 1 do monitor>
. . .
<funcao N do monitor>
}
{
<inicializacao_variaveis>
}
Figura 5.10 Sintaxe de um Monitor

A linguagem CPAR facilita o desenvolvimento de uma aplicao paralela, pois
ela abstrai a utilizao dos recursos do sistema operacional para o paralelismo,
como threads e mecanismos de sincronizao. A sua execuo acontece em um n
multiprocessador.
Alm disso, a linguagem CPAR possui elementos de processamento que
oferecem vrios nveis de paralelismo, desde o paralelismo de granularidade mais
fina, como as microtarefas, at o paralelismo de granularidade mais grossa, como os
macroblocos.
79
6. MODELO DE PROCESSAMENTO PARALELO PARA GRADES

COMPUTACIONAIS
O modelo de processamento proposto neste trabalho leva em considerao
as
caractersticas
das
grades
computacionais,
abstraindo
do
usurio
as
caractersticas presentes na infraestrutura da grade. Este modelo baseado em

variveis compartilhadas, pois as linguagens de programao paralela podem
compartilhar uma rea de memria e assim, deixar transparente para o usurio a
comunicao entre os processos [56]. Alm disso, as variveis compartilhadas
facilitam a programao de uma aplicao paralela, no havendo a necessidade de
explicitar a troca de mensagens para atualizar as variveis entre os processos.
O modelo busca otimizar a utilizao dos recursos existentes e o custo da
comunicao entre os ns, minimizando o trfego de mensagens na rede, dado que
em uma grade computacional os ns podem estar localizados em lugares
geograficamente distantes. Com esta finalidade, o modelo de processamento aplica
um mecanismo para o escalonamento dos recursos na execuo de aplicaes
paralelas, que priorizam o escalonamento dos ns prximos para grupos de
processos que se relacionam entre si.
O modelo de processamento composto pelos modelos de programao e de
execuo, sendo que o modelo de programao explicita a linguagem de
programao utilizada e os elementos de construo presentes nesta linguagem que
facilitam a explorao da estrutura hierrquica das grades computacionais. J o
modelo de execuo descreve a arquitetura do ambiente responsvel por gerenciar,
distribuir e executar a aplicao paralela do usurio.
No decorrer deste captulo, o modelo de programao adotado, os recursos
que a linguagem oferece para a implementao de aplicaes paralelas e o modelo
de execuo proposto so apresentados.
80
6.1 Caractersticas de grades computacionais

As grades computacionais possuem algumas caractersticas que tornam o
ambiente de desenvolvimento complexo. As seguintes caractersticas devem ser
consideradas:
Localizao dos ns: os ns, entre si, podem estar prximos ou distantes
geograficamente. A sua localidade deve ser considerada para escalonar
os elementos de execuo de uma aplicao, com o objetivo de minimizar
o tempo gasto com o trfego de mensagens.
Heterogeneidade de hardware: cada n pode ser monoprocessador ou

multiprocessador, alm de possuir capacidade de processamento
diferente. No instante da distribuio dos itens de execuo da aplicao,
a quantidade de processadores de um n considerada, pois se houver a
possibilidade de colocar todos os itens no mesmo n, o tempo gasto para
troca de mensagens ser menor.
Composio da grade computacional: uma grade composta por diversos

domnios, sendo que cada domnio pode ser composto por ns simples,
supercomputadores ou clusters. Independente da composio da grade, o
modelo deve otimizar a utilizao dos recursos disponveis em cada
domnio.
Balanceamento de cargas: devido heterogeneidade do hardware dos

ns que podem compor uma grade computacional, deve haver um
escalonador para dividir a carga de processamento entre os ns,
utilizando as suas caractersticas para decidir o melhor n para executar
um item.
6.2 Ambiente de programao

Para a execuo de uma aplicao paralela CPAR em uma grade
computacional, o ambiente proposto neste trabalho realiza a pr-compilao da
aplicao, gerando um cdigo expandido para a linguagem C. Esse mesmo cdigo
passa por um compilador C, pela biblioteca MPI, implementada na infraestrutura da
grade detalhada no captulo 4, e por bibliotecas do sistema para gerar o arquivo
81
executvel. A Figura 6.1 mostra o processo de compilao do arquivo exemplo.cpar

para o ambiente proposto neste trabalho.
Figura 6.1 Gerao do cdigo executvel no ambiente
As bibliotecas do sistema contm o modelo de execuo do ambiente e

devem ser ligadas aplicao paralela durante a sua compilao, assim como a
biblioteca MPI para grades computacionais. O arquivo executvel gerado
submetido para a infraestrutura do ambiente, sendo que a infraestrutura
responsvel por fazer uma cpia deste arquivo executvel para todos os ns
responsveis pela execuo da aplicao. Este arquivo contm todas as entidades
que realizam o gerenciamento e a execuo da aplicao paralela e ele submetido
para a
Os pontos principais a serem tratados no desenvolvimento de um ambiente
que permita a execuo de uma aplicao paralela em uma grade computacional
so a troca de mensagens e o balanceamento de carga. necessrio que o
ambiente, entre os ns de execuo, minimize a quantidade de mensagens trocadas
entre os processos da aplicao e a distncia entre os ns de processamento que
compartilham informaes. A carga de processamento entre os ns tambm precisa
82
ser balanceada para que o tempo de execuo no seja elevado devido a um n ter
mais carga para processar do que os demais.
O ambiente possui dois escalonadores, sendo eles:
Escalonador da infraestrutura: responsvel pela escolha dos ns que

sero disponibilizados para a aplicao. Este escalonador pertence ao
mecanismo de escalonamento GCSE, utilizado na infraestrutura deste
trabalho e detalhado na seo 4.3.
Escalonador do ambiente: com os ns disponibilizados pelo escalonador

da infraestrutura, o escalonador do ambiente escolhe os ns para a
execuo dos elementos de processamento paralelo da aplicao. O
objetivo do escalonador do ambiente escolher os ns, visando minimizar
o custo da comunicao e promover um balanceamento de carga. O
escalonador detalhado na seo 6.4.7.
6.3 Modelo de programao

Para a criao de um ambiente que permita a execuo de uma aplicao
paralela utilizando grades computacionais, o modelo de programao precisa
oferecer elementos de processamento adequados para este ambiente. O objetivo
buscar a utilizao dos recursos oferecidos pelas grades computacionais de maneira
eficiente e minimizar o custo da comunicao, reduzindo a quantidade de
mensagens trocadas e a distncia entre os ns que se comunicam.
O ambiente utiliza o modelo de programao da linguagem CPAR [56], pois
ele oferece mltiplos nveis de paralelismo atravs dos seus elementos de
construo, alm de possuir uma estrutura hierrquica de processamento. Devido
linguagem CPAR utilizar variveis compartilhadas para a comunicao entre os
processos, a programao de aplicaes paralelas facilitada, j que o usurio no
precisa se preocupar com o envio e recebimento de mensagens para o
compartilhamento de dados. Quando um processo altera o contedo de uma
varivel compartilhada, automaticamente, todos os processos que compartilham
esta varivel conseguem visualizar o seu novo valor.
83
Conforme detalhado no captulo 5, os elementos de construo presentes na

linguagem CPAR so os macroblocos, os blocos paralelos, as macrotarefas e as
microtarefas.
Para a execuo de uma aplicao CPAR em um ambiente de grades
computacionais, os principais elementos de construo da linguagem CPAR so os
macroblocos (blocos) e as macrotarefas (tarefas). O macrobloco, por ser
independente do restante da aplicao, pode ser executado em um domnio distinto
do restante da aplicao, j que provavelmente conter pouca comunicao com o
restante da aplicao. Desta forma, o macrobloco possibilita a diviso do
processamento entre os domnios do ambiente, buscando minimizar a comunicao
entre processos que estejam em domnios distintos.
Uma macrotarefa, por ser dependente do escopo em que foi instanciada,
deve ser executada no mesmo domnio do n que a instanciou, preferencialmente
utilizando ns multiprocessados. Geralmente, os ns executores de uma
macrotarefa compartilham variveis e a alocao de ns prximos para a sua
execuo faz com que a distncia, entre os ns que se comunicam durante a
execuo de uma macrotarefa, seja minimizada.
A Figura 6.2 ilustra um exemplo de aplicao CPAR. Nesta figura, pode-se
identificar a existncia de dois macroblocos (m1e m2), trs blocos paralelos (b1, b2
e b3) e dez macrotarefas (t1, t2, t3, t4, t5, t6, t7, t8, t9 e t10). As microtarefas so a
parte paralela das macrotarefas.
84
Figura 6.2 Exemplo de aplicao CPAR
A quantidade de processos que executam cada macrotarefa identificado

pelo nmero acima de cada tarefa. Por exemplo, a macrotarefa 1 (t1) executada
por 42 processos. Cada macrobloco executado por um processo. Para executar a
aplicao da Figura 6.2 so necessrios 126 processos.
A escolha dos ns do ambiente que executaro cada elemento de
processamento fundamental para o desempenho da aplicao. Os elementos de
processamento da linguagem CPAR geram uma estrutura hierrquica, facilitando a
sua alocao em um ambiente de grades computacionais.
De acordo com as caractersticas dos elementos de processamento, para
cada macrotarefa criada, apropriado que ela seja executada no mesmo domnio do
n que a instanciou. A execuo de um macrobloco deve ocorrer em um domnio
que esteja ocioso no momento. Isso otimiza a execuo do macrobloco, pois ele
pode criar macrotarefas que executem no mesmo domnio em que ele executa.
Provavelmente, este domnio estar com vrios ns ociosos, j que somente um n
estar executando o macrobloco e a chance dos demais ns estarem executando
outras macrotarefas bem pequena.
85
A Figura 6.3 ilustra a alocao da aplicao da Figura 6.2 em um ambiente de

grades computacionais, composto por dois domnios, sendo que o domnio A possui
um servidor com quatro processadores (cores), um cluster com oito ns, totalizando
61 cores, e um cluster com cinco ns, totalizando 30 cores. O domnio B possui um
cluster com trs ns, totalizando 19 cores, e um cluster com trs ns, totalizando 12
cores. O ambiente ilustrado na Figura 6.3 possui 126 cores (processadores)
disponveis.
Figura 6.3 Exemplo de alocao de processos para uma aplicao exemplo
O macrobloco 1 (m1 da Figura 6.2) foi atribudo ao domnio A, sendo que ele
possui quatro macrotarefas. A macrotarefa 1 (t1) foi atribuda ao cluster 1, a t2 foi
atribuda ao cluster 2, a t3 tem alguns processos no cluster 1 e alguns no cluster 2, e
a t4 foi atribuda ao cluster 1 e ao cluster 2.
O macrobloco 2 (m2 da Figura 6.2) foi atribudo ao domnio B, sendo que ele
possui seis macrotarefas. A t5 foi atribuda ao cluster 4, a t6 foi atribuda ao cluster
3, a t7 foi atribuda ao cluster 3, a t8 foi atribuda ao cluster 3 e ao servidor do
86
domnio A, a t9 foi atribuda ao servidor do domnio A, e a t10 foi atribuda ao cluster

3.
A alocao dos macroblocos e das macrotarefas ilustrados na Figura 6.3
mostra a estratgia do ambiente em alocar os recursos, buscando minimizar o custo
da comunicao entre os processos, atravs da considerao da distncia entre os
ns. O ideal que as macrotarefas sejam escalonadas em ns que estejam
prximos e no mesmo domnio do n que fez a sua criao. O macrobloco deve ser
escalonado em outro domnio para que ele possa executar as suas macrotarefas
neste domnio, j que, geralmente, um macrobloco tem a sua execuo
independente do restante da aplicao. Isso faz com que o custo da comunicao
seja minimizado.
A distncia entre os ns importante ser considerada para a atualizao das
variveis compartilhadas, sendo que os ns que recebero a atualizao so
definidos atravs do escopo do varivel. O menor escopo de uma varivel
compartilhada ocorre quando ela declarada dentro de uma macrotarefa. Por isso,
importante que os ns que executem uma macrotarefa estejam prximos e no
mesmo domnio, j que o maior fluxo de utilizao das variveis compartilhadas
dentro de uma macrotarefa.
Todos os elementos de construo da linguagem e o funcionamento das
variveis compartilhadas so detalhados a seguir.
Macrotarefas
Este elemento de construo gera uma tarefa a ser executada de maneira

paralela pelos ns selecionados. Uma macrotarefa composta por n processos,
sendo um executor principal (pai da macrotarefa) e o restante so os executores
paralelos. Todos os executores so responsveis pela execuo da parte paralela. A
parte sequencial executada somente pelo executor principal. H uma barreira
antes do incio da execuo das microtarefas (forall e parbegin), sendo que somente
quando todos os executores estiverem na barreira, comea a execuo da
microtarefa. Tambm h uma barreira na finalizao da parte paralela. O executor
principal o responsvel por gerenciar a barreira de incio e trmino das
microtarefas.
87
A alocao das macrotarefas realizada na Figura 6.3 ilustra a estratgia para

minimizar o trfego de mensagens e a distncia entre os processos que se
comunicam, pois a maioria das macrotarefas foram alocadas no mesmo domnio dos
macroblocos que as criaram, fazendo que a distncia entre os ns que se
comunicam seja minimizada. O escalonador do ambiente o responsvel por decidir
os ns que executaro cada macrotarefa e ele tem impacto direto na distncia entre
os ns que se comunicam.
Microtarefas
A microtarefa um elemento de construo interno macrotarefa, ou seja,

ela disparada somente no escopo de uma macrotarefa. Uma microtarefa pode
implementar um paralelismo homogneo (forall) ou paralelismo heterogneo
(parbegin).
No paralelismo homogneo, as iteraes do lao so divididas entre os
processos que executam a macrotarefa, sendo que o ideal que os processos
estejam em ns prximos geograficamente. Por exemplo, caso o lao seja de 100
iteraes e tenham quatro processos executando-o, as primeiras 25 iteraes iro
para o primeiro processo, as prximas 25 iteraes iro para o segundo processo, e
assim por diante.
J no paralelismo heterogneo, cada trecho entre parbegin-also, also-also ou
also-parend executado por um processo da macrotarefa. Se houver quatro trechos
e quatro processos, cada processo executar um trecho diferente.
Blocos paralelos
A construo de blocos paralelos (cobegin) funciona como uma estrutura para

dividir um trecho de cdigo em partes que estejam relacionadas. Todos os trechos
paralelos (cobegin-also, also-also e also-coend) so executados paralelamente no
mesmo processo, sendo que cada trecho paralelo gera um fluxo distinto. Portanto,
sero executadas por um nico n da grade.
Estes fluxos so executados no mesmo n e tem a funcionalidade de
controlar o fluxo de execuo da aplicao, provendo a sincronizao entre
elementos de processamento paralelo quando necessria. Esta soluo centralizada
88
em um nico n permite a utilizao da memria compartilhada para efetuar o

controle.
Se
este
for
multiprocessado,
os
fluxos
sero
executados
simultaneamente. Caso contrrio, a execuo ser concorrente.

Cada trecho ter a sua prpria linha de execuo independente. H uma
barreira no coend para sincronizar a finalizao do bloco paralelo. Ao final da
execuo do bloco paralelo, o processo que estava aguardando a sua finalizao,
desbloqueado e pode prosseguir com a execuo da parte sequencial.
Macroblocos
Os macroblocos, quando gerados, vo para a fila de execuo e o

escalonador ser o responsvel por definir o processo que o executar. O ideal
que um macrobloco seja executado em um domnio que esteja ocioso, conforme foi
realizado na Figura 6.3, onde se pode visualizar que o macrobloco 1 est alocado no
domnio A e o macrobloco 2 est alocado no domnio B.
Com a utilizao dos macroblocos, uma aplicao dividida em blocos,
sendo que, geralmente, h pouca dependncia entre eles. As macrotarefas criadas
em um macrobloco devero ser executadas, preferencialmente, por ns do mesmo
domnio do macrobloco que a criou.
Quando ocorre a chamada de um macrobloco, o processo que fez a chamada
continua a sua execuo normalmente e no h nenhum ponto de sincronizao
entre eles. No modelo de processamento foi implementado um mtodo chamado
Wait_Block(nome) e este mtodo realiza a sincronizao do processo que fez a
criao do macrobloco com o prprio macrobloco. Quando o processo executa o
mtodo Wait_Block, ele fica em estado de espera at que o macrobloco em questo
seja finalizado.
Variveis compartilhadas
A linguagem CPAR utiliza variveis compartilhadas para a comunicao entre

os processos. Estas variveis compartilhadas armazenam dados que so utilizados
por processos de maneira simultnea. Para a proteo destes dados, a linguagem
possui um mecanismo de sincronizao para evitar que dois ou mais processos
utilizem uma varivel compartilhada ao mesmo tempo.
89
As variveis compartilhadas tm escopos hierrquicos. Neste sentido, a

linguagem permite a declarao de variveis compartilhadas entre os processos de
uma macrotarefa, no escopo de um macrobloco ou no escopo global da aplicao.
Porm, a sua utilizao e atualizao so de acordo com o seu escopo. Caso
um macrobloco possua uma varivel compartilhada, todas as macrotarefas criadas a
partir deste macrobloco e o processo que o executa compartilham esta varivel.
A declarao de uma varivel compartilhada global somente deve ser feita em
ltimo caso, pois ela impactar no envio de mensagens entre todos os processos,
que executam a aplicao, para a sua atualizao, sendo que esta necessria
para manter a consistncia da aplicao.
O modelo de consistncia para a atualizao das variveis compartilhadas faz
uma cpia da varivel em cada processo que a utiliza e, a cada atualizao por um
processo, ele verifica os processos que esto no escopo de execuo desta varivel
e que j utilizaram alguma varivel compartilhada deste escopo, enviando uma
mensagem com o novo valor da varivel para estes processos [64].
6.4 Modelo de execuo

Para uma aplicao desenvolvida em uma linguagem de programao
paralela ser executada em uma grade computacional, necessrio que haja um
modelo que d suporte a sua execuo. Considerando a infraestrutura da grade
proposta neste trabalho, as entidades, aqui definidas, so utilizadas para o
gerenciamento e a execuo da aplicao neste modelo, sendo elas:
Coordenador mestre: responsvel por gerenciar a execuo da

aplicao.
Executores: responsvel pela execuo das macrotarefas e dos

macroblocos.
Coordenadores locais: responsvel por gerenciar a execuo local.
Emissor: responsvel pelo controle do fluxo dos dados entre o executor e

os coordenadores.
Mecanismo
de
escalonamento:
responsvel
por
realizar
escalonamento das macrotarefas e dos macroblocos. O escalonador no

realiza o escalonamento dos blocos paralelos, pois eles so executados
90
pelo n que fez a sua criao, e das microtarefas, j que todas as

instncias da uma macrotarefa iro executar as microtarefas que esto no
seu escopo.
Fila de execuo: local em que os coordenadores armazenam os

macroblocos e as macrotarefas a serem executados em cada n.
Gerenciador
das
variveis
compartilhadas:
responsvel
pelo
armazenamento das variveis compartilhadas.
O modelo de execuo foi baseado no modelo do CPAR-Cluster [9] e do

CPAR-WinCluster [28]. Tanto o CPAR-Cluster, quanto o CPAR-WinCluster, so
modelos de processamento paralelo da linguagem CPAR para cluster de
computadores. Estes modelos so executados diretamente no cluster, necessitando
somente da interface MPI [48] como infraestrutura para a sua execuo,
diferentemente da infraestrutura que necessria para a execuo em um ambiente
de grades computacionais.
O escalonador destes modelos no se preocupa com a localidade dos ns no
momento de fazer a alocao, j que todos os ns esto no mesmo domnio, dentro
de um cluster. O mecanismo de atualizao das variveis compartilhadas faz a
atualizao das variveis para todos os ns do cluster, inclusive para os ns que
no utilizam a varivel. Alm disso, os coordenadores locais no se preocupam com
o escalonamento de macroblocos e macrotarefas, j que tudo realizado e
gerenciado pelo coordenador da aplicao.
A Figura 6.4 mostra o modelo de execuo adotado para a linguagem de
programao paralela ser utilizada em um ambiente de grades computacionais.
Neste modelo, um dos ns o coordenador mestre e responsvel pela
execuo do bloco principal. Os demais ns so escravos e responsveis pela
execuo das tarefas e dos blocos. A fila de execuo fica nos ns escravos, pois
somente nestes ns h a execuo da aplicao.
91
Figura 6.4 Modelo de execuo para grades computacionais
O escalonador fica somente no n mestre, j que somente este n tem todas

as informaes atualizadas. Para gerenciar as variveis compartilhadas, todos os
ns possuem uma entidade responsvel por isso.
Todas as entidades que compem o modelo so apresentadas nas sees a
seguir, onde feita uma distino sobre o que cada entidade realiza no n mestre e
no n escravo, e tambm se ela participa ou no da configurao.
6.4.1 Coordenador Mestre

O coordenador mestre a entidade responsvel por gerenciar a execuo no
n mestre e possui as seguintes atribuies:
Iniciao das variveis de controle: todas as variveis utilizadas para o

controle do mestre so iniciadas por seu coordenador.
Iniciao do executor: o coordenador inicia a thread que far a execuo

do bloco principal do programa do usurio.
92
Atualizao das variveis compartilhadas: o coordenador recebe um

pacote contendo a atualizao remota das variveis compartilhadas
globais e deve realizar essas alteraes sobre as cpias das variveis
compartilhadas do seu local.
Escalonamento e submisso das macrotarefas e dos macroblocos: o

coordenador envia o pedido de escalonamento de uma macrotarefa ou de
um macrobloco para o escalonador. Assim que o escalonador retorna os
ns escolhidos, caso a macrotarefa ou o macrobloco tenha sido
instanciado no bloco principal, o coordenador mestre faz a sua submisso
aos ns selecionados pelo escalonador.
Trmino de uma macrotarefa: o coordenador recebe mensagens dos ns

que esto executando a macrotarefa, informando que esta terminou. Aps
receber a mensagem de todos os ns, o coordenador retira a macrotarefa
da tabela de macrotarefas para execuo e libera os ns para
continuarem a execuo das outras macrotarefas.
Trmino de um macrobloco: o coordenador recebe uma mensagem, do n

que est executando o macrobloco, de finalizao da sua execuo. O
coordenador libera o n que estava executando o macrobloco e o retira da
fila de execuo.
Trmino da execuo do sistema: aps todo o programa do usurio ser

executado, o coordenador finaliza o sistema liberando os recursos
alocados para a execuo.
6.4.2 Coordenador Local

O coordenador local a entidade responsvel por gerenciar a execuo nos
ns escravos e possui as seguintes atribuies:
Iniciao das variveis de controle: todas as variveis utilizadas para o

controle do escravo so iniciadas por seu coordenador.
Iniciao do(s) executor(es): o coordenador faz a iniciao dos

executor(es) escravo(s) que far(o) parte do n.
Insero das macrotarefas na fila de execuo: o coordenador de um n

recebe do coordenador mestre ou de outro coordenador local uma
93
mensagem contendo as macrotarefas que ele executar, e as insere na

fila de execuo.
Insero dos macroblocos na fila de execuo: o coordenador escravo

recebe do coordenador mestre ou de outro coordenador local os
macroblocos que ele executar e os insere na fila de execuo.
Atualizao das variveis compartilhadas: o coordenador recebe um

pacote contendo a atualizao remota das variveis compartilhadas
globais e/ou locais e deve realizar essas alteraes sobre as cpias das
variveis compartilhadas do seu local.
Escalonamento das macrotarefas e dos macroblocos: o coordenador local

envia uma mensagem para o coordenador mestre, informando a
macrotarefa ou o macrobloco a ser escalonado e espera a resposta sobre
os ns selecionados. Posteriormente, o coordenador envia uma
mensagem para os ns selecionados informando a macrotarefa ou o
macrobloco que deve ser executado.
Liberao dos recursos alocados: todos os recursos alocados para a

execuo no coordenador e do seu executor so liberados aps o seu
trmino.
6.4.3 Executor
O executor no n mestre iniciado pelo coordenador mestre, sendo
responsvel pelas seguintes atribuies:
Elaborao das tabelas de controle da execuo: as tabelas que

controlam a execuo do sistema so elaboradas de acordo com as
informaes fornecidas pelo usurio atravs dos arquivos de configurao
do sistema. O controle desta tabela feito pelo executor mestre.
Execuo do ramo principal: o fluxo de execuo da funo main do

programa do usurio feito pelo executor mestre.
Sincronizao dos escravos: o executor mestre espera que as

macrotarefas que esto em execuo no momento terminem, para que ele
possa prosseguir a sua execuo.
94
Finalizao do programa do usurio: aps o programa do usurio finalizar,

o executor mestre envia uma mensagem ao coordenador mestre
informando que o sistema pode ser finalizado.
O executor no n escravo iniciado pelo seu coordenador local, sendo

responsvel pelas seguintes atribuies:
Execuo das macrotarefas e dos macroblocos: o executor escravo retira

a macrotarefa, atribuda pelo mestre, da fila de execuo e a executa.
Atualizao das variveis compartilhadas: as variveis compartilhadas

alteradas pelo executor escravo so atualizadas por ele localmente, e um
pacote enviado aos coordenadores dos outros ns para que as rplicas
desta varivel estejam atualizadas em todos os locais.
6.4.4 Emissor
O emissor o responsvel pelo empacotamento e envio das mensagens para
os coordenadores dos outros ns. Este processo foi inserido no modelo de execuo
porque se o executor fizesse o empacotamento e envio, ele perderia tempo de
processamento e, alm disso, ficaria esperando pela confirmao da chegada da
mensagem no destinatrio. Neste perodo de tempo, o executor poderia continuar a
execuo de outras tarefas. Por este motivo, houve a necessidade da insero do
emissor no modelo.
Para a comunicao entre o emissor e o executor existe uma rea de
memria compartilhada. Nesta rea de memria, o executor armazena as
informaes referentes s atualizaes das variveis. O emissor retira as
informaes desta rea e faz o envio para os coordenadores dos ns que precisam
das informaes atualizadas.
6.4.5 Fila de execuo

A Fila de execuo uma rea de memria compartilhada entre o
coordenador local e o executor de um n. O coordenador local recebe uma
95
macrotarefa ou um macrobloco para executar e coloca na fila. Assim que uma

macrotarefa ou um macrobloco colocado na fila, o executor recebe uma
sinalizao atravs de mecanismos de sincronizao.
Caso o executor esteja livre, ele retira a macrotarefa ou o macrobloco da fila e
o executa. Este procedimento repetido at que todas as macrotarefas e
macroblocos tenham sido executados.
6.4.6 Gerenciador de variveis compartilhadas

Uma caracterstica de uma linguagem de programao paralela que facilita o
desenvolvimento de aplicaes a utilizao de variveis compartilhadas entre as
tarefas. Porm, no ambiente de grades computacionais, no existe uma regio de
memria compartilhada global entre todos os processos. Para simular as variveis
compartilhadas, cada n possui uma tabela para armazenar as variveis
compartilhadas declaradas na aplicao.
Sempre que uma varivel compartilhada for atualizada em um n, uma
mensagem deve ser enviada para todos os ns que utilizam esta varivel,
informando a sua atualizao.
A estrutura que armazena as informaes utilizadas pelas variveis
compartilhadas para o mapeamento em endereos de memria est presente na
Figura 6.5.
No mapeamento das variveis compartilhadas, cada uma possui identificador,
tipo, quantidade e tamanho de cada dimenso, endereo inicial, deslocamento e
escopo.
Figura 6.5 Mapeamento das variveis compartilhadas em endereos de memria
Como todas as variveis compartilhadas esto armazenadas em uma tabela,

sendo que cada uma pode ter vrias dimenses, o acesso a uma varivel
compartilhada realizado atravs do endereo inicial da varivel e do deslocamento
96
at o item desejado. Isso torna possvel o acesso a qualquer varivel compartilhada

de uma aplicao.
6.4.7 Escalonador
Geralmente, as macrotarefas e os macroblocos so executados por ns
diferentes daqueles que os instanciaram. Desta forma, necessrio escolher os ns
em que eles sero executados, sendo que este escalonamento realizado pelo n
mestre. Caso a macrotarefa ou o macrobloco seja instanciado no escopo de outro
macrobloco, o coordenador local envia uma mensagem ao coordenador mestre,
solicitando o escalonamento.
O escalonador escolhe os ns para a execuo da macrotarefa ou do
macrobloco em questo e informa o coordenador mestre. Caso a macrotarefa ou o
macrobloco esteja no escopo do bloco principal, o coordenador mestre faz a sua
submisso aos ns selecionados. Caso contrrio, o coordenador mestre envia uma
mensagem ao coordenador local responsvel pelo gerenciamento do bloco,
informando os ns selecionados. Nesse caso, o coordenador local o responsvel
pela submisso da macrotarefa ou do macrobloco aos ns selecionados.
O escalonador precisa conhecer a configurao do ambiente e ter as
informaes atualizadas sobre a situao dos ns, pois o seu escalonamento tem
um impacto grande no desempenho do ambiente. Caso ele faa uma m escolha, o
desempenho da aplicao ficar comprometido. Por este motivo, o escalonador est
somente no n mestre. Se todos os ns pudessem realizar diretamente o
escalonamento, seria necessria uma troca grande de mensagens para todos
manterem as informaes atualizadas, impactando no desempenho da aplicao.
O tempo total de execuo de uma aplicao formado pelo tempo de
processamento e pelo tempo gasto em comunicao. A Equao 6.1 mostra a
frmula que calcula o tempo de execuo. Para a troca de mensagens, entre
processos no mesmo domnio, foi adotado o tempo de X segundos, e para a
comunicao entre processos de domnios distintos, de Y segundos.
Como X refere-se ao tempo para a comunicao entre dois processos no
mesmo domnio, e Y a dois processos em domnios distintos, o ideal que o nmero
multiplicado por X seja maior do que o nmero multiplicado por Y, j que, com
certeza, o valor de X menor do que Y. Portanto, para o impacto da comunicao
97
no tempo total de execuo ser minimizado, o quociente da diviso do nmero de

mensagens internas (Ni) pelo nmero de mensagens externas (Ne) deve ser o maior
possvel.
Ttotal = Tprocessamento + X*Ni + Y*Ne

(Equao. 6.1)
Onde:
Ttotal = tempo total de execuo.
Tprocessamento = tempo gasto no processamento da aplicao.
Ni = quantidade de mensagens internas (processos no mesmo domnio)

enviadas durante a execuo.
Ne = quantidade de mensagens externas (processos em domnios

distintos) enviadas durante a execuo.
De acordo com a frmula, pode-se concluir que o escalonador tem um papel

fundamental no desempenho da aplicao, pois se ele fizer escolhas corretas, a
quantidade de mensagens internas ser maior e a quantidade de mensagens
externas ser menor, diminuindo o tempo total de execuo e otimizando a
distribuio dos itens de execuo entre os ns que compem o ambiente.

Este captulo mostrou as caractersticas das grades computacionais e o seu
impacto em uma linguagem de programao. Para uma linguagem ser utilizada
neste ambiente, necessrio que ela possua algumas construes que se adaptem
a uma grade computacional, sendo que a linguagem deve possuir uma estrutura
hierrquica. Por este motivo, a linguagem CPAR foi adotada.
O
modelo
de
programao
explora
as
caractersticas
das
grades
computacionais, utilizando os elementos de processamento de forma adequada para

a execuo neste tipo de ambiente.
O modelo de execuo deve possuir algumas entidades para cuidar do
gerenciamento e execuo da aplicao, da comunicao entre os processos, do
98
escalonamento das tarefas e dos blocos, alm do armazenamento das variveis

compartilhadas da linguagem. O modelo de execuo adotado contempla estas
entidades, criando uma arquitetura especfica para grades computacionais.
99
7. O AMBIENTE DE EXECUO CPAR-GRID

Este captulo apresenta o desenvolvimento do ambiente de execuo de
aplicaes paralelas para grades computacionais, implementando o modelo de
programao e de execuo apresentados no captulo 6.
A linguagem de programao paralela escolhida para ser utilizada neste
trabalho foi a linguagem CPAR [56]. A implementao da linguagem CPAR,
aplicando o modelo de programao e de execuo adotados, explora as
caractersticas de grades computacionais e abstrai do usurio as caractersticas
presentes na infraestrutura da grade. Desta forma, o usurio se preocupa somente
com o desenvolvimento da aplicao paralela. A distribuio, a execuo e o
gerenciamento da aplicao ficam sob responsabilidade do ambiente, denominado
CPAR-Grid.
O ambiente de execuo prov suporte a programao paralela, atravs da
linguagem CPAR, com variveis compartilhadas e mecanismos de sincronizao.
Este ambiente executa na plataforma Linux, utilizando a infraestrutura descrita no
captulo 4. Uma diferena do ambiente CPAR-Grid, com relao aos demais
ambientes estudados, est no fato do CPAR-Grid utilizar variveis compartilhadas
como o mecanismo de compartilhamento das informaes e utilizar uma linguagem
de programao que possui elementos de construo que facilitam a explorao da
Nas sees deste captulo apresentado o modelo do sistema CPAR-Grid,
suas estratgias de escalonamento, de distribuio e de atualizao dos dados.
7.1 Modelo do CPAR-Grid

O modelo da linguagem CPAR possui elementos de construo que permitem
o desenvolvimento de aplicaes paralelas utilizando estruturas hierrquicas. Os
principais elementos utilizados so macroblocos, blocos paralelos, macrotarefas e
microtarefas.
Tais
elementos
so
programao apresentado no captulo 6.
implementados
atravs
do
modelo
de
100
Uma aplicao paralela CPAR, compilada no ambiente CPAR-Grid, gera um

arquivo executvel, no qual todo o modelo necessrio para a execuo e para o
gerenciamento da aplicao est na biblioteca do sistema que ligada ao cdigo do
arquivo executvel no momento da sua compilao.
O mecanismo de escalonamento e submisso da infraestrutura utilizada neste
trabalho atribui o arquivo executvel para cada processador escolhido para a
execuo da aplicao paralela. Como um ambiente de grades computacionais pode
ser composto por diversos domnios, sendo que cada domnio pode ter ns
monoprocessadores e multiprocessadores e clusters, caso o mecanismo de
escalonamento escolha dois ou mais processadores no mesmo n, ele submete o
mesmo arquivo executvel para os processadores selecionados.
Para o compartilhamento de informaes entre processos no mesmo n, ser
necessrio que eles troquem mensagens. Para eliminar a troca de mensagens entre
processos no mesmo n, em tempo de execuo, todos os processos, no mesmo
n, so unificados em um nico processo. Este processo unificado dispara uma
thread para cada processador neste n. Aps a unificao, o n fica com um
processo composto por threads que implementam os executores e so responsveis
pela execuo das macrotarefas e dos macroblocos.
Neste contexto, a troca de mensagens minimizada, pois as threads
executoras compartilham a memria e no h a necessidade de troca de
mensagens para a atualizao das variveis compartilhadas. Caso no houvesse a
unificao, com vrios processos no mesmo n, haveria a necessidade de troca de
mensagens para a atualizao das variveis compartilhadas, aumentando o tempo
gasto em comunicao entre os processos.
A Figura 7.1 mostra a configurao de um n multiprocessador, com quatro
processos, no instante da submisso da aplicao e depois mostra a sua
configurao aps a unificao em um nico processo. Esta unificao feita pelo
CPAR-Grid faz com que as threads se comuniquem atravs de uma rea de
memria compartilhada, ao invs de troca de mensagens. Vale ressaltar que a
quantidade de threads executoras criadas pelo processo unificado igual ao nmero
de processos que havia antes da unificao.
101
Figura 7.1 Unificao dos processos em um n multiprocessador
A execuo da aplicao feita sobre um modelo mestre-escravo, no qual o

n mestre realiza a coordenao, distribuio e recepo dos resultados, e os ns
escravos executam as macrotarefas e os macroblocos que so enviados pelo
mestre.
Para verificar quem o n mestre, cada processo possui um rank, sendo que
o rank zero o n mestre e os demais ranks so os ns escravos. Associado ao
arquivo executvel h um mtodo responsvel pela coordenao do mestre, e outro
mtodo responsvel pela coordenao do escravo. Assim que o arquivo descobre se
ele o mestre ou o escravo, ele faz o disparo do seu mtodo especfico.
O modelo de execuo do CPAR-Grid o mesmo modelo detalhado no
captulo 6. Neste modelo h as seguintes entidades: coordenador mestre e escravo,
executor mestre e escravo, emissor, fila de execuo, tabela de variveis
compartilhadas e escalonador.
O coordenador mestre e escravo e o emissor so processos, sendo que o
processo emissor criado atravs do coordenador, utilizando o comando fork do
UNIX [61]. Houve a necessidade da utilizao deste comando, pois a infraestrutura
102
do ambiente de grades computacionais, utilizada neste trabalho, d suporte apenas

para a submisso de um arquivo executvel.
O arquivo submetido infraestrutura do ambiente contm o executvel do
coordenador. O processo emissor de um n gerado pelo coordenador deste n,
assim como as threads responsveis pela execuo da aplicao paralela CPAR. As
threads executoras geradas pelos coordenadores so a entidade executor e so
criadas atravs do comando pthread_create da biblioteca pthreads [40].
As threads executoras ficam ativas enquanto a aplicao CPAR do usurio
estiver em execuo. Aps a finalizao da aplicao CPAR, as threads executoras
so finalizadas. O processo coordenador de cada n gerencia a execuo destas
threads.
7.2 Controle de finalizao das macrotarefas e dos macroblocos

O controle da execuo de uma macrotarefa ou de um macrobloco uma
atividade que envolve os executores, os coordenadores escravos e o coordenador
mestre.
H um fluxo para o controle da execuo de uma macrotarefa ou de um
macrobloco que estejam no escopo da funo main do programa do usurio, e h
um fluxo para o controle da execuo de uma macrotarefa/macrobloco que esteja no
escopo de um macrobloco. No primeiro caso, o escalonamento realizado pelo
executor mestre, e no segundo caso, pelo executor escravo.
Ao final da execuo de uma macrotarefa ou de um macrobloco, vrias
estruturas de controle devem ser atualizadas para que a execuo do programa
possa prosseguir normalmente.
Para realizar a atualizao das estruturas de controle, no primeiro fluxo, devese executar o seguinte protocolo de comunicao entre os escravos e o mestre:
O executor escravo indica ao coordenador escravo do seu n que

terminou de executar a macrotarefa ou o macrobloco (item 1 da Figura
7.2) e a seguir pode retirar outras macrotarefas/macroblocos da fila de
execuo;
O coordenador repassa a mensagem ao coordenador do n mestre (item

2 da Figura 7.2);
103
O coordenador mestre fica aguardando que todos os executores enviem a

mensagem indicando o trmino da tarefa ou do bloco. A cada mensagem
recebida ele atualiza as estruturas de controle que mantm informaes
sobre a carga corrente do sistema (item 3 da Figura 7.2). As estruturas
sobre a carga do sistema devem estar sempre atualizadas para que o
escalonador possa trabalhar corretamente;
Aps todos os executores terem finalizado a execuo da macrotarefa ou

do macrobloco, e o coordenador mestre ter recebido todas as mensagens
indicando o trmino da macrotarefa ou do macrobloco, este retirado da
tabela de macrotarefas e macroblocos. Se os seus executores estiverem
presos em um ponto de sincronizao esperando que todos terminem a
execuo da macrotarefa ou do macrobloco, eles so liberados para
prosseguir sua execuo.
A Figura 7.2 mostra a troca de mensagens realizadas no primeiro fluxo para o

controle de execuo das macrotarefas no sistema.
Figura 7.2 Primeiro fluxo para o controle do trmino de uma tarefa ou bloco
104
Para o segundo fluxo, ocorre o seguinte protocolo de comunicao:
O executor escravo indica ao coordenador escravo do seu n que

terminou de executar a macrotarefa/macrobloco (item 1 da Figura 7.3).
Com
esta
informao,
executor
pode
retirar
outras
macrotarefas/macroblocos da fila de execuo;
O coordenador repassa a mensagem ao coordenador do n escravo, pai

da macrotarefa/macrobloco, que fez o seu disparo (item 2 da Figura 7.3);
O coordenador escravo que gerencia a macrotarefa/macrobloco fica

aguardando que todos os executores enviem a mensagem indicando o
seu trmino. A cada mensagem recebida ele atualiza as estruturas que
controlam a macrotarefa/macrobloco (item 3 da Figura 7.3);
Aps todos os executores terem finalizado a sua execuo, o coordenador

escravo que gerencia a macrotarefa/macrobloco envia uma mensagem
para o coordenador mestre informando que a macrotarefa/macrobloco foi
finalizada (item 4 da Figura 7.3), retirando-a da tabela;
O coordenador mestre atualiza a sua estrutura de controle (item 5 da

Figura 7.3);
A Figura 7.3 mostra a troca de mensagens realizadas no segundo fluxo para

o controle de execuo das macrotarefas/macroblocos no sistema.
105
Figura 7.3 Segundo fluxo para o controle do trmino de uma macrotarefa ou

macrobloco
7.3 Buffer
No CPAR-Grid, buffers foram utilizados para evitar que ocorresse uma
sobrecarga no sistema com o envio de mensagens de atualizao. Pois, se a cada
atualizao de uma varivel compartilhada fosse enviada uma mensagem para os
demais ns, o tempo gasto com a atualizao das informaes seria muito grande.
Com a utilizao dos buffers, as atualizaes so enviadas somente quando
houver a necessidade de disponibilizar estes valores aos outros ns. Um
detalhamento sobre as atualizaes de variveis apresentado na seo 7.4. Cada
buffer uma rea de memria compartilhada entre o executor e o emissor de cada
n, e possui um papel importante para a atualizao das variveis no sistema.
Quando um executor atualiza uma varivel compartilhada do sistema, ele
escreve o valor na varivel mantida em memria local, e tambm armazena estas
informaes no buffer de armazenamento. No momento apropriado, o emissor
empacotar o buffer e o transmitir para todos os ns que j tiverem utilizado esta
106
varivel. A Figura 7.4 mostra os locais de armazenamento desta informao, no qual

a varivel compartilhada X atualizada com o valor 20.
Figura 7.4 Regio que compartilha o dado entre o emissor e o executor
Os coordenadores recebem a mensagem de atualizao e se encarregam de

atualizar a posio de memria, calculada atravs das informaes constantes na
mensagem e na tabela de variveis compartilhadas. Na Figura 7.5 observa-se que
qualquer escrita realizada pelo coordenador visvel para o(s) executor(es) de um
n, pois trata-se de uma rea compartilhada por ambos.
Figura 7.5 Escrita pelo coordenador na rea compartilhada com o executor
A estratgia de estrutura de buffer definida no trabalho de Craveiro [9] foi

utilizada neste trabalho. Os buffers so vetores com 4 dimenses, sendo estas
descritas a seguir:
Dimenso1: esta dimenso diz respeito ao escopo da varivel. Se ela

local a alguma macrotarefa / macrobloco ou global.
107
Dimenso 2: especifica se a atualizao deve ser central, somente para o

coordenador mestre ou pai da macrotarefa/macrobloco, ou total, para
todos os ns que esto no escopo da varivel. Caso ela seja total, a
escrita de uma varivel compartilhada deve ser propagada para todos os
ns aos quais foi atribuda a execuo da macrotarefa / macrobloco na
qual foi declarada. J se for central, apenas um n ir centralizar o
resultado da computao. Com esta estratgia, pretende-se um aumento
no desempenho devido diminuio do trfego de mensagem.
Na estratgia central, a atualizao de uma varivel compartilhada global
enviada somente para o n em que reside a execuo da funo
principal do programa CPAR (coordenador). Caso a varivel seja local a
alguma macrotarefa, sua atualizao propagada somente para o n em
que reside o executor pai da macrotarefa ou macrobloco em questo.
Dimenso 3: esta dimenso trata do tipo da varivel (inteiro, caractere, e

double). Cada tipo de dado tem um buffer especfico, pois o seu tamanho
diferente. Com isso, o tratamento deste tipo de informao deve ser
diferenciado.
Dimenso 4: esta dimenso identifica o buffer que est sendo utilizado

para armazenamento dos dados, no momento. Esta dimenso
necessria porque h um rodzio de buffers para que quando o emissor
estiver empacotando e enviando um buffer, o executor no necessite
parar a sua execuo e esperar pela liberao do espao de
armazenamento. O executor prossegue sobre um segundo conjunto
disponibilizado pela implementao do sistema de chaveamento de
buffers de atualizao.
Considerando as dimenses do buffer, o formato final do envio de uma

atualizao para o buffer inclui os seguintes itens: manipulador da varivel
(identificao da varivel no sistema), escopo, tipo da distribuio, tipo bsico,
informaes para o clculo do endereo da varivel (deslocamento) e o valor atual
da varivel.
O acesso ao buffer realizado pelo(s) executor(es) e pelo emissor de um n.
Devido ao seu compartilhamento, necessria a utilizao de um mecanismo que
controle o seu acesso. A estratgia para o controle de acesso semelhante ao
108
problema do produtor-consumidor [61], no qual o executor funciona como um

produtor, e o emissor como um consumidor. Enquanto o executor est produzindo, o
emissor fica suspenso. No momento que o executor acabar de produzir todos os
dados, ele ativa o emissor para que ele consuma os dados presentes no buffer.
Enquanto os dados esto sendo enviados, nada pode ser escrito no buffer. Aps
esta etapa, o buffer liberado para a escrita, e o emissor torna-se novamente
suspenso at que haja mais dados a serem enviados.
A vantagem deste modelo que o executor responsvel apenas pela
execuo das macrotarefas e dos macroblocos, ficando a cargo do emissor o
controle do fluxo dos dados entre os ns.
7.4 Atualizao das variveis compartilhadas

As variveis compartilhadas podem ser utilizadas na funo principal do
programa, dentro de macrotarefas, microtarefas, blocos paralelos e macroblocos.
Para otimizar a quantidade de mensagens trocadas para a atualizao das variveis
compartilhadas, as mensagens so enviadas somente nas seguintes situaes:
No final de uma seo crtica definida pelos comandos lock e unlock do

semforo.
No final de uma microtarefa (forall ou parbegin).
As mensagens com a atualizao das variveis compartilhadas so enviadas

nestas duas situaes. Assim que uma seo crtica finalizada, o executor notifica
o seu emissor com as variveis que precisam ser enviadas. O mesmo ocorre no final
de uma microtarefa. A Figura 7.6 ilustra os dois pontos de sincronizao existentes
no CPAR-Grid. Alm destas duas situaes, a atualizao das variveis
compartilhadas ocorre quando o buffer que armazena as atualizaes estiver cheio.
Neste momento, o emissor faz o envio das atualizaes.
As variveis compartilhadas de uma aplicao esto na sua rea de memria
compartilhada distribuda e a estratgia de atualizao segue o modelo de
consistncia relaxada, explicado na seo 2.2.2.
109
Figura 7.6 Pontos de sincronizao do CPAR-Grid
A estratgia para atualizao das variveis compartilhadas utilizada no

CPAR-Grid faz a atualizao das variveis somente nos processos que j a
utilizaram. Os processos que nunca utilizaram a varivel, no recebem a sua
atualizao. Porm, para manter a consistncia do ambiente, sempre que um
processo for acessar uma varivel compartilhada pela primeira vez, ele ter que se
comunicar com o pai da macrotarefa/macrobloco ou com o coordenador mestre para
receber o valor atual da varivel.
Esta estratgia diminui a troca de mensagens, pois somente quem j utilizou
a varivel, receber a atualizao. A notificao dos processos que j utilizaram uma
varivel compartilhada feita pelo pai da macrotarefa/macrobloco se a varivel for
local, ou pelo coordenador mestre se a varivel for global.
No primeiro acesso a uma varivel compartilhada, o executor informa o
emissor (passo 1 da Figura 7.7) que o primeiro acesso e pede para ele entrar em
contato com o pai da macrotarefa/macrobloco ou com o coordenador mestre. O
emissor envia uma mensagem solicitando o valor atual desta varivel (passo 2 da
Figura 7.7). O coordenador mestre ou pai da macrotarefa/macrobloco envia o valor
atual e todos os ns que j utilizaram esta varivel para o coordenador do n (passo
3 da Figura 7.7). Posteriormente, ele tambm envia uma mensagem para os demais
110
coordenadores que utilizam esta varivel, informando o identificador do novo n que

iniciou a utilizao da varivel compartilhada em questo (passo 4 da Figura 7.7).
Na Figura 7.7, o n 1 o pai da tarefa, sendo que ela executada pelos ns
1, 2, 3 e 4. A varivel compartilhada local a esta tarefa, na qual os ns 1, 2 e 4 j a
utilizaram, e o n 3 est acessando pela primeira vez.
Figura 7.7 Primeiro acesso a uma varivel compartilhada
A Figura 7.8 mostra o funcionamento da atualizao das variveis

compartilhadas. O executor notifica o emissor do seu n (item 1 da Figura 7.8) que a
rea compartilhada est cheia ou que atingiu-se um ponto de sincronizao. O
emissor empacota e envia a mensagem para o(s) coordenador(es) do(s) n(s)
correspondente(s) (item 2 da Figura 7.8). O coordenador do destinatrio recebe a
mensagem e atualiza os dados na sua tabela de variveis compartilhadas (item 3 da
Figura 7.8).
111
Figura 7.8 Atualizao das variveis compartilhadas
Para o emissor saber quais so os ns que precisam receber a mensagem de

atualizao de uma varivel compartilhada, h uma tabela que indica todos os ns
que j utilizaram uma varivel compartilhada e a que escopo ela pertence. Ela uma
estrutura compartilhada entre o coordenador e o emissor do mesmo n. Sempre que
o emissor precisar enviar uma mensagem de atualizao, ele verifica nesta tabela os
ns que precisam receber a mensagem.
7.5 Estratgia de escalonamento

O escalonador do ambiente CPAR-Grid chamado sempre que um
macrobloco ou uma macrotarefa forem executados. Ele o responsvel por escolher
o(s) n(s) de execuo dos macroblocos ou macrotarefas. Alm disso, h uma
estratgia de distribuio das iteraes para a execuo das microtarefas (forall e
parbegin).
O escalonamento correto das macrotarefas e dos macroblocos de
fundamental importncia para a obteno de alto desempenho. O algoritmo faz um
escalonamento para os macroblocos, outro para as macrotarefas e outro para as
microtarefas. As sees, a seguir, apresentam o seu funcionamento.
112
7.5.1 Escalonamento dos macroblocos

A finalidade da utilizao de um macrobloco que ele tenha pouca
dependncia de dados com o restante da aplicao. Ou seja, um macrobloco deve
ser uma poro independente de cdigo.
Quando ocorre uma chamada para a execuo de um macrobloco, o
processo que fizer a chamada ser o responsvel pela sua submisso e seu
gerenciamento. Isso ocorre, pois um macrobloco pode ser chamado no escopo da
funo principal (main) do programa, ou no escopo de outros macroblocos. Caso ele
seja chamado pelo main, o coordenador mestre gerenciar a sua execuo. Caso
contrrio, o coordenador do n escravo a gerenciar.
A estratgia utilizada para escalonar macroblocos de buscar ns que
estejam ociosos ou com pouca carga de processamento, e que estejam em
domnios distintos do n que est realizando o seu escalonamento. Isso faz com que
um trecho de cdigo independente seja executado em um domnio distinto, fazendo
com que a quantidade de mensagens trocadas entre os domnios seja pequena, j
que h pouca dependncia de dados entre um bloco e o restante da aplicao. A
Figura 7.9 mostra o fluxograma da estratgia de escalonamento de um macrobloco.
Neste fluxograma, pode-se visualizar que caso haja domnios ociosos, o
escalonador escolhe o domnio ocioso que tiver a maior quantidade de
processadores livres. Caso no haja domnios ociosos, o escalonador verificar em
todos os domnios qual tem a maior quantidade de processadores livres e o
escolher. Dentro do domnio escolhido, o n escolhido para processar o
macrobloco ser aquele que tiver a maior quantidade de processadores livres.
113
Figura 7.9 Fluxograma da estratgia de escalonamento dos macroblocos
Como a entidade que realiza o escalonamento est somente no n mestre,

conforme foi explicado na seo 6.4.7, caso o macrobloco seja criado no escopo de
outro macrobloco, o coordenador do n escravo que fez a criao do macrobloco ir
enviar uma mensagem ao coordenador do n mestre solicitando o escalonamento
de um macrobloco. A mensagem contm apenas a identificao do macrobloco que
deve ser escalonado. O coordenador mestre recebe a solicitao e a transmite para
o escalonador. Assim que o escalonador selecionar o n para executar o
macrobloco, o coordenador mestre informado da escolha, enviando esta
informao ao coordenador escravo que far o gerenciamento do macrobloco. O
coordenador escravo verifica o n selecionado e envia uma mensagem ao
coordenador escravo do n selecionado, informando que ele executar o
macrobloco em questo.
A Figura 7.10 ilustra a troca de mensagens realizada para o escalonamento
de um macrobloco sendo chamado no escopo de outro macrobloco. A Figura 7.10
mostra um ambiente composto por trs domnios, no qual o n mestre est no
domnio 1. No momento, com exceo do n escravo 3 que est executando um
macrobloco, os demais ns escravos esto ociosos. Durante a execuo de um
macrobloco pelo n escravo 3, h uma chamada para a execuo de um
macrobloco. O n escravo 3 envia uma mensagem para o n mestre solicitando o
escalonamento deste macrobloco. Como o n mestre e o n escravo 3 esto em
domnios distintos, a mensagem deve passar pelo servio de mensagem de cada
114
domnio, sendo que ele ser o responsvel pelo encaminhamento das mensagens
entre os domnios.
Figura 7.10 Mensagens enviadas para o escalonamento de um macrobloco
Desta forma, o envio da mensagem do n escravo 3 para o n mestre

propagado em 3 mensagens: uma mensagem do n escravo 3 para o servio de
mensagem do seu domnio (instante 1 da Figura 7.10), uma mensagem entre os
servios de mensagem dos respectivos domnios (instante 2 da Figura 7.10), e uma
mensagem do servio de mensagem do domnio do n mestre para o n mestre
(instante 3 da Figura 7.10).
O n mestre realiza o escalonamento do bloco e envia o local selecionado, no
caso o n escravo 5, para o n escravo 3. Esta mensagem tambm propagada em
3 mensagens, conforme pode ser visualizado nos instantes 4, 5 e 6 da Figura 7.10.
O n escravo 3 envia a mensagem para o n escravo 5 informando que ele deve
executar o bloco em questo. Esta mensagem tambm propagada em 3
mensagens, sendo visualizada nos instantes 7, 8 e 9 da Figura 7.10.
Esta estratgia de escalonamento de macroblocos gera dois teros de
mensagens internas e um tero de mensagem externa. As mensagens internas so
115
enviadas entre ns do mesmo domnio ou entre um n e o seu servio de

mensagem. As mensagens externas so enviadas entre servios de mensagens de
domnios distintos. Neste exemplo da Figura 7.10, os instantes 1, 3, 4, 6, 7 e 9 so
mensagens internas, e os instantes 2, 5 e 8 so mensagens externas. Esta
proporo de dois teros de mensagens internas e um tero de mensagens internas
sempre ocorrer neste contexto, j que o escalonamento de macroblocos, mostrado
na Figura 7.10, utiliza somente comunicao entre ns de domnios distintos e para
a comunicao entre eles sempre h duas mensagens internas e uma mensagem
externa.
Caso o macrobloco seja instanciado no escopo do main de um programa,
como o main executado pelo n mestre, o prprio n faz o escalonamento e envia
uma mensagem para o n escravo selecionado para executar o bloco que foi
instanciado no seu escopo. Desta forma, ocorrer o envio de duas mensagens
internas e uma mensagem externa.
7.5.2 Escalonamento das macrotarefas

Uma macrotarefa representa uma sequncia de instrues sequenciais e/ou
paralelas, que geralmente possui certa dependncia de dados com o escopo em que
foi criada, podendo estar no escopo de um macrobloco ou do bloco principal.
Portanto, a estratgia de escalonamento de macrotarefas deve ser diferente da
estratgia utilizada no escalonamento dos macroblocos.
Na estratgia adotada, independente da macrotarefa ser chamada no escopo
do main, ou no escopo de um macrobloco, o n em que foi feita a sua chamada,
ser o responsvel pela sua submisso e gerenciamento. Caso a macrotarefa seja
chamada no main, o n mestre o responsvel. Caso contrrio, a responsabilidade
do n escravo que executa o macrobloco que fez a instanciao da macrotarefa.
A estratgia adotada para escalonar macrotarefas buscar ns que estejam
ociosos ou com pouca carga de processamento, e que estejam no mesmo domnio
do n que fez a chamada da macrotarefa. Neste contexto, ainda h a prioridade da
escolha por ns que sejam multiprocessadores, pois isso minimiza a troca de
mensagens, j que eles compartilham a memria.
Caso no seja possvel alocar todas as instncias (processadores que
executaro uma macrotarefa) de uma macrotarefa em um n multiprocessador que
116
esteja no mesmo domnio, o escalonador buscar por ns monoprocessadores, mas

que estejam no mesmo domnio. Se isso tambm no for possvel, o escalonador
alocar algumas instncias em outro domnio. Mas isso ocorrer somente na
impossibilidade da alocao de todas as instncias em um nico domnio. A Figura
7.11 mostra o fluxograma da estratgia de escalonamento de uma macrotarefa.
Figura 7.11 Fluxograma da estratgia de escalonamento das macrotarefas
Neste fluxograma, pode-se visualizar que a primeira opo de alocao so

os ns que esto no mesmo domnio do n que fez a chamada da macrotarefa.
Caso no seja possvel alocar todas as instncias da macrotarefa no mesmo
domnio, o escalonador aloca todas as instncias que conseguir no domnio em
questo. Aps esta alocao, o escalonar verifica se h algum domnio que consiga
alocar as instncias restantes. Caso haja, ele verifica qual o domnio que tem a
menor quantidade de processadores livres e faz a alocao neste domnio. Esta
estratgia realizada para deixar disponveis os domnios que possuem mais
processadores livres, j que eles so timos candidatos a executar os macroblocos
que forem instanciados durante a execuo da aplicao.
117
Caso no haja um domnio que consiga alocar todas as instncias restantes

da macrotarefa, o escalonador verifica o domnio que consegue alocar mais
instncias e realiza a alocao. At que todas as instncias sejam alocadas, o
escalonador repete este processo, verificando um domnio que consiga alocar as
instncias restantes.
Para ilustrar a troca de mensagens realizada para o escalonamento de uma
macrotarefa, a Figura 7.12 mostra um ambiente composto por dois domnios, no
qual o n mestre est no domnio 1. No momento, todos os ns escravos esto
ociosos, com exceo do n escravo 3 que est executando um macrobloco. Vale
ressaltar que todos os ns escravos, no ambiente ilustrado pela Figura 7.12, so
monoprocessadores. Durante a execuo deste bloco h uma chamada para
execuo de uma macrotarefa com duas instncias. O n escravo 3 envia uma
mensagem para o n mestre solicitando o escalonamento desta macrotarefa
(instantes 1, 2 e 3 da Figura 7.12). A mensagem contm a identificao da
macrotarefa e a quantidade de instncias necessrias para a sua execuo. O n
mestre realiza o escalonamento da macrotarefa e seleciona os ns que a
executaro. De acordo com a estratgia de escalonamento, os ns escravos 4 e 5
sero selecionados para a execuo das instncias da tarefa.
Aps a escolha dos ns para a execuo da macrotarefa, o n mestre envia
estas informaes para o n escravo 3 (instantes 4, 5 e 6 da Figura 7.12). Os ns
escravos 4 e 5 recebem uma mensagem do n escravo 3, informando que eles
executaro a tarefa (instantes 7 e 8 da Figura 7.12).
118
Figura 7.12 Mensagens enviadas para o escalonamento de uma macrotarefa
Para o escalonamento da macrotarefa, ilustrado na Figura 7.12, os instantes

1, 3, 4, 6, 7 e 8 so mensagens internas, e os instantes 2 e 5 so mensagens
externas. Se o escalonador alocar as instncias da macrotarefa no mesmo domnio
do n escravo que fez a sua solicitao, haver apenas duas mensagens externas.
As outras mensagens sero internas. Desta forma, o tempo gasto para a troca de
mensagens minimizado, j que a estratgia de escalonamento minimiza a
distncia entre os ns que se comunicam, diminuindo a quantidade de mensagens
externas.
Caso a macrotarefa seja instanciada no escopo do main de um programa,
como o main executado pelo n mestre, o prprio n faz o escalonamento e envia
uma mensagem para os ns escravos selecionados para executar a tarefa. Desta
forma, ocorrer somente o envio de mensagens para os ns selecionados para
executar a tarefa.
119
7.5.3 Escalonamento das microtarefas

As microtarefas so a parte paralela da macrotarefa e a sua execuo pode
ser realizada atravs dos comandos forall ou parbegin. As iteraes das
microtarefas so escalonadas de maneiras distintas. No forall, h duas estratgias
de escalonamento para serem utilizadas na distribuio dos blocos de execuo,
sendo elas:
Escalonamento esttico: neste caso, a quantidade de iteraes a ser

executada por executor igual a N/p, onde N a quantidade de loops do
forall e p a quantidade de executores.
Escalonamento dinmico: no incio atribu-se uma quantidade k de

iteraes por executor. medida que os executores terminam de
processar o seu bloco de iteraes, eles verificam se h mais iteraes a
serem executadas. Caso haja, outras k iteraes so atribudas ao
executor.
No parbegin, cada trecho escalonado para um executor, sendo que se

houverem mais executores do que trechos, os executores de rank maior no so
executados. Se houver mais trechos do que executores, os primeiros n trechos so
atribudos aos n executores. medida que os executores finalizam a execuo do
seu trecho, o executor principal informa se h mais algum trecho a ser executado. E
assim sucessivamente, at que todos os trechos sejam executados.

O modelo do CPAR-Grid adotou estratgias de escalonamento, de
comunicao e de atualizao das variveis compartilhadas para minimizar a
quantidade de mensagens enviadas para o controle do ambiente, alm de minimizar
a distncia entre os processos que se comunicam. Grande parte das mensagens
enviadas relacionada atualizao das variveis compartilhadas e ao
gerenciamento da execuo da aplicao.
O intuito foi otimizar a comunicao e buscar a melhor utilizao das
caractersticas presentes das grades computacionais. O objetivo que as
120
estratgias utilizadas faam com que as aplicaes paralelas tenham um bom

desempenho no ambiente proposto.
Os elementos de construo utilizados no modelo de programao possuem
uma hierarquia de funcionamento que favorece a sua utilizao em grades
computacionais. Eles possuem desde granularidade fina, como as microtarefas, at
granularidade grossa, como os macroblocos Isso faz com que ela se adapte a um
ambiente heterogneo e hierrquico como o ambiente utilizado neste trabalho.
121
8. TESTES E ANLISE DOS RECURSOS OFERECIDOS PELO

CPAR-GRID
Planejou-se um conjunto de testes com o intuito de verificar o funcionamento
correto das funcionalidades oferecidas e o desempenho da execuo das aplicaes
paralelas no CPAR-Grid.
Para verificar as funcionalidades oferecidas, foi realizado o teste de uma
aplicao que utiliza todas as funcionalidades oferecidas no CPAR-Grid, sendo elas:
utilizao dos elementos de construo da linguagem CPAR (macroblocos,
macrotarefas, microtarefas e blocos paralelos); utilizao e atualizao de variveis
compartilhadas globais, locais a um macrobloco e locais a uma macrotarefa; e
escalonamento de macrotarefas e de macroblocos de acordo com os ns de
processamento disponveis na grade computacional. O objetivo desta anlise
verificar se todas as estratgias implementadas, neste trabalho, para as
funcionalidades do CPAR-Grid funcionam corretamente.
Alm do teste de funcionalidade, tambm foram realizados testes para
analisar o desempenho das aplicaes CPAR no ambiente CPAR-Grid. O tempo
total de execuo a soma do tempo de processamento e do tempo gasto em
comunicao. Para uma aplicao paralela ter um bom desempenho, necessrio
que o tempo de comunicao seja pequeno. Desta forma, os objetivos das
estratgias implementadas no CPAR-Grid so diminuir a troca de mensagens
durante a execuo de uma aplicao e minimizar a distncia entre os ns de
processamento que se comunicam, atravs do escalonamento adequado dos ns.
As estratgias implementadas no ambiente CPAR-Grid foram as seguintes:
Atualizao das variveis compartilhadas de acordo com a sua utilizao:

as variveis compartilhadas so dependentes do escopo em que foram
declaradas e quando o valor de uma varivel compartilhada alterado, a
estratgia de atualizao das variveis compartilhadas somente envia a
mensagem de atualizao para o coordenador que gerencia o escopo da
varivel e para os ns que j a utilizaram pelo menos uma vez. Isso faz
com que os ns que nunca utilizaram esta varivel no recebam
mensagens de atualizao. Vale ressaltar que somente os ns que esto
122
executando uma macrotarefa ou um macrobloco que esteja no escopo

desta varivel compartilhada podem utiliz-la. Esta estratgia tende a
minimizar a quantidade de mensagens enviadas.
Escalonamento de macrotarefas e macroblocos visando a melhor

explorao da localizao e da capacidade de processamento dos ns
que compem a grade computacional: a estratgia de escalonamento dos
macroblocos faz a sua alocao em domnios distintos e que estejam
ociosos com o objetivo de colocar um trecho de cdigo, geralmente,
independente do restante da aplicao em outro domnio para que ele
utilize os ns de processamento deste domnio para executar as suas
macrotarefas. Com relao macrotarefa, o escalonador faz a sua
alocao no mesmo domnio de quem a criou, pois ela dependente do
seu escopo e provavelmente ir trocar mensagens com as suas
instncias e com o n que gerencia o seu escopo. Esta estratgia de
escalonamento tem o objetivo de minimizar a quantidade de mensagens
trocadas entre ns de domnios distintos, explorando a localizao dos
ns de processamento e fazendo com que as mensagens trocadas sejam
entre ns prximos geograficamente e no mesmo domnio.
Minimizao
das
mensagens
enviadas
para
gerenciamento
coordenao da execuo de uma aplicao paralela: em uma grade

computacional, h a necessidade de troca de mensagens para o
gerenciamento de uma aplicao paralela, sendo que o tempo gasto
nesta comunicao contabilizado no tempo total de execuo da
aplicao. A estratgia utilizada para o gerenciamento da aplicao foi
centralizar o escalonamento no coordenador mestre, pois caso todos os
coordenadores pudessem realizar o escalonamento, a quantidade de
mensagens necessrias para que todos os coordenadores tivessem as
informaes atualizadas do ambiente seria muito alta. Dessa forma, as
mensagens so trocadas somente para a solicitao de escalonamento
de uma macrotarefa ou de um macrobloco. Alm disso, a atualizao das
variveis ocorre somente quando h um mecanismo de sincronizao ou
quando o buffer de um n est cheio. Quando h a necessidade do envio
de duas ou mais mensagens pequenas em sequncia, para o mesmo n,
123
elas so empacotadas em uma nica mensagem, diminuindo a

quantidade de mensagens trafegadas na rede.
O algoritmo que efetua o clculo da mdia da soma das matrizes

multiplicadas foi utilizado para avaliar o desempenho do sistema CPAR-Grid. As
consideraes sobre as verses dos programas utilizados nos testes, bem como a
configurao do ambiente de grades computacionais e a anlise dos resultados
obtidos so descritas neste capitulo.
8.1 Testes escolhidos

Foi utilizado um algoritmo sinttico para avaliar as funcionalidades oferecidas
pelo ambiente CPAR-Grid. O algoritmo do clculo da mdia da soma das matrizes
multiplicadas foi utilizado para avaliar: o mecanismo de atualizao das variveis
compartilhadas de acordo com o seu escopo (global, bloco, tarefa); o impacto da
comunicao entre os ns de processamento; e a estratgia de escalonamento das
tarefas e dos blocos de acordo com a quantidade de ncleos de processamento
disponveis em cada domnio. Este algoritmo foi implementado com quatro verses
diferentes, sendo elas: verso sequencial, verso com variveis locais, verso
completa e verso somente com macrotarefas. Estas verses foram utilizadas para
analisar:
Impacto da comunicao no gerenciamento e coordenao de uma

aplicao paralela: foi realizada a comparao da verso sequencial com
a verso com variveis locais. A verso sequencial realiza toda a
execuo em um ncleo de processamento, sem realizar troca de
mensagens. A verso com variveis locais realiza todo o processamento
de maneira distribuda, criando macrotarefas e macroblocos, porm no
utiliza variveis compartilhadas. Com isso, as mensagens que esta verso
envia so somente para gerenciar a execuo da aplicao. A
comparao entre as duas verses verificar o impacto das mensagens
enviadas no desempenho da aplicao.
Escalonamento
comparao
da
de
macrotarefas
verso
completa
macroblocos:
com
verso
foi
realizada
somente
com
124
macrotarefas. A verso completa utiliza os elementos de construo da

linguagem da melhor maneira, explorando a hierarquia destes elementos.
A verso somente com macrotarefas no utiliza macroblocos e todas as
macrotarefas so criadas no escopo do bloco principal. A comparao
entre as duas verses mostra o impacto do escalonador do ambiente. Na
verso completa ele conseguir escalonar os ns para executar os
macroblocos e as macrotarefas hierarquicamente, se beneficiando das
caractersticas das grades computacionais. Na verso somente com
macrotarefas, ele escalonar todas as macrotarefas como se elas fossem
dependentes do bloco principal, o que no uma verdade. Com isso, a
tendncia que a comunicao seja mais intensa na verso somente
com macrotarefas.
Atualizao das variveis compartilhadas: foi realizada a comparao da

quantidade de mensagens enviadas na verso completa e na verso
somente com macrotarefas. O objetivo verificar se no momento que
uma varivel compartilhada alterada, a estratgia de atualizar somente
os ns que j utilizaram esta varivel faz com que a quantidade de
mensagens enviadas seja minimizada.
Anlise de desempenho: foi realizada a comparao da verso sequencial

com a verso completa. O objetivo verificar se o desempenho da verso
completa, que explora a estrutura hierrquica das grades computacionais
de maneira correta, consegue um bom desempenho na sua execuo.
As sees a seguir detalham os algoritmos utilizados para os testes de

funcionalidade e de desempenho.
8.1.1 Algoritmo sinttico para o teste de funcionalidade

Este algoritmo utiliza todos os elementos de construo da linguagem CPAR,
alm de possuir variveis compartilhadas globais e locais s macrotarefas e aos
macroblocos. No escopo do bloco principal (main), h a utilizao de trs blocos
paralelos, sendo que os dois primeiros blocos paralelos criam um macrobloco cada
um. O terceiro bloco paralelo cria uma macrotarefa com seis processadores. A
125
Figura 8.1 ilustra a estrutura deste algoritmo sinttico e o cdigo fonte CPAR deste
algoritmo est no Apndice C.1.
Figura 8.1 Estrutura do algoritmo sinttico
O primeiro macrobloco criado faz a instanciao de um novo macrobloco e o

segundo macrobloco criado faz a instanciao de uma macrotarefa com quatro
processadores. O macrobloco criado a partir do outro macrobloco faz a instanciao
de uma macrotarefa com quatro processadores.
Todas as tarefas criadas utilizam microtarefas e variveis compartilhadas. A
primeira macrotarefa criada utiliza somente variveis compartilhadas que foram
declaradas no seu escopo. A segunda macrotarefa utiliza variveis compartilhadas
que foram declaradas no seu escopo e no escopo do macrobloco que a instanciou e
a terceira macrotarefa utiliza variveis compartilhadas globais.
O bloco principal de execuo, aps a criao dos blocos paralelos, espera o
trmino da execuo dos blocos e imprime os valores das variveis compartilhadas
globais.
O objetivo deste algoritmo verificar se todos os elementos de construo da
linguagem foram criados e utilizados corretamente, alm de verificar se as
126
funcionalidades do ambiente CPAR-Grid como o escalonamento e a atualizao das

variveis compartilhadas funcionam corretamente.
8.1.2 Mdia da soma de multiplicaes de matrizes

Este algoritmo efetua o clculo da mdia da soma de matrizes multiplicadas.
A equao 8.1 ilustra a frmula utilizada para o clculo. Todas as matrizes utilizadas
so quadradas e do tipo double. Este algoritmo foi implementado com quatro
verses diferentes.
media = ( (AxB + CxD) + (ExF + GxH) ) / 2

(Equao. 8.1)
Verso sequencial
Esta verso efetua todo o processamento de maneira sequencial, utilizando

apenas um ncleo de processamento. Esta verso utilizada para medir o tempo de
execuo do algoritmo que efetua a mdia da soma das matrizes multiplicadas sem
utilizar
processamento
referncia,
pode-se
paralelo/distribudo.
calcular
ganho
Utilizando-se
de
esta
desempenho
verso
das
como
verses
paralelas/distribudas.
Verso com variveis locais
Esta verso cria dois macroblocos, no qual o primeiro macrobloco efetua a

multiplicao das matrizes AxB e CxD e posteriormente faz a soma destas matrizes
multiplicadas. O segundo macrobloco faz a mesma coisa que o primeiro macrobloco,
porm ele utiliza as matrizes E, F, G e H. Assim que os dois macroblocos finalizam,
o bloco principal calcula a mdia das matrizes que possuem a soma efetuada nos
blocos. A multiplicao e a soma das matrizes so realizadas nas macrotarefas. A
Figura 8.2 ilustra um fluxograma com o funcionamento deste algoritmo utilizando a
verso com variveis locais e a verso completa. O cdigo fonte CPAR desta verso
est no Apndice C.2.1.
127
Figura 8.2 Estrutura do algoritmo das matrizes utilizando a verso com variveis
locais e a verso completa
Cada macrobloco cria duas macrotarefas para efetuar a multiplicao das

matrizes e depois criam uma macrotarefa para efetuar a soma. Nesta verso, todas
as matrizes so variveis locais e no h variveis compartilhadas. O objetivo desta
verso analisar o custo da comunicao para efetuar o controle e o gerenciamento
de uma aplicao paralela que utiliza macroblocos e macrotarefas, excluindo o custo
da utilizao das variveis compartilhadas.
Verso completa
Esta verso semelhante verso com variveis locais. A diferena que

nesta verso h a utilizao das variveis compartilhadas. As matrizes A, B, C, D, E,
F, G e H so variveis compartilhadas no escopo das macrotarefas que as utilizam.
As matrizes que armazenam a multiplicao das matrizes AxB, CxD, ExF e GxH so
variveis compartilhadas no escopo dos macroblocos que as utiliza. O cdigo fonte
CPAR desta verso est no Apndice C.2.2.
As matrizes que efetuam a soma das matrizes multiplicadas e a matriz que
armazena a mdia das matrizes que efetuaram a soma so variveis compartilhadas
128
globais. Desta forma, esta verso utiliza variveis compartilhadas globais, locais
macrotarefa e locais ao macrobloco. O objetivo desta verso analisar o
desempenho de uma aplicao paralela que possui variveis compartilhadas e o
impacto da atualizao das suas variveis, alm de analisar a utilizao de
macroblocos
para
realizar
diviso
do
processamento
entre
domnios
hierarquicamente.
Verso somente com macrotarefas
Esta verso no utiliza macroblocos e todas as macrotarefas so criadas no

escopo do bloco principal. Primeiro so criadas quatro macrotarefas, na qual cada
uma efetua a multiplicao de duas matrizes. Aps o trmino das quatro
macrotarefas, o bloco principal cria duas macrotarefas que efetuam a soma das
matrizes multiplicadas e, por fim, o bloco principal calcula a mdia das matrizes que
efetuaram a soma. Nesta verso, as matrizes A, B, C, D, E, F, G e H so variveis
compartilhadas no escopo das macrotarefas que as utilizam. As demais variveis
compartilhadas, necessrias para a multiplicao, a soma e o clculo da mdia das
matrizes, so globais. A Figura 8.3 ilustra o fluxograma com o funcionamento deste
algoritmo com a verso somente com macrotarefas.
Figura 8.3 Estrutura do algoritmo das matrizes utilizando a verso somente com
macrotarefas
129
Como esta verso no utiliza macroblocos e todas as macrotarefas so

criadas no escopo do bloco principal, grande parte das variveis compartilhadas so
globais, o que aumenta a quantidade de mensagens trocadas para a sua
atualizao. Alm disso, o escalonador do ambiente far a escolha dos ns para
executarem as macrotarefas objetivando que eles estejam prximos, j que todas as
macrotarefas foram criadas no mesmo escopo. Porm, h macrotarefas que so
independentes e poderiam ser escalonadas em outro domnio, facilitando o
escalonamento e diminuindo a quantidade de mensagens enviadas. Caso a
aplicao utilizasse macroblocos, o escalonador faria a escolha mais acertada.
O objetivo desta verso verificar se a utilizao correta dos elementos de
construo da linguagem aumenta o desempenho da aplicao e diminui a
quantidade de mensagens enviadas, j que esta verso no utiliza os elementos da
linguagem da maneira mais eficiente. Alm disso, esta verso objetiva a verificao
se a estratgia de escalonamento eficiente. O cdigo fonte CPAR desta verso
est no Apndice C.2.3.
8.2 Configurao do ambiente de teste

Para a execuo dos testes, foi configurado um ambiente simulado de grades
computacionais, no qual um cluster SGI Altix 1300 XEON composto por seis ns de
processamento foi utilizado para a gerao da grade computacional. Cada n possui
dois processadores Quadi-Core de 2.0 Ghz, 8 Gbytes de memria e 210 Gbytes de
disco. O n de entrada do cluster possui a mesma configurao que os ns de
processamento, com exceo do tamanho do disco que de 1,5 Tbytes. O Sistema
Operacional o Susi 9 64 bits e o ambiente utiliza a infraestrutura de grades
computacionais descrita no captulo 4.
O cluster foi dividido em trs domnios, sendo que cada domnio possui dois
ns de processamento. Este ambiente tem 48 ncleos de processamento
disponveis para a execuo de uma aplicao CPAR.
Como os domnios esto no mesmo cluster, o tempo gasto para a troca de
mensagens entre eles pequeno, fato este que no ocorre em um ambiente real de
grades computacionais. Desta forma, foi adicionado um tempo extra para a troca de
mensagens entre processos de domnios distintos. Para estimar um tempo real para
130
a comunicao entre domnios distintos, foi utilizado o tempo mdio do comando

ping entre trs universidades: USP (Universidade de So Paulo), UFABC
(Universidade Federal do ABC) e UNESP (Universidade do Estado de So Paulo),
no qual cada universidade foi considerada como um domnio.
Na execuo do comando ping, os dez primeiros tempos de comunicao
obtidos foram utilizados para o clculo do valor mdio do tempo de comunicao. A
Tabela 8.1 mostra o tempo mdio e o desvio padro para a comunicao entre as
universidades e a Figura 8.4 ilustra um grafo com o tempo mdio para a
comunicao entre elas. Nesta figura, os domnios so representados pelos vrtices
e as arestas representam o tempo de comunicao.
Tabela 8.1 Tempo de comunicao entre os domnios (universidades)
Universidades
Tempo
Desvio
Origem
Destino
mdio (ms)
padro
USP
UNESP
2,29
0,10
UNESP
USP
2,29
0,10
USP
UFABC
2,08
0,24
UFABC
USP
2,08
0,24
UNESP
UFABC
6,18
0,93
UFABC
UNESP
6,18
0,93
Figura 8.4 Grafo com o tempo de comunicao entre os domnios (universidades)
131
8.3 Anlise do CPAR-Grid

A anlise da funcionalidade das estratgias implementadas neste trabalho e
do comportamento do CPAR-Grid com relao atualizao das variveis
compartilhadas, sobrecarga de mensagens impostas para a coordenao da
execuo do programa do usurio e ao escalonamento de macrotarefas e
macroblocos foi realizada baseando-se nos resultados dos testes. As prximas
sees discutem os resultados obtidos.
8.3.1 Funcionalidade das estratgias implementadas

Para verificar o funcionamento das estratgias implementadas no CPAR-Grid,
utilizou-se o algoritmo sinttico descrito na seo 8.1.1. Neste algoritmo, h variveis
compartilhadas globais e locais a macroblocos e macrotarefas. Durante a execuo
da aplicao, verificou-se que as variveis foram declaradas corretamente,
respeitando o seu escopo. Alm disso, a atualizao das variveis compartilhadas
ocorreu conforme a sua utilizao, ou seja, somente os processos que j a
utilizaram, receberam a sua atualizao. Desta forma, no foi enviada mensagens
para processos que nunca utilizaram a varivel compartilhada que estava sendo
atualizada no momento. Esta estratgia visa minimizar a quantidade de mensagens
trocadas durante a execuo da aplicao do usurio.
O algoritmo criou trs macroblocos, sendo que dois macroblocos foram
criados no escopo do bloco principal e um macrobloco foi criado no escopo de outro
macrobloco. Quando um macrobloco criado no bloco principal, o coordenador
mestre faz o escalonamento e envia uma mensagem para o n escolhido para
process-lo. J, quando um macrobloco criado no escopo de outro macrobloco, o
coordenador escravo do macrobloco que solicitou a sua criao envia uma
mensagem para o coordenador mestre pedindo para ele realizar o escalonamento.
O coordenador mestre efetua o escalonamento e envia uma mensagem, com o n
escolhido, para o coordenador escravo do macrobloco solicitante. O coordenador
recebe a mensagem e envia uma mensagem para o n selecionado para a
execuo.
132
Durante a execuo do algoritmo, os macroblocos foram criados corretamente

e o escalonador selecionou domnios que estavam ociosos para a execuo dos
macroblocos, conforme a estratgia de escalonamento utilizada. A troca de
mensagens para o gerenciamento e para a criao dos macroblocos funcionou
corretamente.
O algoritmo criou trs macrotarefas, sendo uma macrotarefa no bloco
principal e duas macrotarefas no escopo dos macroblocos. Quando uma
macrotarefa criada no escopo dos macroblocos, o coordenador escravo do
macrobloco envia uma mensagem para o coordenador mestre informando a
macrotarefa a ser escalonada e quantidade de processadores necessrios. O
coordenador mestre efetua o escalonamento e informa os ns escolhidos para o
coordenador escravo do macrobloco. Este, por sua vez, envia uma mensagem para
os ns escolhidos para executar a macrotarefa, informando que eles sero os
responsveis pela sua execuo. J, quando uma macrotarefa criada no bloco
principal, o coordenador mestre efetua o escalonamento e envia uma mensagem
para os ns selecionados para a execuo.
A troca de mensagens para a criao e gerenciamento das macrotarefas
funcionou corretamente e a escolha dos ns para a execuo das macrotarefas
funcionou de acordo com a estratgia de escalonamento adotada, sempre dando
preferncia para os ns de processamento que estivessem no mesmo domnio dos
ns que solicitaram a sua criao.
Todos os elementos de construo foram utilizados no algoritmo. Os
macroblocos e as macrotarefas foram mencionados nos pargrafos anteriores. Os
blocos paralelos foram utilizados no bloco principal, gerando trs fluxos paralelos no
qual dois deles foram responsveis pela criao de dois macroblocos e o outro bloco
paralelo criou uma macrotarefa. A execuo do bloco paralelo gerou corretamente
os trs fluxos paralelos.
No escopo das macrotarefas foram utilizadas microtarefas e a sua execuo
ocorreu simultaneamente entre todos os processadores da macrotarefa. As variveis
compartilhadas foram utilizadas nos trs nveis possveis: global, no escopo de um
macrobloco e no escopo de uma macrotarefa. A execuo da aplicao mostrou que
as funcionalidades CPAR-Grid esto funcionando conforme a sua estratgia
implementada.
133
8.3.2 Impacto da comunicao na coordenao e gerenciamento de uma

aplicao paralela
Para analisar o impacto da troca de mensagens imposta pelo CPAR-Grid no
gerenciamento e coordenao de uma aplicao paralela, utilizou-se a verso que
faz a mdia da soma da multiplicao de matrizes com variveis locais. Desta forma,
no haver troca de mensagens para a atualizao de variveis compartilhadas e as
mensagens trocadas sero exclusivamente para o gerenciamento da aplicao.
Foram utilizados trs domnios, sendo que o primeiro domnio executou o
bloco principal, o segundo domnio executou um macrobloco e as suas trs
macrotarefas e o terceiro domnio executou o outro macrobloco e as suas trs
macrotarefas Os testes foram realizados com cada macrotarefa sendo executada
por dois, quatro e seis processadores. A Tabela 8.2 mostra e detalha as mensagens
enviadas na execuo deste teste, alm de informar a quantidade de mensagens
internas (mesmo domnio) e externas (domnios distintos) enviadas. A Figura 8.5
mostra um grfico com a quantidade de mensagens internas e externas enviadas de
acordo com a quantidade de processadores para cada macrotarefa.
A coluna Motivo da Tabela 8.2 mostra a finalidade de cada mensagem
enviada, sendo que ela foi numerada de 1 a 11. As finalidades so as seguintes:
1: Iniciao das variveis de controle;
2: Finalizao da execuo da aplicao;
3: Execuo dos macroblocos;
4: Escalonamento das macrotarefas;
5: Execuo das macrotarefas;
6: Finalizao das macrotarefas;
7: Escalonamento das macrotarefas;
8: Finalizao dos macroblocos;
9: Finalizao das macrotarefas;
10: Controle da macrotarefa;
11: Finalizao das macrotarefas e dos macroblocos.
134
Tabela 8.2 Detalhes das mensagens enviadas na verso com variveis locais
Origem
Coordenador
Mestre
Destino
Emissor
Coordenador
Coordenador
Mestre
Escravo
Coordenador
Coordenador
Mestre
Escravo
Coordenador
Coordenador
Mestre
Escravo
Coordenador
Escravo
Emissor
Coordenador
Coordenador
Escravo
Escravo
Coordenador
Coordenador
Escravo
Escravo
Coordenador
Coordenador
Escravo
Mestre
Coordenador
Coordenador
Escravo
Mestre
Coordenador
Coordenador
Escravo
Mestre
Emissor
Emissor
Coordenador
Escravo
Coordenador
Escravo
Motivo
Tarefa: 2
Tarefa: 4
Tarefa: 6
processado
processado
processado
res
res
res
Int
Ext
Int
Ext
Int
Ext
11
11
11
77
77
77
12
12
12
10
12
36
60
11
118
33
142
33
166
33
Quantidade Total de Mensagens
Na Tabela 8.2, a coluna Int significa mensagem interna e Ext significa

mensagem externa. De acordo com a Tabela 8.2, pode-se visualizar que a maioria
135
das mensagens trocadas interna, o que minimiza o tempo gasto na comunicao.

Grande parte das mensagens internas enviada para iniciar as variveis de controle
entre o coordenador e o emissor dos ns de processamento. Entre cada
coordenador e emissor so necessrias 11 mensagens para iniciar todas as
variveis e estruturas de controle.
Figura 8.5 Grfico de mensagens internas e externas para o gerenciamento da

aplicao
O grfico da Figura 8.5 ilustra que a quantidade de mensagens externas

enviadas para o gerenciamento da aplicao do usurio no muda em funo da
quantidade de processadores de cada macrotarefa. Isso ocorre porque as
macrotarefas so executadas no mesmo domnio do macrobloco que realizou a sua
criao.
A quantidade de processadores para cada macrotarefa impacta na
quantidade de mensagens internas enviadas para o controle das macrotarefas. O
restante das mensagens enviadas independente da quantidade de processadores
das macrotarefas.
A Tabela 8.3 ilustra o tempo de processamento (em segundos) desta verso e
da verso sequencial e a Figura 8.6 mostra um grfico com o ganho de desempenho
(speedup) obtido entre a verso com variveis locais e a verso sequencial.
136
Tabela 8.3 Tempo de processamento da verso com variveis locais
Tamanho
da matriz
Tempo
Sequencial
(seg)
Quantidade de processadores para cada macrotarefa

Duas
Quatro
Seis
Tempo
Desvio
Tempo
Desvio
Tempo
Desvio
(seg)
Padro
(seg)
Padro
(seg)
Padro
1000x1000
33,623
4,795
0,101
2,713
0,048
2,251
0,073
1200x1200
57,859
8,232
0,163
4,138
0,098
3,131
0,176
1500x1500
124,015
17,723
0,111
8,773
0,136
6,467
0,175
2000x2000
325,483
45,685
0,267
23,284
0,065
17,537
0,189
Figura 8.6 Grfico de desempenho da verso com variveis locais
Os resultados mostrados na Tabela 8.3 e na Figura 8.6 mostram que as

mensagens enviadas para o controle e gerenciamento da aplicao paralela,
excluindo o uso das variveis compartilhadas, no impactam no desempenho da
aplicao. Os tempos obtidos foram muito bons, j que o desempenho obtido ficou
prximo da quantidade mxima de processadores utilizados para o processamento
das tarefas. Este desempenho obtido era esperado, pois como no h variveis
137
compartilhadas, as mensagens utilizadas so somente para gerenciar a execuo

da aplicao e, com isso, h o envio de poucas mensagens enviadas durante a sua
execuo.
Na verso com dois processadores para cada macrotarefa, as quatro
macrotarefas
que
simultaneamente,
efetuam
utilizando
multiplicao
oito
das
processadores.
matrizes
so
Posteriormente,
executadas
as
duas
macrotarefas que efetuam a soma das matrizes multiplicadas so executadas em

paralelo, utilizando quatro processadores. Finalmente, a mdia das matrizes
somadas executada pelo n mestre e o desempenho obtido ficou em torno de 7,
independente do tamanho da matriz. Este desempenho est muito prximo da
quantidade mxima de processadores utilizados simultaneamente, que neste caso
foram 8.
A verso com quatro processadores para cada macrotarefa obteve o
desempenho de 14, sendo que foi utilizado dezesseis processadores para a
execuo das macrotarefas que efetuam a multiplicao de matrizes e oito
processadores para as macrotarefas que efetuam a soma das matrizes
multiplicadas. Nesta verso, houve um ganho de desempenho quando o tamanho da
matriz aumentou de 1000 para 1200 e depois manteve o desempenho quase
constante nos tamanhos de 1500 e 2000. O desempenho obtido tambm foi prximo
da quantidade mxima de processadores utilizados simultaneamente.
A verso com seis processadores para cada macrotarefa obteve desempenho
mdio de 18,5, utilizando vinte e quatro processadores para a execuo das
macrotarefas que multiplicam as matrizes e doze processadores para as
macrotarefas que efetuam a soma das matrizes. Nesta verso, o desempenho
aumentou medida que o tamanho da matriz aumentou. Somente com o tamanho
da matriz de 2000 que o desempenho diminuiu um pouco, mas nada que
comprometesse a sua eficincia.
8.3.3 Escalonamento de macrotarefas e macroblocos

Para analisar a estratgia de escalonamento das macrotarefas e dos
macroblocos no ambiente CPAR-Grid, foi utilizada a verso completa e a verso
somente com macrotarefas do algoritmo que efetua a mdia da soma das matrizes
multiplicadas, conforme a sua descrio na seo 8.1.2.
138
A verso completa utiliza dois macroblocos, sendo que um macrobloco faz a

soma da multiplicao das matrizes AxB e CxD e o outro macrobloco faz a soma da
multiplicao das matrizes ExF e GxH. A utilizao dos macroblocos facilita o
escalonamento da aplicao, j que o escalonador procura alocar cada macrobloco
em um domnio distinto e as tarefas de um macrobloco so alocadas nos ns de
processamento do seu domnio.
A verso que possui somente macrotarefas no utiliza macroblocos e no
escalonamento das macrotarefas, o escalonador procura alocar todas as
macrotarefas no mesmo domnio do bloco principal da aplicao. O problema que
provavelmente no h ns de processamento disponveis no mesmo domnio para
executar todas as macrotarefas ao mesmo tempo. Com isso, algumas macrotarefas
executaro em outros domnios e alguns processadores de uma macrotarefa estaro
em um domnio e os outros processadores estaro em outro domnio. Isso faz com
que a quantidade de mensagens enviadas, principalmente para atualizao das
variveis compartilhadas, entre domnios distintos seja maior, impactando no tempo
de execuo da aplicao.
A Tabela 8.4 mostra a quantidade de mensagens internas (no mesmo
domnio) e externas (entre domnios distintos) enviadas utilizando as duas verses
da mdia da soma das matrizes multiplicadas. A Figura 8.7 mostra um grfico com
as mensagens internas e externas enviadas neste teste. Vale ressaltar que todas as
macrotarefas so executadas com seis processadores.
Tabela 8.4 Quantidade de mensagens enviadas na mdia da soma das matrizes
multiplicadas
Tamanho da
Matriz
Verso Completa
Verso somente com

Macrotarefas
Internas
Externas
Internas
Externas
1000 x 1000
464
303
288
1062
1200x 1200
578
419
301
1504
1500 x 1500
794
635
340
2332
2000 x 2000
1262
1103
420
4126
139
Figura 8.7 Grfico com a quantidade de mensagens enviadas internas e externas
Conforme pode ser visualizado na tabela 8.4 e na Figura 8.7, a quantidade

total de mensagens enviadas na verso somente com macrotarefas maior do que
a verso completa. Alm disso, a verso somente com macrotarefas possui a
maioria absoluta das suas mensagens enviadas, sendo externas, enquanto a verso
completa possui mais mensagens internas enviadas, do que externas. Isso ocorre
porque a verso completa possui variveis compartilhadas para armazenar as
matrizes multiplicadas no escopo do macrobloco, fazendo com que haja menos
mensagens externas enviadas, j que as tarefas que efetuam a multiplicao esto
no mesmo domnio dos macroblocos que fizeram a sua criao.
Na verso somente com macrotarefas, as variveis compartilhadas que
armazenam as matrizes multiplicadas so globais e, assim, as macrotarefas que so
executadas em domnios diferentes do domnio do bloco principal precisam enviar
mensagens externas para atualizar estas variveis.
Como o tempo de comunicao no envio de uma mensagem externa maior
do que o tempo de uma mensagem interna, o tempo de processamento da verso
somente com macrotarefas maior do que a verso completa. A Figura 8.8 mostra
um grfico com os tempos de execuo, em segundos, das duas verses. O desvio
padro destes tempos variou de 0,11 a 0,20.
140
Figura 8.8 Grfico com o tempo de execuo das verses somente com tarefas e
completa
Os tempos de execuo da Figura 8.8 mostram que o tempo de execuo

da verso completa menor do que a outra verso. Isso mostra que a utilizao
corretamente dos elementos de construo da linguagem CPAR faz com que a
aplicao consiga utilizar, de uma maneira melhor, a estrutura hierrquica das
grades computacionais. A utilizao de macroblocos consegue distribuir a aplicao
em domnios, fazendo com que haja pouca comunicao entre eles.
Alm disso, a utilizao de macroblocos faz com que o escalonador consiga
escolher melhor os locais para executarem as macrotarefas e os macroblocos,
mostrando que a estratgia de escalonamento utilizada para grades computacionais
consegue explorar a sua estrutura hierrquica. Para isso, necessrio que a
aplicao utilize corretamente os elementos de construo existentes na linguagem
CPAR.
8.3.4 Atualizao das variveis compartilhadas

Cada n de processamento possui uma cpia local das variveis
compartilhadas e cada cpia de uma varivel, em um n, ativada somente aps a
sua primeira utilizao. Neste momento, o n em questo informa o n gerenciador
da varivel compartilhada que ele est utilizando-a pela primeira vez. O n
141
gerenciador envia os valores atuais desta varivel e, com isso, o n passar a

receber todas as atualizaes desta varivel compartilhada.
As variveis compartilhadas so atualizadas somente nos ns que j a
utilizaram. Com isso, os ns que esto no escopo da varivel compartilhada, mas
nunca a utilizaram, no recebero as suas atualizaes. O objetivo desta estratgia
minimizar a quantidade de mensagens enviadas durante a execuo de uma
aplicao paralela.
A Tabela 8.4 e a Figura 8.7 mostram a quantidade de mensagens internas e
externas enviadas para a execuo da mdia da soma das matrizes multiplicadas
utilizando a verso completa e a verso somente com macrotarefas.
A verso completa possui variveis compartilhadas globais e no escopo de
macroblocos e macrotarefas, enquanto a verso somente com macrotarefas possui
variveis compartilhadas globais e no escopo da macrotarefa. As atualizaes das
variveis compartilhadas de uma macrotarefa so enviadas para todos os ns que a
executam,
pois a macrotarefa
executada
paralelamente por todos
os
processadores e as variveis compartilhadas so utilizadas para armazenar as

matrizes a serem multiplicadas, sendo que cada processador de uma macrotarefa
inicia uma parte destas matrizes.
As variveis compartilhadas que armazenam as matrizes multiplicadas, na
verso completa so declaradas no escopo de um macrobloco. Com isso, somente
mensagens internas so enviadas para a sua atualizao e as mensagens so
enviadas somente para o n que executa o macrobloco. No caso da verso somente
com macrotarefas, estas variveis compartilhadas so globais e, para a sua
atualizao, as macrotarefas que esto no domnio do bloco principal enviam
mensagens internas para o n que executa o bloco principal. As demais
macrotarefas realizam o envio de mensagens externas. As mensagens so enviadas
somente para o bloco principal, pois os demais ns no utilizaram estas variveis.
Com relao s variveis compartilhadas que armazenam a soma das
matrizes, nas duas verses elas so globais e as atualizaes so enviadas para o
n que executa o bloco principal.
A execuo das duas verses mostrou que a estratgia de atualizao
diminuiu a quantidade de mensagens enviadas, j que no houve o envio de
mensagens para todos os ns de execuo para atualizar uma varivel
compartilhada global. Isso faria com que as duas verses aumentassem
142
significativamente a quantidade de mensagens externas. Na verso completa, a

maioria das mensagens enviadas so entre ns que esto no mesmo domnio,
diminuindo a distncia entre os ns que se comunicam.
8.3.5 Anlise de desempenho

Para analisar o desempenho do ambiente CPAR-Grid, foi realizada a
comparao do tempo de execuo entre a verso completa e a verso sequencial
do algoritmo que efetua o clculo da mdia da soma das matrizes multiplicadas.
A Tabela 8.5 mostra o tempo de processamento, em segundos, da verso
sequencial e da verso completa, utilizando dois, quatro e seis processadores para a
execuo de cada macrotarefa na verso completa. O desvio padro dos tempos de
execuo, neste teste, variou de 0,09 a 0,22. A Figura 8.9 mostra o ganho de
desempenho da verso completa em relao verso sequencial.
Tabela 8.5 Tempo de processamento da verso completa
Quantidade de processadores para cada macrotarefa
Tamanho
Tempo
da Matriz
Sequencial
Dois
Quatro
Seis
1000x1000
33,626
8,038
6,529
5,074
1200x1200
57,859
13,899
9,497
8,145
1500x1500
124,015
24,664
17,009
13,843
2000x2000
325,483
62,794
38,294
29,739
Nos testes, o aumento do nmero de processadores que executam uma

macrotarefa, gerou melhores resultados, mostrando que medida que o tamanho da
matriz aumenta, o desempenho da aplicao tambm aumenta. O teste com seis
processadores obteve os melhores resultados, como era esperado, j que a
quantidade de processadores utilizados maior.
O grfico de desempenho da Figura 8.6 mostra que o ganho de desempenho
da verso completa aumenta quase que linearmente, nos testes com quatro e seis
processadores, quando o tamanho da matriz aumenta. No teste com dois
processadores, a curva de ganho de desempenho foi menor, mas ela tambm
ocorreu.
143
Figura 8.9 Grfico de desempenho da verso completa
Conforme foi explicado na seo 8.3.2, no teste com seis processadores, as

macrotarefas que efetuam a multiplicao das matrizes utilizam 24 processadores,
as macrotarefas que efetuam a soma das matrizes multiplicadas utilizam 12
processadores e a mdia das matrizes efetuada somente no bloco principal. O
desempenho, neste teste, variou de 6,6 11, aumentando de acordo com o
tamanho da matriz. Pela quantidade de dados a serem enviados atravs de
mensagens para a atualizao freqente das variveis compartilhadas, j que este
algoritmo possui um volume de comunicao muito alto, o tempo gasto na
comunicao entre os processos no impactou muito no desempenho da aplicao.
Nos testes com dois e quatro processadores, levando em considerao a
quantidade de mensagens enviadas e o nmero de processadores utilizados para a
execuo de cada macrotarefa, o tempo gasto na comunicao tambm no
impactou muito no desempenho da aplicao.
A Tabela 8.4 mostrou a quantidade de mensagens enviadas na execuo da
verso completa, utilizando seis processadores para cada macrotarefa. Nesta
tabela, pode-se verificar que medida que o tamanho da matriz aumenta, a
quantidade
de
mensagens
tambm
aumenta,
impactando
no
tempo
de
comunicao. Mesmo assim, o ambiente se comportou muito bem, dividindo a carga
144
de processamento hierarquicamente nos ns de processamento da grade

computacional e obtendo um aumento no desempenho.
O desempenho obtido reflete a eficcia das estratgias utilizadas no CPARGrid para o escalonamento das macrotarefas e das microtarefas e a atualizao das
variveis compartilhadas de acordo com o seu escopo. Alm disso, a unificao dos
processos executores do mesmo n em um nico processo com vrias threads
possibilitou a utilizao de memria compartilhada para a comunicao entre os
processos do mesmo n, diminuindo a quantidade de mensagens enviadas entre
estes processos, j que agora eles formam um nico processo.

Os testes realizados neste captulo mostraram que as funcionalidades
oferecidas pelo ambiente CPAR-Grid esto funcionando corretamente, de acordo
com as estratgias implementadas neste trabalho.
A estratgia de atualizao das variveis compartilhadas enviou a mensagem
de atualizao somente para os ns que j a utilizaram, respeitando o escopo da
varivel em questo. Desta forma, houve uma diminuio na quantidade de
mensagens enviadas durante a execuo da aplicao.
O escalonador do ambiente efetuou a alocao das macrotarefas e dos
macroblocos, de acordo com a hierarquia da grade computacional, respeitando a
estratgia de escalonamento. Os resultados obtidos mostraram que a utilizao dos
elementos de construo da linguagem trouxeram bons resultados, minimizando a
quantidade de mensagens enviadas e a distncia entre os ns que se comunicam.
Os resultados mostraram que o ambiente realiza de maneira eficiente a
execuo de aplicaes paralelas, utilizando a hierarquia que uma grade
computacional possui, alm de explorar corretamente os elementos de construo
da linguagem CPAR.
145
9. CONCLUSO
Hoje em dia, a maioria das aplicaes paralelas so executadas em grades
computacionais atravs de workflows. H poucos ambientes que do suporte
execuo de aplicaes paralelas escritas atravs de uma linguagem de
programao que possua elementos de processamento paralelos. Isso ocorre
devido necessidade de uma infraestrutura que consiga realizar o escalonamento
dos ns, a submisso e o monitoramento da aplicao, alm de um modelo de
processamento que consiga explorar a estrutura hierrquica presente nas grades
computacionais.
O modelo de processamento, proposto neste trabalho, utilizou os elementos
de construo da linguagem paralela CPAR para explicitar os trechos de cdigo que
so executados de maneira paralela, sendo que estes elementos podem ser
executados hierarquicamente.
A linguagem CPAR utiliza variveis compartilhadas para a comunicao entre
processos no mesmo n. O modelo de execuo utiliza memria compartilhada
distribuda para o armazenamento das variveis compartilhadas na grade
computacional. Para manter a consistncia das variveis, o modelo de execuo
realiza a atualizao das variveis compartilhadas atravs de um mecanismo de
consistncia relaxada.
Para minimizar a quantidade de mensagens enviadas, quando ocorre a
atualizao de uma varivel compartilhada, a estratgia de atualizao faz com que
este n envie mensagens de atualizao da varivel somente para os ns que j a
utilizaram.
A execuo de uma aplicao paralela em um ambiente de grades
computacionais exige que o ambiente possua um escalonador de tarefas que
selecione os melhores ns para a sua execuo. O escalonador possui um impacto
muito grande no desempenho da aplicao, pois caso ele escolha ns ruins para a
execuo, a aplicao provavelmente enviar muitas mensagens de atualizao de
variveis entre ns distantes.
O escalonador desenvolvido neste trabalho procurou selecionar os ns para a
execuo das tarefas de acordo com a carga de processamento de cada n e com
146
as caractersticas da tarefa a ser executada, objetivando a minimizao da distncia

entre os ns que se comunicam e a utilizao da estrutura hierrquica das grades
computacionais. Os resultados obtidos nos testes realizados comprovaram que a
estratgia de escalonamento adequada.
O ambiente CPAR-Grid implementou o modelo de processamento para
grades computacionais proposto no captulo 6. Este ambiente responsvel por
compilar a aplicao do usurio, ligando as bibliotecas do sistema e a biblioteca MPI
para grades, e gerar o arquivo executvel que submetido aos ns da grade
computacional. Os resultados obtidos mostraram que o ambiente consegue utilizar a
estrutura hierrquica das grades computacionais corretamente, alocando os
elementos de construo da linguagem CPAR de acordo com as suas
caractersticas.
9.1 Contribuies
No
desenvolvimento
deste
trabalho,
algumas
contribuies
foram
identificadas e so apresentadas a seguir:
Proposta de um modelo de processamento para aplicaes paralelas

baseadas em variveis compartilhadas para grades computacionais. Este
modelo composto pelos modelos de programao e de execuo, no
qual o modelo de programao utiliza a linguagem CPAR, consistindo de
elementos de construo que permitem a explorao hierrquica das
grades computacionais. O modelo de execuo composto por entidades
que do suporte execuo de aplicaes paralelas, realizando a sua
coordenao e gerenciamento.
Utilizao de variveis compartilhadas para o compartilhamento de

informaes. Os ambientes estudados neste trabalho compartilham
informaes atravs de arquivos, servios ou objetos. A utilizao de
variveis
compartilhadas
possibilita
uma
alternativa
para
compartilhamento de informaes, alm de possuir uma estrutura mais

simples que os demais mecanismos de comunicao.
Desenvolvimento do ambiente CPAR-Grid que consiste de um prcompilador, de bibliotecas do sistema e da biblioteca MPI para grades
147
computacionais. A aplicao paralela do usurio compilada para gerar o

arquivo executvel submetido grade computacional. O ambiente CPARGrid consegue executar a aplicao do usurio de maneira transparente,
abstraindo todas as caractersticas e a infraestrutura da grade
computacional.
Desenvolvimento de estratgias de escalonamento de macrotarefas e de

macroblocos
baseados
na
estrutura
hierrquica
das
grades
computacionais e na localizao dos ns de processamento.
Implementao
de
estratgias
de
atualizao
das
variveis
compartilhadas de acordo com o seu escopo e com a sua utilizao,

enviando as atualizaes somente para os ns que j utilizaram as
variveis que foram atualizadas.
Implementao de uma estratgia que unifica os processos que so

executados no mesmo n em um nico processo com vrias threads. Isso
fez com que as threads utilizassem a memria compartilhada como
mecanismo de comunicao, ao invs de utilizar a troca de mensagens,
minimizando a quantidade de mensagens enviadas.
9.2 Trabalhos futuros

A continuidade deste projeto cria oportunidades para o desenvolvimento de
outros trabalhos que dem continuidade neste. Os principais temas que podem ser
abordados em um trabalho futuro so os seguintes:
Finalizao da construo do pr-compilador: atualmente, o prcompilador consegue gerar o cdigo da linguagem C dos seguintes
elementos de construo: macrotarefas, microtarefas, macroblocos e
blocos paralelos. Porm, a gerao do cdigo para as variveis
compartilhadas no est concluda, principalmente para a atualizao das
variveis compartilhadas. No momento, para a execuo, no CPAR-Grid,
de aplicaes desenvolvidas para testes na linguagem CPAR
necessrio incluir manualmente chamadas do CPAR-Grid na aplicao.
Otimizao da alocao de memria das variveis compartilhadas:

para todas as variveis compartilhadas declaradas na aplicao, o
148
ambiente CPAR-Grid aloca um espao de memria para elas em cada n,

independente se ela utilizada pelo n em questo. Isso faz com que
haja desperdcio de memria em alguns ns, j que eles alocaro espao
de memria para variveis que no sero utilizadas. O ideal que cada
n consiga alocar espao de memria somente para as variveis
compartilhadas que sero utilizadas por ele. O problema que um n
descobre somente em tempo de execuo as variveis compartilhadas
que ele utilizar.
Escalonamento de macroblocos otimizado: atualmente, quando um

macrobloco escalonado, o escalonador seleciona um n para execut-lo
sem o conhecimento do nmero de ncleos de processamento que sero
necessrios para a execuo das macrotarefas que poderiam estar nele
presentes. Isso pode gerar a escolha de um domnio para execut-lo que
no o mais apropriado, fazendo com que outros macroblocos sejam
executados em domnios com poucos ncleos de processamento para a
quantidade de ncleos que eles precisam e, com isso, dividindo a
execuo das macrotarefas deste macrobloco em domnios distintos. Uma
otimizao para o escalonamento dos macroblocos que no instante do
seu escalonamento, o ambiente informe a quantidade de ncleos de
processamento que ele utilizar.
Tolerncia falhas: um ponto importante em sistemas de alto

desempenho a incorporao de aspectos de tolerncia falhas, e o
oferecimento ao usurio de uma robustez maior e da opo de ajustes na
configurao conforme a necessidade da aplicao.
Testes com uma aplicao real: os testes realizados nesta tese foram
baseados em uma aplicao sinttica e em uma aplicao cientfica. No
foram realizados testes com aplicaes reais ou de mercado. A utilizao
de aplicaes deste nvel poderia demonstrar a eficincia do ambiente
CPAR-Grid.
149
Referncias
[1]
AHO, A. V. et al. Compiladores: Princpios, Tcnicas e Ferramentas. So

Paulo. Editora Pearson. 2007.
[2]
BAL, H. E. et al. Performance Evaluation of the Orca Shared Object

System. ACM Transactions on Computer Systems. 1998. p. 140.
[3]
BATISTA, D. M. Escalonamento de Tarefas Dependentes para Grades

Robustos s Incertezas das Informaes de Entrada. Tese de Doutorado.
Universidade Estadual de Campinas. Instituto de Computao. 2010.
[4]
CAO, J. et al. GridFlow: Workflow Management for Grid Computing. In 3rd

International Symposium on Cluster Computing and the Grid (CCGrid), Japo.
2003. p. 198-205.
[5]
CONDOR. Projeto Condor. Disponvel em <http://www.cs.wisc.edu/condor/>.

Acesso em outubro, 2009.
[6]
CONSORTIUM,
P.
C.
PC
cluster
consortium.
Disponvel
em
<http://www.pccluster.org >. Acesso em novembro, 2009.

[7]
CORMEN, T. H. Algoritmos. Rio de Janeiro, Campus. 2002.
[8]
COULOURIS, G. Sistemas Distribudos: Conceitos e Projeto. So Paulo,

Bookman, 2007.
[9]
CRAVEIRO, G. S. Um ambiente de execuo para suporte programao

paralela com variveis compartilhadas em sistemas distribudos
heterogneos. Tese de Doutorado. Escola Politcnica da Universidade de
So Paulo. 2003.
[10]
DAGMan.
Projeto
Condor
DAGMan.
Disponvel
em
<http://www.cs.wisc.edu/condor/dagman/>. Acesso em junho, 2011.

[11]
DEELMAN, E. et al. Pegasus: Mapping Scientific Workflows onto the Gid.

In Grid Computing: Second European Across Grids Conference (AxGrids).
Cyprus. 2004. p. 11-26.
150
[12]
DEELMAN, E. et al. Workflows and e-Science: An overview of workflow

system features and capabilities. Journal of Future Generation Computer
Systems. Volume 25. 2009. p. 528-540.
[13]
DEITEL, P., DEITEL, H. Java Como Programar. 8 ed. So Paulo, Pearson

Prentice Hall Brasil. 2010 8.ed.
[14]
DEPPMAN, E. C. M. Gerenciamento de tarefas com ou sem dependncia,

sequenciais
computacionais.
paralelas,
em
Dissertao
sistemas
de
heterogneos
Mestrado.
Escola
de
grades
Politcnica
da
Universidade de So Paulo. 2010.

[15]
DONG, F., AKL, S. G. Scheduling Algorithms for Grid Computing: State of

the Art and Open Problems. Technical Report. School of Computing.
Queen's University, Ontrio, Canad. 2006.
[16]
DUBOIS, M., SCHEURICH, C., BRIGGS, F. A. Synchronization, Coherence

and Event Ordering in Multiprocessors. IEEE Computer, Vol 21, No 2.
1988. p. 9-21.
[17]
FOSTER,
I.
Globus
Primer.
Disponvel
em
<http://www.globus.org/toolkit/docs/4.0/key/GT4_Primer_0.6.pdf> . Acesso em
outubro, 2009.
[18]
FOSTER, I. Globus toolkit version 4: Software for service-oriented

systems. In IFIP International Conference on Network and Parallel
Computing. LNCS 3779. Springer-Verlag. 2006. p. 213.
[19]
FOSTER, I., KESSELMAN, C. Globus: A Meta Computing Infrastructure

Toolkit. International Journal of Supercomputer Applications, 11(2). 1997. p.
115-128.
[20]
FOSTER, I., KESSELMAN, C., TUECKE, S. The anatomy of the grid:

Enabling
scalable
virtual
organizations.
International
Journal
of
Supercomputer Applications, 15(3), 2001.

[21]
GEIST, A. et al. PVM: Parallel Virtual Machine. A Users Guide and Tutorial
for Networked Parallel Computing. The MIT Press. 1994.
[22]
GGF.
Data
Replication
Research
Group.
2004.
Disponvel
<http://forge.gridforum.org/projects/jsdl-wg/> . Acesso em maro, 2010.
em
151
[23]
GGF. Distributed Resource Management API Working Group. 2003.

Global Grid Forum. Disponvel em <http://forge.gridforum.org/projects/drmaawg/>. Acesso em maro, 2010.
[24]
GGF. Grid Checkpoint Recovery Working Group. 2003. Global Grid Forum.
Disponvel em <http://forge.gridforum.org/projects/gridcpr-wg/>. Acesso em
maro, 2010.
[25]
GGF. Grid File Systems Working Group. 2004. Global Grid Forum.
Disponvel
em
<http://forge.gridforum.org/projects/gfs-wg/>.
Acesso
em
maro, 2010.
[26]
GHARACHORLOO, K. et al. Memory consistency and event ordering in

scalable shared-memory multiprocessors. Proceedings in 17th Annual
International Symposium on Computer Architecture. 1990. p. 15-26.
[27]
GOMES JR, A. M. et al. Implementao da Interface MPI e de sua

Infraestrutura para Grades Computacionais. 1a Escola Regional de Alto
Desempenho de So Paulo (ERAD-SP). So Paulo. 2010.
[28]
GOMES JR, A. M. Um ambiente de execuo para um sistema de

memria compartilhada distribuda utilizando plataforma Windows.
Dissertao de Mestrado. Escola Politcnica da Universidade de So Paulo.
2005.
[29]
GOMES, D. A. Web Services SOAP em Java. Editora Novatec. So Paulo.

2010.
[30]
GOODALE, T. et al. SAGA: A Simple API for Grid Applications. High-level

application programming on the Grid. Computacional Methods in Science
and Technology. 2006. p. 7-20.
[31]
GRAM.
GRAM
Globus
Toolkit.
Disponvel
em
<http://www.globus.org/toolkit/gram>. Acesso em dezembro, 2009.

[32]
GRAMA, A. et al. Introduction to Parallel Computing. Second Edition.

Editora Addison-Wesley. 2003.
[33]
IGUMA,
D.
Aspectos
de
implementao
de
um
ambiente
para
programao paralela com variveis compartilhadas em sistemas
152
distribudos. Dissertao de Mestrado. Escola Politcnica da Universidade

de So Paulo. 1997.
[34]
INTELLIGENCE,
E.
CxC
Engineered
Intelligence.
Disponvel
em
<http://www.engineeredintelligence.com>. Acesso em setembro, 2009.

[35]
JU, J.; BUYYA, R. A Taxonomy of Workflow Management Systems for

Grid Computing. Journal of Grid Computing. 2005.
[36]
KARONIS, N., TOONEN, B., FOSTER, I. MPICH-G2: A Grid-Enabled

Implementation of the Message Passing Interface. Journal of Parallel and
Distributed Computing. 2003.
[37]
KELEHER, P. Lazy Release Consistency for Distributed Shared Memory.

Ph.D. Thesis, Department of Computer Science, Rice University, December
1994.
[38]
LASZEWSKI, G. et al. CoG Kits: A Bridge between Commodity Distributed

Computing and High Performance Grids. In ACM 2000 Java Grande
Conference. Estados Unidos. 2000. p. 97-106.
[39]
LENOSKI, D. et al. The Stanford Dash Multiprocessor. IEEE Computer, Vol

25 No 3. 1992. p. 63-79.
[40]
LEWIS, B., BERG, D. J. Multithreaded Programming with Pthreads. Sun

Microsystems Press. Prentice Hall. 1998.
[41]
LI, W. et al. A Service Management Scheme for Grid Systems. The Second
International Workshop on Grid and Cooperative Computing. Springer-Verlag.
Berlin. 2003. p. 541-548.
[42]
LI, W., XU, Z. Model of grid address space with applications. Journal of
Computer Research and Development. Science Press. Beijing, 2003, p. 17561770.
[43]
MASHESWARAN, M. et al. Dynamic Matching and Scheduling of a Class

of Independent Tasks onto Heterogeneous Computing Systems. In
Journal of Parallel and Distributed Computing, Vol. 59, No. 2, November.
1999. p. 107-131.
153
[44]
MASSETTO, F. I. et al. A Message Forward Tool for integration of

Clusters of Clusters based on MPI Architecture. The 2nd Russia-Taiwan
Symposium on Methods and Tools of Parallel Programming Multicomputers.
Russia, Maio, 2010.
[45]
MATTSON, T. G., SANDERS, B. A., MASSINGILL, B. L. A Pattern Language

for Parallel Programming. Addison Wesley Software Patterns Series. 2004.
[46]
MDS.
MDS
Globus
Toolkit.
Disponvel
em
<http://www.globus.org/toolkit/mds>. Acesso em dezembro, 2009.

[47]
MOSBERGER, D. Memory Consistency Models. Technical Report 93/11.

University of Arizona. 1993.
[48]
MPI2. MPI-2: Extensions to the Message-Passing Interface. University of

Tennessee. 2003.
[49]
NIEUWPOORT, R. V. v. Efficient Java-centric grid-computing. Tese de

Doutorado.
Vrije
Universiteit
Amsterdam.
Disponvel
em
<http://www.cs.vu.nl/~rob/>. 2003.
[50]
NIEUWPOORT, R. V. v. et al. Ibis: a flexible and efficient Java-based grid

programming environment. Concurrency & Computation: Practice &
Experience. 2005. p. 10791107.
[51]
NIEUWPOORT, R. V. v. et al. Satin: a High-Level and Efficient Grid

Programming Model. ACM Transactions on Programming Languages and
Systems. Vol. 10. 2010. p. 140.
[52]
NIEUWPOORT, R. V. v., KIELMANN, T., and BAL, H. E. User-friendly and

reliable grid computing based on imperfect middleware. In Proceedings of
the ACM/IEEE Conference on Supercomputing (SC07).
Estados Unidos.
2007.
[53]
OPENMPI. Open MPI: Open Source High Performance Computing.

Disponvel em <http://www.open-mpi.org>. Acesso em julho, 2010.
[54]
PAULA, N. C. Um ambiente de monitoramento de recursos e

escalonamento
cooperativo
de
aplicaes
paralelas
em
grades
computacionais. Tese de doutorado. Escola Politcnica da Universidade de

So Paulo. 2009.
154
[55]
RAJIC, H. et al. Distributed Resource Management Application API

Specification 1.0. Global Grid Forum. Tech. Rep. 2004. Disponvel em
<http://www.ggf.org/documents/GFD.22.pdf>. Acesso em maro, 2010.
[56]
SATO, L. M. Ambientes de programao para sistemas paralelos e

distribudos. Tese de Livre Docncia, Escola Politcnica da Universidade de
So Paulo, 1995.
[57]
SCHREINER, A. T., FRIEDMAN JR, H. G. Introduction to Compiler

Construction with Unix. Prentice-Hall. 1985.
[58]
SEBESTA, R. W. Conceitos de Linguagens de Programao. 5 ed. Porto

Alegre, Bookman. 2003
[59]
SEYMOUR, K. et al. An Overview of GridRPC: A Remote Procedure Call

API for Grid Computing. In 3rd International Workshop on Grid Computing.
Springer-Verlag. Lecture Notes in Computer Science. 2002. p. 274-280.
[60]
TANENBAUM, A. S. Distributed Systems: Principles and Paradigms. 2nd

Edition. Prentice-Hall, 2007.
[61]
TANENBAUM, A. S. Sistemas Operacionais Modernos. 3 ed. So Paulo,

Prentice-Hall. 2010.
[62]
VOSS, M. J. OpenMP Shared Memory Parallel Programming. Proceedings

on International workshop on OpenMP applications and tools. Canad.
Springer Verlag. 2003.
[63]
WANG, X. et al. Abacus: A Service-Oriented Programming Language for

Grid Applications. Proceedings of the 2005 IEEE International Conference
on Services Computing. Vol. 1. 2005. p. 225-232.
[64]
WIECZOREK, M., PRODAN, R., FAHRINGER, T. Scheduling of Scientific

Workflows in the ASKALON Grid Environment. ACM SIGMOD Record, vol.
34, No 3. 2005. p. 56-62.
[65]
WRZESINSKA, G. et al. Satin++: Divide-and-share on the grid. In 2nd IEEE

International Conference on e-Science and Grid Computing. Amsterdam,
Holanda. 2007.
155
[66]
XU, Z., LI, W. The Research on Vega Grid Architecture. Journal of

Computer Research and Development. Science Press. Beijing. 2002. p. 923929.
[67]
YELLICK, K.; BONACHEA, D.; WALLACE, C. A Proposal for a UPC Memory

Consistency Model. Technical report - (LBNL-54983). Lawrence Berkeley
National Lab. 2004.
[68]
YU, J., BUYYA, R., RAMAMOHANARAO, K. Workflow Scheduling

Algorithms for Grid Computing. Proceedings on Metaheuristics for
Scheduling in Distributed Computing Environments. Springer Berlin /
Heidelberg. Volume 146. 2008. p. 173-214.
156
Apndice A - Tokens da Linguagem CPAR

Os tokens da linguagem CPAR foram desenvolvidos com o auxlio da
ferramenta lex [57]. As expresses regulares que definem cada um dos tokens so
descritas a seguir.
[0-9]
[a-zA-Z_]
[a-fA-F0-9]
[Ee][+-]?{D}+
FS
(f|F|l|L)
IS
(u|U|l|L)*
%{
#include <stdio.h>
#include <stdlib.h>
#include "grammar.tab.h"
void count();
%}
%%
"/*"
{ comment(); }
"#include"
{ count(); return(INCLUDE); }
"#define"
{ count(); return(DEFINE); }
"auto"
{ count(); return(AUTO); }
"body"
{ count(); return(BODY); }
"break"
{ count(); return(BREAK); }
"case"
{ count(); return(CASE); }
"char"
{ count(); return(CHAR); }
"const"
{ count(); return(CONST); }
"continue"
{ count(); return(CONTINUE); }
157
"default"
{ count(); return(DEFAULT); }
"do"
{ count(); return(DO); }
"double"
{ count(); return(DOUBLE); }
"else"
{ count(); return(ELSE); }
"enum"
{ count(); return(ENUM); }
"extern"
{ count(); return(EXTERN); }
"float"
{ count(); return(FLOAT); }
"for"
{ count(); return(FOR); }
"goto"
{ count(); return(GOTO); }
"if"
{ count(); return(IF); }
"int"
{ count(); return(INT); }
"long"
{ count(); return(LONG); }
"register"
{ count(); return(REGISTER); }
"return"
{ count(); return(RETURN); }
"short"
{ count(); return(SHORT); }
"signed"
{ count(); return(SIGNED); }
"sizeof"
{ count(); return(SIZEOF); }
"static"
{ count(); return(STATIC); }
"struct"
{ count(); return(STRUCT); }
"switch"
{ count(); return(SWITCH); }
"typedef"
{ count(); return(TYPEDEF); }
"union"
{ count(); return(UNION); }
"unsigned"
{ count(); return(UNSIGNED); }
"void"
{ count(); return(VOID); }
"volatile"
{ count(); return(VOLATILE); }
"while"
{ count(); return(WHILE); }
"also"
{ count(); return(ALSO);}
"block"
{ count(); return(BLOCK);}
"cobegin"
{ count(); return(COBEGIN);}
"coend"
{ count(); return(COEND);}
"create"
{ count(); return(CREATE);}
"create_sem"
{ count(); return(CREATE_SEM); }
"end"
{ count(); return(END); }
"event"
{ count(); return(EVENT);}
158
"forall"
{ count(); return(FORALL);}
"lock"
{ count(); return(LOCK); }
"monitor"
{ count(); return(MONITOR);}
"par"
{ count(); return(PAR);}
"parbegin"
{ count(); return(PARBEGIN);}
"parend"
{ count(); return(PAREND);}
"remove_sem"
{ count(); return(REMOVE_SEM); }
"sch"
{ count(); return(SCH); }
"semaph"
{ count(); return(SEMAPH);}
"shared"
{ count(); return(SHARED);}
"spar"
{ count(); return(SPAR);}
"spec"
{ count(); return(SPEC);}
"task"
{ count(); return(TASK);}
"task_shared"
{ count(); return(TASK_SHARED);}
"to"
{ count(); return(TO);}
"unlock"
{ count(); return(UNLOCK);}
"var"
{ count(); return(VAR);}
"wait_all"
{ count(); return(WAIT_ALL);}
"wait_task"
{ count(); return(WAIT_TASK);}
"when"
{ count(); return(WHEN);}
{L}({L}|{D})*
{ count(); strcpy(nome,yytext); return(check_type()); }
0[xX]{H}+{IS}?
{ count(); strcpy(nome,yytext); return(CONSTANT); }
0{D}+{IS}?
{D}+{IS}?
L?'(\\.|[^\\'])+'
{D}+{E}{FS}?
{D}*"."{D}+({E})?{FS}?
{D}+"."{D}*({E})?{FS}?
L?\"(\\.|[^\\"])*\"
{ count(); strcpy(nome,yytext); return(STRING_LITERAL); }
"..."
{ count(); /*fprintf(fd, "%s", yytext);*/ return(ELLIPSIS); }
">>="
{ count(); return(RIGHT_ASSIGN); }
"<<="
{ count(); return(LEFT_ASSIGN); }
159
"+="
{ count(); return(ADD_ASSIGN); }
"-="
{ count(); return(SUB_ASSIGN); }
"*="
{ count(); return(MUL_ASSIGN); }
"/="
{ count(); return(DIV_ASSIGN); }
"%="
{ count(); return(MOD_ASSIGN); }
"&="
{ count(); return(AND_ASSIGN); }
"^="
{ count(); return(XOR_ASSIGN); }
"|="
{ count(); return(OR_ASSIGN); }
">>"
{ count(); return(RIGHT_OP); }
"<<"
{ count(); return(LEFT_OP); }
"++"
{ count(); return(INC_OP); }
"--"
{ count(); return(DEC_OP); }
"->"
{ count(); return(PTR_OP); }
"&&"
{ count(); return(AND_OP); }
"||"
{ count(); return(OR_OP); }
"<="
{ count(); return(LE_OP); }
">="
{ count(); return(GE_OP); }
"=="
{ count(); return(EQ_OP); }
"!="
{ count(); return(NE_OP); }
";"
{ count(); return(';'); }
("{"|"<%")
{ count(); return('{'); }
("}"|"%>")
{ count(); return('}'); }
","
{ count(); return(','); }
":"
{ count(); return(':'); }
"="
{ count(); return('='); }
"("
{ count(); return('('); }
")"
{ count(); return(')'); }
("["|"<:")
{ count(); return('['); }
("]"|":>")
{ count(); return(']'); }
"."
{ count(); return('.'); }
"&"
{ count(); return('&'); }
"!"
{ count(); return('!'); }
"~"
{ count(); return('~'); }
"-"
{ count(); return('-'); }
160
"+"
{ count(); return('+'); }
"*"
{ count(); return('*'); }
"/"
{ count(); return('/'); }
"%"
{ count(); return('%'); }
"<"
{ count(); return('<'); }
">"
{ count(); return('>'); }
"^"
{ count(); return('^'); }
"|"
{ count(); return('|'); }
"?"
{ count(); return('?'); }
[ \t\v\n\f]
{ count(); fprintf(fd, "%s", yytext);}
{ /* ignore bad characters */ }
%%
yywrap()
{
return(1);
}
comment()
{
char c, c1;
loop:
c = input();
while (c != '*')
{
if(c == '\n')
{
linhas++;
}
c = input();
}
161
if ((c1 = input()) != '/') // && c != '/0')

{
goto loop;
}
}
int column = 0;
int linha = 1;
void count()
{
int i;
for (i = 0; yytext[i] != '\0'; i++)

if (yytext[i] == '\n')
{
column = 0;
linhas++;
}
else if (yytext[i] == '\t')
column += 8 - (column % 8);
else
column++;
int check_type()
{
return(IDENTIFIER);
}
162
Apndice B - Gramtica da Linguagem CPAR

A gramtica da linguagem CPAR foi desenvolvida com o auxlio da ferramenta
yacc [57]. A gramtica descrita a seguir, no qual o smbolo inicial da gramtica o
start_program. Todos os tokens especificados no Apndice A so utilizados pela
gramtica.
%token IDENTIFIER CONSTANT STRING_LITERAL SIZEOF

%token ALSO BLOCK BODY COBEGIN COEND CREATE CREATE_SEM EVENT
FORALL LOCK MONITOR PAR PARBEGIN PAREND REMOVE_SEM SCH
SEMAPH SHARED SPAR SPEC TASK TASK_SHARED TO UNLOCK WAIT_ALL
WAIT_TASK WHEN
%token PTR_OP INC_OP DEC_OP LEFT_OP RIGHT_OP LE_OP GE_OP EQ_OP
NE_OP
%token
AND_OP
OR_OP
MUL_ASSIGN
DIV_ASSIGN
MOD_ASSIGN
ADD_ASSIGN
%token SUB_ASSIGN LEFT_ASSIGN RIGHT_ASSIGN AND_ASSIGN
%token XOR_ASSIGN OR_ASSIGN TYPE_NAME
%token TYPEDEF EXTERN STATIC AUTO REGISTER
%token CHAR SHORT INT LONG SIGNED UNSIGNED FLOAT DOUBLE CONST
VOLATILE VOID VAR END
%token STRUCT UNION ENUM ELLIPSIS INCLUDE DEFINE
%token CASE DEFAULT IF ELSE SWITCH WHILE DO FOR GOTO CONTINUE
BREAK RETURN
%start start_program
%%
primary_expression
: IDENTIFIER
| CONSTANT
| STRING_LITERAL
| '(' expression ')'
163
postfix_expression
: primary_expression
| postfix_expression '[' expression ']'
| postfix_expression '(' ')'
| postfix_expression '(' argument_expression_list ')'
| postfix_expression '.' IDENTIFIER
| postfix_expression PTR_OP IDENTIFIER
| postfix_expression INC_OP
| postfix_expression DEC_OP
;
argument_expression_list
: assignment_expression
| argument_expression_list ',' assignment_expression
;
unary_expression
: postfix_expression
| INC_OP unary_expression
| DEC_OP unary_expression
| unary_operator cast_expression
| SIZEOF sufixo_sizeof
;
sufixo_sizeof
: unary_expression
| '(' type_name ')'
;
unary_operator
: '&'
| '*'
164
| '+'
| '-'
| '~'
| '!'
;
cast_expression
: unary_expression
| '(' type_name ')' cast_expression
;
multiplicative_expression
: cast_expression
| multiplicative_expression '*' cast_expression
| multiplicative_expression '/' cast_expression
| multiplicative_expression '%' cast_expression
;
additive_expression
: multiplicative_expression
| additive_expression '+' multiplicative_expression
| additive_expression '-' multiplicative_expression
;
shift_expression
: additive_expression
| shift_expression LEFT_OP additive_expression
| shift_expression RIGHT_OP additive_expression
;
relational_expression
: shift_expression
| relational_expression '<' shift_expression
| relational_expression '>' shift_expression
165
| relational_expression LE_OP shift_expression

| relational_expression GE_OP shift_expression
;
equality_expression
: relational_expression
| equality_expression EQ_OP relational_expression
| equality_expression NE_OP relational_expression
;
and_expression
: equality_expression
| and_expression '&' equality_expression
;
exclusive_or_expression
: and_expression
| exclusive_or_expression '^' and_expression
;
inclusive_or_expression
: exclusive_or_expression
| inclusive_or_expression '|' exclusive_or_expression
;
logical_and_expression
: inclusive_or_expression
| logical_and_expression AND_OP inclusive_or_expression
;
logical_or_expression
: logical_and_expression
| logical_or_expression OR_OP logical_and_expression
;
166
conditional_expression
: logical_or_expression
| logical_or_expression '?' expression ':' conditional_expression
;
assignment_expression
: conditional_expression
| unary_expression assignment_operator assignment_expression
;
assignment_operator
: '='
| MUL_ASSIGN
| DIV_ASSIGN
| MOD_ASSIGN
| ADD_ASSIGN
| SUB_ASSIGN
| LEFT_ASSIGN
| RIGHT_ASSIGN
| AND_ASSIGN
| XOR_ASSIGN
| OR_ASSIGN
;
expression
| expression ',' assignment_expression
;
constant_expression
: conditional_expression
;
167
declaration
: declaration_specifiers ';'
| declaration_specifiers init_declarator_list ';'
| IDENTIFIER init_declarator_list ';'
| SHARED specifier_tipo_shared declarator_shared_var ';'
| DEFINE IDENTIFIER CONSTANT
| TASK SPEC IDENTIFIER '(' ')'';'
| SEMAPH declarator_semaph ';'
;
declaration_specifiers
: storage_class_specifier
| storage_class_specifier declaration_specifiers
| type_specifier
| type_specifier declaration_specifiers
| type_qualifier
| type_qualifier declaration_specifiers
;
specifier_tipo_shared
: CHAR
| SHORT
| INT
| LONG
| FLOAT
| DOUBLE
| SIGNED
| UNSIGNED
;
declarator_shared_var
: IDENTIFIER
| declarator_shared_var '[' CONSTANT ']'
| declarator_shared_var ',' declarator_shared_var
168
declarator_semaph
: IDENTIFIER
| declarator_semaph '['CONSTANT']'
| declarator_semaph ',' declarator_semaph
;
init_declarator_list
: init_declarator
| init_declarator_list ',' init_declarator
;
init_declarator
: declarator
| declarator '=' initializer
;
storage_class_specifier
: TYPEDEF
| EXTERN
| STATIC
| AUTO
| REGISTER
;
type_specifier
: VOID
| CHAR
| SHORT
| INT
| LONG
| FLOAT
| DOUBLE
169
| SIGNED
| UNSIGNED
| struct_or_union_specifier
| enum_specifier
| TYPE_NAME
;
struct_or_union_specifier
: struct_or_union IDENTIFIER '{' struct_declaration_list '}'
| struct_or_union '{' struct_declaration_list '}'
| struct_or_union IDENTIFIER
;
struct_or_union
: STRUCT
| UNION
;
struct_declaration_list
: struct_declaration
| struct_declaration_list struct_declaration
;
struct_declaration
: specifier_qualifier_list struct_declarator_list ';'
;
specifier_qualifier_list
: type_specifier specifier_qualifier_list
| type_specifier
| type_qualifier specifier_qualifier_list
| type_qualifier
;
170
struct_declarator_list
: struct_declarator
| struct_declarator_list ',' struct_declarator
;
struct_declarator
: declarator
| ':' constant_expression
| declarator ':' constant_expression
;
enum_specifier
: ENUM '{' enumerator_list '}'
| ENUM IDENTIFIER '{' enumerator_list '}'
| ENUM IDENTIFIER
;
enumerator_list
: enumerator
| enumerator_list ',' enumerator
;
enumerator
: IDENTIFIER
| IDENTIFIER '=' constant_expression
;
type_qualifier
: CONST
| VOLATILE
;
declarator
: pointer direct_declarator
171
| direct_declarator
;
direct_declarator
: IDENTIFIER
| '(' declarator ')'
| direct_declarator '[' constant_expression ']'
| direct_declarator '[' ']'
| direct_declarator '(' parameter_type_list ')'
| direct_declarator '(' identifier_list ')'
| direct_declarator '(' ')'
;
pointer
: '*'
| '*' sufixo_pointer
;
sufixo_pointer
: type_qualifier_list
| pointer
| type_qualifier_list pointer
;
type_qualifier_list
: type_qualifier
| type_qualifier_list type_qualifier
;
parameter_type_list
: parameter_list
| parameter_list ',' ELLIPSIS
;
172
parameter_list
: parameter_declaration
| parameter_list ',' parameter_declaration
;
parameter_declaration
: declaration_specifiers declarator
| declaration_specifiers abstract_declarator
| declaration_specifiers
;
task_parameters
: '(' ')'
| '(' identifier_list ')' task_declaration
;
task_declaration
: type_specifier IDENTIFIER ';'
| task_declaration type_specifier IDENTIFIER ';'
;
identifier_list
: IDENTIFIER
| identifier_list ',' IDENTIFIER
;
type_name
: specifier_qualifier_list
| specifier_qualifier_list abstract_declarator
;
abstract_declarator
: pointer
| direct_abstract_declarator
173
| pointer direct_abstract_declarator
;
direct_abstract_declarator
: '(' abstract_declarator ')'
| '[' ']'
| '[' constant_expression ']'
| direct_abstract_declarator '[' ']'
| direct_abstract_declarator '[' constant_expression ']'
| '(' ')'
| '(' parameter_type_list ')'
| direct_abstract_declarator '(' ')'
| direct_abstract_declarator '(' parameter_type_list ')'
;
initializer
| '{' initializer_list sufixo_initializer
;
sufixo_initializer
: '}'
| ',' '}'
;
initializer_list
: initializer
| initializer_list ',' initializer
;
cob_statement
: statement_list
| cob_statement ALSO statement_list
;
174
statement
: labeled_statement
| compound_statement
| expression_statement
| selection_statement
| iteration_statement
| jump_statement
| DEFINE IDENTIFIER CONSTANT
| CREATE CONSTANT ',' IDENTIFIER '(' ')' ';'
| COBEGIN cob_statement COEND
| CREATE_SEM '(' IDENTIFIER ',' CONSTANT ')' ';'
| REMOVE_SEM '(' IDENTIFIER ')' ';'
| LOCK '(' IDENTIFIER ')' ';'
| UNLOCK '(' IDENTIFIER ')'
| IDENTIFIER ';'
;
labeled_statement
: IDENTIFIER ':' statement
| CASE constant_expression ':' statement
| DEFAULT ':' statement
;
par_statement
: statement_list
| par_statement ALSO statement_list
;
sufixo_compound_statement
: '}'
| statement_list '}'
;
sufixo_forall
175
: '{' statement_list '}'

| SCH '=' primary_expression '{' statement_list '}'
;
compound_statement
: '{' '}'
| '{' statement_list '}'
| '{' VAR ':' declaration_list END ';' sufixo_compound_statement
| FORALL IDENTIFIER '=' primary_expression
sufixo_forall
| PARBEGIN par_statement PAREND
;
declaration_list
: declaration
| declaration_list declaration
;
statement_list
: statement
| statement_list statement
;
expression_statement
: ';'
| expression ';'
;
selection_statement
: IF '(' expression ')' sufixo_if
| SWITCH '(' expression ')' statement
;
sufixo_if
: statement
TO
primary_expression
176
| statement ELSE statement

;
iteration_statement
: WHILE '(' expression ')' statement
| DO statement WHILE '(' expression ')' ';'
| FOR '(' expression_statement expression_statement sufixo_for
;
sufixo_for
: ')' statement
| expression ')' statement
;
jump_statement
: GOTO IDENTIFIER ';'
| CONTINUE ';'
| BREAK ';'
| RETURN ';'
| RETURN expression ';'
;
start_program
: declaration_include translation_unit
| translation_unit
;
declaration_include
: declaration_include INCLUDE '<' IDENTIFIER '.' IDENTIFIER '>'
| INCLUDE '<' IDENTIFIER '.' IDENTIFIER '>'
;
translation_unit
: declaration_include external_declaration
177
| translation_unit external_declaration
;
external_declaration
: function_definition
| declaration
;
function_definition
: declaration_specifiers declarator declaration_list compound_statement
| declaration_specifiers declarator compound_statement
| declarator declaration_list compound_statement
| declarator compound_statement
| TASK BODY IDENTIFIER task_parameters compound_statement
| BLOCK IDENTIFIER compound_statement
;
178
Apndice C Cdigo fonte dos Testes

O cdigo fonte dos testes realizados so exibidos neste apndice. As
prximas sees ilustram os cdigos utilizando a linguagem CPAR.
C.1 Algoritmo sinttico

#include <stdio.h>
#define SIZE 2000
shared double W[SIZE][SIZE], Z[SIZE][SIZE];
task body macrotarefa1() {
int i, j;
shared double A[SIZE][SIZE], B[SIZE][SIZE];
forall i=0 to (SIZE-1){
for (j = 0; j < SIZE; j++) {
A[itera_][j] = 2.0;
B[itera_][j] = 0.5;
}
}//end forall
}/*end macrotarefa1 */
int i, j;
shared double Y[SIZE][SIZE];
for (j = 0; j < SIZE; j++) {
X[itera_][j] = 2.0;
Y[itera_][j] = 0.5;
}
}//end forall
int i, j;
for (j = 0; j < SIZE; j++) {
Z[itera_][j] = 2.0;
W[itera_][j] = 0.5;
}
}//end forall
179
block macrobloco1() {
printf("Antes da criao do Macrobloco 3!\n");
fflush(stdout);
block macrobloco3;
printf("Macrobloco 3 foi criado!\n");
fflush(stdout);
WaitBlock(macrobloco3);
} // fim do macrobloco 1
shared double X[SIZE][SIZE];
printf("Antes da criao da macrotarefa 2!\n");
fflush(stdout);
create 4, macrotarefa2();
printf("Macrotarefa 2 foi criada!\n");
fflush(stdout);
WaitTask(macrotarefa2); // espera o fim da task macrotarefa2
printf("Antes da criao da macrotarefa 1!\n");
fflush(stdout);
printf("Macrotarefa 1 foi criada!\n");
fflush(stdout);
/* Bloco Principal*/
void main()
{
int i, j;
double media[SIZE][SIZE], media1[SIZE][SIZE],
media2[SIZE][SIZE];
cobegin
block macrobloco1;
also
180
block macrobloco2;
also
coend
for(i=0; i<SIZE; i++){
for(j=0; j<SIZE; j++){
printf("Z[%d][%d] = %f\n",i, j, Z[i][j]);
printf("W[%d][%d] = %f\n",i, j, W[i][j]);
fflush(stdout);
}
}
}
C.2 Algoritmo que calcula a mdia da soma das matrizes multiplicadas

C.2.1 Verso com variveis locais
#include <stdio.h>
#define SIZE 2000
task body multAB() {

int i, j, k;
double A[SIZE][SIZE], B[SIZE][SIZE], X[SIZE][SIZE], C_aux;

for (j = 0; j < SIZE; j++) {
A[itera_][j] = 2.0;
B[itera_][j] = 0.5;
}
}//end forall

for (j = 0; j < SIZE; j++) {
C_aux = 0;
for (k = 0; k < SIZE; k++) {
C_aux = C_aux + A[i][k] * B[k][j];
}
X[i][j] = C_aux;
}
181
}
}/*end multAB*/
task body multCD() {

int i, j, k;
double C[SIZE][SIZE], D[SIZE][SIZE], Y[SIZE][SIZE], C_aux;

for (j = 0; j < SIZE; j++) {
C[itera_][j] = 2.0;
D[itera_][j] = 0.5;
}
}//end forall

for (j = 0; j < SIZE; j++) {
C_aux = 0;
for (k = 0; k < SIZE; k++) {
C_aux = C_aux + C[i][k] * D[k][j];
}
Y[i][j] = C_aux;
}
}
}/*end multCD*/
task body multEF() {

int i, j, k;
double E[SIZE][SIZE], F[SIZE][SIZE], Z[SIZE][SIZE], C_aux;

for (j = 0; j < SIZE; j++) {
E[itera_][j] = 2.0;
F[itera_][j] = 0.5;
}
}//end forall
182
for (j = 0; j < SIZE; j++) {

C_aux = 0;
for (k = 0; k < SIZE; k++) {
C_aux = C_aux + E[i][k] * F[k][j];
}
Z[i][j] = C_aux;
}
}
}/*end multEF*/
task body multGH() {

int i, j, k;
double G[SIZE][SIZE], H[SIZE][SIZE], W[SIZE][SIZE], C_aux;

for (j = 0; j < SIZE; j++) {
G[itera_][j] = 2.0;
H[itera_][j] = 0.5;
}
}//end forall

for (j = 0; j < SIZE; j++) {
C_aux = 0;
for (k = 0; k < SIZE; k++) {
C_aux = C_aux + G[i][k] * H[k][j];
}
W[i][j] = C_aux;
}
}
}/*end multGH*/
task body mediaXY() {

int i, j;
double X[SIZE][SIZE], Y[SIZE][SIZE], media1[SIZE][SIZE];
183
for (j = 0; j < SIZE; j++) {

media1[i][j] = (X[i][j] + Y[i][j]) /2;
}
}//end forall
}/*end mediaXY*/
task body mediaZW() {

int i, j;
double Z[SIZE][SIZE], W[SIZE][SIZE], media2[SIZE][SIZE];

for (j = 0; j < SIZE; j++) {
media2[i][j] = (Z[i][j] + W[i][j]) /2;
}
}//end forall
}/*end mediaZW*/
/* bloco que gerencia as matrizes A, B, C, D */

int i, j;
double soma_local;
create 6, multAB();
create 6, multCD();
WaitTask(multAB); // espera o fim da task multAB
WaitTask(multCD); // espera o fim da task multCD
create 6, mediaXY(); // executa a task mediaXY

WaitTask(mediaXY); // espera o fim da task mediaXY
/* bloco que gerencia as matrizes E, F, G, H */
184
int i, j;
double soma_local;
create 6, multEF();
create 6, multGH();
WaitTask(multEF); // espera o fim da task multEF
WaitTask(multGH); // espera o fim da task multGH
create 6, mediaZW(); // executa a task mediaZW

WaitTask(mediaZW); // espera o fim da task mediaZW
void main()
{
int i, j;
double
media[SIZE][SIZE],
media1[SIZE][SIZE],
media2[SIZE][SIZE];
block macrobloco1;
block macrobloco2;

media[i][j] = (media1[i][j] + media2[i][j]) / 2;
}
}
}
185
C.2.2 Verso completa

#include <stdio.h>
#define SIZE 2000
shared
double
media[SIZE][SIZE],
media1[SIZE][SIZE],
media2[SIZE][SIZE];

int i, j, k;
double C_aux;

for (j = 0; j < SIZE; j++) {
A[itera_][j] = 2.0;
B[itera_][j] = 0.5;
}
}//end forall

for (j = 0; j < SIZE; j++) {
C_aux = 0;
for (k = 0; k < SIZE; k++) {
}
X[i][j] = C_aux;
}
}
}/*end multAB*/

int i, j, k;
double C_aux;
shared double C[SIZE][SIZE], D[SIZE][SIZE];
186
for (j = 0; j < SIZE; j++) {

C[itera_][j] = 2.0;
D[itera_][j] = 0.5;
}
}//end forall

for (j = 0; j < SIZE; j++) {
C_aux = 0;
for (k = 0; k < SIZE; k++) {
}
Y[i][j] = C_aux;
}
}
}/*end multCD*/

int i, j, k;
double C_aux;
shared double E[SIZE][SIZE], F[SIZE][SIZE];

for (j = 0; j < SIZE; j++) {
E[itera_][j] = 2.0;
F[itera_][j] = 0.5;
}
}//end forall

for (j = 0; j < SIZE; j++) {
C_aux = 0;
for (k = 0; k < SIZE; k++) {
}
Z[i][j] = C_aux;
}
187
}
}/*end multEF*/

int i, j, k;
double C_aux;
shared double G[SIZE][SIZE], H[SIZE][SIZE];

for (j = 0; j < SIZE; j++) {
G[itera_][j] = 2.0;
H[itera_][j] = 0.5;
}
}//end forall

for (j = 0; j < SIZE; j++) {
C_aux = 0;
for (k = 0; k < SIZE; k++) {
}
W[i][j] = C_aux;
}
}
}/*end multGH*/

int i, j;

for (j = 0; j < SIZE; j++) {
media1[i][j] = (X[i][j] + Y[i][j]) /2;
}
}//end forall
}/*end mediaXY*/
188

int i, j;

for (j = 0; j < SIZE; j++) {
media2[i][j] = (Z[i][j] + W[i][j]) /2;
}
}//end forall
}/*end mediaZW*/
/* bloco que gerencia as matrizes A, B, C, D */

int i, j;
shared double X[SIZE][SIZE], Y[SIZE][SIZE];
create 6, multAB();
create 6, multCD();

/* bloco que gerencia as matrizes E, F, G, H */

int i, j;
shared double Z[SIZE][SIZE], W[SIZE][SIZE];
create 6, multEF();
create 6, multGH();
189

void main()
{
int i, j;
double
media[SIZE][SIZE],
media1[SIZE][SIZE],
media2[SIZE][SIZE];
block macrobloco1;
block macrobloco2;

}
}
}
C.2.3 Verso somente com macrotarefas

#include <stdio.h>
#define SIZE 2000
shared
double
X[SIZE][SIZE],
Y[SIZE][SIZE],
Z[SIZE][SIZE],
W[SIZE][SIZE];
shared
double
media2[SIZE][SIZE];
media[SIZE][SIZE],
media1[SIZE][SIZE],
190

int i, j, k;
double C_aux;

for (j = 0; j < SIZE; j++) {
A[itera_][j] = 2.0;
B[itera_][j] = 0.5;
}
}//end forall

for (j = 0; j < SIZE; j++) {
C_aux = 0;
for (k = 0; k < SIZE; k++) {
}
X[i][j] = C_aux;
}
}
}/*end multAB*/

int i, j, k;
double C_aux;
shared double C[SIZE][SIZE], D[SIZE][SIZE];

for (j = 0; j < SIZE; j++) {
C[itera_][j] = 2.0;
D[itera_][j] = 0.5;
}
}//end forall
191
for (j = 0; j < SIZE; j++) {

C_aux = 0;
for (k = 0; k < SIZE; k++) {
}
Y[i][j] = C_aux;
}
}
}/*end multCD*/

int i, j, k;
double C_aux;
shared double E[SIZE][SIZE], F[SIZE][SIZE];

for (j = 0; j < SIZE; j++) {
E[itera_][j] = 2.0;
F[itera_][j] = 0.5;
}
}//end forall

for (j = 0; j < SIZE; j++) {
C_aux = 0;
for (k = 0; k < SIZE; k++) {
}
Z[i][j] = C_aux;
}
}
}/*end multEF*/

int i, j, k;
double C_aux;
shared double G[SIZE][SIZE], H[SIZE][SIZE];
192

for (j = 0; j < SIZE; j++) {
G[itera_][j] = 2.0;
H[itera_][j] = 0.5;
}
}//end forall

for (j = 0; j < SIZE; j++) {
C_aux = 0;
for (k = 0; k < SIZE; k++) {
}
W[i][j] = C_aux;
}
}
}/*end multGH*/

int i, j;

for (j = 0; j < SIZE; j++) {
media1[i][j] = (X[i][j] + Y[i][j]) /2;
}
}//end forall
}/*end mediaXY*/

int i, j;

for (j = 0; j < SIZE; j++) {
media2[i][j] = (Z[i][j] + W[i][j]) /2;
}
193
}//end forall
}/*end mediaZW*/
void main()
{
int i, j;
create 6, multAB();
create 6, multCD();
create 6, multEF();
create 6, multGH();




}
}
}

Ex de Pesquisa Aplicada PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ex de Pesquisa Aplicada PDF

Caricato da

Copyright:

Formati disponibili

AUGUSTO MENDES GOMES JNIOR

Um Ambiente de Programao e Processamento de Aplicaes

AUGUSTO MENDES GOMES JNIOR

Um Ambiente de Programao e Processamento de Aplicaes

Tese apresentada Escola Politcnica da

AUGUSTO MENDES GOMES JNIOR

Um Ambiente de Programao e Processamento de Aplicaes

Tese apresentada Escola Politcnica da

descontrao e de aprendizado. Em especial, agradeo trs irmos que formei

Um sonho que se sonha s,

Palavras-Chave: Sistemas distribudos. Grades computacionais. Processamento de

Key-Words: Distributed systems. Grid computing. High performance computing.

LISTA DE ABREVIATURAS E SIGLAS

Application Program Interface

Backus Normal Form

Linguagem C com construes paralelas

Cluster-aware Random Stealing

Distributed Resource Managment

Distributed Shared Memory

Dynamically Updated Resource Online Co-Allocator

File Transfer Protocol

Global Access to Secondary Storage

Grid Cooperative Scheduling Environment

Grid File System

Globus Resource Allocation Manager

Grid Remote Procedure Call

Grid Checkpoint and Recovery

Grid Security Infrastructure

HyperText Transfer Protocol Secure

Java Virtual Machine

Laboratory of Architecture and High Perfomance Computing

Light-weIght Monitoring Architecture

Monitoring and Discovery Service

Message Passing Interface

Pool Resource Monitoring Manager

Parallel Virtual Machine

Simple Object Access Protocol

Single Program multiple Data

Transmission Control Protocol

Wide Area Network

Web Service Deployment Descriptor

eXtensible Markup Language

4.2.2 Monitoramento e Descoberta dos Servios (MDS) .............................. 62

7.5 Estratgia de escalonamento................................................................... 111

O paradigma de programao paralela [45], geralmente, utiliza variveis

computadores, como as linguagens C x C [34] e UPC (Unified Parallel C) [67].

Geralmente, os ns internos de um cluster possuem endereamento privado,

Monitoramento da execuo da aplicao;

Escalonamento dos ns;

Envio da aplicao para os ns remotos da grade;

Disparo e gerenciamento da execuo da aplicao;

Comunicao entre os ns da grade.

Atravs desta infraestrutura, o ambiente possibilita que uma aplicao escrita

Oferecimento de mecanismos de sincronizao e de primitivas para

Otimizao no escalonamento de tarefas e blocos para que a estrutura

Estratgia de atualizao das variveis, conforme a utilizao para

multiprocessadores para minimizar a troca de mensagens.

desenvolvimento de aplicaes paralelas, geralmente utiliza memria compartilhada

proposta apresentada nesta tese utiliza variveis compartilhadas para a troca de

envio/recebimento de mensagens. Alm disso, a estrutura de uma varivel mais

compartilhadas em um sistema distribudo heterogneo (quanto ao nmero de

caractersticas foram estudados. Com base neste estudo, o ambiente CPAR-Grid

O ponto fundamental foi a definio do modelo de processamento, orientado