UNIVERSIDADE TUIUTI DO PARAN FACULDADE DE CINCIAS EXATAS E TECNOLOGIA CURSO DE CINCIA DA COMPUTAO Professor: Gilson Luiz Santin Disciplina:

Sistemas Distribudos 2010, 2 1 Introduo Multiprocessamento um termo que pode ser aplicado a duas combinaes distintas: - processamento em computadores separados Sistemas Distribuidos (SD), ou - processamento em nico computador dotado de mais de um processador Sistemas Concentrados (SC). O primeiro caso requer um sistema de controle e comunicao em rede entre os computadores para a distribuio de tarefas e coleta dos resultados. J no segundo existem benefcios adicionais, especialmente com a possibilidade de comunicao mais rpida, e em baixo nvel (barramento), entre os processadores. Sistemas multiprocessados geralmente so implementados nos modelos: SMP ou NUMA. SMP - Multiprocessamento simtrico: os processadores compartilham a mesma memria, embora possam ter caches separadas. O sistema operacional deve estar preparado para trabalhar com coerncia de caches e, principalmente, evitar condies de conflito na memria principal. NUMA - Acesso no uniforme memria: a cada processador associado um banco de memria. Nesse caso, o sistema operacional trata cada banco separadamente, pois cada banco tem um acesso diferente, dependendo de qual processador est associado a ele e onde est sendo executado o processo que tenta acessar a memria. Sistemas Distribudos Sistemas Distribudos so sistemas compostos de computadores acoplados, interconectados por rede que fornecem servios, disponibilizam acesso e manuseio de dados alm de compartilhar diversos recursos, resultando em uma diversidade de classificaes e comparaes. Entre os maiores computadores do mundo, mais de 200 so clusters (trata-se de um tipo de sistema distribudo a partir de computadores convencionais desktops, cada mquina denominada n ou nodo), e eles podem ser conectados para formar redes ainda maiores, os chamados grids (grades) computacionais. A idia realmente interessante: somar os recursos ociosos de mquinas independentes para chegar a um poder de processamento de supercomputadores. Surge, ento, uma nova modalidade: a computao sob demanda, Web services e aluguel de capacidade de processamento na Internet. Para que tudo isso funcione, as aplicaes precisam ser divididas e as tarefas distribudas de forma inteligente, com alta disponibilidade e desempenho. As principais questes abordadas em Sistemas Distribudos dizem respeito a algoritmos distribudos, sistemas operacionais e kernels, ambientes de programao (linguagens), confiabilidade (tolerncia a falhas e segurana), sistemas multimdias, sistemas de tempo real (por exemplo: automao industrial, robtica, aviao e eletrnica automotiva), heterogeneidade dos equipamentos e de protocolos de comunicao, integridade de dados e o controle de acesso a eles, a extenso das aplicaes distribudas em redes de dimenso mundial, requisitos de segurana e o atendimento das restries temporais, so alguns dos desafios atuais em Sistemas Distribudos. O desenvolvimento de aplicaes em arquiteturas distribudas tem sido largamente utilizado, pricipalmente devido ao volume de processamento e a disponibilidade de hardware a baixo custo, proporcionando uma integrao com diversas reas. O conceito de sistemas abertos e hbridos, padres de comunicao, os modelos de orientao a objetos e servios, as ferramentas para implementao WEB, as metodologias para desenvolvimento de sistemas mesmo em presena de falhas e as tcnicas de escalonamento em tempo real so alguns dos suportes disponveis para criar aplicaes distribudas. Programas em execuo sobre diversos processadores no precisam ser necessariamente distintos. Neste caso utiliza-se o modelo SPMD (Single Program - Multiple Data). Este modelo implica que sejam distribudos pelos processadores o mesmo cdigo fonte, e cada processador deve execut-lo de maneira independente. Quando se distribui cdigos fonte distintos para os processadores, utiliza-se o modelo MPMD (Multiple Program - Multiple Data). Visto que os diferentes programas em um ambiente MPMD podem ser unidos em um s, excetuando-se um eventual gasto maior de memria em cada processador, praticamente no h perda de desempenho na utilizao deste modelo. O ganho, neste caso, reside na simplicidade de gerenciamento de um sistema deste tipo. O modelo MPMD tambm chamado por alguns autores de MIMD (Multiple Instruction Multiple Data) e tem se destacado na computao paralela devido a sua flexibilidade e potencialidade para a execuo de programas paralelos de alta e mdia granularidade1. Entre as plataformas MIMD destacam-se as plataformas de memria distribuda, que podem ser computadores paralelos ou mquinas paralelas virtuais. Este modelo bastante genrico envolvendo o processamento de mltiplos dados por parte de mltiplas instrues. Neste caso, vrias unidades de controle comandam suas unidades funcionais, as quais tm acesso a vrios mdulos de memria. Qualquer grupo de mquinas operando como uma unidade (deve haver certo grau de interao entre as mquinas) enquadra-se como
1

Granularidade, ou nvel de paralelismo, define o tamanho das unidades de trabalho submetidas aos processadores. Esta uma definio importante na computao paralela, visto que est ligada ao tipo de plataforma (o porte e a qualidade de processadores) qual se aplica o paralelismo. Pode ser dividida em fina, mdia e grossa. Granularidade grossa relaciona o paralelismo em nvel de processos e programas, e geralmente se aplica a plataformas com poucos processadores grandes e complexos. Granularidade fina relaciona paralelismo em nvel de instrues ou operaes e implica em grande nmero de processadores pequenos e simples. A granularidade mdia situa-se em um patamar entre as duas anteriores, implicando em procedimentos sendo executados em paralelo.

MIMD. Alguns representantes desta categoria so os servidores multiprocessados, as redes de estaes e as arquiteturas massivamente paralelas. Processamento Paralelo Processamento paralelo consiste na utilizao de mltiplos processadores para executar partes diferentes de um mesmo programa simultaneamente. O principal objetivo reduzir o tempo total de processamento (wallclock time). Processamento paralelo a execuo de mais de uma tarefa ao mesmo tempo atravs do uso de vrios processadores. Trata-se de um conjunto de processadores que trabalham cooperativamente para resolver um problema computacional. Os processadores podem estar na mesma mquina, nesse caso, tem-se alto desempenho na comunicao em funo da memria compartilhada. Princpio: Uma grande tarefa dividida em partes menores para serem executadas em paralelo. Objetivo: Reduzir o tempo de processamento. Algumas literaturas chamam de paralelismo: Sobreposio de I/O e processamento utilizando threads; Sobreposio de preparao da Instruo e sua execuo (pipeline2); Paralelismo Temporal; Processamento Superescalar; Separao de operaes com inteiros e ponto flutuante em ULAs3 diferentes. Paralelismo Realizar mais de uma tarefa simultaneamente pode ser interpretado como paralelismo, mesmo que as tarefas sirvam a fins diferentes ou relacionados. Quando elas prestam-se ao mesmo fim, preciso identificar se uma delas depende da outra, ou seja, se podem ser executadas em qualquer seqncia temporal. Este um dos aspectos importantes para compreender por que no possvel dobrar a performance com a utilizao de duas CPUs iguais. Por exemplo, imagine uma seqncia de anlise condicional com vrios ramos (vrias estruturas similares a se...ento... seno). impossvel passar para o prximo ramo sem antes determinar o resultado do anterior. Talvez no seja nem possvel pr-determinar (pr-fetch) o resultado de um prximo ramo se um dos operando depender do resultado anterior. A programao paralela potencialmente mais complexa que a programao seqencial. Principalmente porque envolve a necessidade de sincronizao entre tarefas (troca de mensagens para controle da execuo das tarefas), como tambm a anlise de dependncia de dados (os resultados de uma instruo so necessrios para o processamento das prximas instrues) e dependncia de recursos (mais de uma instruo concorre pelo mesmo recurso). Em mquinas multiprocessadas, as tarefas podem ser divididas indiscriminadamente entre os vrios processadores, ou ento cada processador pode assumir a responsabilidade de executar determinada tarefa. Isto determina o modelo de multiprocessamento, como descrito a seguir. Modo SMP Symmetric Multiprocessing a tcnica de processamento paralelo que procura dividir a carga de operaes igualmente entre todos os processadores. o mtodo mais adotado atualmente pelos sistemas operacionais mais populares. As operaes de processamento so entregues aos processadores mais desocupados. Neste modelo todos os recursos so compartilhados, desde barramentos, memria e dispositivos. Algumas operaes, como o boot privilegia um dos processadores, mas nas demais operaes todos os processadores so tratados sem distino. Modo ASMP - A tcnica Assymmetric Multiprocessing filtra as tarefas para cada processador. Usualmente um dos processadores s se dedicar a cuidar do sistema operacional, enquanto os outros se encarregam das demais tarefas. As desvantagens so evidentes, especialmente quando h apenas dois processadores. Modo MPP - Este modelo, o Massively Parallel Processing, quase o oposto do SMP. Nenhum recurso compartilhado, nem mesmo o sistema operacional nico h uma cpia sendo executada em cada poro de memria destinada a cada processador. A multiprogramao (ou programao concorrente - multitarefa) originada em funo da velocidade do processador ser superior aos demais componentes, ocasionando a subutilizao do processador. Desta forma a tcnica de multiprogramao permite utilizar o processador em seu tempo ocioso, executando processamentos de vrios programas num curto espao de tempo, dando ao usurio a idia de paralelismo (pseudoparalelismo). Associado a esse fato surgiu o conceito de processo que uma abstrao de um programa e pode ser entendido como um programa em execuo. Um processo constitudo de vrios tens, como por exemplo: espao de endereamento; descritores de arquivos abertos; permisses de acesso; quotas, dentre outros. Tambm est associado ao processo um fluxo de execuo. Um thread, portanto, um fluxo nico de controle dentro de um programa e contm informaes a respeito da execuo do mesmo como, por exemplo, pode ser o contador do programa que indica a prxima instruo a ser executada na pilha de execuo. Threads podem ser definidos como linhas de execuo dentro do cdigo do aplicativo. Eles so partes de um mesmo processo, compartilham os seus recursos, como o espao de endereamento, cdigo e dados e, devido a essa caracterstica a gerncia de threads (criao, destruio, troca de contexto, sincronizao) mais leve quando comparada com processos. Cada programa, ou processo, possui normalmente um fluxo de controle. Assim o programa executado sequencialmente passo a passo com seu nico fluxo de controle. nesse ponto que entram os threads, eles permitem ter mais de um nico fluxo de controle no aplicativo. Assim o aplicativo agir como se existissem vrios pequenos aplicativos com partes de seu cdigo atuando em paralelo no sistema. Logo Threads tambm podem ser
2

Pipelining uma tcnica muito utilizada para aumentar o desempenho de tarefas seqenciais de software. Trata-se de uma tcnica onde se dividem tarefas seqenciais em estgios distintos que podem ser executados no modelo de linha estruturada. Em outras palavras uma tcnica que permite a execuo de mltiplas instrues em um nico ciclo de clock. 3 ULA Unidade Lgica Aritmtica, ela executa as principais operaes lgicas e aritmticas do computador. Ela soma, subtrai, divide, determina se um nmero positivo ou negativo ou se zero. Alm de executar funes aritmticas, uma ULA deve ser capaz de determinar se uma quantidade menor ou maior que outra e quando quantidades so iguais. A ULA pode executar funes lgicas com letras e com nmeros.

percebidos como entidades escalonadas para execuo na CPU, por isso, a simulao de uma espcie de paralelismo, pois threads concorrero pelo processador juntamente com outros que existirem no programa. Threads permitem que mltiplas execues ocorram no mesmo ambiente do aplicativo com certo grau de independncia entre eles, portanto, se existir muitos threads sendo executados em paralelo no sistema anlogo dizer que temos mltiplos aplicativos sendo executados em paralelo no computador. Deve-se salientar que o termo multithreading nada mais do que um aplicativo possuir vrios threads desse mesmo aplicativo. Tambm se deve ressaltar que threads podem compartilhar o mesmo espao de endereamento do aplicativo em execuo, portanto, nota-se que ao invs de criarmos um novo aplicativo para fazer uma determinada tarefa desse aplicativo, mais vivel criar um thread para esse fim, visto que criar um aplicativo requer muito processamento por parte do processador, alm de alocar mais memria para o novo aplicativo. Por exemplo, um browser pode executar varias atividades ao mesmo tempo, enquanto fazemos um download podemos clicar em um link, usar a barra de rolagem, etc. Isso s possvel graas aplicao do conceito de Multithreads que nada mais do que vrios threads de um mesmo processo. Na evoluo da fabricao de processadores destacam-se duas tecnologias: hyper-threading (HT) e a multicore. A tecnologia hyper-threading possibilita o processamento concorrente atravs do uso de threads. Esta tecnologia simula em um nico processador fsico dois processadores lgicos. Cada processador lgico recebe seu prprio controlador de interrupo programvel e um conjunto de registradores. Os outros recursos do processador fsico, tais como, cache de memria, unidade de execuo, unidade lgica e aritmtica, unidade de ponto flutuante e barramentos, so compartilhados entre os processadores lgicos. Em nvel de software, significa que o sistema operacional pode enviar tarefas para os processadores lgicos como se estivesse enviando para processadores fsicos em um sistema de multiprocessamento. A segunda tecnologia, multicore, o ltimo conceito em tecnologia de processadores. Tecnologia, constituda de mltiplos ncleos, ou seja, duas ou mais unidades fsicas de execuo no interior de um nico chip. O sistema operacional trata esses ncleos como se cada um fossem processadores diferentes, com seus prprios recursos de execuo. Em processadores de mltiplos ncleos, cada ncleo possui sua prpria memria cache, assim os sistemas operacionais dispem de recursos para trabalhar com processos que so executados em paralelo. A diferena entre a tecnologia hyper-threading e a multicore, que a primeira limitada a um nico ncleo que utiliza os recursos de execuo de forma mais eficiente para realizar o processamento. J a segunda proporciona dois ou mais conjuntos completos de recursos de execuo (processamento paralelo) que possibilitam o aumento do desempenho dos processos em execuo. Sabemos que no processamento concorrente os processos se alternam na CPU dando a impresso ao usurio que tudo esta acontecendo ao mesmo tempo. A execuo de threads anloga, eles se alternam esperando sua vez para executar, a diferena bsica que processos executam com maior independncia do que threads, pois threads de um mesmo processo compartilham o mesmo espao de endereamento de memria. Nesse caso, threads compartilham recursos comuns e, para gerenciar o uso desses recursos necessrio sincronizar a execuo. Alm disso, cada thread pode acessar qualquer endereo de memria dentro deste espao. Dessa forma, um thread pode alterar dados em outro, j que no existe mecanismo de proteo de acesso, os threads devem cooperar entre si, o que mostra mais uma vez a necessidade de sincronizao. importante salientar que embora seja fundamental o cuidado em sincronizar threads, as vantagens que eles proporcionam execuo de um processo superam as dificuldades desse trabalho. muito mais simples criar threads dentro de um mesmo processo do que ter que criar dois processos para atender a mesma funo. Alm disso, como os threads esto compartilhando um mesmo espao de endereamento, a comunicao entre eles muito mais rpida do que entre processos. A implementao de Multithreads, com seus devidos cuidados, tende a aumentar o desempenho do programa. Na sincronizao imprescindvel entender que um aplicativo possui uma rea de disputa de memria compartilhada entre os threads, essa rea denomina-se Regio Critica. Para que uma aplicao torne-se confivel ter que garantir que somente um thread utilizara a Regio Critica por vez - Excluso mtua. A conduta ideal de um programador que desejar utilizar a sincronizao perceber quando mais de um thread modifica uma determinada rea de memria em comum. No necessria a sincronizao quando os valores da memria compartilhada no so modificados, ou seja, caso os threads s compare ou tome qualquer outro tipo de deciso que no venha modificar os dados da memria compartilhada entre os threads. Sabendo que atualmente as empresas de processadores esto investindo em arquiteturas paralelas, a utilizao da programao multithread, que consiste em colocar vrios fluxos de execuo (threads) dentro de um nico processo, passa a ser uma alternativa muito interessante. O desenvolvimento de programas depende do tipo de arquitetura onde o mesmo ser executado. Nas arquiteturas onde a memria distribuda precisa-se utilizar a tcnica de troca de mensagens para que seja feita a comunicao e sincronizao entre processos, j nas arquiteturas que compartilham memria, threads ou processos utilizam o mesmo espao de endereamento, assim a comunicao entre eles feita atravs da prpria memria. Um programa que utiliza troca de mensagens pode ser definido como um conjunto de programas seqenciais, distribudos em vrios processadores, que se comunicam atravs de um conjunto limitado e bem definido de instrues. Estas instrues formam o ambiente de troca de mensagens e so disponibilizadas atravs de uma biblioteca de troca de mensagens. Um ambiente de programao via troca de mensagens pode ser criado por linguagem seqencial como C, Fortran, e etc, que ser utilizada na implementao do cdigo fonte dos programas seqenciais, e a biblioteca de troca de mensagensfornecer as ferramentas necessrias para a ativao e cooperao entre os processos paralelos.

2 Histrico Computadores iniciais: grandes e elevado custo. Anos 50 e 60: batching, spooling batching: juntar jobs semelhantes para processamento spooling: sobreposio de I/O e CPU Objetivo: otimizar a utilizao da CPU Incio dos anos 60: Sistemas Time Sharing4 Primeiro passo na direo dos Sistemas Distribudos Incorpora dois conceitos fundamentais: Compartilhamento de recursos e Acesso remoto. Final dos anos 60 e incio dos anos 70: Surgimento das redes / Unix. Anos 70: Protocolo TCP/IP A Tecnologia de Objetos (Object Technology) foi introduzida no fim dos anos 70 com uma linguagem chamada Smalltalk. No modelo orientado a objetos, sistemas so visualizados como objetos cooperantes, que encapsulam estrutura e comportamento, pertencentes a classes hierarquicamente construdas. Anos 80: Incio dos anos 80: Microprocessadores e estaes de trabalho. Reduo do custo (em relao aos mainframes). A Tecnologia de Distribuio (Distributed Technology), a qual envolve computadores autnomos, no compartilhando memria fsica, conectados atravs de uma rede, data do incio dos anos 80. Os modelos modernos de distribuio evoluram a partir da arquitetura tradicional, passando a utilizar a tecnologia middleware5 que geralmente fornecem uma infra-estrutura runtime de servios para a interoperao de componentes (objetos) com a transparncia de localizao entre os computadores e objetos. Estaes de trabalho ligadas em rede. Diversos servios para comunicao entre pessoas/mquinas: FTP, TELNET, MAIL. Anos 90: Internet Rede mundial: World Wide Web (Web Technology) nasceu nos anos 90 e rapidamente causou uma exploso no uso da Internet e a disseminao de sistemas distribudos. Anos 2000 O Hyper-Threading foi introduzido no final de 2002, na forma de duas verses especiais do Pentium 4 Northwood (soquete 478), que operavam a 2.8 e 3.06 GHz. Com o Hyper-Threading, o processador se apresenta ao sistema operacional como um sistema dual-core. Com isso, o sistema ativa os mdulos que ativam o suporte a SMP e passa a dividir o processamento dos aplicativos entre os dois processadores lgicos. Em 2006 so lanados no mercado, os processadores dual core tecnologia de multiprocessamento simtrico ou SMP (Symmetric Multi-Processing). Antigamente para implementar o modelo SMP era necessrio hardware especfico, placas-me com dois ou mais soquetes de CPU, grandes estruturas de servidores clusterizados. Hoje em dia com a tecnologia multi-core, as fabricantes j integram tudo isso em apenas um dispositivo fsico, tambm conhecidos como processadores multi-core. O futuro prximo o das mquinas multiprocessadas. No caso do multiprocessamento, o limite atual reside no sistema operacional. No adianta o computador ter um nmero elevado de processadores ou uma rede de computadores numerosa se o sistema operacional no gerenci-los com transparncia. Colocar mais de um processador em um nico chip realmente vivel para possibilitar a reduo do clock (velocidade), pois em funo da alta frequncia (GHz) de operao at uma simples trilha de circuito impresso tem influncia considervel devido emisso de microondas e energia dissipada (calor). A sada mais lgica foi
4

Time Sharing (tempo compartilhado) um termo referente a sistemas operacionais, que surgiu durante a 3 gerao dos sistemas operacionais, atualmente em sua 4 gerao. Este conceito significa compartilhamento de tempo, ou seja, o tempo ocioso entre os processos so compartilhados com outros processos para dinamizar o sistema. Mltiplas tarefas so executados concorrentemente, sendo que a CPU atende cada tarefa por um determinado tempo, em sequncia. Os tempos dedicados para cada tarefa so pequenos o suficiente para dar a iluso de que as tarefas esto sendo executadas simultaneamente. 5 Middleware ou mediador, no campo de computao distribuda, um programa de computador que faz a mediao entre outros softwares. utilizado para mover informaes entre programas ocultando ao programador diferenas de protocolos de comunicao, plataformas e dependncias do sistema operacional. geralmente constitudo por mdulos dotados com APIs de alto nvel que proporcionam a sua integrao com aplicaes desenvolvidas em diversas linguagens de programao e interfaces de baixo nvel que permitem a sua independncia relativamente ao dispositivo. Seu objetivo mascarar a heterogeneidade e fornecer um modelo de programao mais produtivo para os programadores de aplicativos. composto por um conjunto de processos ou objetos em um grupo de computadores, que interagem entre si de forma a implementar comunicao e oferecer suporte para compartilhamento de recursos a aplicativos distribudos. Exemplos: Monitores de processamento de transaes; Conversores de dados; Controladores de comunicao.

desenvolver chips com vrios processadores operando em clocks menores, o que diminuiu emisso de calor e proporcionou uma maior eficincia do processamento em funo da distribuio de tarefas. Boa parte do mundo acadmico aposta em projetos de Sistemas Operacionais nos moldes do Hurd 6 da Debian. Com ele e sem nenhuma biblioteca especial, o sistema rodaria qualquer programa realmente multiprocessado. O Hurd, o quase mtico kernel que est sendo preparado h anos por desenvolvedores GNU, pode ser a soluo para o processamento paralelo. Considerando que a tendncia ser de que os Sistemas Operacionais fiquem independentes do nmero de processadores e os Sistemas Distribudos absorvam tambm esta heterogeneidade de mquinas multicore (com grande diversidade de ncleos especializados), pode-se vislumbrar num tempo bem prximo a criao de computadores que contemplem todos estes recursos concentrados em uma nica mquina ou chip. To logo isto ocorra o poder concentrado de processamento de uma mquina dessas superaria de longe a capacidade da raa humana. Uma pessoa, por enquanto, ainda processa mais dados em paralelo do que um computador, embora a freqncia do crebro seja consideravelmente baixa (Hz) o volume, a diversidade e complexidade de dados (cinco sentidos) processados pelas pessoas so relativamente alto quando comparados as atuais capacidades dos computadores multicore. 3 Definies e Classificaes As diversas combinaes de hardware e suas caractersticas funcionais permitem varias classificaes (taxonomia) em realao a algum aspecto em particular que ser considerado como caracterstica de destaque do sistema. A unio coordenada desses diversos computadores com o objetivo de colaborar na execuo de tarefas, conhecida como Sistema Sistribudo. Definies de Sistemas Distribudos Segundo Andrew Tanenbaum uma coleo de computadores independentes que parecem um sistema nico para o usurio Transparncia. Segundo George Coulouris Sistema onde os componentes de HW e SW, localizados em computadores autnomos interligados por uma rede, se comunicam e coordenam suas aes atravs de troca de mensagens. Segundo Leslie Lamport Voc sabe que tem um sistema distribudo quando a falha de um computador do qual voc nunca ouviu falar faz com que voc pare completamente de trabalhar. Sistemas Homogneos Composto por mquinas onde os processadores, memria e rede so iguais ou muito semelhantes. Mais empregado em aplicaes para processamento paralelo (processando um nico problema) Sistemas Heterogneos Neste tipo de conjunto as mquinas que compe o arranjo tm processadores, memria e redes de vrios tipos e modelos. Sistemas Multiprocessadores (SMP) ou Centralizados Maquinas MIMD com memria compartilhada (um nico espao de endereamento compartilhado por todos processadores). Fortemente acoplado (tighly coupled): comunicao rpida entre processadores (grande nmero de bits por segundo). Sistemas Multicomputadores (SMC) ou Distribudos Maquinas que no possuem memria compartilhada, isto , cada processador possui sua memria privada. Fracamente acoplado (loosely coupled): atraso na troca de mensagens entre as mquinas muito alto. Taxonomia Flynn Dentre as classificaes de arquiteturas de computadores existentes a mais duradoura e ainda razovel foi proposta em 1966 por Flynn7, leva em considerao o nmero de fluxo de instrues e o nmero de fluxo de dados. Flynn props que as 2 dimenses sejam chamadas: Instrues e Dados. Ambas, podem assumir dois valores: nico e Mltiplo. As 2 dimenses podem ser representadas por uma matriz 2 x 2 e cada uma das 4 clulas caracteriza um tipo nico de arquitetura:

O Hurd um conjunto de servidores que funcionam sobre o microkernel GNU Mach. Juntos eles formam a base para o sistema operacional GNU. O Hurd almeja superar os ncleos tipo Unix em termos de funcionalidade, segurana e estabilidade, e ao mesmo tempo manter uma certa compatibilidade com o Unix. 7 Michael J. Flynn (nascido em 20 de maio de 1934 em Nova Iorque) professor emrito da Universidade de Stanford. Cofundador da Palyn Associates com Max Paley e presidente da Maxeler Technologies. props a Taxonomia de Flynn em 1966.

SISD (Single Instruction Single Data) nico fluxo de instrues atua sobre um nico fluxo de dados. Funcionamento: Fluxo de instrues alimenta a unidade de controle UC que ativa o elemento central de processamento EP. O EPatua sobre o fluxo de dados que lido, processado e reescrito na memria M. Exemplos: Mquinas de Von Neumman com apenas um processador, como PCs e estaes de trabalho, computadores seqenciais comuns.

MISD (Multiple Instruction Single Data) Mltiplos fluxos de instrues atuariam sobre um nico fluxo de dados. Mltiplos elementos de processamento EP (cada um com uma unidade de controle C), recebendo um fluxo diferente de instrues. Estas sero executadas sobre o mesmo fluxo de dados, operam como um pipeline. Sem aplicabilidade comercial, somente terica, systolic arrays.

SIMD (Single Instruction Multiple Data) Uma nica instruo executada ao mesmo tempo sobre mltiplos dados. Existe uma nica unidade UC, alimentada por um nico fluxo de instrues. A mesma instruo enviada para mltiplos processadores, onde estes executam suas instrues em paralelo de forma sncrona sobre diferentes fluxos de dados. O mesmo programa est sendo executado sobre diferentes dados. Exemplos: Mquinas Vetoriais como CM-2 e MasPar.

MIMD (Multiple Instruction Multiple Data) Cada unidade UC recebe um fluxo de instrues prprio e repassa-o para sua unidade EP. Ou seja, cada processador executa seu prprio programa sobre seus prprios dados, de forma assncrona. Exemplo: Grupo de Mquinas em cluster, computadores paralelos intrnsecos. CM-5, nCUBE, Inter Paragon e Cray T3D. Atualmente os computadores multicore.

Taxonomia Flynn-Johnson: Eric E Johnson props em 1988 um complemento na taxonomia Flynn para as arquiteturas do tipo MIMD com base na: - Estrutura de Memria: Global ou Centralizada e Distribuda. - Mecanismo de Comunicao: Passagem de Mensagem e Variveis Compartilhadas.

Comunicao Sincronizao Shared Variables Comunicao Implcita - atravs do compartilhamento de variveis em operaes de load e store. Message Passing Comunicao Explcita - atravs da troca de mensagens em operaes de send e receive. Estrutura de Memria: - Memria Global ou Centralizada nico espao de endereamento, a memria encontra-se mesma distncia de todos os processadores. Todos os processadores acessam a mesma memria fsica. UMA Uniform Memory Access Multiprocessadores Memria Centralizada Mesma distncia (latncia) de todos os processadores A interconexo mais utilizada o barramento. - Memria Distribuda Mltiplos espaos de endereamento privados. A memria definida para cada processador separadamente. Cada processador acessa o seu endereamento de memria. NUMA Non Uniform Memory Access Multiprocessadores ou Multicomputadores Memria distribuda em mltiplos mdulos associados a cada processador. Espao de endereamento nico para todos os processadores. A distncia memria no sempre a mesma e depende do endereamento desejado. Tempo de acesso no uniforme. Implementao atravs de hardware ou software.

Classificao segundo Tanenbaum Arquitetura de Hardware quanto memria pode ser classificada quanto: O local da memria principal: Centralizada Distribuda A existncia ou no de vrias cpias dos dados em locais diferentes: Simples Mltiplas-Cpias

UMA (Uniform Memory Access) Acesso uniforme a memria. Memria Centralizada Mesma distncia / latncia de todos os processadores Rede de Interconexo / comunicao: Barramento NUMA (Non Uniform Memory Access) Acesso no uniforme a memria. Memria distribuda em mltiplos mdulos associados a cada processador. A distncia da memria depende do endereamento desejado Espao de endereamento nico para todos os processadores NCC-NUMA (Non Cache Coherence Non Uniform Memory Access) Sem coerncia de cache8 em hardware CC NUMA (Cache Coherence Non Uniform Memory Access) Com coerncia de Cache em Hardware SC-NUMA (Software Coherence - Non Uniform Memory Access) Cache garantida em software - transparncia para o usurio; Duas abordagens possveis: Modificar o mecanismo de gerncia de um S.O (Shared Virtual Memory SVM). Utilizar compiladores e bibliotecas para converter o cdigo desenvolvido. CC-UMA (Cache Coherent Uniform Memory Access) Coerncia de Cache por hardware COMA (Cache-Only Memory Architecture) Arquitetura de memria somente com cache Todas as memrias locais esto estruturadas com memria cache. (COMA caches). Mais caras Tm mais capacidade que caches normais, sendo que elas compem a memria principal das mquinas. Hardware de suporte deve integrar a gerncia de caches e a gerncia de memria. Existe um diretrio de cache (D) que auxilia no acesso a cache remota. NORMA (Non-Remote Memory Access) No memria compartilhada. Sem acesso a variveis remotas. Os registradores e endereamento de cada n s conseguem enderear a sua memria local. Classificao segundo o compartilhamento de memria

Coerncia de Cache: Em sistemas com memria compartilhada em que os processadores fazem uso de caches necessrio manter a consistncia dos dados armazenados nessas caches. Existem dois tipos bsicos de protocolo de coerncia de cache: 1 - Para sistemas que fazem uso de barramento compartilhado; 2 - Para sistemas que fazem uso de redes de interconexo. O principal problema ocorre quando um processador modifica (escreve) em um dado que est em um bloco (linha) armazenado na sua cache.

DSM (Distributed Shared Memory) Memria Compartilhada Distribuda Uma abstrao usada para compartilhar dados entre computadores que no dividem a mesma memria fsica (memria principal) multicomputadores com barramento Camada de SW que implementa a abstrao de um espao comum de endereamento integra memrias locais isoladas em uma nica entidade lgica.

As aplicaes podem usar DSM como memria local: tambm chamado de Distributed Shared Virtual Memory

Estrutura geral de sistemas com DSM Os nodos tem memria local e um ou mais processadores, nodos so interconectados por rede de alta velocidade. O SW em cada nodo faz funo de Memory-mapping Manager: - mapeia memria local na DSM - a memria compartilhada particionada em blocos O cache utilizado para reduzir latncia de acesso memria remota, a memria principal dos nodos usada para cachear DSM. O Memory-mapper de cada nodo v a memria local como uma grande cache da DSM, unidade bsica de caching o bloco Procedimento de acesso: O processo em um nodo acessa posio de memria da DSM. O memory-mapper local toma conta do pedido: - se o bloco contendo os dados acessados reside na memria local, o request satisfeito passando os dados locais. - seno gera um network block fault (manda mensagem para nodo onde o bloco est, o bloco migra para o nodo onde o processo deseja acessar) Cpias de blocos podem ser mantidas, necessidade de coerncia. 4 Modelos de Computao Distribuda A computao distribuda consiste em adicionar o poder computacional de diversos computadores interligados por uma rede de computadores ou mais de um processador trabalhando em conjunto no mesmo computador, para processar colaborativamente determinada tarefa de forma coerente e transparente, ou seja, como se apenas um nico e centralizado computador estivesse executando a tarefa. Arquitetura Multiprocessos Modelo mais simples de sistema distribudo. Sistema composto de mltiplos processos que podem (mas no precisam) ser executados em diferentes processadores. Modelo utilizado em vrios sistemas de grande porte em tempo real. A distribuio de processos para os processadores pode ser predeterminada ou pode ficar sob o controle de um escalonador.

Sistema de controle de trfego multiprocessado Arquitetura Cliente-servidor Cliente-servidor um modelo computacional que separa clientes e servidores, interligados entre si geralmente utilizando-se uma rede de computadores. Cada instncia de um cliente pode enviar requisies de dados

para algum dos servidores conectados e esperar pela resposta. Por sua vez, algum dos servidores disponveis pode aceitar tais requisies, process-las e retornar o resultado para o cliente. Apesar do conceito ser aplicado em diversos usos e aplicaes, a arquitetura praticamente a mesma. A aplicao modelada como um conjunto de servios que so fornecidos pelos servidores e um conjunto de clientes que utilizam esses servios. Clientes conhecem os servidores disponveis, mas os servidores no precisam conhecer os clientes. Clientes e servidores so processos lgicos. O mapeamento de processadores a processos no necessariamente 1:1.

Caractersticas do Cliente Sempre inicia pedidos a servidores; Espera por respostas; Recebe respostas; Normalmente, se conecta a um pequeno nmero de servidores de uma s vez; Normalmente, interage diretamente com os usurios finais atravs de qualquer interface com o usurio , como interface grfica do usurio. Caractersticas do Servidor Sempre esperar por um pedido de um dos clientes; Serve os clientes pedidos, em seguida, responde com os dados solicitados aos clientes; Um servidor pode se comunicar com outros servidores, a fim de atender uma solicitao do cliente. Vantagens Na maioria dos casos, a arquitetura cliente-servidor permite que os papis e responsabilidades do sistema de computao pode ser distribudo entre vrios computadores independentes que so conhecidos so pela rede interna. Isso cria uma vantagem adicional para essa arquitetura: maior facilidade de manuteno. Por exemplo, possvel substituir, reparar, atualizar ou mesmo realocar um servidor, enquanto seus clientes continuam trabalhando sem ser afetado por essa mudana; Todos os dados so armazenados nos servidores, que geralmente possuem controles de segurana muito maior do que a maioria dos clientes. Servidores podem controlar melhor o acesso e recursos, para garantir que apenas os clientes com as permisses adequadas podem acessar e alterar dados; O armazenamento de dados centralizado, as atualizaes dos dados so muito mais fceis de administrar, em comparao com o paradigma P2P, onde atualizaes de dados podem estar distribuda em cada ponto na rede, e pode haver milhares ou mesmo milhes de pares; Muitas tecnologias avanadas de cliente-servidor j esto disponveis, e foram projetadas para garantir a segurana e interface com o usurio de facil operao; Funciona com vrios clientes diferentes de capacidades diferentes. Desvantagens Redes com muito trfego um dos problemas relacionados com o modelo cliente-servidor. Como o nmero de solicitaes simultneas de cliente para um determinado servidor, o servidor pode ficar sobrecarregado; O paradigma cliente-servidor no tem a robustez de uma rede P2P. Na arquitetura cliente-servidor, se um servidor crtico falhar, os pedidos dos clientes podem no ser cumpridos. Em redes P2P, os recursos so normalmente distribudos entre vrios ns. Mesmo se um ou mais ns desaparecem, os ns restantes podem ainda completar o download. Arquitetura P 2 P Peer-to-Peer (do ingls: par-a-par), entre pares, uma arquitetura de sistemas distribudos caracterizada pela descentralizao das funes na rede, onde cada n realiza tanto funes de servidor quanto de cliente. Os ns da rede Peer-to-Peer podem diferir em termos de configurao local, capacidade de processamento, capacidade de armazenamento, largura de banda, entre outras caractersticas particulares. Exemplos: Gnutella9, SETI10 (Search for Extra-Terrestrial Intelligence). O primeiro uso da expresso Peer-to-Peer foi em 1984, com o desenvolvimento do projeto Advanced Peer-to-Peer Networking Architecture na IBM. Caractersticas
9

Gnutella - Rede open-source surgida no final de 2000 utilizada inicialmente por usurios do sistema Linux. Possui uma estrutura altamente descentralizada no havendo mesmo nenhum servidor central sequer. Os usurios constituem a estrutura da prpria rede. Entre os programas que a utilizam, esto o BearShare , LimeWire, Azureus e agora o Shareaza. 10 SETI (sigla em ingls para Search for Extra-Terrestrial Intelligence, que significa Busca por Inteligncia Extraterrestre) um projeto que tem por objetivo analisar o mximo de sinais de rdio captados por radiotelescpios terrestres (principalmente pelo Radiotelescpio de Arecibo), A nova verso do programa de computao distribuda a aplicao pioneira do BOINC - Berkeley Open Infrastructure for Network Computing, um sistema com o que h que mais moderno em termos de Grid e Computao distribuda.

Geralmente, uma rede Peer-to-Peer constituda por computadores ou outros tipos de unidades de processamento que no possuem um papel fixo de cliente ou servidor, pelo contrrio, costumam ser considerados de igual nvel e assumem o papel de cliente ou de servidor dependendo do tipo de transao iniciada ou recebida de um outro par da rede. Esta modelo permite que cada usurio contribua com recursos para o sistema. Apesar de que eles poam diferir nos recursos que contribuem, todos os nodos em um sistema peer-to-peer possuem as mesmas capacidades funcionais e responsabilidades. Heterogeneidade Em redes peer-to-peer, a heterogeneidade dos recursos envolvidos uma preocupao que deve ser levada em conta durante o seu projeto. Computadores e conexes administrados por diferentes usurios e organizaes no tm garantias de ficarem ligados, conectados ou sem falhas, o que os torna necessariamente recursos volteis. Isso torna a disponibilidade dos nodos de uma rede peer-to-peer imprevisvel. Essa imprevisibilidade no permite garantir acesso a recursos individuais, j que eles podem falhar. Para contornar isso, possvel lanar mo da tcnica de replicao, diminuindo consideravelmente a probabilidade de falha ao acessar um objeto replicado. A replicao pode tambm tornar o sistema mais confivel se utilizada para neutralizar a ao de nodos maliciosos, que interceptam o sistema e corrompem os dados, atravs de tcnicas de tolerncia falhas bizantinas. Descentralizao A correta operao de sistemas P2P no depende da existncia de uma administrao centralizada. Assim, sistemas P2P se confudem com sistemas descentralizados. Num sistema totalmente descentralizado, no s todos os hospedeiros so iguais, mas tambm no h hospedeiros com atribuies especiais, como administrao e atendimento de servios. Na prtica, construir sistemas totalmente descentralizados pode se tornar difcil, o que faz os projetistas geralmente adotarem paradigmas hbridos na construo de aplicaes P2P. O DNS por exemplo, um protocolo peer-to-peer, porm com um senso de hierarquia embutido. H outros exemplos de sistemas P2P no seu ncleo e com alguma organizao semi-centralizada, como o Napster11 e BitTorrent12. Sistemas Hbridos Os sistemas centralizados so simples de implementar e gerenciar, entretanto so um gargalo em potencial, uma vez que o servidor central tem capacidade limitada e pode no suportar o aumento da demanda. Por outro lado, os sistemas descentralizados so escalveis e robustos, mas isso demanda certa complexidade de implementao, principalmente nas questes de tolerncia falhas e descoberta de recursos. Muitos sistemas distribudos combinam caractersticas das duas arquiteturas, parte do sistema no tradicional modelo cliente-servidor e outra parte peer-topeer. Estruturas hbridas so implantadas notavelmente em sistemas distribudos colaborativos. A principal preocupao em muitos desses sistemas como se juntar ao sistema, para o qual muitas vezes um esquema tradicional cliente-servidor adotado. Uma vez que o nodo se junta ao sistema, ele pode utilizar um esquema totalmente descentralizado para colaborao. Arquiteturas de objetos distribudos Um sistema de objetos distribudos aquele que permite a operao com objetos remotos. Dessa forma possvel, a partir de uma aplicao cliente orientada a objetos, obter uma referncia para um objeto que oferece o servio desejado e, atravs dessa referncia, invocar mtodos desse objeto - mesmo que a instncia desse objeto esteja em uma mquina diferente daquela do objeto cliente. Nenhuma distino entre clientes e servidores. Qualquer objeto no sistema pode fornecer e utilizar servios de outros objetos. Cada entidade distribuda um objeto que fornece servios a outros objetos e utiliza servios de outros objetos. Comunicao entre objetos realizada por meio de um middleware denominado requisitor de objetos (barramento de software). Mais complexo de ser projetado do que sistemas cliente-servidor. O conceito bsico que suporta plataformas de objetos distribudos o conceito de arquiteturas de objetos. Essencialmente, uma arquitetura orientada a objetos estabelece as regras, diretrizes e convenes definindo como as aplicaes podem se comunicar e inter-operar. Dessa forma, o foco da arquitetura no em como a implementao realizada, mas sim a infra-estrutura e a interface entre os componentes da arquitetura. Na plataforma Java, dois mecanismos so oferecidos para o desenvolvimento de aplicaes usando o conceito de objetos distribudos: Java RMI e Java IDL. RMI (invocao remota de mtodos) um mecanismo para desenvolver aplicaes com objetos distribudos que opera exclusivamente com objetos Java. Java IDL utiliza a arquitetura padro CORBA para integrao de aplicaes Java a aplicaes desenvolvidas em outras linguagens. No paradigma de arquiteturas de objetos, h trs elementos principais. A arquitetura que fornece uma descrio abstrata do software - quais categorias de objetos sero utilizadas, como estaro particionados e como interagiro. As interfaces so as descries detalhadas das funcionalidades do software. Finalmente, a implementao que composta por mdulos de software que suportam as funcionalidades especificadas nas interfaces.
11

Napster, criado por Shawn Fanning, foi o programa de compartilhamento de arquivos em rede P2P que protagonizou o primeiro grande episdio na luta jurdica entre a indstria fonogrfica e as redes de compartilhamento de msica na internet. Compartilhando, principalmente, arquivos de msica no formato MP3, o Napster permitia que os usurios fizessem o download de um determinado arquivo diretamente do computador de um ou mais usurios de maneira descentralizada, uma vez que cada computador conectado sua rede desempenhava tanto as funes de servidor quanto as de cliente. 12 Torrent - um sistema de download de arquivos P2P. A idia basica que quando um usurio procura por um arquivo, ele baixa "pedaos" do arquivo de outros usurios at que o arquivo fique completo. Um importante objetivo de projeto foi garantir colaborao. Na maioria dos sistemas de compartilhamento de arquivo, uma frao significante dos usurios somente baixa os arquivos e contribuem pouco. Para isso, um arquivo pode ser baixado somente quando o cliente que est baixando tambm est provendo contedo para algum.

O uso de interfaces permite isolar a arquitetura de um sistema de sua implementao. Dessa forma, o sistema pode ser construdo com um alto grau de independncia em relao s implementaes especficas de suas funcionalidades, ou seja, possvel substituir implementaes especficas com pequeno impacto sobre o sistema como um todo. A adoo do paradigma de arquitetura de objetos permite tambm atingir um alto grau de inter-operabilidade atravs da adoo de uma infra-estrutura padronizada de comunicao entre objetos atravs das interfaces. Assim, cada componente da arquitetura deve se preocupar apenas em como se dar sua comunicao com a infra-estrutura de comunicao, estabelecida atravs de um objeto wrapper. Sem essa padronizao, seria necessrio estabelecer os mecanismos de comunicao com todos os demais componentes do sistema:

Em uma arquitetura de objetos, alguma forma deve ser estabelecida para que clientes possam localizar servios que esto sendo oferecidos. Isso usualmente oferecido na forma de um servio bsico da plataforma de objetos distribudos. CORBA Abreviao de Common Object Request Broker Architecture) a arquitetura padro criada pelo Object Management Group13 para estabelecer e simplificar a troca de dados entre sistemas distribudos heterogneos. Em face da diversidade de hardware e software que encontramos atualmente, a CORBA atua de modo que os objetos (componentes dos softwares) possam se comunicar de forma transparente para o usurio, mesmo que para isso seja necessrio interoperar com outro software, em outro sistema operacional e em outra ferramenta de desenvolvimento. CORBA um dos modelos mais populares de objetos distribudos, juntamente com o DCOM 14 - formato proprietrio da Microsoft. CORBA um padro internacional para um Requisitor de objeto middleware que gerencia a comunicao entre objetos distribudos. Diversas implementaes do CORBA esto disponveis. DCOM uma abordagem alternativa para requisitores de objetos desenvolvida pela Microsoft. CORBA foi definido pelo OMG (Object Management Group) A arquitetura CORBA define o ORB (Object Request Broker) como um mdulo intermedirio entre cliente e objeto, sendo responsvel em aceitar a requisio do cliente, envi-la para o objeto competente e, assim que disponvel a resposta, entreg-la para o cliente. A CORBA utiliza a IDL (Interface Definition Language), uma linguagem baseada em C++ que no possui algoritmos nem variveis, ou seja, puramente declarativa, e, portanto, independente da linguagem de programao utilizada para acess-la. H padro de IDL definido pelo OMG para C, C++, Java, TTCN, COBOL, Smalltalk, Ada, Lisp, Python e IDLscript. Possibilita a interoperabilidade entre os diversos sistemas, visto a separao que definida entre interface e execuo. A interface de cada objeto definida de forma bastante especfica, enquanto a sua execuo (cdigo fonte e dados) permanece oculta para o resto do sistema. Ao contrrio dos objetos tradicionais, os objetos em sistemas distribudos possuem uma caracterstica de dualidade: um estado dinmico, tipicamente alocado em memria voltil (em tempo de execuo), e um estado persistente, que no pode ser destrudo aps o encerramento do programa que os criou e que pode ser usado para reconstruir o estado dinmico, devendo ser armazenado em memria no voltil, seja em sistema de arquivos ou banco de dados. A arquitetura CORBA, para prover a persistncia, define o Persistent Object Service (POS) como sendo responsvel por armazenar o estado persistente dos objetos, utilizando quatro elementos: Objetos Persistentes (Persistent Object (POs)); Gerenciador de Objetos Persistentes (Persistent Objects Manager (POM)); Servios de Persistncia de Dados (Persistent Data Services (PDSs)); Base de Dados (Datastores). Service-oriented architectures (SOA)
13

O Object Management Group, ou OMG, uma organizao internacional que aprova padres abertos para aplicaes orientadas a objetos. Esse grupo define tambm a OMA (Object Management Architecture), um modelo padro de objeto para ambientes distribudos. O Object Management Group foi fundado em 1989.
14

DCOM - Distributed Component Object Model uma tecnologia proprietria da Microsoft para criao de componentes de software distribudos em computadores interligados em rede. O DCOM uma extenso do COM (tambm da Microsoft) para a comunicao entre objetos em sistemas distribudos. A tecnologia foi substituda, na plataforma de desenvolvimento .NET, pela API .NET Remoting. O DCOM pode ser utilizado na construo de aplicaes em trs camadas, de forma a centralizar as regras de negcio e processos, obter escalabilidade e facilitar a manuteno.

O termo SOA pode ser traduzido como arquitetura orientada a servios, e um estilo de arquitetura de software cujo princpio fundamental preconiza que as funcionalidades implementadas pelas aplicaes devam ser disponibilizadas na forma de servios. Freqentemente estes servios so conectados atravs de um "barramento de servios" (enterprise service bus, em ingls) que disponibiliza interfaces, acessveis atravs de web services ou outra forma de comunicao entre aplicaes. A arquitetura SOA baseada nos princpios da computao distribuda e utiliza o modelo request/reply para estabelecer a comunicao entre os sistemas clientes e os sistemas que implementam os servios. O fornecimento dos servios independe da aplicao que usa o servio. A maior parte das implementaes de SOA se utilizam de Web services ( SOAP15 , REST16 e WSDL17). Entretanto, uma implementao de SOA pode se utilizar de qualquer tecnologia padronizada baseada em web. Um Web service uma abordagem padronizada para tornar um componente reutilizvel disponvel e acessvel atravs da rede. As implementaes SOA dependem de uma rede de servios de software. Servios incluem baixo acoplamento de unidades e de funcionalidade. Cada servio implementa uma ao, como preencher um requerimento on-line para uma conta ou visualizar um banco on-line de instruo, ou colocar uma reserva on-line ou para bilhete de avio. Em vez de servios de chamadas para encaixar uns aos outros em seu cdigo fonte que eles usam protocolos definidos que descrevem como os servios de anlise e passar mensagens, utilizando metadados descrio. A Arquitetura Orientada a Servios pode ser bem representada a partir do seguinte processo, chamado de "find-bind-execute paradigm" o que significa aproximadamente paradigma de "procura-consolida-executa". Tal conceito anlogo a "Ciclo de Deming" aplicado aos servios, que define o ciclo que envolve o planejamento, a execuo, o monitoramento e a tomada de ao pr ativa para a melhoria da qualidade.

Tecnicamente falando, o processo preconiza que os provedores de servios registrem informaes em um registro central, com suas caractersticas, indicadores, e aspectos relevantes s tomadas de decises. O registro utilizado pelo cliente para determinar as caractersticas dos servios necessrios, e se o mesmo estiver disponvel no registro central, como por exemplo por um catlogo de servios, o cliente poder utiliz-lo, sendo este oficializado atravs de um contrato que enderece este servio. Arquitetura em camadas Three-tier architectures Em uma arquitetura de trs camadas, cada camada da arquitetura da aplicao pode ser executada em processador separado. -Camada de apresentao: Se ocupa de apresentar informaes aos usurios e todas as interaes com eles. -Camada de processamento de aplicao: Se ocupa de implementar a lgica da aplicao (ex. em um sistema bancrio, funes como abrir conta, fechar conta, etc.) -Camada de gerenciamento de dados: Se ocupa de gerenciar o sistema de banco de dados Modelo cliente-magro (thin): Todo o processamento da aplicao e gerenciamento de dados realizado no servidor. O cliente responsvel apenas por executar o software de apresentao. Utilizado quando sistemas legados so migrados para arquiteturas cliente-servidor. O sistema legado atua como um servidor com a interface grfica implementada nos clientes. A principal desvantagem que ele atribui uma grande carga de processamento ao servidor e rede. Modelo cliente-gordo (fat): O servidor responsvel somente pelo gerenciamento de dados. O software no cliente implementa a lgica da aplicao e as interaes com o usurio do sistema. Distribui o processamento lgico da aplicao e a apresentao para o cliente. Mais adequado para novos sistemas cliente servidor onde os clientes possuem uma grande capacidade de processamento. Mais complexo que o modelo cliente magro especialmente
15

SOAP (originado do acrnimo ingls Simple Object Access Protocol) um protocolo para troca de informaes estruturadas em uma plataforma descentralizada e distribuda, utilizando tecnologias baseadas em XML. Sua especificao define um framework que prov maneiras para se construir mensagens que podem trafegar atravs de diversos protocolos e que foi especificado de forma a ser independente de qualquer modelo de programao ou outra implementao especfica. 16 A Transferncia de Estado Representacional (Representational State Transfer) ou somente (REST) uma tcnica de engenharia de software para sistemas hipermdia distribudos como a World Wide Web. O termo se originou no ano de 2000, em uma tese de doutorado sobre a web escrita por Roy Fielding, um dos principais autores da especificao do protocolo HTTP que utilizado por sites da internet.
17

O Web Services Description Language (WSDL) uma linguagem baseada em XML utilizada para descrever Web Services funcionando como um contrato do servio. Trata-se de um documento escrito em XML que alm de descrever o servio, especifica como acess-lo e quais as operaes ou mtodos disponveis. WSDL utilizado para definir servios como uma coleo de endpoints (endereos de rede), ou portas. A definio abstrata de portas e mensagens so separadas do uso concreto de instncias, permitindo o reuso de definies. Uma porta definida por associao a um endereo de rede com um binding reutilizvel, e uma coleo de portas definidas como servio. Mensagens so descries abstratas dos dados a serem trocados.

para o gerenciamento. Novas verses da aplicao devem ser instaladas em todos os clientes. Permite melhor performance que a abordagem cliente magro e maior simplicidade de gerenciamento que a abordagem cliente gordo. Uma arquitetura mais escalvel medida que a demanda aumenta, novos servidores podem ser adicionados.

Data mining Data mining - Prospeco de dados ou minerao de dados o processo de explorar grandes quantidades de dados procura de padres consistentes, como regras de associao ou sequncias temporais, para detectar relacionamentos sistemticos entre variveis, detectando assim novos subconjuntos de dados. Esse um tpico recente em cincia da computao que utiliza vrias tcnicas: estatstica, recuperao de informao, inteligncia artificial e reconhecimento de padres. O modelo lgico do sistema no o de proviso de servios, em que h servios distintos de gerenciamento de dados. Este paradigma permite que o nmero de bancos de dados acessados seja aumentado, sem interferir no sistema. Permite que novos tipos de relacionamentos sejam selecionados pela adio de novos objetos integradores. Logo, um problema comum da minerao de dados a sua aplicao em grandes bases de dados, pois o custo computacional gasto para realiz-la pode ser elevado. Uma possvel soluo para tal problema paralelizar algoritmos envolvidos na minerao de dados uma vez que, pelo menos, muitos deles podem ser decompostos em tarefas independentes; conseqentemente, as tarefas podem ser executadas paralelamente de foma distribuda. Sendo assim, a minerao de dados de forma paralela pode reduzir o tempo de processamento, caso seja executada, por exemplo, utilizando diversas mquinas, que estaro compartilhando seus processadores, discos rgidos e memria. Para tanto, preciso ter um ambiente adequado onde hajam mquinas conectadas por uma rede para que as tarefas sejam executadas. Dentre os ambientes existentes, vale destacar as grades computacionais, que uma plataforma para execuo de aplicaes paralelas que possui uma alta disperso geogrfica, heterognea no sentido de hardware e software, compartilhada, sem controle central e com mltiplos domnios administrativos. Cluster Clusters de Computadores podem ser definidos como sendo um conjunto de computadores interconectados atravs de alguma tecnologia de rede de comunicao, trabalhando juntos para fins comuns. A idia deste modelo consiste em unir o poder computacional de todos os ns integrantes deste agrupamento de computadores para oferecer uma computao de alto desempenho e de alta disponibilidade, criando um ambiente computacional nico. Na sua forma mais bsica um cluster um sistema que compreende dois ou mais computadores ou sistemas (denominados nodos) na qual trabalham em conjunto para executar aplicaes ou realizar outras tarefas, de tal forma para que os usurios que os utilizam tenham a impresso que somente um nico sistema responde para eles, criando assim uma iluso de um recurso nico (computador virtual). Este conceito denominado transparncia do sistema. Como caractersticas fundamentais para a construo destas plataformas incluem-se elevao da: confiana, distribuio de carga e desempenho. Desse modo, pode-se dizer que sistemas distribudos esto associados ao processamento paralelo e descentralizado, realizado por dois ou mais computadores conectados atravs de uma rede, cujo objetivo concluir uma tarefa em comum. Logo os clusters so espcies de arranjos computacionais com essas caractersticas. Tipos de Clusters Alta Disponibilidade (High Availability (HA) and Failover), estes modelos de clusters so construdos para prover uma disponibilidade de servios e recursos de formas ininterruptas atravs do uso da redundncia implcitas ao sistema. A idia geral que se um n do cluster vier a falhar (failover), aplicaes ou servios possam estar disponveis em outro n. Estes tipos de cluster so utilizados para base de dados de misses crticas, correio, servidores de arquivos e aplicaes. Alto Desempenho ou Alto Processamento, este modelo de cluster aumenta a disponibilidade e performance para as aplicaes, particularmente as grandes tarefas computacionais. Uma grande tarefa computacional pode ser dividida em pequenas tarefas que so distribudas ao redor das estaes (nodos), como se fosse um supercomputador massivamente paralelo. comum associar este tipo de cluster ao projeto Beowulf da NASA. Estes clusters so usados para computao cientifica ou anlises financeiras, tarefas tpicas para exigncia de alto poder de processamento. Balanceamento de carga (Load Balancing), este modelo distribui o trfego entrante ou requisies de recursos provenientes dos nodos entre as mquinas que compem o cluster. Todos os nodos esto responsveis em

controlar os pedidos. Se um n falhar, as requisies so redistribudas entre os ns disponveis no momento. Este tipo de soluo normalmente utilizado em Data Center nos Servidores de web. Combinao HA & Load Balancing, como o prprio nome diz combina as caractersticas dos dois tipos de cluster, aumentando assim a disponibilidade e escalabilidade de servios e recursos. Este tipo de configurao de cluster bastante utilizado em servidores de web, mail, news ou ftp. 5 Caractersticas dos Sistemas Distribudos So computadores acoplados que no compartilham a mesma memria ou o mesmo relgio. Cada processador possui sua memria local (fracamente acoplados). Os processadores podem variar em tamanho e funo. A comunicao feita atravs de redes. O objetivo principal a distribuio da computao entre vrios computadores. relativamente fcil agrupar um grande nmero de computadores, conectando-os por uma rede de alta velocidade. A maior dificuldade reside no software para gerenciamento e sincronismo do conjunto. Vantagens Melhor relao custo/benefcio Permite o compartilhamento de dados/informao (Ex licenas, banco de dados, vdeos, udios, etc) Permite compartilhamento de recursos (Ex. impressora, disco, CPUs, memria, etc.) Transparncia Facilidade de expanso, permite aumentar o poder de processamento/armazenamento sem se desfazer daquilo que j possui, isto , de maneira gradativa Maior confiabilidade e disponibilidade, grau de tolerncia contra erros e falhas de componentes em um sistema Capacidade de processamento alm dos limites prticos de Sistemas Centralizados Desvantagens Alto custo para programar aplicaes colaborativas Desenvolvimento de software distribudo mais complexo Sincronizao de mensagens. Recursos so fisicamente separados, mensagens podem atrasar ou mensagens podem ser perdidas Gerncia de recursos Manuteno do sistema Maior nmero de pontos de falhas. Falhas e saturao da rede de comunicao podem eliminar as vantagens de Sistemas Distribudos Maior dificuldade na garantia de segurana (crtico!). Segurana pode ser comprometida: fcil acesso a dados e recursos reservados

Compartilhamento de Recursos Isso significa estar apto para compartilhar com desempenho e segurana recursos fsicos ou lgicos, como por exemplo, impressoras, scanners, dados, espao em disco, processamento, memria entre outros. Tudo deve ser gerenciado por um software administrador. Concorrncia Os servios e aplicativos fornecem recurso que podem ser compartilhados, assim existe a possibilidade de que vrios clientes tentem acessar o mesmo recurso ao mesmo tempo. Acesso concorrente a recursos compartilhados requer sincronizao. Escalabilidade O sistema capaz de usar recursos medida que so acrescentados (processadores, memria, etc.). Um sistema escalvel se ele permanece eficiente quando h um aumento significativo no nmero de recursos e no nmero de usurios. Portanto a quantidade de trabalho envolvido no processamento de qualquer requisio de acesso a um recurso compartilhado independe do tamanho da rede. Tcnicas utilizadas: replicao, caching, servidores mltiplos. Extensibilidade, Portabilidade ou abertura (openness) O Sistema consegue operar em diferentes configuraes de hardware / software. Adapta-se bem a novas tecnologias (tarefas que no foram previstas no projeto original do Sistema Operacional hardware, servios e protocolos). Caracterstica que determina se um sistema pode ser estendido e reimplementado de vrias maneiras. Normalmente obtido se forem seguidos padres de interface entre componentes de software e hardware: Extenses de hardware: perifricos, memria, interfaces de comunicao, etc. Extenses de software: funes de SO, protocolos de comunicao, etc. Interatividade Permite que aplicaes respondam rapidamente s aes do usurio ou a eventos. Usabilidade Suportar um grande nmero de aplicaes e fornecer uma interface amigvel ao usurio. A Usabilidade depende da: Heterogeneidade de HW e SW (Interfaces definidas de forma que possam ser processadas por vrios HW e SW); e da Escalabilidade (Servio deve ser extensvel para acomodar mudanas de escala do SD).

Tolerncia a falhas Preveno para que falhas num componente no afetem outros componentes do sistema. Falhas de hardware e software (em CPUs e redes): programas param ou produzem resultados errados Abordagens: Redundncia de hardware (Ex: banco de dados replicado em diversos servidores) Recuperao por software: manter dados permanentes e consistentes. Replicao (diversas cpias) ou partio (cada parte com um pedao do todo). Problemtica: quanto + cpias + disponibilidade + inconsistncia desempenho. Transparncia Esconder do usurio e do programador de aplicaes a separao de componentes em um sistema distribudo, de forma que ele seja visto como um sistema centralizado. Formas de transparncia: acesso, localizao, migrao, realocao, replicao, concorrncia, falha, persistncia. Transparncia de acesso Operaes de acesso a recursos so idnticas para recursos locais e remotos. Exemplo: CORBA. Transparncia de localizao Acesso a um recurso ocorre sem que seja necessrio o conhecimento de sua localizao. Exemplo: Operao de envio de uma mensagem eletrnica especificando o destinatrio atravs de seu endereo Internet. Outras formas de transparncia Migrao: oculta o fato de que um recurso pode ter sido movido para outra localizao. Relocao: oculta o fato de que um recurso pode ter sido movido para outra localizao, enquanto ele est sendo utilizado. Replicao: vrias instncias de recurso so usadas sem requerer o conhecimento das rplicas pelos usurios e aplicaes. Concorrncia: oculta o fato de que um recurso pode ser compartilhado entre vrios usurios. Falha: oculta a ocorrncia de falhas de hardware e software. Persistncia: oculta o fato de que um recurso (software) est na memria ou em disco. Sistemas Distribudos X Sistemas Centralizados Sistemas Distribudos Sistemas Centralizados Arquitetura baseada em uso de redes os processadores esto todos localizados em uma mesma placa me, ou em poucas fracamente acoplados fortemente acoplados: compartilham hardware ou se comunicam atravs de um barramento de alta velocidade so mais imprevisveis devido ao uso da rede e a Comportamento mais previsvel falhas so bastante influenciados pelo tempo de o tempo de troca de mensagens pode ser desconsiderado comunicao pela rede no possuem limitaes em nmero de mquinas possuem limitaes em processadores cada processador com sua memria processadores compartilham memria Tolerante a falha, pois caso algum computador seja No tolerante a falha, pois caso um processo fique retido retirado da rede, o funcionamento no ser no processador, e existirem processos que dependam prejudicado deste, ficaro aguardando para receberem a informao do processo que depende do que se encontra travado Custo baixo, pois no necessrio investir no Custo alto, pois envolve um suporte de hardware grande, hardware que ir participar desta implementao para poder utilizar todos os componentes disponibilizados pelo nmero de processadores. Manuteno Complexa, pois os sistemas rodam em mais de uma maquina, fazendo com que para cada manuteno, seja necessria uma vistoria nas estaes que formam o sistema. Troca de dados somente por mensagens Alto processamento mais fcil, pois basta adicionar mais uma mquina na rede. Alta disponibilidade Manuteno Simples, pois o sistema que opera sobre estas mquinas, operam apenas em uma estao, facilitando a manuteno. Troca de dados pode ser realizada utilizando memria ou discos rgidos aumento do processamento depende dos avanos da tecnologia e hardware Alto desempenho

6 Topologias de Rede Topologia Linear ou Barramento A topologia barramento tambm denominada Array Linear e no possui caminhos alternativos em caso de falha. Tal topologia linear, consistem em organizar os ns em seqncia, ligando cada n ao seus vizinhos, isto um nico cabo, rede, barramento ou outro meio que conecte todas as mquinas. As vantagens da topologia linear so o baixo custo e a simplicidade. Entretanto, como h sempre apenas uma rota para cada mensagem, o centro da rede tende a ser um gargalo e comunicaes entre os ns distantes tm grande latncia. O nmero de ns N e o nmero de ligaes (L) N-1, neste caso como temos 6 ns o nmero de ligaes entre os ns 5 (L=N-1). Nesta rede o dimetro N/2, o grau 1e a largura de bisseo 1.

Topologia circular ou em anel A topologia circular semelhante a topologia linear, mas tem uma linha de conexo entre o primeiro e o ltimo processo, gerando um anel. Desta forma, h sempre duas rotas para cada n, diminuindo os problemas da topologia linear. Porm, o custo da rede ligeiramente superior. A rede circular adequada para pequenas redes, mas em redes maiores a baixa largura da bisseo torna-se um problema. O dimetro na topologia circular N/2, o grau 2 e a largura da bisseco igual a 2. Ou seja, temos duas rotas para qualquer n em caso de falha de uma rota outra pode ser utilizada.

Topologia em Estrela Esta a topologia mais utilizada atualmente. Nela, todas as estaes so conectadas a um perifrico chamado de hub ou switch. Um comutador (switch) possui portas, assim como os concentradores (hubs) e a principal diferena entre um comutador e um concentrador, que o comutador segmenta a rede internamente, sendo que a cada porta corresponde a um domnio de coliso diferente, o que significa que no haver colises entre os pacotes de segmentos diferentes, ao contrrio dos concentradores, cujas portas partilham o mesmo domnio de coliso.

Topologia Malha, Grid, ou Mesh O termo grid computing (grade ou malha computacional) surgiu na metade dos anos 90 como uma proposta para denotar um sistema distribudo de computao que pudesse oferecer servios, que so recursos computacionais, de acordo com a real necessidade de seus usurios de maneira transparente. Esses ambientes normalmente dizem respeito a um grande nmero de ns conectados e sugerem a conexo de clusters geograficamente dispersos pelo mundo, atravs da infra-estrutura da Internet. Essa idia de conexo para uso da computao sobreposta deu origem a um novo campo na computao distribuda, denominado metacomputao. O termo metacomputador definido como sendo um supercomputador virtual, composto dinamicamente por recursos geograficamente distribudos e interconectados atravs de enlaces de alta velocidade, porm entende-se hoje, que grid computing o termo mais adequado para denotar este sistema, embora ainda haja divergncias e autores diferentes optem por utilizar termos distintos de acordo com seus pensamentos. Ideal para resolver problemas com 2 dimenses, como teoria de grafos, viso de robs, anlise de fotografias

Essa topologia consiste em dividir uma rede linear de tamanho N em diversas sub-redes de tamanho K, tal que N=K e conectar os ns correspondentes gerando uma grade. A topologia mesh tem o dimetro inferior e a largura da bisseo superior s topologias linear e circular, e portanto menos gargalos. Entretanto, a topologia assimtrica e a conectividade da rede baixa. Os processadores nesta topologia tem um canal de comunicao direto com o seu vizinho. O hardware para este tipo de tecnologia de simples construo e expanso. A malha se adapta bem a algoritmos utilizados em clculos cientficos, os quais se destacam a manipulao de matrizes. Neste tipo de rede o dimetro 2(k 1), o grau igual a 2 e a largura da bisseo K. Topologia Torus Assim como a topologia mesh consiste em dividir uma rede em sub-redes lineares, a topologia torus consiste em dividir uma rede em sub-redes circulares e conectar os ns correspondentes. No caso de redes com muito ns, pode-se utilizar uma topologia torus multidimensional. Neste caso a rede complexa, mas a conectividade e a largura de bisseo so maiores, evitando gargalos. O dimetro diminui com o nmero de dimenses, reduzindo a latncia. Na topologia Torus 0 dimetro k a, conectividade 4 e a largura da bissecao 2k.

Topologia A topologia hipercubo consiste em organizar os ns em forma de um cubo de dimenso d tal que N=2^d, todos os ns so conectados a outros d ns. Assim, os tamanhos de hipercubos so definidos por potncias de 2 onde d a dimenso do hipercubo e N o nmero de processadores. Toda rede de interconexo hipercbica est alicerada sobre uma estrutura multidimensional baseada em endereos binrios. Em funo disto, todos os ns podem ser identificados por um nmero binrio. Cada n conectado a todos os seus vizinhos; isto faz com que o hipercubo tenha grau varivel e de valor d.

A topologia hipercbica confere boas propriedades rede de interconexo do cluster; a largura da bisseo N/2, e o dimetro log2N. Apesar de apresentar bom desempenho para muitos padres de comunicao, sua eficincia se mostra bastante dependente do algoritmo de roteamento a ser empregado. Um aspecto inconveniente do hipercubo sua escalabilidade, o nmero de processadores sempre deve crescer em potncia de 2. Alm disso, com o grau de cada n em funo do tamanho do cubo, toda expanso no nmero de processadores implica em adicionar mais um canal de comunicao a todos os ns. Para cubos maiores, estas caractersticas podem trazer inconvenientes para a administrao de custo/beneficio quando da expanso da arquitetura. Um equipamento que emprega esta topologia o Ncube2. Cubo n-dimensional: Um cubo de X dimenses formado pela interligao completa de dois cubos de X-1 dimenses. Topologia em rvore Na topologia em rvore, um n raiz divide em duas subrvores, que por sua vez tambm tem uma raiz que a subdivide em outras duas, e assim sucessivamente. A topologia em rvore adequada a aplicaes regulares com

comunicao local, e aplicaes com esta topologia so comuns. Em uma rvore, a largura de ramos (canal) cresce na medida em que se sobe em direo das folhas. A largura da bisseo a rvore normalmente N e o seu dimetro proporcional a 2(logN). A arquitetura da CM-5 da Thinking Machines utiliza uma verso modificada da rvore larga. A topologia em rvore uma boa opo de topologia para arquiteturas paralelas. Pois o dimetro cresce de forma linear com a altura h, o grau de n mximo igual 3, mas no existem caminhos alternativos e o n raiz um gargalo.

7 Sistemas Operacionais Podemos definir um Sistema Operacional (SO) como sendo um software composto de um conjunto de rotinas que fornecem servios bsicos de uso geral que simplificam a utilizao dos recursos de hardware de uma mquina. No caso de Sistemas Operacionais para Redes de Computadores so muitas as opes que esto disponveis. Basta conhecer as caractersticas bsicas de cada verso ou distribuio e levar em considerao alguns itens que devem ser dominados pelo profissional responsvel pela implantao: o equipamento em que ser instalado; recursos que devero estar presentes no servidor; quantidade de mquinas clientes; aplicaes que estaro rodando; tipo de dado a ser processado; custo de implantao e manuteno; segurana e estabilidade. Estes so apenas alguns fatores bsicos que estaro presentes na tomada de decises do profissional de TI. Alguns Sistemas Operacionais que costumam habitar os servidores so o Linux em suas diversas distribuies (Red Hat, SuSe, Mandriva Mandrake e Conectiva, Debian, etc), Windows (NT, 2000 e 2003 server), Unix, Solaris, Free BSD, Mac OS X e Novell Netware. Se voc est se perguntando qual o melhor, a resposta ser Depende Porm, sempre opte por um que voc tenha domnio, ou que te oferea um bom suporte. Porque voc um dia precisar com certeza. Sistema Operacional de Rede (SOR) Sistemas com hardware heterogneo (multi-computadores), os usurios sabem da existncia das diversas mquinas e usam recursos remotos compartilhados, abrindo sesso em mquina remota ou transferindo dados da maquina remota para a local. A comunicao entre as maquinas feita por protocolos, fica simples adicionar ou remover uma maquina (nodos independentes).

M1

M2 Aplicaes Distribudas

M3

SOR Kernel

SOR Kernel

SOR Kernel
Rede

Sistema Operacional Distribudo (SOD) So aqueles que gerenciam as atividades e os recursos distribudos, possibilitando um processamento descentralizado, melhorando assim o desempenho do sistema. Para os usurios e suas aplicaes como se no existisse uma rede de computadores, mas sim um nico sistema centralizado. Outra definio: Conjunto de processos que so executados de forma concorrente, cada um dos quais acessando um subconjunto de recursos do sistema por meio de um mecanismo de troca de mensagens atravs de uma rede de comunicao, que nem sempre confivel. As vantagens de um Sistema Distribudo em relao aos outros sua maior disponibilidade, geralmente resultante da redundncia de seus componentes. Em Sistemas Distribudos a transparncia maior em relao aos Sistemas em Rede. Suas principais caractersticas so: suporte para memria compartilhada; o nmero de mquinas transparente para aplicao; os usurios usam recursos remotos da mesma forma que usam recursos locais; o Sistema Operacional responsvel pela transferncia de dados e processos de uma mquina para outra.

Exemplos: BSD Unix18, Amoeba19, BCCD20.

M1

M2 Aplicaes Distribudas SOD

M3

Kernel

Kernel

Kernel
Rede

Quadro evolutivo dos S.O. Gerao Sistema 1a. S.O. Centralizado

2a. 3a.

S.O. De Rede (network operating system) S.O. Distribudo

4a

Transparncia - o usurio e as aplicaes vem o sistema de mltiplos computadores como se fosse um nico computador. S. O. Cooperativo Orientado a servios de alto nvel (muitos Autonomia Trabalho cooperativo Autnomo autores no o reconhecem como S. O.)

Caractersticas Gerenciamento de processos Gerenciamento de memria Gerenciamento de E/S Gerenciamento de arquivos Acesso remoto Troca de Informaes Navegao na rede Viso global dos elementos do sistema, Disponibilidade, Tempo, Segurana Poder computacional

Objetivos Gerenciamento de recursos locais Maquina virtual estendida Compartilhamento de recursos Interoperabilidade

Caractersticas dos S.O.s Modernos Comunicabilidade Servios Bsicos Cliente/Server - Servio Nomes RPC21 - Sincronismo Mobilidade - Coordenao Dados - Eleio Cdigo - Manuteno e Consistncia Agentes - Transaes e Replicao - Tolerncia Falhas

Extenso SO - Balanceamento de Carga - Memria Compartilhada - Servio Arquivo Distribudo - Gerencia Recursos Distribudos

OpenMosix O projeto Mosix - Multicomputer Operating System unIX - um sistema operacional distribudo, desenvolvido originalmente pelos estudantes do professor Amnom Barak, na Universidade Hebrew em Jerusalm, Israel. Foi utilizado nos anos 80 pela fora rea americana para a construo de um cluster de computadores PDP11/45. O projeto foi desenvolvido em sete fases, para diferentes verses de UNIX e arquiteturas de computadores. A primeira verso para PC foi desenvolvida para o BSD/OS. A ltima verso foi para o sistema operacional Linux em plataforma Intel. O OpenMosix uma extenso do projeto Mosix, baseado no GPLv2, iniciado em 10 de fevereiro de 2002, coordenado pelo Ph.D Moshe Bar, para manter os privilgios desta soluo Linux para cluster disponvel com software de cdigo aberto.
18

O BSD (Berkeley Software Distribution) um Sistema Operacional UNIX desenvolvido pela Universidade de Berkeley, na Califrnia, durante os anos 70 e 80. Actualmente, o BSD no um nico Sistema Operacional mas sim uma larga famlia derivada do original, sendo os mais conhecidos membros da famlia: 4.4BSD (ltima verso do BSD original); FreeBSD; NetBSD; OpenBSD; BSDI (anteriormente BSD/OS); Darwin (que serve como base ao Mac OS X). 19 Amoeba um sistema operacional distribuido baseado em microncleo e de cdigo aberto, criado por Andrew S. Tanenbaum e outros na Universidade Vrije na Holanda. O objetivo do projeto era construir um sistema operacional de tempo compartilhado que fizesse um conjunto de computadores em rede comportar-se como uma nica mquina ao usurio. O desenvolvimento do sistema aparentemente foi interrompido pois os arquivos da ltima verso (5.3) datam de 12 de fevereiro de 2001. 20 The BCCD (Bootable Cluster CD) um CD de Inicializao (Boot) criar um ambiente de computao distribuda. 21 RPC (Remote Procedure Call ou Chamada Remota de Procedimento) uma tecnologia de comunicao entre processos que permite a um programa de computador chamar um procedimento em outro espao de endereamento (geralmente em outro computador, conectado por uma rede). O programador no se preocupa com detalhes de implementao dessa interao remota: do ponto de vista do cdigo, a chamada se assemelha a chamadas de procedimentos locais. Trata-se de uma tecnologia popular para a implementao do modelo cliente-servidor de computao distribuda. Uma chamada de procedimento remoto iniciada pelo cliente enviando uma mensagem para um servidor remoto para executar um procedimento especfico. Uma resposta retornada ao cliente. Uma diferena importante entre chamadas de procedimento remotas e chamadas de procedimento locais que, no primeiro caso, a chamada pode falhar por problemas da rede. Nesse caso, no h nem mesmo garantia de que o procedimento foi invocado.

Este agrupamento de mquinas Linux o que poderamos classificar de verdadeiro sistema de imagem nica (SSI - Single System Image), pois j clara a idia de que no se tm um cluster verdadeiro enquanto no existir um SSI. Podemos ter como referencia os primeiros clusters SSI como o IBM SysPlex e o cluster DEC. Por exemplo, em um cluster DEC se voc fizer um telnet para um endereo no cluster, essa chamada ser atendida por qualquer n do cluster, e o usurio no precisa se preocupar com qual n que ir atender esta chamada, e qualquer programa iniciado pelo usurio ser executado no n que possuir maior disponibilidade de recursos para atender ao programa. O OpenMosix uma extenso do ncleo do sistema operacional Linux, e faz com que um cluster de computadores se comporte como um grande e nico supercomputador atravs da utilizao de migrao preemptiva de processos e balanceamento dinmico de carga. A Migrao Preemptiva de processos permite migrar qualquer processo do usurio, em qualquer instante e para qualquer n disponvel de maneira transparente. Para atingir um melhor desempenho este controlado por algoritmos de Balanceamento Dinmico de Carga e de Preveno Contra Falta de Memria. Estes algoritmos so projetados para responder dinamicamente as variaes da utilizao dos recursos nos diversos ns. Isto garante que o cluster se comporte muito bem, seja numa configurao com poucas ou com muitas mquinas, propiciando uma maior escalabilidade. Ou seja, se o programa que estamos rodando em uma mquina consumir muitos recursos dela, o sistema varre toda e rede e procura uma mquina mais "disponvel no momento" em termos de memria e CPU, e desloca o "programa" ou parte dele para ser executado remotamente. Com isso, o sistema ganha desempenho. Estes algoritmos so descentralizados, ou seja, no existe a configurao de Controlador Mestre e ns escravos como ocorre no Cluster Beowulf para computao paralela. Cada n um mestre para os processos que so criados localmente, e um escravo para processos remotos, migrados de outros ns do cluster. Isto significa que podemos acrescentar ou remover as mquinas do cluster em qualquer momento, com um mnimo de distrbio no sistema. Este cluster possui tambm algoritmos de monitoramento que identificam a velocidade de cada n, a carga da CPU, a memria livre disponvel, como tambm a comunicao interprocessos IPC e a velocidade de acesso de cada processo. Como o OpenMosix opera de forma silenciosa, e as operaes so transparentes para as aplicaes, ou seja, pode-se executar aplicaes seqenciais e paralelas como se fosse um nico computador SMP (Symmetric Multi-Processor - Multiprocessamento simtrico). Voc no precisa conhecer onde seus processos esto sendo executados, nem se preocupar com que os outros usurios esto fazendo na rede por isso ele usa o acrnimo "fork and forget". O que ele faz , pouco tempo depois de iniciar os processos, o OpenMosix envia-os para um melhor computador da rede, o OpenMosix continua a monitorar os novos processos e os demais, e poder moviment-los pelos computadores com pouca carga de trabalho maximizando o trabalho e melhorando a performance. Alicaes que se beneficiam com o OpenMosix: -Processos CPU-bound: processos com longos tempos de execuo e baixo volume de comunicao entre processos, ex: aplicaes cientficas, engenharia e outras aplicaes que demandam grande quantidade de processamento. -Grandes compilaes. -Para processos que misturam longos e rpidos tempos de execuo ou com moderadas quantias de comunicao interprocessos, recomendado o uso das bibliotecas MPI/PVM amplamente utilizadas em computao paralela. -Processos I/O bound misturados com processos da CPU: executados atravs do servidor de arquivos, usando o sistema de arquivos distribudos do OpenMosix, o MFS (Mosix File System) e o DFSA (Distributed File System Architeture). -Banco de dados que no usem memria compartilhada. -Processos que podem ser migrados manualmente. As desvantagens do OpenMosix: -Processos com baixa computao, como aplicativos com alta comunicao interprocessos. -Aplicaes com memria compartilhada. -Aplicaes dependentes de hardware que necessitam de acesso a um perifrico de um n em especial. -Aplicaes com muitos threads no ganham desempenho. -No se ganha desempenho quando se roda um nico processo, tal como seu browser. Alicaes testadas que no migraram sobre OpenMosix: -Programas em Java usando threads nativos no migram quando eles utilizam memria compartilhada. Green Threads JVMs, entretanto, podem ser migrados porque cada thread Java um processo separado. -Aplicaes que usam pthreads. -MySQL, Apache, Oracle, Postgres, SAP, Baan, usam memria compartilhada. -Python com threading habilitada. -VMware, este ao rodar no Win98, algumas vezes travou e em outras o emulador do SO parou. Voc dever ter muito cuidado quando usar o VMware com o OpenMosix. A caracterstica de no migrar uma situao normal para programas que falhariam ao serem movimentados pelo OpenMosix. Estes programas devem rodar como planejado no n onde foram iniciados. Portanto ser bem interessante ao leitor executar testes com uma infinidade de aplicaes que se beneficiariam ou no com este cluster, para criarmos um banco de dados sobre este assunto. Por isso aguardem minha nova publicao.

OpenMOSIXVIEW O OpenMosixview um gerenciador grfico (GUI - Graphic User Interface), ele um front-end para os comandos "mosctl". Com esta aplicao possvel gerenciar e ajustar os principais parmetros deste cluster tais como: visualizar a carga de todos os ns do cluster, visualizao de processos remotos em outors ns, bem como executar ou transferir processos para outros computadores que compem o cluster. O OpenMosixview um conjunto de cinco ferramentas utilizadas para administrao e monitoramento do Cluster OpenMosix. So eles: -OpenMosixview: a aplicao principal de administrao/monitoramento. -OpenMosixprocs: um box para gerenciamento de processos. -OpenMosixcollector: coleta informaes dos ns do cluster atravs de um processo daemons para gerao de logs do sistema. -OpenMosixanalyzer: utilizado para a anlise dos dados coletados pelo OpenMosixcollector. -OpenMosixhistory: histrico dos processos no nosso cluster.

O OpenMosixview. Existem basicamente trs aplicaes para um cluster de micros PCs: A primeira e provavelmente a mais usada a tolerncia a falhas (alta diponibilidade), onde temos dois ou mais PCs ligados entre s. O primeiro PC faz todo o trabalho enquanto o segundo se limita a manter seus dados atualizados em relao ao primeiro e a monitor-lo constantemente. Se o primeiro PC sair do ar por qualquer motivo, o segundo imediatamente assume suas funes. Esta tecnologia muito usada em servidores Web e servidores de banco de dados em Intranets. A segunda aplicao o balanceamento de carga, usada principalmente em servidores Web. Neste caso temos pelo menos trs PCs, onde o primeiro recebe todas as requisies e se encarrega de divid-las entre os demais PCs. Ao invs de ter apenas um super-servidor carssimo, voc pode usar vrios PCs baratos para fazer o mesmo trabalho. A terceira aplicao o processamento paralelo (alto processamento), onde brilham os famosos clusters Beowulf. Este tipo de cluster muito til em aplicaes cientficas, assim como animaes e efeitos destinados a filmes onde existe um gigantesco volume de dados a ser processado. O trabalho dividido em pequenas partes, processado de forma distribuda e depois o quebra cabeas montado, gerando o trabalho final. Os clusters Beowulf22 so muito famosos pelo seu uso na NASA, em vrias universidades, na renderizao 23 das cenas de filmes como StarWars ep. 2, Final Fantasy (entre muitos outros) e assim por diante. Configurar um cluster Beowulf no nenhum bicho papo, voc poderia configurar um se quisesse, mas existe um pequeno detalhe que os torna pouco teis em ambientes domsticos: possvel processar quantidades fabulosas de dados, mas apenas ao utilizar aplicativos escritos com suporte arquitetura. Isto no um grande problema para as universidades ou grandes estdios, que geralmente cuidam de grande parte do desenvolvimento dos programas e podem port-los, mas no uma alternativa vivel na maioria dos casos. Os clusters OpenMosix seguem uma idia diferente, que os torna mais adequados para o uso geral. Ao invs de dividir o processamento interno de um mesmo programa (o que exigiria que o programa fosse portado e otimizado), vrios programas diferentes, ou vrias instncias do mesmo programa migram para os outros ns do cluster e so executados em paralelo de forma transparente para o usurio. A vantagem que o sistema funciona com os programas que voc j usa no dia a dia, no preciso sair caando aplicativos especiais. Imagine que voc tente comprimir dois vdeos em Divx ao mesmo tempo, abrindo duas instncias do mesmo programa de compresso. A primeira instncia continuar rodando no seu PC, mas a segunda migrar para o outro n da rede. Se os dois PCs tiverem mais ou menos o mesmo desempenho voc ter os dois vdeos compactados quase que no tempo de um.
22

Cluster Beowulf, constitudo por diversos ns escravos gerenciados por um s computador, usando computadores pessoais, no especializados e, portanto mais baratos. O projeto foi criado por Donald Becker da NASA, e hoje so usados em todo mundo, principalmente para processamento de dados com finalidade cientfica, uma area em que so muito utilizados na renderizaco de filmes.
23

Renderizao o processo pelo qual pode-se obter o produto final de um processamento digital qualquer. Este processo aplica-se essencialmente em programas de modelagem 2D e 3D (3ds Max, Maya, Cinema 4D, Blender 3D, Adobe Photoshop, Gimp, Corel PhotoPaint, etc.), bem como udio (CUBase, Ableton Live!, Logic Pro, etc) e vdeo. O processo de tratamento digital de imagens e sons consome muitos recursos dos processadores, e pode tornar-se pesado de forma que sua realizao em tempo real fica invivel. Neste caso, os softwares trabalham em um modo de baixa resoluo para poder mostrar uma viso prvia do resultado. Quando o projeto est concludo, ou em qualquer momento que se queira fazer uma aferio de qual ser o resultado final, faz-se a "renderizao" do trabalho.

O sistema envia uma cpia do programa para o segundo n, e em seguida passar a aliment-lo com os dados necessrios. Ao invs de ter todo o trabalho de comprimir o segundo vdeo, o seu PC receber apenas os resultados mastigados. Veja que para comprimir um vdeo em divx necessria uma quantidade absurda de processamento, um DVD de duas horas demora aproximadamente 11 horas num Athlon de 1.0 GHz. Em compensao, temos uma quantidade relativamente pequena de dados, cerca de 4 GB para a imagem do DVD (os dados so transmitidos ao longo das 11 horas, o que daria uma mdia de 103 KB/s) e no final temos gerado um arquivo menor ainda, que pode ser transmitido facilmente atravs da rede. O mesmo acontece se voc estiver comprimindo audio, renderizando cenas 3D ou outras tarefas onde seja necessria uma grande quantidade de processamento. Voc no precisa fazer nada para que os processos migrem. Cada micro roda uma distribuio Linux completa, com um pequeno cliente OpenMosix que monitora o nvel de carregamento dos demais ns da rede. O software inclui um conjunto de funes que "decidem" quais programas so bons candidatos a serem migrados, baseado no nvel de carregamento do sistema e no tipo e quantidade de dados manipulados por eles. Outra coisa que levada em conta o desempenho de cada micro disponvel na rede: o software sempre procura o micro onde a tarefa possa ser processada mais rapidamente. Se voc est usando um Celeron 366, mas existe um Athlon XP 2200+ disponvel do lado, ele quem acabar recebendo a maior parte do trabalho, fazendo com que alm de realizar as tarefas muito mais rpido, o seu Celeron fique bem mais leve. Mas, por outro lado, tarefas que envolvem uma carga muito grande de I/O, como por exemplo, assistir um vdeo em Divx ou um DVD ou rodar um servidor de banco de dados, por exemplo nunca so migradas automaticamente. Mesmo que voc forasse a tarefa a migrar para outro n manualmente, o desempenho provavelmente acabaria sendo inferior ao original. Vamos imaginar o que aconteceria se voc tentasse migrar um processo do mPlayer que est exibindo aquele filme em divx que voc baixou ontem. Normalmente o filme descomprimido cena por cena, gerando bitmaps que so exibidos pela placa de vdeo. Num filme com resoluo de 640x480, por exemplo, temos 614 KB por quadro (se forem usados 16 bits de cor) e geralmente 25 quadros por segundo o que vai dar uma transmisso de pouco mais de 15 MB/s para o vdeo e mais 88 KB/s para o udio. Se o vdeo estiver sendo processado localmente, os dados vo direto para a placa de vdeo e a quatidade de dados no problema, j que o barramento PCI transmite a 133 MB/s e o AGP atinge muito mais. Mas, se voc migrar o processo para outra mquina da rede os clculos j ficam mais apertados. Uma rede de 100 megabits permite uma taxa de transmisso terica de 12.5 MB/s, mas na prtica sempre temos um pouco menos. preciso ao mesmo tempo enviar os dados a serem descomprimidos junto com outras informaes e receber os quadros e udio prontos para serem exibidos. No final voc acabar com uma utilizao muito alta da rede, atrapalhando o trabalho dos outros micros e ainda por cima um vdeo falhado. Com uma conexo full-duplex (100 Mb de upload e 100 Mb de download simultneos) o cenrio j seria mais confortvel, mas ainda assim seria difcil ver o vdeo com qualidade. Embora no seja a soluo pra tudo, o OpenMosix uma soluo interessante pois no necessrio ter ns dedicados. Voc pode manter o cliente OpenMosix (que ao mesmo tempo um servidor) nas mquinas da sua rede, de forma que os ciclos livres de uma mquina sejam usados para processar dados enviados por outras mquinas. O OpenMosix no ajuda muito nas tarefas do dia a dia, como editar um arquivo no OpenOffice, jogar Unreall 2003 ou abrir um monte de pginas no Mozilla, mas pode ajudar bastante em tarefas mais pesadas, que so afinal onde voc realmente precisa de mais desempenho. A pgina oficial do OpenMosix a: http://openmosix.org ou http://openmosix.sourceforge.net/ Para funcionar preciso um mdulo compilado no Kernel. Em muitos casos as distribuies j vm com o modulo pronto na forma de um pacote instalvel, mas em outros preciso recompilar o Kernel adicionando o patch do OpenMosix. Existe um arquivo muito bom sobre a instalao do OpenMosix em vrias distribuies disponvel no: http://howto.ipng.be/openMosix-HOWTO/. O ClusterKnoppix uma verso customizada do Knoppix que inclui uma instalao do OpenMosix pronta pra usar, basta dar boot em alguns PCs ligados em rede, abrir o programa monitor e os ns comearo a se comunicar e trocar processos entre s. Se voc s tiver um CD, existe ainda a possibilidade de dar boot nos demais PCs via rede, via PXE. A pgina do ClusterKnoppix : http://bofh.be/cluster/. A imagem do CD tem quase 700Mb, o mesmo tamanho do Knoppix original e por enquanto est disponvel apenas via bittorrent. Depois de dar boot com o CD em todos os micros, use o ping para verificar se a rede est funcionando. O Knoppix configura a rede via DHCP durante o boot. Se no houver nenhum servidor disponvel voc pode configurar a rede manualmente em cada micro no Iniciar > Knoppix > Network/Internet > Network card configuration. Assim que a rede estiver configurada, o cluster formado automaticamente. Abra um terminal, use o "su" para virar root e chame o comando "openmosixmigmon". A janela mostra os ns do cluster, junto com seus respectivos endereos IP. O que est no centro o seu micro, os pontos pretos em volta dele so os processos que esto sendo executados e os pontos verdes mostram os processos que migraram para outros ns do cluster:

Se voc arrastar um dos pontos para outro n, o programa tentar migr-lo, mas voc logo vai perceber que a maioria dos processos de sistema no pode ser migrada. Por outro lado, muitos dos programas que voc abrir sero imediatamente migrados, mesmo sem a sua interveno. Outro programa til o "openmosixview". Ele mostra o nvel de carregamento de cada um dos ns do cluster. O "13667" na linha do n 234 mostra seu ndice de desempenho (no muito apurado) que usado para determinar quais ns devem receber trabalho primeiro. O n 250 aparece em vermelho, pois ele j fez parte do cluster, mas est no momento desligado ou desconectado da rede. Se voc estiver usando o micro mais rpido do cluster vai perceber que os processos demoram a migrar, mesmo que os outros PCs estejam livres. A idia bsica executar as tarefas o mais rpido possvel, ento se o seu micro o mais rpido normal que elas sejam executadas nele. Mas, voc pode alterar o ndice de desempenho do seu micro, fazendo com que o monitor passe a consider-lo mais lento que os demais e migre o mximo de processos possvel. Experimente usar o comando: mosctl setspeed 1000 Existe outro programa mais simples chamado "mosmon", que mostra um grfico simples, em modo texto indicando o nvel de carregamento de cada n. Aqui estou rodando duas instncias do kandel, um programa gerador de factrais que faz parte da distribuio. Ele um bom exemplo de programa que se beneficia do cluster pois seu trabalho envolve um quase nada de dados e um mundo de processamento. Abrindo duas instncias do Kandel cada um dos ns do cluster fica com uma:

De volta ao openmosixview, abra o openmosixcollector em Collector > openMosixCollector > Start. Ele um daemon que monitora a atividade do cluster e gera um log que depois pode ser examinado usando as outras ferramentas do openmosixview. Clicando sobre o boto com o endereo IP de qualquer um dos ns voc tem acesso a um menu de configurao, onde voc pode desabilitar a migrao automtica de processos para um determinado n da rede (uma mquina lenta por exemplo) entre outras opes. Esta configurao pode ser salva, mas isso s ser til se voc estiver usando o ClusterKnoppix instalado no HD (a instalao idntica do Knoppix normal) caso contrrio voc perde tudo ao reiniciar a mquina.

Obs: Embora o sistema de arquivos aparea como opo durante a instalao do ClusterKnoppix, a instalao vai falhar se voc escolh-lo. Verses antigas do ClusterKnoppix tambm tinham problemas com o Ext3

(bug que j foi corrigido segundo o chage-log), por isso o ideal que ao instalar no HD voc escolha o sistema de arquivos ReiserFS. Ainda no openmosixview, clique no File > Run Program e escolha um executvel qualquer (a maioria dos programas est na pasta /usr/bin ou /usr/share). Voc cair no menu de execuo avanada, onde voc pode definir em qual n do cluster o programa ser executado (opo "run on") especificar que o programa utiliza muito processamento e por isso um candidato a ser migrado rapidamente ("cpu job") ou que ele executa principalmente tarefas que envolvem grandes quantidades de dados ("io job") e que por isso no deve ser migrado:

Outro programa interessante o "openmosixprocs" que mostra uma lista dos processos que esto rodando e permite gerenciar os processos que migraram para outras mquinas:

Clicando sobre um processo qualquer na lista principal voc tem a opo de envi-lo para outra mquina ou mesmo fech-lo:

Se voc tiver apenas um CD do ClusterKnoppix, ou no tiver drive de CD em todas as mquinas, possivel configurar o micro com o CD-ROM para atuar como um servidor de boot remoto para os demais micros da rede, via PXE. O atalho est em: Iniciar > Knoppix > Services > Start Knoppix OpenMosix Terminal Server. O Wizard configurar o servidor para atender os chamados dos clientes e fornecer a eles os arquivos do CD (via NFS) para que eles possam dar boot atravs da rede. Este sistema basicamente o mesmo utilizado pelo LTSP e pelo Kurumin Terminal Server, a diferena que os clientes carregam todo o sistema do servidor e rodam os aplicativos localmente ao invs de passarem a atuar como terminais burros do servidor. A configurao bem simples. Ele pergunta a faixa de endereos IP que ser reservada para os clientes remotos e em seguida pede que voc escolha os mdulos das placas de rede usadas nos clientes. Voc pode

marcar quantos mdulos achar necessrio (em caso de dvida, por exemplo), o nico inconveniente que com muitos mdulos ativos o servidor consumir um pouco a mais de memria RAM. A seguir voc ter a opo de ativar mais alguns recursos:

A opo "textmode" faz com que os clientes no careguem o modo grfico durante o boot, deixando mais memria RAM disponvel para rodar os aplicativos. Esta opo interessante apenas caso voc queira deixar os outros clientes disponveis para receber processos, sem que ningum os use. As opes Masq, DNS e Squid cache/Proxy ativam o compartilhamento da conexo com a Intenret para os clientes. Estas opes so necessrias apenas caso o servidor esteja acessando diretamente a internet. Se todos os micros, incluindo o servidor estiverem atrs de outro micro que compartilha a conexo ou caso voc no pretenda acessar a Internet, as trs podem ficar desativadas. A ltima tela permite que voc passe parmetros de boot para as mquinas clientes, aquelas mesmas opes que podem ser usadas na tela de boot do Knoppix para ativar a rodinha do mouse (whellmouse), forar uma determinada resoluo de tela (screen=1024x768) e assim por diante. A maioria das placas me atuais, sobretudo as com rede onboard, suportam boot via rede utilizando o protocolo PXE. Voc precisa apenas configurar a sequncia de boot no Setup ou pressionar F8 ou F12, dependendo da placa durante a verificao de memria. O isso far o cliente enviar um pacote de broadcast pela rede, que ser respondido pelo servidor, dando sequncia ao carregamento do sistema.

O cliente vai se comportar quase da mesma forma que se comportaria caso estivesse com o CD do ClusterKnoppix no drive. Tambm no existe muita diferena de desempenho, pois numa rede de 100 megabits o gargalo a velocidade de leitura do CD-ROM e no a rede. Seria preciso um leitor de quase 100X para atingir uma taxa de leitura prxima de 12.5 MB/s. 8 Comunicao A comunicao em Sistemas Distribudos ocorre atravs da troca de mensagens que so objetos cuja estrutura e aplicao so definidas pelas prprias aplicaes que a usaro. Sendo a troca de mensagens feita atravs de duas primitivas explicitas de comunicao: send (destino, mensagem) envio da mensagem para o destino. receive (origem, mensagem) recebimento da mensagem enviada pela origem. As primitivas acima podem ser classificadas segundo: forma de comunicao: a.1) Direta send (process, msg) h indicao do processo receptor. receive (process, msg) h indicao do processo emissor. a.2) Indireta send (mailbox, msg) envio para uma porta ou mailbox sem o conhecimento de quem ser o receptor. receive (mailbox, msg) obteno da mensagem guardada no mailbox, possivelmente desconhecendo a identidade do processo emissor. forma de Sincronizao b.1) Sncrona ou Bloqueante send: espera at que a mensagem seja recebida pelo receptor. receive: aguarda at a mensagem estar disponvel b.2) Assncrona ou No Bloqueante send: envia a mensagem mas no espera at que a mensagem seja recebida pelo receptor.

receive: se a mensagem estiver disponvel, recebe a mensagem, caso contrrio continua o processamento retornando uma indicao de que a mensagem no estava disponvel. Um sistema pode possuir diferentes combinaes desses tipos de primitivas, sendo que a comunicao passa a ser conhecida como sncrona se ambas as primitivas (send, receive), forem do tipo bloqueante. Por outro lado, a comunicao dita assncrona se pelo menos uma das primitivas for assncrona. A principal desvantagem dessa abordagem o baixo nvel de abstrao que permite apenas a modelagem de troca indireta de informao entre processos. 8.1 Comunicao na arquitetura Cliente/Servidor um paradigma de programao que representa as interaes entre os processos e as estruturas do sistema. Neste modelo existem dois tipos de processos: Clientes: processos que requisitam servios; Servidores: processos que recebem requisies realizam alguma operao e retornam servios. No modelo cliente/servidor, o processo cliente necessita de um servio (ex. Ler dados de um arquivo), ento ele envia uma mensagem para o servidor e espera pela mensagem de resposta. O processo servidor, aps realizar a tarefa requisitada, envia o resultado na forma de uma mensagem de resposta ao processo cliente. Note que os servidores, em um sistema deste tipo, apenas respondem as requisies dos clientes, e, geralmente, no iniciam conversao com os clientes. A principal vantagem desta abordagem a simplicidade, porm a implementao menos eficiente do que a troca de mensagens pura. Possibilidade de vrios clientes acessarem um recurso de forma consistente e transparente atravs do uso de um nico servidor. Mas tambm possvel termos ambientes com mltiplos servidores, onde os mesmos podem ser replicados, isto , quando existem vrias instncias do mesmo servidor. A replicao muitas vez ocorre por questes de desempenho, distribuio natural dos recursos ou por tolerncia a falhas. Tambm possvel termos servidores hierrquicos, isto , servidores que usam o(s) servio(s) de outros servidores. Nestes casos, as localizaes e converses entre servidores devero ser transparentes aos clientes. Endereamento Para que um cliente envie mensagens a um servidor primeiro o cliente deve necessariamente conhecer o endereo do servidor, desse modo, preciso estabelecer uma forma de identificao: i) um identificador nico de processo quando na mesma mquina - com um nico processo por mquina basta indicar o endereo da mquina, pois o kernel consegue determinar qual o nico processo servidor. Esta no abordagem vivel, porque dificilmente teremos um nico processo servidor em uma mquina. ii) endereamento indicando o processo e a mquina - quando se permite mais de um processo servidor por mquina, devese enderear a mensagem a esse servidor especifico. Um esquema comum o uso de um nome composto por duas partes. Ex: 12,4 - sendo que 12 a mquina e 4 o processo. Nessa abordagem a identificao includa no cdigo do cliente. Com isso evitase o custo de coordenao global e tambm as ambigidades entre processos com identificadores idnticos, mas em mquinas distintas, no entanto, perdese em transparncia, pois preciso que o cliente conhea a localizao fsica do servidor. Isso pode causar problemas, como por exemplo: se um servidor de banco de dados normalmente executa na maquina 12, no momento em que a mesma for desligada para manuteno, podese disponibilizar o mesmo servio em outra mquina. Ao usar este esquema com maquinas fixas, o servio poder estar disponvel em outra mquina, mas no poder ser usado. iii) processos escolhem endereos que so detectados por broadcast24 - Cada processo deve receber um endereo nico que no envolva o nmero da sua mquina. Este endereo pode ser atribudo de duas formas: a) atravs de um escalonador de endereos de processo centralizado, que mantm um contador e ao receber uma requisio incrementa esse contador e envia o valor. A principal desvantagem a utilizao de um componente centralizado que compromete a tolerncia a falhas e a escalabilidade; b) cada processo escolhe um valor aleatoriamente a partir de um espao de endereamento grande (ex. 64 bits) e portanto com pouca probabilidade de coliso. O kernel emissor de uma requisio pode determinar para qual maquina enviar atravs do seguinte procedimento: I) o emissor envia a mensagem para todas as maquinas (broadcast) com um pacote especial de localizao contendo o endereo do processo destino; II) em cada maquina da rede o kernel verifica se o processo est na mquina. Quem estiver com o processo envia mensagem indicando seu endereo na rede; III) o kernel emissor guarda essas informaes para requisies futuras. Essa abordagem tem como vantagem ser transparente, mas tem o custo da mensagem broadcast. iv) servidor de nomes - neste esquema os servidores so indicados por um identificador de alto nvel (nome ASCII) que no inclui nem identificao da maquina nem do processo. Quando um cliente executa uma requisio a um servidor pela primeira vez, uma mensagem especial enviada para um servidor de mapeamento ou servidor de nomes solicitando o nmero da mquina onde est o servidor.
24

broadcast (Transmio em larga escala) permite que a informao seja enviada para todas as maquinas de uma LAN, MAN, ou WAN, redes de computadores e sub-redes. A RFC (Request for comments), RFC 919 a RFC padro que trata deste assunto. Uma de suas aplicaes no controle de trfego de dados de vrias redes, quando uma mquina (computador) ligada rede envia informaes para o hub, e se o mesmo estiver ocupado transmitindo outras informaes, o pacote de dados retornado a mquina requisitante com um pedido de espera, at que ele termine a operao. Esta mesma informao enviada a todas as mquinas interligadas a este hub porm aceita somente por um computador pr-endereado, os demais ecos retornam ao hub, e mquina geradora do pedido (caracterizando redundncia).

Se as mensagens envolvidas na comunicao cliente/servidor for assumida como no confiveis, recair ao usurio a tarefa de controlar possveis perdas de mensagens. Isso no desejvel uma vez que o objetivo tornar o mais transparente possvel para o usurio. Logo, desejvel que o kernel do SO se preocupe em verificar se as mensagens foram corretamente recebidas garantindo dessa forma uma comunicao confivel. 8.2 Comunicao atravs de Chamada Remota de Procedimento (RPC Remote Procedure Call) Chamada remota de procedimento permite que programas invoquem procedimentos ou funes localizadas em outras mquinas como se eles estivessem localmente definidos. Em nvel do programa, as informaes so passadas do chamador para o procedimento chamado atravs de parmetros e resultados so retornados atravs do resultado do procedimento. Deste modo, nenhuma mensagem ou entrada/sada visvel ao programador. Apesar de simples existem alguns pontos crticos que complicam este modelo, tais como: - chamador e chamado operam em espaos de endereamento diferentes (mquinas distintas); - a passagem de parmetros e resultados em maquinas com arquiteturas diversas; - possibilidades de falhas. Operao RPC Bsica A chamada de procedimento remoto deve parecer o mximo possvel com a chamada local de procedimentos. Por isso, utilizase a estrutura de cliente/servidor stubs25. A RPC segue os seguintes passos: i. O procedimento chama o stub cliente como se fosse um procedimento local qualquer; ii. O stub cliente constri mensagens e passa ao kernel; iii. O kernel remoto envia a mensagem ao stub servidor; iv. O kernel remoto entrega a mensagem ao stub servidor; v. O stub servidor desempacota os parmetros e chama o servidor; vi. O servidor realiza o trabalho solicitante e envia o resultado ao stub servidor; vii. O stub servidor empacota o resultado em uma mensagem e passa para o kernel; viii. O kernel remoto envia mensagem ao kernel cliente; ix. O kernel cliente entrega a mensagem ao stub cliente; x. O stub desempacota o resultado e retorna ao stub cliente. O efeito da execuo de todos esses passos a converso da chamada local de um cliente a um stub cliente em uma chamada ao procedimento servidor sem que o cliente ou servidor percebam os passos intermedirios. Via de regra os stubs so gerados automaticamente por um compilador. Essa operao RPC bsica tem alguns aspectos e problemas interessantes que sero vistos a seguir: a) Passagem de Parmetros preciso tratar a passagem de parmetros e a converso de dados. Isso feito pela operao de empacotamento de parmetros (parameter marshalling). Essa operao trata problemas de representao distinta de dados (nmeros/caracteres) para mquinas heterogneas: Tanto o cliente quanto o servidor sabem os tipos de parmetros passados (identificador do procedimento + parmetros) e devem conseguir obter a representao correta dos dados. Opo 1: uso de um padro de representao de dados, como por exemplo o XDR26 do RPC UNIX. Essa alternativa muito interessante por permitir a comunicao entre mquinas heterogneas. A vantagem que entre mquinas homogneas no h necessidade de incluir um custo adicional de converso da representao da mquina para a representao padro. Opo 2: a mensagem enviada no formato nativo com indicao de qual formato foi utilizado. O receptor deve fazer a converso quando for o caso. Essa opo evita custos de converso em ambientes homogneos, entretanto exige que clientes e servidores saibam converter qualquer formato para a sua representao nativa. b) Passagem de Ponteiros Um ponteiro representa um endereo de memria que no tem nenhum significado na mquina remota. Opo 1: proibir a passagem de ponteiros, essa obviamente no uma alternativa desejvel pelo programador; Opo 2: Copiar o valor apontado pela varivel ponteiros. As alteraes so feitas remotamente e no retorno as alteraes so atualizadas no chamador (semntica cpia/restaurao). Uma otimizao possvel consiste em, sabendo que um determinado parmetro apenas de entrada, evita o retorno do contedo do ponteiro. De forma anloga, se ele for apenas de sada, ele no precisa ser copiado no envio. Esse tipo de informao pode ser fornecido pelo programador ou extrado a partir da anlise do cdigo fonte (anlise esttica).

25

stub um mecanismo padro empregado em sistemas RPC, para se comunicar com objetos remotos. O stub funciona semelhante a um proxy para o objeto remoto. Quando um objeto local invoca um mtodo num objeto remoto, o stub fica responsvel por enviar a chamada ao mtodo para o objeto remoto. 26 XDR - eXternal Data Representation um padro IETF (Internet Engineering Task Force comunidade internacional preocupada com a arquitetura e perfeito funcionamento da Internet) de 1995 da camada de apresentao do Modelo OSI. XDR permite dados serem empacotados em uma arquitetura de maneira independente para que o dado seja transferido entre sistemas com computadores heterogneos. Converter da representao local para XDR conhecido como codificao. Converter do XDR para a representao local conhecido como decodificao. XDR implementado como uma biblioteca de funes que so portveis entre diferentes sistemas operacionais e tambm so independentes da camada de transporte.

c) Semntica RPC na Presena de Falhas Na execuo de uma chamada remota de procedimentos, existem cinco classes diferentes de falhas possveis: - O cliente no consegue localizar o servidor - Mensagem de requisio perdida - Mensagem de resposta perdida - O servidor cai aps receber uma requisio - O cliente falha aps enviar uma requisio (falha do cliente). Questes de Implementao As questes de implementao analisadas a seguir esto relacionadas s questes de desempenho. i) Protocolo Em principio qualquer mecanismo de troca de mensagem poderia dar suporte a implementao de RPC. Uma das questes a serem decididas na implementao se o protocolo ser orientado a conexo ou sem conexo. No primeiro caso, evitase o problema de mensagens perdidas, pois isso tratado em baixo nvel, porm, o desempenho menor. No segundo caso, o desempenho melhor, sendo indicado para implementao em redes que no so confiveis. ii) Confirmao (Acknowledgment ACK) As mensagens de confirmao so usadas para deteco de falhas. No momento de implementar, preciso decidir se os pacotes sero confirmados individualmente ou no. Assim temos dois tipos de protocolos: stopandwait - se um pacote for danificado ou perdido, o cliente no recebendo o ACK providncia o reenvio; e o Blast onde o servidor envia mensagem ACK apenas no final. No caso do protocolo Blast, h duas formas de tratar o fato se apenas alguns pacotes foram entregue e outros no. Uma hiptese ignorar todos os pacotes e solicitar a retransmisso de todos os pacotes. Outra possibilidade realizar uma repetio seletiva (selective repeat), porm no compensa devido ao custo de controle envolvido. Outro problema est relacionado ao fato de que os buffers de recepo so limitados. O envio de vrias mensagens consecutivas pode causar um overrum error. O overrum error caracterizase pela incapacidade do receptor de receber um pacote que chega corretamente causando dessa forma uma perda de mensagem. Na prtica esse um erro mais srio do que a perda por rudo ou outros problemas fsicos na rede. Com o uso de stopandwait em princpio esse erro no ocorre, pois uma s mensagem enviada de cada vez. No entanto, poder ocorrer caso diferentes emissores enviem vrias mensagens ao mesmo tempo. 8.3 Comunicao em Grupos Um grupo uma coleo de processos que agem juntos. Quando uma mensagem enviada ao grupo, todos os membros do grupo recebem a mesma mensagem. Grupos so dinmicos, podem ser criados e destrudos, processos podem entrar ou abandonar um grupo, e um mesmo processo pode pertencer a mais de um grupo, desta forma permite-se que processos em grupos sejam tratados como uma nica abstrao. Existem vrias tipos de aplicaes que utilizam a comunicao com mltiplos processadores. Ex.: - Grupos de servidores de arquivos que fornecem servio de arquivos tolerantes a falhas - se um servidor falha, o cliente ainda pode ser atendido. Um processo pode enviar mensagens para um grupo de servidores sem saber quantos eles so ou onde se localizam, sendo que tais parmetros podem mudar na prxima chamada. - Localizar objetos em servios distribudos - encontrar um arquivo num sistema de arquivos distribudo. - Propagao de notificaes de eventos - um sistema de noticias pode avisar os usurios interessados quando uma nova mensagem tenha sido divulgada. - Dados replicados: quando dados mudam, o valor passado aos processos que gerenciam as replicas por multicast. Propriedades: Atomicidade: Ou todos os processos do grupo recebem uma mensagem ou nenhum processo recebe a mensagem. O caso normal, sem atomicidade, seria aquele em que a mensagem transmitida enviada para todos os processos que so membros do grupo de recebimento, mas sem garantia de recebimento. Ordenao: Quando varias mensagens so enviadas, e elas devem chegar na mesma ordem em que foram enviadas para todos os integrantes do grupo (ordenamento total - mensagens so enviadas com nmero de seqncia). Tipos de Emissores Grupos Abertos: Qualquer processo pode enviar mensagem ao grupo.Usados nos casos de replicao do servio Grupos Fechados: Apenas um dos membros do grupo pode enviar mensagens ao grupo. Usados tipicamente para processamento paralelo. Tipos de Remetentes Todos respondem Somente quem precisa responde

P B C

P B C

Tipos de arquiteturas Grupos Pares (distribudo): Todos os processos so iguais (pares). Decises so tomadas coletivamente. Vantagem: no tem nico ponto de falha. Desvantagem: tomada de decises exige votao mais tempo. Grupos Hierrquicos (centralizado): Um processo o coordenador e os outros so subordinados a ele. Vantagem: coordenador gerencia as atividades. Desvantagem: ponto nico de falha. Tipos de Difuso Anycast uma forma de transmisso onde a mensagem enviada ao destino o mais prximo ou melhores definido pelo roteamento da rede. O anycast serve melhor para os protocolos connectionless (construdos geralmente sobre UDP27), ao invs dos protocolos orientados conexo, como o TCP28 ou o UDP baseados em protocolos que mantm seu prprio estado, j que o receptor selecionado para toda a fonte dada pode mudar de tempo em tempo como a mudana otimizada das rotas, quebrando silenciosamente quaisquer conversaes que puderem estar em andamento naquele momento. Para esta razo, o anycast usado geralmente como uma maneira fornecer a disponibilidade elevada e balanceamento de carga para servios sem estado, como o acesso a dados replicados.

Unicast ou difuso simples: transmisso ponto-a-ponto, isto , a mensagem enviada para uma nica mquina.

Broadcast ou difuso em larga escala: a mensagem enviada para todas as mquinas da rede. Uma de suas aplicaes no controle de trfego de dados de vrias redes, quando uma mquina (computador) ligada rede envia informaes para o hub, e se o mesmo estiver ocupado transmitindo outras informaes, o pacote de dados retornado a mquina requisitante com um pedido de espera, at que ele termine a operao. Esta mesma informao enviada a todas as mquinas interligadas a este hub e aceita somente por um computador pr-endereado, os demais ecos retornam ao hub, e mquina geradora do pedido (caracterizando redundncia). A RFC (Request for comments), RFC 919 a RFC padro que trata deste assunto.
27

UDP (User Datagram Protocol) um protocolo simples da camada de transporte. Ele descrito na RFC 768 e permite que a aplicao escreva um datagrama encapsulado num pacote IPv4 ou IPv6, e ento enviado ao destino. Mas no h qualquer tipo de garantia que o pacote ir chegar ou no. O protocolo UDP no confivel. Caso garantias sejam necessrias, preciso implementar uma srie de estruturas de controle, tais como timeouts, retransmisses, acknowlegments, controle de fluxo, etc. Cada datagrama UDP tem um tamanho e pode ser considerado como um registro indivisvel, diferentemente do TCP, que um protocolo orientado a fluxos de bytes sem incio e sem fim. Tambm dizemos que o UDP um servio sem conexo, pois no h necessidade de manter um relacionamento longo entre cliente e o servidor. Assim, um cliente UDP pode criar um socket, enviar um datagrama para um servidor e imediatamente enviar outro datagrama com o mesmo socket para um servidor diferente. Da mesma forma, um servidor poderia ler datagramas vindos de diversos clientes, usando um nico socket. O UDP tambm fornece os servios de broadcast e multicast, permitindo que um nico cliente envie pacotes para vrios outros na rede.
28

TCP (Transmission Control Protocol) um dos protocolos sob os quais assenta o ncleo da Internet. A versatilidade e robustez deste protocolo tornou-o adequado a redes globais, j que este verifica se os dados so enviados de forma correta, na sequncia apropriada e sem erros, pela rede. O TCP um protocolo do nvel da camada de transporte (camada 4) do Modelo OSI e sobre o qual assentam a maioria das comunicaes, como o SSH, FTP, HTTP e, a World Wide Web. O TCP usa vrias tcnicas para proporcionar uma entrega confivel dos pacotes de dados, que a grande vantagem que tem em relao ao UDP, e motivo do seu uso extensivo nas redes de computadores. O TCP permite a recuperao de pacotes perdidos, a eliminao de pacotes duplicados, a recuperao de dados corrompidos, e pode recuperar a ligao em caso de problemas no sistema e na rede. O TCP usa o campo janela ou window para controlar o fluxo. O receptor, medida que recebe os dados, envia mensagens ACK (Acknowledgement, confirmao), confirmando a recepo de um segmento; como funcionalidade extra, estas mensagens podem especificar o tamanho mximo do buffer no campo (janela) do segmento TCP, determinando a quantidade mxima de bytes aceita pelo receptor. O transmissor pode transmitir segmentos com um nmero de bytes que dever estar confinado ao tamanho da janela permitido: o menor valor entre sua capacidade de envio e a capacidade informada pelo receptor. A aplicao faz a entrega ao TCP de blocos de dados com um tamanho arbitrrio num fluxo (ou stream) de dados, tipicamente em octetos. O TCP parte estes dados em segmentos de tamanho especificado pelo valor MTU. Porm, a circulao dos pacotes ao longo da rede (utilizando um protocolo de encaminhamento, na camada inferior, como o IP) pode fazer com que os pacotes no cheguem ordenados. O TCP garante a reconstruo do stream no destinatrio mediante os nmeros de sequncia.

Multicast ou difuso seletiva: a mensagem enviada para as mquinas que fazem parte de determinado grupo. Isto permite que o remetente transmita um nico datagrama29 IP30 para um conjunto de computadores que formam um grupo de multicast. Um grupo multicast especificado por um endereo IP classe D (primeiros 4 bits so 1110 no protocolo IPv4). Os endereos multicast podem ser permanentes ou temporrios. O multicast IP est disponvel somente atravs do protocolo UDP. API Java oferece suporte para multicast IP atravs da classe MulticastSocket.

8.4 Sockets Um socket um programa, ou rotinas de programas (funes) que permitem a comunicao, interligao e troca de dados entre aplicaes. Por exemplo, quando feita uma conexo de FTP, um socket estabelecido entre a origem e o destino. At mesmo os famosos exploits31 utilizam sockets para estabelecer comunicao. Tipos de sockets : stream (TCP/IP) e datagram (UDP/IP) Stream: confiveis, os dados so entregues em ordem na mesma seqncia de envio. Comunicao bidirecional, orientado a conexo. Existe uma conexo lgica entre os processos. Este alto grau de qualidade na transmisso proporcionado pelo Protocolo de Controle de Transmisso, mais conhecido como TCP. TCP assegura que os dados chegaro sequencialmente e livres de erros. O TCP a melhor metade do TCP/IP, onde IP significa Protocolo de Internet. O IP cuida basicamente do roteamento e no responsvel pela integridade dos dados. Datagram: no confiveis, os dados podem ser recebidos fora de ordem. Comunicao bidirecional, porm sem conexo. Cada datagrama enviado separadamente podendo usar caminhos diferentes. Os Datagram Sockets tambm so conhecidos com sem conexo basicamente devido ao fato de no precisar manter uma conexo aberta como os Stream Sockets. so construir um pacote, anexar um cabealho IP com informaes de destino, e enviar. No precisa haver conexo. Ele so mais utilizados para transferncias pacote por pacote de informaes. Comunicao via Sockets tipo stream (TCP/IP) socket: cria um tipo de socket para a comunicao com outro processo bind: associa o descritor com o endereo socket (porta) listen: ouve no socket por pedidos de conexo de clientes. connect: solicita conexo com processo servidor. accept: aceita a conexo requisitada e obtm um novo socket para comunicao com este cliente. write: envia sequncias de bytes. read: recebe sequncias de bytes.

29

Em uma rede de computadores ou telecomunicaes, pacote, trama ou datagrama uma estrutura unitria de transmisso de dados ou uma sequncia de dados (stream) transmitida por uma rede ou linha de comunicao que utilize a comutao de pacotes. 30 IP (Internet Protocol) um protocolo de comunicao usado entre duas ou mais mquinas em rede para transmisso de dados. 31 Um exploit, em segurana da informao, um programa de computador, uma poro de dados ou uma sequncia de comandos que se aproveita das vulnerabilidades de um sistema computacional como o prprio sistema operativo ou servios de interao de protocolos (ex: servidores Web).

Comunicao via Sockets tipo datagramas (UDP/IP) socket: cria um socket para a comunicao com outro processo bind: associa o descritor com o endereo socket (porta) sendto: manda uma mensagem para outro socket recvfrom: coleta a primeira mensagem que chegar na fila do socket (wait)

Implementao prtica de um Socket Basicamente um socket pode ser declarado mediante trs bibliotecas bsicas no Linux. Estas trs bibliotecas permitem a chamada para as funes que estabelecem uma conexo. No Windows a biblioteca a ser includa winsock.h. De forma geral a declarao de socket em linguagem C feita da seguinte maneira:
//Linux #include <sys/types.h> #include <sys/socket.h> #include <arpa/inet.h> //Windows #include <winsock.h> main() { int e_socket; ... }

Os dois tipos de sockets mais utilizados em aplicaes so os baseados em protocolo TCP (Stream Sockets) e os que utilizam o protocolo UDP (Datagram Sockets). Estes sockets tambm so conhecidos como "SOCK_STREAM" e "SOCK_DGRAM", respectivamente. A estrutura quem define o tipo de Socket: SOCK_STREAM ou SOCK_DGRAM, assim ela pode ser definida da seguinte maneira :
struct sockaddr_in { short int sin_family; unsigned short int sin_port; struct in_addr sin_addr; unsigned char sin_zero[8]; }

Cada item desta estrutura define uma caracterstica importante, so elas : - Tipo de famlia do socket, sendo que os padres mais comuns seriam os seguintes : i) AF_INET - ARPA INTERNET PROTOCOLS ii) AF_UNIX - UNIX INTERNET PROTOCOLS iii) AF_ISSO - ISO PROTOCOLS iv) AF_NS - XEROX NETWORK SYSTEM PROTOCOLS unsigned short int sin_port; - Nmero da porta TCP ou UDP a ser utilizada para a comunicao dos programas. struct in_addr sin_addr; - Endereo IP do host destino. Pode ser colocado de maneira direta ou atravs de parmetro via entrada de dados. unsigned char sin_zero[8]; - Zera a estrutura do socket.
short int sin_family;

Logo a declarao do socket feita da seguinte maneira :

e_socket = socket(sin_family, tipo_do_socket_desejado,nmero_do_protocolo);

Convertendo para o C ANSI ficaria assim :

e_socket = socket(AF_INET,SOCK_STREAM,0);

Onde 0 o nmero do protocolo IP, e pode ser substitudo pelos seguintes protocolos: 0 - IP - INTERNET PROTOCOL 1 - ICMP - INTERNET CONTROL MESSAGE PROTOCOL 2 - IGMP - INTERNET GROUP MULTICAST PROTOCOL 3 - GGP - GATEWAY-GATEWAY PROTOCOL 6 - TCP - TRANSMISSION CONTROL PROTOCOL 17 - UDP - USER DATAGRAMA PROTOCOL Veja agora um cdigo fonte com mais detalhes:
main() { int e_socket; // declarao variveis struct sockaddr_in destino; e_socket = socket(AF_INET,SOCK_STREAM,0); // cria um socket tipo Stream if(e_socket < 0) { perror("Erro na criao do Socket"); exit(1); } // configura as caractersticas do destinatrio da comunicao destino.sin_family = AF_INET; // protocol ARPA Internet destino.sin_port = htons(2048); // nmero da porta TCP destino.sin_addr.s_addr = inet_addr("10.0.0.1"); // endereo IP do destino bzero(&(destino.sin_zero),8); // zera - limpa a estrutura do socket ... }

A Funo connect() Responsvel pelo estabelecimento da conexo em uma porta propriamente dita. Quando um programa vai se comunicar com outro a funo connect() do socket utilizada para testar a conexo e iniciar o processo de comunicao. O prottipo da declarao da funo o seguinte :
int connect(socket,(struct sockaddr * )&destino, sizeof(destino));

A Funo gethostbyname() Est funo nos permite digitar um endereo e retorna o endereo IP. Ela est descrita da seguinte forma na biblioteca winsock.h:
DECLARE_STDCALL_P(struct hostent *) gethostbyname(const char*);

Para uso desta funo, deve-se entender a estrutura hostent, que onde ela ser armazenada. Ento vamos analizar a estrutura hostent de acordo com a biblioteca winsock.h.
struct hostent { char *h_name; char **h_aliases; short h_addrtype; short h_length; char **h_addr_list; #define h_addr h_addr_list[0] };

- h_name Nome do domnio do host - h_aliases Lista de nomes alternativos que o site pode ter - h_addrtype O tipo de endereo que est retirando na conexo, que pode ser AF_INET, AF_UNIX, AF_ISSO ou AF_NS. - h_lenght Tamanho, em bytes, do endereo - h_addr_list Um array que termina em zero, do endereo de rede do host. A Funo inet_ntoa() Faz a converso de Network-to-ASCII, ou seja, faz a converso de nmeros de Rede para ASCII (que legvel), pois o endereo vir em nmeros de redes, ilegveis para ns. Esta funo descrita da seguinte forma na winsock.h e necessita do argumento struct in_addr dentro dela:
DECLARE_STDCALL_P(char *) inet_ntoa(struct in_addr);

Agora um programa completo onde verificado se determinada porta de uma mquina est aberta.
#include <stdio.h> #include <stdlib.h> #include <winsock.h> // biblioteca do windows #include <arpa/inet.h> // biblioteca do linux #include <sys/types.h> // biblioteca do linux #include <sys/socket.h> // biblioteca do linux // declarao variveis globais do socket int e_socket; struct sockaddr_in destino; int conexao; main() { // Faz o windows iniciar a dll e o ocx responsvel pela comunicao WSADATA wsaData; WSAStartup(MAKEWORD(1, 1), &wsaData); // cria o socket TCP SOCK_STREAM e_socket = socket(AF_INET,SOCK_STREAM,0); // testa se ele foi criado corretamente if(e_socket < 0) { perror("ERRO: !"); exit(1); } // configura as caractersticas do destinatrio da comunicao destino.sin_family = AF_INET; // protocol ARPA Internet destino.sin_port = htons(22); // nmero da porta TCP destino.sin_addr.s_addr = inet_addr("100.100.160.209"); // endereo IP do destino bzero(&(destino.sin_zero),8); // zera - limpa a estrutura do socket memset(&(destino.sin_zero),/0, 8); // copia para a memria(memset) a estrutura zerada (sin_zero) // cria a conexo conexao = connect(e_socket,(struct sockaddr * )&destino, sizeof(destino)); // testa se ela foi estabelecida corretamente

if(conexao < 0) { perror("Porta fechada !\n"); close(e_socket); exit(1); } printf("A PORTA 22 DA Mquina 100.100.160.209 ESTA ABERTA !\n"); close(e_socket); }

Com este cdigo fonte inicial possvel comear a especular algumas coisas. O programa descrito acima o princpio remoto de um scanner TCP de portas, pois estamos testando se a porta 22 est ativa ou no. Pode-se propor o seguinte: criar um scanner TCP que teste um range de portas. Ou ainda fazer uma troca de dados. 9 Algoritmos, Tempo, Relgios, Sincronizao, Excluso Mtua, Deadlock, Coordenao 9.1 Algoritmos Distribudos Existem vrios modelos de algoritmos para Sistemas Distribudos, cada um com destaque em relao a alguma caracterstica, por exemplo, quanto ao: - Mtodo de comunicao entre processos (IPC - Inter-Process Communication); - Modelo de tempo; - Modelo de falhas; - Tipo de Problema que se deseja resolver. Esses algoritmos diferem da classe genrica de algoritmos concorrentes por possurem um maior grau de incertezas e distribuio de controle. Incertezas se referem falta de conhecimento sobre: - Nmero de processadores, velocidades relativas entre processadores; - Topologia da rede, tempo de entrega de mensagem, ordem de entrega de mensagens; Nem todo algoritmo precisa tratar de todas essas incertezas, mas devido a essas incertezas, o comportamento de algoritmos distribudos complexo. O cdigo pode ser pequeno, mas comportamento pode ser muito diferente para uma mesma entrada (muitos passos intercalados de muitas maneiras ou combinaes). 9.2 Tempo em sistemas distribudos O Tempo, portanto, uma grandeza que se deseja medir precisamente. A necessidade de tratar o Tempo surge em funo da: - Ordenao de Eventos: necessrio determinar em que ordem dois eventos quaisquer ocorreram, mesmo que em ns diferentes; - Sincronizao devido existncia de diversos problemas relacionados na distribuio como: Manuteno da consistncia de dados distribudos; Utilizao de recursos compartilhados (deadlock); Ordem de chegada de requisies enviadas para um servidor; Eliminao do processamento de atualizaes replicadas. Limitaes inerentes a um Sistema Distribudo O problema consiste em indicar o tempo dos eventos de modo suficientemente preciso. No existe um tempo global absoluto ao qual se possa recorrer. No h relgio comum (compartilhado) em um sistema distribudo. O estado temporal do sistema est distribudo pela rede. Surgem dificuldades para desenvolver e depurar algoritmos em Sistemas Distribudos como: excluso mtua, sincronizao, deadlock, entre outros. Tempo Astronmico: Desde o sculo XVII, o tempo medido astronomicamente. Um segundo era definido como 1/86400 do perodo entre a passagem do sol pelo ponto mais alto no cu em dois dias consecutivos. Em 1940 descobriu-se que o perodo de rotao da Terra no constante, e est aumentando. Gelogos acreditam que 300 milhes de anos atrs havia 400 dias por ano (causa principal: atrito das mars). Tempo Atmico: Em 1949 a NBS (em ingls: National Bureau of Standards - atualmente NIST) apresentou o primeiro relgio atmico mundial, permitindo medir o tempo sem depender de caractersticas da Terra. Desde 1967, o segundo padro ficou definido como 9.192.631.770 perodos de radiao durante a transio entre duas camadas hiper-finas do estado fundamental do Csio-133. O Tempo Atmico Internacional (TAI) o nmero de segundos desde meia-noite de 1 de Janeiro de 1958, calculado pelo Escritrio Internacional de Pesos e Medidas (BIPM), na Frana, usando informaes de cerca de duzentos relgios atmicos em mais de 50 laboratrios ao redor do mundo. Segundo Solar mdio (MSS - Mean Solar Second): o segundo mdio obtido pela medio do perodo entre as passagens do sol ao longo de um ano. Se a rbita da Terra fosse circular e o eixo da Terra fosse perpendicular elptica, entre o meio-dia de dois dias consecutivos, observados num relgio solar decorriam exactamente 24 horas, ou seja 86400s. Tempo Universal Coordenado (UTC): o TAI com "segundos extras" adicionados sempre que a diferena entre o TAI e o MSS passa de 800 msec, e a base para a contagem de tempo em todo o mundo. Os sinais UTC so sincronizados e transmitidos por estaes de radio terrestres e por satlites, incluindo o GPS (Global Positioning System). Receptores esto disponveis comercialmente.

No sentido de se estabelecer um Tempo preciso e sincronizado varias tcnicas foram desenvolvidas, veja aseguir. 9.3 Relgios Fsicos (RF) Os computadores (PCs tradicionais) tm um relgio fsico baseado em oscilaes de um cristal que pode variar de acordo com as caractersticas de cada relgio. No entanto existem relgios atmicos que contam as transies de estado do material radioativo, so considerados de: alta preciso, alto custo, em quantidade limitada, em geral localizados em centros de pesquisa. Para determinadas aplicaes (ex. sistemas de tempo real) a sincronizao do tempo necessria. A Soluo, portanto, sincronizar periodicamente os relgios de cada computador com um relgio mais preciso. Problemas: Como sincronizar os relgios de um sistema com o mundo real; Como sincronizar os diversos relgios entre si. 9.4 Relgios Lgicos (RL) Baseiam-se em nmeros de seqncia atualizados localmente, que permitem verificar a ordem de eventos. O nmero de seqncia pode ser implementado atravs de um relgio local ou um contador de mensagens. Abordagem: - Execuo de processos uma seqncia de eventos; - Receber e Enviar mensagens so eventos. Assim definir um ordenamento parcial dos eventos e estender a definio para ordenamento total uma soluo eficiente para a ordenao de eventos. Relao de Ordenamento Causal Conceito descrito por Lamport em 1978. A relao que acontece antes () descreve ordenamento causal entre eventos: AA1: Se a e b so eventos no mesmo processo e a acontece antes de b, ento a b. AA2: Para qualquer mensagem m, send(m) receive(m). AA3: Se a b e b c ento a c. (transitividade). Eventos Concorrentes: Dois eventos a e b so concorrentes (a || b) Exemplo: | | a b | c | e | d | f

p1 p2 p3

Um sistema de relgios lgicos representado por uma funo C que atribui um nmero C(a) para todo evento a em um sistema distribudo. Existe um relgio lgico Ci para cada processo Pi; Os valores atribudos para Ci so valores crescentes. Para cada evento a atribudo um valor de relgio C(a) que todos os processos concordam. C(a) o timestamp do evento a; Condies de Relgio As seguintes condies devem ser satisfeitas por parte dos relgios (locais) Ci para satisfazer a condio do relgio: C1: Para quaisquer dois eventos a e b no mesmo processo Pi: Se a b ento Ci(a) < Ci(b) C2: Se a=send(m) num processo X e b=receive(m) num processo Y, ento Cx(a) < Cy(b). Condies de Correo As seguintes regras fazem com que as condies C1 e C2 sejam satisfeitas: RL1: Ci incrementado antes da ocorrncia de um evento no processo Pi: Ci = Ci + d (d>0) RL2: (a) Se a o envio de m pelo processo Pi ento m leva de carona o valor Tm = Ci(a). (b) Se b a recepo de m pelo processo Pj ento Cj recebe um valor Cj e > que Tm: Cj = max( Cj + d, Tm + e) (d>0, e>0) 9.5 Relgios Vetoriais (RV) Propostos por Mattern e Fidge em 1991. Esta abordagem supera as deficincias dos relgios de Lamport, considerando o fato de que a partir de C(a) < C(b) no podemos concluir que a b.

Um relgio vetorial para um sistema com n processos um vetor de n inteiros. RV1: Inicialmente Vi[k] = 0, para i,k = 1..n RV2: Quando um evento i ocorre num processo p, Vp[p]++ RV3: Se a = send(m) no processo p, Tm = Vp[p] RV4: Se b = receive(m) no processo p, Vp = merge(Vp[p], Tm) Desvantagem: ocupa mais espao de armazenamento. Para analisar se a b: Seja o evento a em Pi e o evento b em Pk. Seja o timestamp(a) = (...,x,...y,...) e o timestamp(b) = (...,w,...,z,...), sendo x e w valores da coluna i e y e z valores da coluna k. Logo a b se e somente se x<=w e y<=z. 9.6 Sincronizao Sincronizao externa: atravs de fonte externa. Sincronizao interna: somente dentro do sistema. Sistemas sncronos Um processo pa envia o tempo ta de seu relgio local para o outro processo pb em uma mensagem m. Ttrans = tempo transmisso de m. tb = ta + Ttrans Na pratica: min <= Ttrans <= max Incerteza u = max min Ideal que Ttrans = (max+min)/2 Desvio mximo: u/2 Sistemas assncronos no se conhece max Ttrans = min + x, onde x >= 0 Algoritmo de Cristian Sincronizao externa. Como nem todos podem (ou querem) ter um relgio atmico torna-se necessrio sincronizar o relgio de um computador cliente com o relgio de um servidor de tempo. No algoritmo de Cristian, o cliente ativo: ele decide quando perguntar ao servidor o valor do seu relgio. Envia um pedido, mede a diferena de tempo entre o envio do pedido e o recebimento da resposta, e assume que o valor retornado foi medido exatamente no ponto mdio entre o envio e o recebimento. Opcionalmente, o cliente pode enviar vrios pedidos e escolher aquele que for atendido mais rpido. Problemas bsicos: Um relgio nunca deve recuar. O servidor ponto de falha. Soluo ao problema Reduzir a freqncia de oscilao do relgio Algoritmo de Berkeley Sincronizao interna. No algoritmo de Berkeley, introduzido no Unix Berkeley, o servidor ativo, e no tem acesso a um relgio de preciso: o objetivo manter um grupo de computadores sincronizado com a mdia dos valores de seus relgios. O servidor pergunta aos clientes o valor de seus relgios, calcula a mdia, ajusta seu prprio relgio, calcula a correo para cada cliente e envia uma mensagem para cada um com a correo a ser aplicada.
3:00 3:00 3:00 3:00

3:00 3:00 +25 -10 -20

3:05 +5 +15

3:25

2:50

3:25

2:50

3:05

3:05

Sincronizao de RF pela Internet NTP (Network Time Protocol - http://www.ntp.org) uma implementao do algoritmo de Cristian utilizado em larga escala na Internet. Organizao Hierrquica: Servidores Stratum 1 esto conectados a relgios atmicos que provm o servio de sincronizao apenas para servidores Stratum 2 (localizados em universidades e rgos governamentais, como a RNP no Brasil). Qualquer um pode acessar servidores Stratum 2 esporadicamente de forma a no congestionar seus canais de comunicao. Em geral empresas e organizaes usam um servidor Stratum 3 para sincronizar os seus computadores.

9.7 Excluso mtua, mutex ou mutual exclusion Trata-se de uma tcnica usada em programao concorrente para evitar que dois processos ou threads tenham acesso simultneo a um recurso compartilhado, esse acesso simultneo denominado de seo crtica (SC). Um meio simples para tratar excluso mtua a utilizao de um semforo binrio, isto , que s pode assumir dois valores distintos, 0 e 1. A alocao do recurso por semforo deve ser feita antes de utilizar o recurso, e aps o uso, o recurso deve ser liberado. Enquanto o recurso estiver em uso, qualquer outro processo que necessite do recurso deve esperar a liberao. Porm, essa tcnica pode causar vrios efeitos colaterais, como: deadlocks, em que dois processos obtm o mesmo semforo e ficam esperando indefinidamente a liberao do semforo; e inanio ou starvation, que quando o processo no consegue obter o recurso para poder executar plenamente. Propostas para implementao da Excluso Mtua: - desabilitao de interrupes; - espera ocupada; - Semforos; - Monitores. Problemas relacionados Excluso mtua Deadlock: um ou mais processos ficam bloqueados, a espera do recurso que outro processo detm. Starvation: alguns processos so repetidamente postergados, enquanto outros ficam com o acesso ao recurso desejado. Exemplo: Considere uma estrada com uma ponte por onde s passa um carro de cada vez.

Deadlock Um carro de cada lado comea a atravessar, e os dois se encontram no meio da ponte. Nenhum dos dois tem como continuar... Starvation Se, ao chegar ponte, j existe um carro atravessando, o carro que chegou na direo de quem est atravessando e atravessa tambm. O carro que est aguardando em direo oposta espera at que os outros carros tenham acabado de cruzar, porm pode ocorrer que sua vez nunca chegue.

Algoritmo Centralizado Um processo o coordenador. Funcionamento Sempre que um processo deseja entrar em uma seo crtica (SC), ele envia uma requisio para o coordenador (mensagem Solicitao). O coordenador garante permisso para entrar na SC (mensagem OK); se existe um processo na SC, as prximas requisies so enfileiradas (mensagem Espere). Tipos de mensagens: Requisio; Ok; Liberao. Pc = 3

0 Requisio

1 OK 3

2 OK

Requisio 3 2

Liberao 3 vazia
(c)

Fila:

vazia

(a) (b) Caractersticas: Garante excluso mtua; justo; Nenhum processo espera indefinidamente (no h starvation); fcil de ser implementado;

Coordenador um ponto nico de falha; Coordenador pode representar um gargalo em termos de desempenho. Exemplo Seja uma seo critica (SC) na qual os processos permanecem por 3 ciclos em execuo. Dar o tempo lgico em que cada mensagem ser emitida. Solicitao P1 OK P1 Solicitao P2 Solicitao P3 Liberao P1 OK P2 Liberao P2 OK P3 Liberao P3 1 2 3 3 5 6 9 10 13

P 2

P 1

Pc

P 3

Algoritmo Distribudo Os eventos tm ordenamento total (algoritmo de relgio lgico de Lamport). Se existe possibilidade de comunicao em grupo, ela pode ser usada no lugar de mensagens individuais. Funcionamento Ao entrar em uma regio crtica, o processo deve enviar uma mensagem m = (nome_regio_crtica, Pi, Ci) para todos os processos inclusive ele prprio. Quando um processo Pj recebe m de Pi, ele deve: Retornar OK se j no estiver naquela regio crtica; No retornar nada se j estiver naquela regio crtica e guardar m numa fila Se Pj quer entrar na SC, ele compara o timestamp de m com o timestamp da mensagem que ele enviou. O menor vence. Se o timestamp da mensagem recebida maior, o recebedor envia um OK. Se a sua mensagem tem um timestamp menor, o recebedor coloca a requisio na fila. Pi deve aguardar at que todos os demais Pj lhe dem permisso para entrar na regio crtica. Exemplo 1 Ns 1 e 3 solicitam entrar na SC. 2 N 1 entra na SC e 3 enfileirado. 3 N 1 sai da SC e envia OK para 3.

P 1 10 12

10

P 2 12 P 3

P 1 OK

OK

P 2 OK

P 1 OK P 3

P 3

Caracteristicas Garante excluso mtua; No h starvation; Gera mais trfego na rede; No h um ponto nico de falha, mas n pontos de falha (n = nmero de processos); Gerncia do grupo mais difcil; Todos os processos esto envolvidos em todas as decises; Cada processo representa um gargalo em potencial. Algoritmo Token Ring Problemas: i) Falha dos processos: a falha de um dos componentes do anel causa a sua quebra. ii) Perda do token: o tempo entre os aparecimentos do token ilimitado, sendo difcil determinar a sua perda.

k no deseja entrar na SC:

executa cdigo na SC k no deseja entrar na SC:

Deadlock Um deadlock causado pela situao onde um conjunto de processos est bloqueado permanentemente, isto , no se consegue prosseguir com a execuo dos processos, esperando por um evento que somente outro processo do conjunto pode processar. Estratgias mais utilizadas para tratar o deadlock: - algoritmo do avestruz (ignorar o problema); - deteco (permite que o deadlock ocorra, detecta e tenta recuperar); - preveno (estaticamente faz com que o deadlock no ocorra); - espera circular (evita deadlock alocando recursos cuidadosamente). Deadlocks em SDs so piores, difcil de evitar, prevenir e mesmo detectar. Mtodos de preveno e para evitar so muito difceis. Alternativa mais procurada: deteco. Deteco Centralizada Como primeira tentativa, pode-se usar um algoritmo centralizado para a deteco de deadlock em um sistema distribudo. Apesar de cada mquina possuir um grafo32 de recursos para seus prprios processo e recursos, um coordenador central deve manter o grafo de recursos para todo o sistema (a unio de todos os grafos individuais). Quando o coordenador detecta um deadlock, ele mata um processo para evitar o travamento. Ao contrrio do caso dos sistemas centralizados, onde todas as informaes esto disponveis automaticamente no lugar certo, em um sistema distribudo, ela deve ser enviada para l explicitamente. Cada uma das mquinas deve manter um grafo com informaes sobre seus prprios processos e recursos. Existem vrias possibilidades para obter tais informaes a partir desta estrutura. Em primeiro lugar, sempre que uma aresta for adicionada ou removida do grafo de recursos, pode ser despachada uma mensagem para o coordenador, informando a alterao e solicitando a atualizao. Uma segunda hiptese seria cada processo enviar periodicamente uma lista das arestas adicionais ou removidas desde a ltima atualizao. Este mtodo requer uma quantidade menor de mensagens que o anterior. Um terceiro caso poderia ser o do coordenador solicitando as informaes quando ele necessitar das mesmas. Infelizmente, nenhum destes mtodos funciona bem. Considere um sistema com os processos A e B rodando na mquina 0, e como o processo C rodando na mquina 1. O sistema possui trs recursos: R, S e T. A de posse do recurso S, e precisando do recurso R, que no lhe pode ser entregue, pois pertence a B. O processo C tem o recurso T e tambm precisa do S. A viso que o coordenador tem do problema ilustrada no terceiro quadro (coordenador). Esta configurao segura. To logo B termine. A pode obter a posse de R e terminar o processamento, liberando S para ser entregue a C.

Aps um tempo, B libera R e solicita T, uma troca perfeitamente legal e segura. A mquina 0 manda uma mensagem para o coordenador anunciado a liberao de R, e a mquina 1 envia uma outra mensagem para o coordenador anunciando o fato de que B agora est esperando pelo recurso T. Infelizmente a mensagem da mquina chega primeiro, levando o coordenador a construir o grafo do falso deadlock. Observe que ele conclui incorretamente
32

grafo uma representao que utiliza um conjunto de pontos (vrtices) ligados por retas (as arestas). Dependendo da aplicao, as arestas podem ser direcionadas, e so representadas por setas.

que est configurada uma situao de deadloclk, e mata alguns processos. Tal situao chamada de falso deadlock. Muitos algoritmos para deadlocks em sistemas distribudos produzerm deadlocks falsos, como este devido a informaes atrasadas ou incompletas. Uma forma de tentar contornar o problema atravs do algoritmo de Lamport para fornecimento do tempo global. Uma vez que a mensagem da mquina 1para o coordenador gatilhada pela requisio da mquina 0, ela ter de fato um suposto deadlock, ele pode enviar uma mensagem a todas as mquinas do sistema dizendo: "Acabei de receber uma mensagem com um carimbo T, que eventualmente vai levar a um deadlock. Se algum tiver uma mensagem para mim com um carimbo anterior, favor envi-la imediatamente." Aps todas as mquinas terem enviado suas respostas, positivas ou negativas, o coordenador vai poder concluir que a aresta de R para B deve ser apagada, de modo que o sistema ainda se encontre em um estado seguro. Apesar de este mtodo eliminar o falso deadlock, ele requer manuteno de tempo global, e por conta disto muito caro. No entanto, existem outras situaes onde a eliminao do falso deadlock muito mais difcil. Deteco Distribuda Algoritmo Chandy-Misra-Hass - quando processo x pede recurso R que esta com processo y. Ento x envia a mensagem (x,x,y) = (originador, emissor, recebedor). Se o recebedor est esperando outros recursos, ele atualiza a mensagem e envia para os processos que os detm. O deadlock detectado quanto a mensagem (x,y,x) retorna a maquina x. Exemplo

Processo 1 envia mensagem (1,1,2). Como 2 espera por recurso que est com 3, ele envia (1,2,3). ... Deadlock detectado quando 1 recebe (1,8,1). Estratgias para quebrar o ciclo: - O iniciante se mata; - Cada processo adiciona na mensagem o seu id; o maior se mata. Preveno de Deadlocks Distribudos A preveno de deadlocks consiste em projetar o sistema com muito cuidado, de forma que a ocorrncia de deadlocks seja estruturalmente impossvel. Algumas tcnicas: - processo s pode deter a posse de um nico recurso por vez; - processo deve pedir com antecedncia todos os recursos que forem necessrios; - processo obrigando a liberar todos os seus recursos sempre que precisar de um novo; - manter uma ordenao de todos os recursos, obrigando os processos a adquiri-los de forma estritamente ordenada. Um processo nunca pode solicitar um recurso com nmero menor que o daquele que ele detm a posse, impossibilitando assim a ocorrncia de ciclos (funciona melhor). No entanto, em um sistema distribudo com tempo global e transaes atmicas, so possveis na prtica implementar dois outros algoritmos. Ambos so baseados na idia de atribuir a cada transao um carimbo indicando o tempo global que marca o momento em que a transao se inicia. A exemplo de muitos algoritmos baseados em carimbos essencial tambm nestes dois novos que duas transaes nunca possam ter carimbos de mesmo valor. Conforme visto anteriormente, o algoritmo de Lamport garante que nunca sero atribudos carimbos de mesmo valor a duas transaes diferentes, empregando os prprios nmeros de identificao dos processos para desempatar. A idia por trs do primeiro algoritmo que quando um processo est prestes a ser bloqueado esperando por um recurso que outro processo estiver usando, faz-se uma verificao para descobrir qual deles tem o carimbo de maior valor, ou seja, qual deles o mais jovem. S podero esperar os processos que forem mais velhos, com carimbo maior do que o processo pelo qual eles estiveram esperando. Desta maneira, se seguirmos qualquer cadeia de processos esperando, os carimbos sempre vo crescer, de modo que impossvel a formao de ciclos. No segundo algoritmo, s ser permitido que os processos esperem, se o processo que estiver esperando possuir um carimbo maior, isto , for mais jovem que o processo que est aguardando. Neste caso os carimbos decrescem ao longo da cadeia. 9.7 Coordenao Eleio Muitos algoritmos distribudos so baseados em um processo coordenador. O processo coordenador responsvel por um servio especial que fornecido para os outros processos do grupo, e que funcione como coordenador, inicializador, seqenciador, entre outros, por exemplo: - coordenador de excluso mtua com controle centralizado

- coordenador para deteco de deadlock distribudo - seqenciador de eventos para ordenao consistente centralizada, etc. A falha do coordenador compromete o servio para vrios processos ento um novo coordenador deve assumir, portanto ser necessrio realizar a eleio de um novo coordenador. O objetivo do algoritmo eleger um processo, entre os ativos, para desempenhar essa funo especial. J que todos os processos de um SD so iguais (instancias de uma mesma classe), como se deve distinguir um processo eleito dos demais? Para tratar deste problema Tanembau adotou um modelo em que cada processo deve possuir uma identificao nica, por exemplo, o endereo de rede. A dificuldade no est em decidir quem o novo coordenador, por exemplo - escolher aquele que tem o ID mais alto, mas fazer com que todos os demais processos o reconheam. Existem algoritmos especiais para escolha do processo que assumir o papel de coordenador. Veja agora dois algoritmos de eleio: - algoritmo valento (bully algorithm) - algoritmo em anel (ring algorithm) Para ambos os algoritmos, assume-se as seguintes premissas genricas: i) Todo processo no sistema tem uma prioridade nica; ii) Quando eleio acontece, o processo com maior prioridade entre os processos ativos eleito como coordenador; iii) Na recuperao (volta atividade), um processo falho pode tomar aes para juntar-se ao grupo de processos ativos. Bully algorithm (algoritmo valento) Desenvolvido por Garcia-Molina em 1982. Assume que um processo sabe a prioridade de todos outros processos no sistema. Algoritmo: Quando um processo Pi detecta que o coordenador no est mais respondendo a um pedido de servio, ele inicia uma eleio da seguinte forma: a) Pi envia uma msg ELEIO para todos processos com prioridade maior que a sua; b) se nenhum processo responde, Pi vence a eleio e torna-se coordenador. Significa que no h processos ativos com maior prioridade que a sua. Logo Pi manda uma msg COORDENADOR para os processos de menor prioridade informando que ele o coordenador, deste momento em diante. c) se existe um processo Pj com prioridade maior que Pi, ento Pi responde msg ALIVE, e Pi no faz mais nada, Pj assume o controle. Pj age como Pi nos passos a) e b)

Anlise Se um processo com prioridade mais baixa detecta a falha do coordenador, em um sistema com n processos, ento acontecem n-1 eleies. Cada eleio tem quantidade de mensagens conforme o nmero de processos - no pior caso. Se o processo que detecta falha o ativo de maior prioridade precisa s de n-2 mensagens - melhor caso.

1 0 7 6 5
Exemplo1:

2 3 4 7

2 3 7

2 3

6 5

6 5

Tempos

Aes I. N 4 nota a quebra de 7 e inicia uma eleio. II. N 4 termina seu trabalho. III. Ns 5 e 6 iniciam uma nova eleio. IV. N 5 termina seu trabalho e 6 descobre que o novo coordenador. V. N 6 anuncia que o novo coordenador.

Exemplo2: Tempos Aes I. N 7 se recupera. Sendo o que possui maior prioridade, ele envia uma mensagem a todos anunciando que o novo coordenador. Ring algorithm (algoritmo em anel) Baseado no uso de um anel lgico, sem uso de token 33. Cada processo conhece o anel inteiro, mas manda mensagens somente para o prximo processo ativo na direo do anel. Quando o processo detecta que o coordenador no est ativo, ele constri uma msg ELEIO contendo seu ID, e manda para o prximo do anel. A cada passo, o processo que recebe a msg inclui seu ID na msg e envia para o prximo n do anel. No final o processo que iniciou a eleio recebe a msg e escolhe aquele que tem maior ID. Nova msg enviada novamente atravs do anel para todos, contendo o novo coordenador. Uma vez que a msg passou por todos os processos e chegou ao originador, ela retirada do sistema. Anlise A eleio precisa de 2(n-1) mensagens, n-1 mensagens para rotao da mensagem de eleio, e n-1 mensagens para rotao da mensagem de coordenador. Exemplo1: Tempos Aes I. N 5 detecta uma falha no 7 e inicia uma eleio circulando a mensagem E. II. A mensagem E transformada em uma mensagem C e circulada para informar quem o novo coordenador (6).

10 Ferramentas e Tecnicas de Programao e Gerenciamento de aplicativos multiprocessados Existem 4 maneiras bsicas de se criar um software para ambiente multiprocessado, isto , para ser executado em vrios processadores (sistemas concentrados) ou mquinas (sistemas distribudos): i) Adio de bibliotecas especiais em linguagens seqenciais normais: - Paralelismo restrito a alguns procedimentos; - O ncleo do software permanece seqencial. ii) Adio de bibliotecas especiais com primitivas de comunicao e controle: - O programador responsvel pela criao e gerenciamento do paralelismo dentro da linguagem de programao convencional. iii) Incorporao de algumas funes especiais otimizadas para execuo paralela sobre linguagens de programao existentes: - a abordagem mais utilizada e muitas linguagens possuem verses paralelas; - As funes especiais permitem a gerao de novos processos em paralelo, execuo das iteraes de um lao em paralelo ou simplesmente operaes vetoriais. iv) Criao de linguagens especficas para processamento paralelo: - A grande vantagem que a linguagem suporta todas as funes paralelas desejadas; - A desvantagem que os programadores precisam se familiarizar com a nova linguagem. Ao longo dos anos, uma infinidade de bibliotecas, extenses, funes e novas linguagens foram criadas para o desenvolvimento de aplicaes multiprocessadas. A seguir sero apresentados alguns aspectos fundamentais que a serem considerados na produo programas multiprocessados: - Modelos de controle; - Granularidade do paralelismo; - Paradigmas computacionais; - Formas de comunicao; - Primitivas de sincronizao. Modelos de controle
33

Token em computao um segmento de texto ou smbolo que pode ser manipulado por um analizador, que fornece um significado ao texto; em outras palavras, um conjunto de caracteres (de um alfabeto, por exemplo) com um significado coletivo. Token tambm o arquivo utilizado em redes tipo anel que quando lanado na rede , informa que um determinado micro deseja falar com outro , evitando assim colises de informaes.

A principal questo envolvida se haver apenas um thread de controle ou vrios threads de controle. No primeiro caso, uma instruo sendo executada em uma unidade de controle opera simultaneamente em vrios dados. No segundo caso, vrias instrues so executadas simultaneamente pelas respectivas unidades de controle, provavelmente comunicando-se e sincronizando-se umas com as outras. O segundo caso possui muitas variaes e compreende o modelo predominante em processamento paralelo. Granularidade do paralelismo O controle do paralelismo pode ocorrer em vrios nveis. No primeiro ou mais baixo deles, o ILP (Instruction Level Parallelism), instrues de mquina so executadas em paralelo, o que gerenciado pelo hardware e pelo compilador. Um nvel acima deste, existe o paralelismo, em nvel de bloco, no qual o programador define o que ser seqencial e o que ser paralelo no programa. Atravs da utilizao de vrgulas, ponto-e-vrgulas, parnteses e delimitadores begin/end, o programador explicitamente gerencia a execuo do programa. Um bom exemplo pode ser visto na linguagem Algol 68: Begin Statement-1; Statement-2; Statement-3 end (execuo seqencial) Begin Statement-1, Statement-2, Statement-3 end (execuo paralela) Outra forma de paralelismo a possibilidade de gerao de vrios threads ou mesmo processos leves que operam no espao de endereos de um processo principal. Cada thread possui o seu prprio contador de programa, registradores e pilha, porm compartilha as variveis globais com outros threads. Cada thread independente e roda em um processador provavelmente diferente. O paralelismo de gro mais largo (mais alto nvel) aquele baseado em vrios processos independentes operando na resoluo de um mesmo problema. Este deve ser dividido em grandes pedaos (chunks), um para cada processo. Este nvel o mais adequado para a utilizao de multicomputadores. Paradigmas computacionais Programas paralelos necessitam de certos modelos para a sua estruturao. O primeiro modelo refere-se operao de um thread de controle sobre um conjunto grande de dados. chamado de SPMD (Single Program Multiple Data). Um segundo modelo o Pipeline, no qual os dados so operados por um 1 processo que os envia para um 2 processo e assim por diante. Pipelines UNIX funcionam desta maneira e podem ser executados como processos separados operando simultaneamente. Outro modelo estabelece uma computao em fases. Em cada fase, mltiplos processos operam em paralelo e preciso esperar at que todos tenham terminado a operao para o incio de uma nova fase. Tal modelo chamado de computao por fases. O quarto modelo, denominado dividir e conquistar estabelece que um processo possa subdividir-se em outros processos para a diviso da carga de trabalho. Os processos assim gerados podem dividir-se subseqentemente. O ltimo modelo conhecido como replicated worker ou tambm task farm, no qual uma fila de tarefas centralizada despacha as tarefas para os trabalhadores (processos). Assim que um processo termina a sua computao ele busca uma nova tarefa na fila. Se durante a execuo de um processo novas tarefas so geradas, estas so enviadas para a fila centralizada. Formas de comunicao Quando existem processos operando em paralelo, geralmente necessria a comunicao entre os mesmos, o que pode ser feito de duas formas primrias de troca entre tarefas paralelas: A primeira consiste em acessar um espao de dados compartilhado - variveis compartilhadas (Load, Store), onde a memria nestas plataformas de espao de endereamento compartilhado pode ser: Local - exclusiva para um processador; ou, Global - comum a todos os processadores. Se o tempo necessrio para um processador acessar qualquer endereo na memria do sistema (local ou global) idntico, a plataforma classificada como multicomputador UMA (uniform memory access). J se o tempo necessrio para um processador acessar certos endereo na memria do sistema maior que para outros, a plataforma chamada de multicomputador NUMA (nonuniform memory access). A segunda forma atravs de troca de mensagens. Plataformas para passagem de mensagens consistem em p ns de processamento cada um com seu espao exclusivo de endereamento. Cada um destes ns de processamento pode ser constituido de processador nico ligado em rede. A troca de mensagens usada para transferir dados, trabalho e sincronizar aes entre processadores. Ainda com relao troca de mensagens (message passing), possvel uma classificao quanto ao nmero de receptores de uma mensagem. Um primeiro caso chamado unicast ou point-to-point onde a mensagem dirigida a um nico receptor. Quando a mensagem dirigida a um conjunto especfico de receptores, chama-se de multicast. E no caso do broadcast a mensagem dirigida a todos os receptores da rede. Com 4 operaes bsicas possvel escrever qualquer programa com passagem de mensagem - Message Passing (Send, Receive): Send, enviar mensagem Receive, receber mensagem ID, identificador do processo em execuo Numprocs, nmero de processo participando do grupo em execuo

Por exemplo, as APIS Parallel Virtual Machine (PVM) e Message Passing Interface (MPI) suportam estas operaes, alm de outras funes de mais alto nvel. Logo possvel a combinao de diferentes arquiteturas com estas tcnicas de comunicao: Multiprocessadores: - comunicao por variveis compartilhadas padro; - a troca de mensagens pode ser implementada em memria. Multicomputadores: - variveis compartilhadas so possveis em sistemas com uma camada de gerenciamento intermedirio (DSM, Linda, Orca, etc); - troca de mensagens com PVM ou MPI. Primitivas de sincronizao Alm da comunicao, os processos muitas vezes necessitam de sincronizao. Tal sincronizao pode ser exemplificada no acesso s estruturas de dados. Apenas um processo deve ter acesso aos dados enquanto estes so modificados. Uma das formas de garantir a integridade dos dados chamada de excluso mtua. Vrias primitivas de software so utilizadas para assegurar excluso mtua: - Semforos - Locks - Mutexes - Sees Crticas - Barreiras, que garantem o bloqueio de processos em uma fase at que todos os processos tenham realizado as suas respectivas computaes. 10.1 Converso de programas seriais em paralelos Converso automtica O Compilador tenta fazer alguma paralelizao automtica nos laos. Para obter bons speedups34 deve-se ter a ajuda de especialistas alm do nvel de automatizao. Converso manual O Programador faz uma anlise no cdigo fonte identificando trechos de cdigo que pode ser paralelizado. Geralmente a paralelizao pode ser aplicada nos casos de: - reestruturao dos ndices de controle dos laos para evitar interdependncia de laos; - chamadas a rotinas j paralelizadas e indicaes (constructs) para pr-processadores ou geradores de cdigo indicando tentativa de paralelismo que deve ser executada em parte do cdigo serial; - checar cdigo gerado com constructs; - reestruturao do algoritmo (tirar o clculo de um lao, por exemplo); Dependncias gerais Existe dependncia entre instrues quando a ordem de execuo delas afeta ou impede o resultado do programa. Dependncia de dados resulta do uso mltiplo do mesmo local da memria. Exemplo: Programa com 3 instrues: a = b + 1; c = 4 - a; b = 2 * a - c; 3 dependncias de dados. 3 instrues dependentes de execuo. Dependncia de comunicao Podem ocorrer problemas de execuo devido dependncia de comunicao para o processamento de tarefas.

Dependncias em laos Lao independente: local da memria usado (escrita/leitura) por instrues sucessivas em uma mesma iterao, mas no por iteraes diferentes. Neste caso pode ser paralelizado porque as iteraes do lao so executadas de forma independente e assncrona. Lao dependente: local da memria usado por instrues e cada iterao do lao depende do valor anterior guardado. Neste caso no pode ser paralelizado.

34

Speedup ganho de velocidade obtido pela paralelizao do algoritmo, definido pela razo entre o tempo levado na executando do algoritmo serial (ts) e o tempo levado executando o algoritmo paralelo usando (tp). Logo S = ts / tp e deve ser no mnimo maior que 1 para ter algum ganho.

10.2 Programao com threads Em C, pode-se dividir o programa em vrias threads e aumentar a prioridade delas, aumentando a prioridade de acesso ao(s) processador(es) e diminuindo a dos outros programas. Mas vamos com calma. Um thread basicamente outro programa rodando, mas com os mesmos direitos de acesso memria que o programa que carrega ele (que seria o thread principal). Esta no a definio formal. mais uma utilidade prtica do negcio. Como o thread tem os mesmos direitos de acesso memria, compartilhar dados entre os dois programas fcil. E cada uma tem sua prpria pilha, ento nem precisa se preocupar com um eventual estouro dela (no abusem dessa frase, possvel estourar a pilha, apenas menos provvel). C no possui nenhum suporte nativo para threads (isso algo que depende muito do kernel do sistema operacional, pois ele quem coordena os processos e verifica quando estes vo para o processador e para qual processador vo). Ento necessrio que voc utilize uma biblioteca do sistema operacional. O Windows utiliza a biblioteca windows.h, mas qualquer coisa que voc compile que tenha includo essa biblioteca ir demorar muito para compilar, pois essa biblioteca realmente imensa. Para evitar isso, defina a constante WIN32_LEAN_AND_MEAN antes de incluir o header e assim voc evitar incluir um monte de coisas nas quais voc provavelmente no est interessado. O Linux e MacOS X utilizam a pthread.h. MacOS Clssico no possui suporte nativo, mas difcilmente voc ir produzir uma aplicao em para MacOS Clssico hoje em dia. Mas se quiseres produzir uma aplicao portvel entre alguns desses sistemas, o que deve ser feito? Forar a portabilidade no brao com #ifdef ? No. Voc pode usar uma das seguintes bibliotecas: SDL (disponvel em: www.libsdl.org): A biblioteca SDL (Simple DirectMedia Layer) possui suporte a threads e portvel para esses sistemas e a vrios outros. pth (disponvel em: www.gnu.org/software/pth): A pth implementao de threads do projeto GNU, que roda em vrios sistemas. pthread: A pthread possui ports para Windows tambm. A vantagem que a pthread possui todas as funcionalidades em qualquer um dos sistemas. A SDL_Thread possui apenas as funcionalidades comuns desses sistemas. (No foi colocado o link porque Pthread a especificao Posix para Threads. Portanto qualquer implementao que siga essas especificaes uma pthread.). Existem algumas outras, mas essas provavelmente so as trs mais poderosas. Mas antes que voc pense que thread a soluo para todos os problemas, tome cuidado. Thread uma tcnica poderosa, mas bem complicado de utiliz-la. Recomenda-se o estudo da programao concorrente antes de se aventurar pelos incontveis erros de sincronismo praticamente indetectveis que os threads produzem. Nos sistemas operacionais mais antigos, o prprio processo constitua a unidade de execuo. Nos sistemas operacionais mais modernos, como o OS/2 e o Windows NT, a unidade de execuo na verdade um thread, ou uma linha de execuo. A thread constitui em um sub-processo, ou processo leve, que visa dar maior grau de concorrncia s atividades processadas. Todo processo possui pelo menos um thread, denominada thread primrio. Outras rotinas de um programa podem ser executadas como threads de forma concorrente ao programa principal, sendo criadas dinamicamente pelo thread primrio. Processo = Conjunto de Threads + Conjunto de Recursos Um dos aspectos importantes na programao concorrente assegurar que um processo no faa acessos indevidos a uma rea de memria de outro processo, ou mesmo do sistema operacional (excluso mtua).

No modo real todos os dispositivos mapeados em memria podiam ser acessados diretamente por qualquer processo, por meio de seu endereo fsico.

Assim uma task/processo de um usurio pode escrever na rea de cdigo ou dados de outro programa, inclusive em reas reservadas do sistema operacional. Um ponteiro desgovernado pode causar danos grandes.

Essa proteo garante que o cdigo de uma aplicao no invada uma rea de memria de outro processo. Cada processo possui um thread principal, ou thread primrio, que a unidade realmente escalonada pelo scheduler35. Este thread criar threads para atenderem as requisies dos usurios. Threads so fceis de criar, escalonar, e manter, pois herdam todos os recursos do processo que as originou. O thread possui apenas um conjunto de registradores, duas pilhas prprias, e uma prioridade. O conjunto de registradores salva o estado do apontador para a pilha e para o cdigo do thread (program pointer). O thread encarregada de fazer a interface com o usurio em ambiente Windows (GUI thread) possui tambm uma fila de mensagens associada.

(*) GUI Threads possuem, por default, fila de mensagens, o que no ocorre com working threads. O chaveamento entre threads simples, pois threads no possuem um espao de endereamento: elas compartilham o espao de endereamento do processo que as criou, bem como todos os demais recursos: handles36 para arquivos, objetos de sincronizao, etc. Quando se trata de compartilhar memria, isso vantajoso: todas as threads enxergam e tm acesso ao mesmo espao de memria. A sincronizao para garantir que duas ou mais threads sempre acessem objetos na memria comum de forma atmica fica a cargo do programador. Quando isso acontece dizemos que o acesso foi feito com excluso mtua. A questo da excluso mtua extremamente importante, e ser estudada com detalhes posteriormente. O Windows NT possui escalonador preemptivo baseado nas prioridades designadas pelo operador, mas que em alguns casos podem ser manipuladas pelo prprio sistema operacional. Threads de mesma prioridade so escalonadas em round hobin37.

O ajuste dinmico de prioridades definido pelo NT leva em conta trs fatores: - Classe de prioridade de processo. - Nvel de prioridade escolhido para a thread. - Aumento de prioridade definido pelo NT.
35

scheduler quem examina a fila de entrada de servios e seleciona o prximo a ser executado, escalonando e priorizando os jobs. O termo escalonamento (scheduling) define o procedimento de ordenar tarefas na fila. Uma escala de execuo (schedule) uma ordenao ou lista que indica a ordem de ocupao do processador por um conjunto de tarefas disponveis na fila. O escalonador (scheduler) o componente do sistema responsvel, em tempo de execuo, pela gesto do processador e que implementa uma poltica de escalonamento ao ordenar, para execuo no processador um conjunto de tarefas. 36 Tudo no Windows controlado por handles. Arquivos, sockets, objetos de sincronizao, etc. O tipo HANDLE na verdade um void* opaco, e somente o Windows sabe o que tem l dentro. Ele um nmero de identificao para determinados componentes de programas, visuais ou no, que o windows gerencia para poder manipular os programas. 37 Round-Robin um dos mais antigos e simples algoritmos de escalonamento, alm de ser totalmente imune a problemas de starvation (processo fica esperando indefinidamente para executar por causa de um escalonamento injusto). Usado em projetos de sistemas operacionais multitarefa. Foi projetado especialmente para sistemas time-sharing, pois este algoritmo depende de um temporizador (Timer). O funcionamento desde algoritmo acontece da seguinte forma: uma unidade de tempo, denominada quantum, definida pelo sistema operacional, onde determina o perodo de tempo entre cada sinal de interrupo. Todos os processos so armazenados em uma fila circular. Cada processo e retirado da primeira posio da fila de prontos e recebe o processador para a sua execuo. Se o processo no termina aps o quantum, ocorre uma preempo e o processo vai para o fim da fila de prontos. Se o processo termina antes do perodo de quantum, o processador liberado para a execuo do processo que estiver no incio da fila. Todo processo que chega fila de prontos e inserido no final da mesma.

Um processo pode estar dentro de uma das quatro classes apresentadas a seguir:

Cada thread assume valor de prioridade em torno da prioridade base ou igual prioridade mnima ou mxima de sua faixa:

importante observar que, na prtica, o range de prioridades que o programador pode escolher para uma thread muito limitado (cinco valores em torno da prioridade do processo, mais dois valores extremos), o que pode dificultar a designao de prioridades em algumas situaes. Uma thread pode receber um aumento de prioridade quando um evento que est aguardando acontece, quando selecionada para execuo em foreground, ou quando est esperando pela sinalizao de um objeto por meio das funes Wait... e o objeto sinalizado. Esse aumento denominado reforo de prioridade (priority boost), e varivel: ao obter o foco de execuo, o aumento default de +2. Quando recebem eventos do mouse ou do teclado, todas as threads de um processo recebem reforo de +5. Para aplicaes de automao, a classe de prioridades ideal a de tempo real, porque o sistema operacional no pode interferir na prioridade designada pelo programador. A escolha da prioridade baseada em critrios que consideram a importncia de cada tarefa para uma aplicao em particular, e, portanto, ela no deve ser alterada sem conhecimento do programador. O escalonador determina quais as thread que se devem executar e quando se devem executar. As thread com prioridade inferior podem ter que esperar pelas thread de maior prioridade. Em mquinas com multiprocessador, o escalonador pode transportar threads individuais para outro processador de modo a balancear a carga de CPU entre os vrios processadores. Cada thread dentro de um processo executada de forma independente. Excetuando quando esta visvel s outras, as threads so executadas individualmente e no se preocupam com as outras thread em execuo no contexto de um processo. As threads compartilham recursos comuns, no entanto, se deve coordenar o seu trabalho utilizando semforos ou outro mtodo de comunicao interprocessos. Uma thread basicamente uma linha de execuo independente, contida dentro de um processo. Ou seja, uma thread permite que um processo "faa varias coisas de forma simultnea", j que um processo pode conter vrias threads. Todas as threads que fazem parte de um mesmo processo compartilham vrios recursos, como o espaamento de memria e os handles. Ou seja, elas acessam as mesmas variveis e podem usar os mesmos handles ao mesmo tempo. O comando bsico para criao de threads no Windows CreateThread(). Esse comando cria uma nova thread, que ser executada concorrentemente com a thread que a criou.
HANDLE CreateThread( LPSECURITY_ATTRIBUTES lpThreadAttributes, DWORD dwStackSize, LPTHREAD_START_ROUTINE lpStartAddress, LPVOID lpParameter, DWORD dwCreationFlags, LPDWORD lpThreadId);

O 1 parmetro responsvel pela segurana e compartilhamento do Objeto thread que vai ser criado. O 2 parmetro responsvel pela definio do tamanho do Stack, ou seja, voc pode definir o tamanho que vai ser utilizado pela thread nos operadores ASM, em todo caso, se lhe falta de entendimento especfico sobre o assunto bom deixar em 0 que ele assume o tamanho padro 1MB. O 3 parmetro responsvel pela definio do endereo inicial da thread. O 4 parmetro responsvel pela definio da chave mestra no processo de criao de uma thread, o ponteiro do parmetro, podendo esse parmetro ser qualquer coisa desde que persista enquanto a thread existir ou at o inicio da mesma. O 5 parmetro responsvel pelo modo em que a thread vai ser criada, Suspensa (CREATE_SUSPENDED) ou No suspensa (0), a API poder receber outro parmetro, o STACK_SIZE_PARAM_IS_A_RESERVATION, mas esse no muito utilizado, pois no tem funcionamento na plataforma Windows 2000. O 6 parmetro responsvel pela recepo do ID da thread na lista de Objetos thread do Windows, esse valor serve para processos de identificao de origem do processamento atravs da API GetCurrentThreadId. O retorno da API CreateThread o handle da thread, como sabemos handles so nmeros que identificam objetos Windows e atravs de APIs podemos control-los com muita especialidade. Quando uma thread criada, ela retorna dois tipos de identificadores: o handle e a threadId.

A threadId um valor global que identifica a thread perante todas as demais threads do sistema. Embora o handle seja mais usado, este identificador tambm empregado como parmetro por algumas funes da Win32. O handle tem abrangncia apenas local, no mesmo processo. Todo objeto do kernel38 tem um handle. O handle no um apontador para o objeto considerado, mas corresponde a um ndice em uma tabela interna do processo. Por meio dessa forma, o Windows evita que o usurio possa manipular o objeto diretamente. O handle para uma thread de propriedade do processo e no da thread que o criou.

Aps utilizar um objeto do kernel, importante fechar o seu handle, por meio da funo BOOL CloseHandle(HANDLE hObject);. Essa funo decrementa o contador de referncias para o objeto, e, quando o contador alcana o valor zero, o objeto apagado, e os recursos por ele ocupados so liberados.

A funoVOID ExitThread(DWORD dwExitCode); a melhor maneira de se terminar a execuo de uma thread. Essa funo notifica as DLLs s quais a thread estiver associada, ao contrrio do acontece com a funo VOID TerminateThread(HANDLE hThread DWORD dwExitCode); permitindo que as DLLs desaloquem memria e efetuem outras funes de limpeza. TerminateThread() s deve ser usada para causar o encerramento de outra thread. Os efeitos negativos dessa funo so muitos: o stack da thread alvo no ser desalocado, o que causar perda de memria, as DLLs ligadas thread no sero notificadas, e se a thread estiver no meio de uma seo crtica, ficar bloqueada para sempre. ExitThread() = Suicdio TerminateThread() = Homicdio Procure evitar o homicdio! Sempre que possvel, faa a thread cometer suicdio!!! Os sistemas operacionais modernos desenvolveram funes especiais que permitem esperar por um evento de interesse sem a necessidade de um loop de espera ocupada39. A espera ocupada deve ser evitada de toda forma. No Windows NT, todo objeto do kernel possui dois estados: sinalizado e no-sinalizado. A funo WaitForSingleObject() especifica para o Windows que a thread dever ficar bloqueada at que um determinado objeto do kernel seja sinalizado. Quando isso acontece, a thread acordada e continua o seu processamento. DWORD WaitForSingleObject(HANDLE hHandle, DWORD dwMilliseconds); Possveis retornos da funo:

38

O kernel fundamentalmente o ncleo sob o sistema operacional que gerencia aplicativos e funes como drivers, memria e sistema de arquivos. 39 As solues com espera ocupada tm o grave inconveniente de desperdiar tempo de CPU nos loops de espera para a entrada na regio crtica. Alm disto, apresenta outro problema quando se trata de processos com prioridades diferentes. Suponha dois processos: um chamado H, de alta prioridade e outro, chamado L de baixa prioridade. Se o processo L estiver executando em sua regio crtica quando o processo H selecionado para execuo, ento, se o processo H tenta entrar em sua regio crtica no pode, pois o processo L est dentro da mesma e, portanto fica em um loop de espera. Mas, como H tem alta prioridade, o processo L no poder executar at que H termine, pois apresenta prioridade mais baixa. Tem-se neste caso uma situao chamada de deadlock, onde nenhum dos processos pode prosseguir, pois est aguardando alguma condio que somente pode ser atingida pela execuo do outro.

A funo WaitForMultipleObjects() espera pela sinalizao de um dos objetos, ou de todos os objetos simultaneamente, dependendo do terceiro parmetro da funo. O nmero mximo de objetos dado pela constante MAXIMUM_WAIT_OBJECTS. DWORD WaitForMultipleObjects(DWORD nCount, CONST HANDLE *lpHandles, BOOL bWaitAll, DWORD dwMilliseconds); Possveis retornos da funo:

Quando dois handles em um array so sinalizados, o primeiro retornar pela funo WaitForMultipleObjects() ser o de menor ordem, isto , o Windows sempre percorre o array da posio 0 para a posio N. Objetos do Kernel O nome de qualquer objeto do kernel deve ser nico. Mesmo que os objetos sejam de tipos diferentes, eles no podem ter o mesmo nome.Os objetos Kernel so especficos do processo. Isto significa que um processo precisa criar um objeto kernel ou ento abrir um objeto existente para obter seu manipulador. Qualquer processo pode criar um manipulador novo para um objeto kernel existente, mesmo para um objeto kernel criado por outro processo, contanto que o processo tenha o nome do objeto e tenha acesso seguro a ele. Manipuladores de objetos kernel incluem direitos de acesso que indicam as aes permitidas ou proibidas a um processo. Um aplicativo especifica os direitos de acesso quando cria um objeto ou obtm um manipulador existente. Cada tipo de objeto kernel d suporte seu prprio conjunto de direitos de acesso. Por exemplo, manipuladores de evento podem possuir acessos "atribuir" (set), "esperar" (wait) ou ambos; manipuladores de arquivos podem ter acessos "leitura", "escrita" ou ambos, e assim por diante. Processos podem herdar ou duplicar manipuladores para os seguintes tipos de objetos kernel, entre outros: -Processos -Linhas de processos (threads) -Arquivos (inclusive objetos de arquivos mapeados) -Eventos -Semforos -Mutex -Pipes (nominados e annimos) -Mailslots -Dispositivos de comunicao Na ilustrao a seguir, um aplicativo cria um objeto evento. A funo CreateEvent() cria o objeto evento e retorna um manipulador de objeto:

(1) Um aplicativo executa a funo CreateEvent(), a qual cria um objeto evento (2) na memria. A funo retorna o manipulador deste objeto (3).

Aps o objeto evento ter sido criado, o aplicativo pode usar o manipulador de evento para atribuir ou esperar pelo evento. O manipulador continua disponvel at que o aplicativo o feche ou at que o aplicativo termine. A maioria dos objetos kernel permitem mltiplos manipuladores atrelados a um nico objeto. Por exemplo, o aplicativo da ilustrao anterior poderia obter manipuladores de objetos de evento adicionais usando a funo OpenEvent(), como mostrado a seguir:

(4) O aplicativo executa a funo OpenEvent que retorna um (5) novo manipulador de evento. Este mtodo permite que um aplicativo tenha dois manipuladores com direitos de acesso diferentes. Por exemplo, o manipulador (3) pode ter os direitos "atribuir" e "esperar" e o manipulador (5) ter apenas o direito "esperar". Se outro processo tiver o nome e o acesso seguro ao objeto, ele pode criar seu prprio manipulador de objeto evento usando OpenEvent(). O aplicativo que criou o primeiro manipulador tambm pode duplicar um de seus manipuladores para o mesmo processo ou para um outro processo atravs da funo DuplicateHandle(). Um objeto permanece na memria enquanto pelo um manipulador deste objeto ainda existir. Na ilustrao seguinte, os aplicativos usam a funo CloseHandle() para fechar seus manipuladores do objeto evento. Quando no existirem mais manipuladores de evento, o sistema remove o objeto da memria:

O sistema trata objetos arquivo de uma forma diferenciada. Os objetos arquivo possuem um ponteiro de arquivo - o ponteiro para o prximo byte a ser lido ou escrito no arquivo. Sempre que um aplicativo criar um novo manipulador de arquivo, o sistema cria um novo objeto arquivo. Portanto, mais de um objeto arquivo pode referenciar o mesmo arquivo em disco, como mostra a ilustrao abaixo:

Apenas atravs de duplicao ou herana mais de um manipulador de arquivo pode referenciar o mesmo objeto arquivo, como mostra a ilustrao seguinte:

A tabela seguinte mostra cada um dos objetos kernel com suas funes de criao e destruio correspondentes. As funes de criao criam um objeto e seu respectivo manipulador ou criam um novo manipulador para um objeto existente. Quando o aplicativo fecha o ltimo manipulador de um objeto, o sistema remove o objeto da memria.
OBJETO KERNEL Alterao de notificao Arquivo Atualizar recurso Buffer de tela de console Desktop Dispositivo de comunicao Entrada de console Estao Windows Evento Heap Log de evento Mailslot Mapeamento de arquivo Mdulo Mutex Notificao de recurso de memria Pipe Processo Procurar arquivo Semforo Socket Tarefa Thread Timer Token de acesso Funo para criar FindFirstChangeNotification CreateFile BeginUpdateResource CreateFile com CONOUT$ GetThreadDesktop CreateFile CreateFile com CONIN$ GetProcessWindowStation CreateEvent, OpenEvent HeapCreate OpenEventLog, RegisterEventSource, OpenBackupEventLog CreateMailslot CreateFileMapping, OpenFileMapping LoadLibrary, GetModuleHandle CreateMutex, OpenMutex CreateMemoryResourceNotification CreateNamedPipe, CreatePipe CreateProcess, OpenProcess, GetCurrentProcess FindFirstFile CreateSemaphore, OpenSemaphore socket, accept CreateJobObject CreateThread, CreateRemoteThread, GetCurrentThread CreateWaitableTimer, OpenWaitableTimer CreateRestrictedToken, DuplicateToken, DuplicateTokenEx, OpenProcessToken, OpenThreadToken Funo para destruir FindCloseChangeNotification CloseHandle, DeleteFile EndUpdateResource CloseHandle Aplicativos no podem eliminar este objeto CloseHandle CloseHandle Aplicativos no podem eliminar este objeto CloseHandle HeapDestroy CloseEventLog CloseHandle CloseHandle FreeLibrary CloseHandle CloseHandle CloseHandle, DisconnectNamedPipe CloseHandle, TerminateProcess FindClose CloseHandle CloseHandle CloseHandle CloseHandle, TerminateThread CloseHandle CloseHandle

As instrues envolvidas no acesso a recursos globais compartilhados so intercaladas pelo escalonador, estando fora do controle do programador. O desejvel seria que todo acesso a recursos compartilhados fosse realizado atravs de instrues atmicas, o que seria de difcil implementao. Qualquer programa concorrente pode ser modelado como sendo constitudo de partes onde suas instrues podem ser entremeadas com as instrues de outros programas (sees no crticas), e partes onde isso no deve ocorrer (sees crticas). As sees crticas devem ter o conjunto de suas instrues executadas como se fosse uma nica instruo atmica. Quando asseguramos que apenas uma unidade de execuo, uma thread no caso do NT estar em sua seo crtica de cada vez, dizemos que a propriedade da excluso mtua se verifica. Sees Crticas So trechos de cdigo de um programa onde as instrues no podem ser intercaladas com a de outro programa. A seo crtica o trecho de um programa que deve ser executado sob excluso mtua(duas threads nunca podero estar executando instrues de suas sees crticas de forma entrelaada). Uma thread nunca pode ficar em loop ou interromper sua execuo dentro da seo crtica ou dos protocolos de entrada ou sada. Se isso ocorresse, nenhuma outra thread poderia continuar sua execuo, o que traria conseqncias desastrosas para todo o sistema. Ausncia de impasse (deadlock): o impasse acontece quando nenhuma thread consegue entrar em sua seo crtica. Quando vrias threads disputam a entrada na seo crtica, temos que assegurar que pelo menos uma tenha xito. Ausncia de inanio (starvation): o critrio de entrada na seo crtica deve ser tal que assegure que nenhuma thread seja excluda da oportunidade de entrar. A inanio tambm conhecida como adiamento indefinido. Acesso facilitado em caso de ausncia de conteno: se apenas uma thread deseja entrar em sua seo crtica, ela dever conseguir faz-lo com um mnimo de overhead. Assim um bom algoritmo de ter as seguintes caractersticas:

Critical Sections, portanto no so objetos do kernel, mas um tipo de varivel especial. Os procedimentos de entrada na seo crtica e de sada da seo crtica so representados pelas rotinas EnterCriticalSection() e LeaveCriticalSection(). Antes de poder usar estes procedimentos devemos declarar uma varivel do tipo CRITICAL_SECTION e inicializ-la com o procedimento InitializeCriticalSection(). Aps usar a varivel ela deve ser apagada atravs do procedimento DeleteCriticalSection(). Uma Critical Sections pode ser utilizada apenas quando todas as threads pertencem ao mesmo processo. A grande vantagem reside na simplicidade do mecanismo! VOID InitializeCriticalSection(LPCRITICAL_SECTION lpCriticalSection); VOID EnterCriticalSection(LPCRITICAL_SECTION lpCriticalSection); VOID LeaveCriticalSection(LPCRITICAL_SECTION lpCriticalSection); VOID DeleteCriticalSection(LPCRITICAL_SECTION lpCriticalSection); Premissas Bsicas para Excluso Mtua i. Excluso mtua: Dois processos no podem estar dentro de suas sees crticas ao mesmo tempo. ii. Nenhuma assero pode ser feita sobre velocidades ou o nmero de CPUs. iii. Progresso: Nenhum processo executando fora de sua seo crtica pode bloquear outros processos, ou seja, nenhum processo deve ficar bloqueado de usar sua seo crtica se nenhum outro processo a estiver usando. iv. Espera Limitada:Nenhum processo deve ter que esperar para sempre para entrar em sua seo crtica, enquanto outros processos, repetidamente, entram e saem de suas respectivas sees crticas. Mutex O nome Mutex vem de MUTual EXclusion. Mutexes so objetos do kernel especializados na sincronizao para acesso a uma seo crtica, e portanto possuem um nome global e um handle local ao processo. O uso do Mutex para controlar o acesso a uma seo crtica implica em maior overhead do que o uso de CriticalSections, j que torna necessria uma chamada ao sistema operacional... HANDLE CreateMutex(LPSECURITY_ATTRIBUTES lpThreadAttributes, BOOL bInitialOwner, LPCTSTR lpName);

Retornos da funo:

Ao encerrar a operao com o Mutex, usamos CloseHandle(hMutex), onde hMutex o handle retornado por CreateMutex(). Isso ir decrementar o contador de referncias do objeto Mutex. Como j vimos, quando o contador de referncias chega a zero, o Mutex automaticamente destrudo. Mutex Abrindo um Objeto Existente HANDLE OpenMutex(DWORD dwDesiredAcess, BOOL bInheritHandle,LPCTSTR lpName); Retornos da funo:

O controle de acesso seo crtica feito atravs de um protocolo de entrada e outro de sada. Para entrar em uma seo crtica, uma thread deve invocar a funo WaitForSingleObject() ou WaitForMultipleObjects(). Ao deixar a seo crtica, deve-se invocar ReleaseMutex(). HANDLE ReleaseMutex(HANDLE hMutex); Retorno da funo:

Propriedades Quando a seo crtica est livre, o Mutex fica no estado sinalizado. Quando uma thread faz um Wait em um Mutex sinalizado, ele passa ao estado no-sinalizado, e dizemos que a thread proprietria do Mutex. Se uma thread terminar dentro da seo crtica, todas as demais threads presas em uma operao de Wait neste Mutex retornaro com o valor:

Ao se esperar por um Mutex, um tempo de timeout pode ser estipulado. Tanto a instruo de Wait como a de Release devem pertencer a uma mesma thread. Para sincronizar threads diferentes, devem ser utilizados semforos binrios, que estudaremos posteriormente. Duas instrues extremamente utilizadas em qualquer programa so o incremento e o decremento de uma varivel. Todo processador se preocupa em ter instrues especiais, de mxima eficincia, para realizar tais operaes. O incremento e decremento de variveis com excluso mtua seria o caso anlogo na programao concorrente. O uso de CriticalSections ou Mutexes seria uma soluo de grande overhead, se usada para este fim. H funes que proporcionam a sincronizao do acesso a variveis compartilhadas por mltiplas threads, ou por mltiplos processos, no caso da varivel estar em memria compartilhada. So elas: InterlockedIncrement, InterlockedDecrement, InterlockedCompareExchange, InterlockedExchange e InterlockedExchangeAdd. A funo InterlockedDecrement decrementa a varivel especificada e verifica o valor resultante. InterlockedDecrement impede que mais de uma thread use a InterlockedDecrement ou a funo InterlockedIncrement para acessar a mesma varivel simultaneamente. LONG InterlockedDecrement(LPLONG lpAddend); lpAddend [in] Ponteiro para decrementar a varivel de 32-bit. A funo InterlockedExchangeAdd executa uma adio atmica de um valor incremento para uma varivel Addend. A funo impede que mais de uma thread use a mesma varivel simultaneamente. LONG InterlockedExchangeAdd(LPLONG Addend, LONG Increment); Addend [in, out] Ponteiro para o nmero que ter o nmero incrementado adicionado a ela. Incremento [in] Especifica o nmero a ser adicionado varivel apontado pelo parmetro Addend. Semforos um dos recursos para a resoluo do problema da excluso mtua; Hoje, os semforos so capazes de resolver muitos outros problemas alm da excluso mtua.

Um semforo um objeto de uma classe que possui um membro de dado inteiro S (contador do semforo) e dois mtodos que definem as nicas operaes permitidas: Wait(S): Se o S do semforo for positivo ento o valor de S decrementado. Se S igual a zero, a thread que chamou o Wait suspensa e fica armazenada em uma fila de processos suspensos associada ao semforo. Signal(S): Acorda uma thread que esteja suspensa na fila do semforo. Caso no haja nenhuma, o valor de S do objeto chamador incrementado. Imagine que faamos S0 = 1 inicialmente. A primeira thread que solicitar um Wait far S = S 1 = 0 e fechar o semforo (passagem) para as outras threads que tentarem executar o mtodo Wait; Tudo isso sem tomar tempo do processador como o algoritmo de alternncia rgida fazia em sua espera ociosa;

Semforos no Windows Para a criao de uma estrutura semforo no windows deve-se usar a funo HANDLE CreateSemaphore(), que dever ter os seguintes parmetros : LPSECURITY_ATTRIBUTES lpSemaphoreAttributes: ponteiros para estrutura de segurana do windows. LONG lInitialCount: Valor inicial para o semforo. LONG lMaximumCount: Mximo valor para o semforo. LPCTSTR lpName: Nome do semforo. Retorno da funo Status Interpretao Handle para o Semforo criado Sucesso NULL Falha

#include #include #include #include

"stdafx.h" "Threads.h" <stdlib.h> <time.h> 32 16 8 // numero de linhas da primeira matriz // numero de colunas da primeira matriz (e de linhas da segunda) // numero de colunas da segunda matriz argv[]) // primeira matriz // segunda matriz // matriz resultante

#define L1 #define C1 #define C2

int _tmain(int argc, _TCHAR* { float M1[L1][C1]; float M2[C1][C2]; float Mr[L1][C2]; int I, J;

/* Cria as threads. /* OBS: Para matrizes pequenas, ha a possibilidade de que um numero menor de threads que o esperado seja usado, uma vez que as primeiras threads a serem disparadas podem fazer todo o trabalho, nada deixando para as outras. */ Inicializa(4); // Inicializa as matrizes com numeros aleatorios. srand( (unsigned)time( NULL ) ); for(I=0; I<L1; I++) { printf("\n"); for(J=0; J<C1; J++) { M1[I][J]= 0.5f + (float)rand()/RAND_MAX; printf(" %.1f",M1[I][J]); } } printf("\n"); for(I=0; I<C1; I++) { printf("\n"); for(J=0; J<C2; J++) { M2[I][J] = 0.5f + (float)rand()/RAND_MAX; printf(" %.1f",M2[I][J]); } } printf("\n"); // Efetua a multiplicacao Processa((float*)M1, (float*)M2, (float*)Mr, L1, C1, C2); // o resultado esta em "Mr" for(I=0; I<L1; I++) { printf("\n"); for(J=0; J<C2; J++) { printf(" %.1f",Mr[I][J]); } } printf("\n"); // Destroi as threads. Finaliza(); return 0; }

#include <Windows.h> int N_threads; bool Destruir; int Esperando_terminar, Esperando_destruir; HANDLE Sema_comecar, Evento_terminou, Evento_destruiu; float *Mat1; // a primeira matriz a multiplicar float *Mat2; // a segunda matriz a multiplicar float *Mat_result; // a matriz resultado da multiplicacao int L1; // numero de linhas da primeira matriz int C1; // numero de colunas da primeira matriz int C2; // numero de colunas da segunda matriz LONG Linha_corrente;// proxima linha da primeira matriz a ser tratada pelas threads //============================================================================== static UINT Rotina_thread(LPVOID) //============================================================================== //Esta rotina e a thread. { while(1) { // a thread permanece inativa ate disparo externo WaitForSingleObject(Sema_comecar, INFINITE);

if(Destruir) break; // foi pedida a destruicao da thread LONG Linha; int I, J; float *P1, *P2, *Pr, S; // Cada iteracao efetua a multiplicacao de uma linha de "Mat1". while(1) { // proxima linha de "Mat1" a multiplicar Linha = InterlockedExchangeAdd(&Linha_corrente, 1); // verifica se "Mat1" ja foi toda tratada if(Linha >= L1) break; // Multiplica a linha de "Mat1" por todas as colunas de "Mat2". P1 = Mat1 + Linha*C1; // linha de "Mat1" P2 = Mat2; // coluna de "Mat2" Pr = Mat_result + Linha*C2; // linha de "Mat_result" for(I=0; I<C2; I++,P2++,Pr++) { // trata as colunas de "Mat2" S = 0; for(J=0; J<C1; J++) // varre as colunas da linha de "Mat1" contra // "Mat2" S += P1[J] * P2[J*C2]; *Pr = S; } } /* Cada thread que nao tiver mais nada a fazer decrementara "Esperando_terminar". Quando a contagem chegar a zero, informa o mundo externo. */ if(!InterlockedDecrement((long*)&Esperando_terminar)) SetEvent(Evento_terminou); } /* Cada thread que tiver sido destruida decrementara "Esperando_destruir". Quando a contagem chegar a zero, informa o mundo externo. */ if(!InterlockedDecrement((long*)&Esperando_destruir)) SetEvent(Evento_destruiu); // Obs: A thread e efetivamente destruida quando a rotina termina. return 0; } //============================================================================== void Inicializa(int nThreads) //============================================================================== /* ENTRADA: nThreads: Numero de threads a usar. Se zero, serao usadas tantas threads quanto os processadores da maquina. COMENTARIOS: Cria as threads. Deve ser chamada uma vez antes da primeira chamada a "Processa". Nao e necessario chama-la antes de cada chamada a "Processa". Quando "Processa" nao for mais usada, a rotina "Finaliza" deve ser chamada para destruir as threads e desalocar recursos. */ { int I; SYSTEM_INFO Si; DWORD dwThreadID; if(!nThreads) { // faz o numero de threads igual ao de processadores GetSystemInfo(&Si); N_threads = Si.dwNumberOfProcessors; } else N_threads = nThreads; // Aloca os objetos usados na sincronizacao das threads. Sema_comecar = CreateSemaphore(NULL, 0, N_threads, NULL); Evento_terminou = CreateEvent(NULL, FALSE, FALSE, NULL); Evento_destruiu = CreateEvent(NULL, FALSE, FALSE, NULL); // Cria as threads. Destruir = false; for(I=0; I<N_threads; I++) CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)Rotina_thread, NULL, 0, &dwThreadID); } //============================================================================== void Processa(float *_Mat1, float *_Mat2, float *_Mat_result, int _L1, int _C1, int _C2) //============================================================================== /* ENTRADA: _Mat1: A primeira matriz a multiplicar; _Mat2: A segunda matriz a multiplicar; _L1: Numero de linhas da primeira matriz; _C1: Numero de colunas da primeira matriz, que deve ser igual ao de linhas a coluna corrente de

da segunda matriz. _C2: Numero de colunas da segunda matriz. SAIDA: _Mat_result: Matriz resultante da multiplicacao. O espaco de memoria deve ser fornecido pelo chamador. COMENTARIOS: Efetua a multiplicacao de duas matrizes, usando threads. A funcao "Inicializa" deve ter sido chamada uma vez antes da primeira chamada a esta. */ { // Inicializa as variaveis globais. Mat1 = _Mat1; Mat2 = _Mat2; Mat_result = _Mat_result; L1 = _L1; C1 = _C1; C2 = _C2; // Dispara as threads. Linha_corrente = 0; // primeira linha de "Mat1" a ser tratada Esperando_terminar = N_threads; ReleaseSemaphore(Sema_comecar, N_threads, NULL); // acorda as threads // espera termino da multiplicacao WaitForSingleObject(Evento_terminou, INFINITE); } //============================================================================== void Finaliza() //============================================================================== /* COMENTARIOS: Destroi as threads e libera recursos alocados por "Inicializa". Cada chamada a "Inicializa" deve gerar uma chamada a esta. */ { // Solicita destruicao das threads. Esperando_destruir = N_threads; Destruir = true; // acorda as threads ReleaseSemaphore(Sema_comecar, N_threads, NULL); // espera destruicao de todas as threads WaitForSingleObject(Evento_destruiu, INFINITE); // Libera recursos. CloseHandle(Evento_destruiu); CloseHandle(Evento_terminou); CloseHandle(Sema_comecar); }

Quando um processo criado no Windows, criado junto com ele a thread principal, que thread que roda a funo main ou WinMain. A partir da possvel criar novas threads, como no exemplo abaixo:
#include "stdafx.h" #include <windows.h> #include <iostream> using namespace std;

// // WINAPI um #define para __stdcall // DWORD WINAPI ThreadProc(void* lpv) { // // vamos esperar at 500 ms com o nosso random() de pobre // Sleep(GetTickCount() % 500); return 0; } int main() { DWORD dwThreadID; static const DWORD THREAD_COUNT = 20; HANDLE hThreads[THREAD_COUNT]; // // vamos criar nossas threads // for(DWORD a = 0 ; a < THREAD_COUNT ; a++) { hThreads[a] = CreateThread(NULL, // segurana, vamos deixar o default NULL, // tamanho da pilha. O default 1MB &ThreadProc, // funo da thread NULL, // parmetro da thread NULL, // flag de criao. Podemos us-lo para criar um thread suspensa &dwThreadID); // // O Sleep(0) diz ao scheduler do Windows que ele // pode agendar a prxima thread em espera, e ns // vamos para o fim da fila. // Sleep(0); } // // coloque um breakpoint aqui, v no menu Debug >> Windows >> Threads // e veja as threads que criamos na lista // __asm nop; // instruo x86 que no faz absolutamente nada // // Para esperar uma thread parar (o que os linux boys conhecem como 'join') // usamos WaitForSingleObject ou WaitForMultipleObjects. Essas funes // funcionam com handles de processos, threads, mutexes e outras coisas mais // que veremos depois // DWORD dw = WaitForSingleObject( hThreads[0], // handle 100); // vamos esperar 100 ms if(dw == WAIT_TIMEOUT) { // // no retornou em 100ms... Vamos esperar para sempre // dw = WaitForSingleObject(hThreads[0], INFINITE); } else if(dw == WAIT_OBJECT_0) { // // esperamos menos de 100 ms // } // // agora vamos ver qual thread para primeiro // dw = WaitForMultipleObjects( THREAD_COUNT - 1, // quantos handles na array hThreads + 1, // array de threads + 1, porque a thread 0 j acabou FALSE, // no quero esperar por todas, se algum thread acabar est bom INFINITE); // senta e espera DWORD qualThread = dw - WAIT_OBJECT_0; cout << "a thread mais rpida foi a " << qualThread << endl; // // agora vamos esperar todas de uma vez --------------| // v dw = WaitForMultipleObjects(THREAD_COUNT, hThreads, TRUE, INFINITE); // // Como a API C, vamos fechar os handles. Lembrando que // o Windows faz isso automaticamente quando o processo acaba // for(DWORD a = 0 ; a < THREAD_COUNT ; a++) CloseHandle(hThreads[a]); return 0; }

A nica diferena entre as threads criadas posteriormente e a thread principal de um processo que quando a thread principal acaba, todas as outras threads so forosamente terminadas e o processo acaba - caso contrrio uma thread esquecida poderia deixar o processo em um estado de limbo. Em um computador rodando Windows, em uma determinada hora, temos vrias threads rodando, e a thread nica entidade que faz uso do processador. No Windows, um processo no "roda" nem executado. O que "roda" uma thread (que por sua vez pertence um processo). Dessa forma, o scheduler (agendador) do Windows trabalha compartilhando e dividindo o uso do processador entre as threads do sistema, independente do processo que contm a thread. Em uma de suas atuaes, o scheduler do Windows (e de qualquer SO) funciona basicamente respondendo uma interrupo de timer que acontece em intervalos de milissegundos. Quando essa interrupo ocorre, a thread atual interrompida, e o scheduler toma seu lugar no processador para verificar se necessrio trocar de thread. Caso o quantum (tempo de cpu determinado para que a thread rode antes de outra thread assumir o processador) da thread atual tenha terminado, o scheduler salva os registradores que definem o estado atual da thread no thread context (veja a estrutura _CONTEXT no winnt.h) e carrega os registradores da prxima thread a ser executada. Com a nova thread pronta para utilizar o processador, o scheduler coloca a thread atual no fim da fila. Falando em cdigo, o ponteiro da estrutura ETHREAD que representa a thread colocada no fim de uma lista duplamente ligada que controla a fila de threads em estado ready. Quando s existe um processador ou core no computador, o scheduler d a impresso de que as threads esto sendo executadas simultaneamente, alternando entre elas dessa forma. Quando mais de um processador ou core esto disponves, vrias threads podem ser executadas simultaneamente, o que faz com que o scheduler precise distribuir as threads entre os N processadores disponveis. O tempo de interrupo citado de 20 120ms, dependendo do processador e da verso do Windows. Nas verses Home, Professional e Business, os intervalos so de 20ms, para que o sistema seja mais responsivo ao usurio interativo. O intervalo de 120ms usado nas verses Server, pois quanto maior o quantum, maior a probabilidade da thread conseguir atender a requisio em um quantum s, aumentando a vazo do servidor. Outra situao onde o scheduler aparece quando uma thread deve esperar uma operao de I/O. Nesse caso a thread perde o controle do processador antes que seu quantum acabe, e ela s ser colocada novamente na lista de threads ready (prontas para serem executadas) quando essa requisio de I/O for respondida. Como sempre, mais informaes podem ser encontradas na MSDN (sobre as funes CreateThread e WaitForXXX), Wikipedia (sobre conceitos do sistemas operacionais, como quantum e thread) e no livro "Windows Internals" (sobre a implementao dos conceitos no kernel do Windows). Multithreading com C e Win32 Microsoft Visual C++ fornece suporte para criar aplicativos multithread com o Microsoft Windows: O Windows XP, Windows 2000, Windows NT, Windows Me e Windows 98. Voc deve considerar usar mais de um segmento se o seu aplicativo precisa gerenciar vrias atividades, como simultneo de teclado e mouse entrada. Um segmento pode processar a entrada do teclado enquanto um segundo segmento filtros atividades do mouse. Um terceiro segmento pode atualizar a tela de vdeo baseada em dados de segmentos de mouse e teclado. Ao mesmo tempo, outros segmentos podem acessar arquivos do disco ou obter dados de um porta de comunicao. Com Visual C++, existem duas maneiras para programa com vrios segmentos: Use a Biblioteca Microsoft Foundation Class (MFC) ou o run-time library C e a API do Win32. Para obter informaes sobre como criar aplicativos multithread com MFC, consulte multithreading com C++ e MFC Depois de ler os tpicos a seguir sobre multithreading no C. Esses tpicos explicam os recursos em Visual C++ que oferecem suporte a criao de programas multithread. Programas multithread Um segmento basicamente um caminho de execuo por meio de um programa. Tambm a menor unidade de execuo que agenda Win32. Um segmento composto por uma pilha, o estado de registradores de CPU e uma entrada na lista de execuo do agendador de sistema. Cada segmento compartilha todos recursos do processo. Um processo consiste em um ou mais segmentos e o cdigo, dados e outros recursos de um programa na memria. Recursos normal do programa so Abrir Arquivos, semforos e memria alocada dinamicamente. Um programa executado quando o sistema Agendador de tarefas fornece um dos seus segmentos de execuo controle. O Agendador de Tarefas determina quais segmentos devem quando eles devem Execute e. Segmentos de prioridade mais baixa talvez precise aguardar enquanto maiores prioridade segmentos concluir suas tarefas. Em computadores multiprocessador, o Agendador de Tarefas pode mover segmentos individuais para diferentes processadores para equilibrar a carga CPU. Cada segmento em um processo funciona de forma independente. A menos que voc torn-las visveis uns aos outros, os segmentos Executar individualmente e so insensveis os outros segmentos em um processo. Segmentos compartilhando recursos comuns, no entanto, devem coordenar seu trabalho usando sinais ou outro mtodo de comunicao entre processos. Para obter mais informaes sobre como sincronizar segmentos, consulte gravar um programa Win32 os. Biblioteca suporte para Multithreading Todas as verses do CRT agora oferecem suporte multi segmentao com exceo de verses de algumas funes no-bloqueio. Consulte Multithreaded Libraries Performance para obter mais informaes. Consulte C RunTime Libraries para obter mais informaes sobre verses CRT.

Escrever um programa Win32 multithreading Quando voc escrever um programa com vrios segmentos, voc deve coordenar seu comportamento e Uso de Recursos do Programa. Voc tambm deve certificar-se que cada segmento recebe sua prpria Pilha . Para uma discusso semelhante do MFC ponto de vista, consulte Multithreading: programao dicas e Multithreading: Quando usar as classes de sincronizao Cada segmento possui sua prpria Pilha e registra sua prpria cpia da CPU. Outros recursos, como arquivos, dados estticos e memria da pilha, so compartilhados por todos os segmentos no processo. Segmentos usando esses recursos comuns devem ser sincronizados. Win32 fornece vrias maneiras para sincronizar recursos, incluindo semforos, as sees crticas, eventos e semforos. Ao vrios segmentos esto acessando dados estticos, o programa deve fornecer para recursos possveis conflitos. Considere um programa no qual um segmento atualiza um estrutura de dados esttico que contm as coordenadas x,y Itens a serem exibidos por outro segmento. Se o segmento de atualizao altera a coordenada x e apropriado antes de ele alterar a coordenada y, o segmento de vdeo pode ser agendado antes de coordenada y atualizada. O item deve ser exibido no local errado. Voc pode evitar esse problema usando semforos para controlar o acesso a estrutura. Um mutex (abreviao de mut ual ex clusion) uma forma de comunicao entre segmentos ou processos que esto sendo executadas de forma assncrona de um outro. Essa comunicao normalmente usada para coordenar as atividades de vrios segmentos ou processos, normalmente, controlando o acesso a um recurso compartilhado pelo bloqueio e desbloqueio o recurso. Para resolver esse problema coordenadas atualizao x,y, o segmento de atualizao define um mutex indicando que o estrutura de dados est em uso antes de executar a atualizao. Ele desmarque o mutex aps ambas as coordenadas tivessem sido processadas. O segmento de vdeo deve aguardar o mutex a ser criptografado antes de atualizar a exibio. Esse processo de esperando um mutex freqentemente chamado bloqueio em um mutex porque o processo est bloqueado e no pode continuar at que o mutex limpa. O programa Bounce.c mostrado na Exemplo C Multithread programa usa um mutex denominado ScreenMutex para coordenar as atualizaes de tela. Toda vez que um dos segmentos de vdeo estiver pronto para gravar a tela, ele chama WaitForSingleObject com a ala para ScreenMutex e constante INFINITE para indicar que a chamada WaitForSingleObject deve bloquear na mutex e no o tempo limite. Se ScreenMutex claro, a funo de espera define o mutex para que outros segmentos no podem interferir com a exibio e continuar executando o segmento. Caso contrrio, o segmento bloqueia at que o mutex limpa. Quando o segmento concluir a atualizao de vdeo, ele libera o mutex chamando ReleaseMutex. Tela exibe e dados estticos so apenas dois dos recursos que requerem gerenciamento cuidadoso. Por exemplo, seu programa pode ter vrios segmentos acessando o mesmo arquivo. Porque outro segmento pode ter movido o ponteiro do arquivo, cada segmento deve redefinir o ponteiro do arquivo antes de ler ou gravar. Alm disso, cada segmento deve certificar-se que ele no apropriado entre o momento que ele posiciona o ponteiro e o tempo que ela acessa o arquivo. Esses segmentos devem usar um sinal para coordenar o acesso ao arquivo pelo cercando cada arquivo acesso com W aitForSingleObject e ReleaseMutex chamadas. O exemplo de cdigo a seguir ilustra essa tcnica:
HANDLE hIOMutex= CreateMutex (NULL, FALSE, NULL); WaitForSingleObject( hIOMutex, INFINITE ); fseek( fp, desired_position, 0L ); fwrite( data, sizeof( data ), 1, fp ); ReleaseMutex( hIOMutex);

Segmento pilhas Todo espao de pilha padro de um aplicativo est alocado para o primeiro segmento de execuo, que conhecido como segmento 1. Como resultado, voc deve especificar a quantidade de memria para alocar para uma pilha separada para cada segmento adicional seu programa precisa. O sistema operacional aloca espao adicional de pilha para o segmento, se necessrio, mas voc deve especificar um valor padro. O primeiro argumento na chamada _beginthread um ponteiro para a funo BounceProc,que executa os segmentos. O segundo argumento especifica o tamanho da pilha padro para o segmento. O ltimo argumento uma identificao numrica que passado para BounceProc. BounceProc usa o nmero de identificao para propagar o gerador de nmero aleatrio e para selecionar o segmento do atributo de cor e exibir caracteres. Segmentos que fazem chamadas para o run-time library C ou para a API do Win32 devem permitem suficiente espao para a biblioteca e eles chamam funes API pilha. C printf funo requer mais de 500 bytes de espao de pilha, e voc deve ter 2 k de espao de pilha disponvel quando chamando rotinas API do Win32. Como cada segmento tem sua prpria Pilha, voc pode evitar possveis conflitos sobre itens de dados usando como dados estticos pouco como possveis. Crie seu programa a usar variveis pilha automtica para todos os dados que podem ser particulares a um segmento. As variveis globais somente no programa de Bounce.c esto excluses mtuas ou variveis que nunca alteram depois que eles so inicializados. Win32 tambm fornece Thread-local de armazenamento (TLS) para armazenar dados por segmento. Para obter mais informaes, consulte Segmento local de armazenamento (TLS). Compilando e vinculando programas Multithread O programa Bounce.c apresentado no exemplo C Multithread Programa. Programas so compilados com vrios segmentos por padro.

Para compilar e vincular o programa multithread Bounce.c de dentro de ambiente de desenvolvimento. 1. No menu File, clique em Novo e em seguida, clique em Project. 2. Na caixa Tipos de Projeto painel, clique em Win32. 3. No painel Templates,clique em Aplicativos Win32 console e, em seguida, o nome do projeto. 4. Adicione o arquivo que contm o cdigo-fonte C para o projeto. 5. No menu Build,compile o projeto clicando no comando Build. Exemplo C Multithread programa Bounce.c um exemplo multithread programa que cria um novo segmento sempre que for digitado a letra um ou A. Cada segmento balana um rosto feliz de uma cor diferente ao redor de tela. At 32 segmentos podem ser criados. Finalizao normal do programa ocorre quando q ou P digitado. Para obter informaes sobre a compilao e a vinculao Bounce.c, consulte compilando e vinculando programas Multithread.
// sample_multithread_c_program.c // compile with: /c // // Bounce - Creates a new thread each time the letter 'a' is typed. // Each thread bounces a happy face of a different color around // the screen. All threads are terminated when the letter 'Q' is // entered. // #include #include #include #include #include #include <windows.h> <stdlib.h> <string.h> <stdio.h> <conio.h> <process.h> 32

#define MAX_THREADS

// The function getrandom returns a random number between // min and max, which must be in integer range. #define getrandom( min, max ) (SHORT)((rand() % (int)(((max) + 1) - \ (min))) + (min)) int main( void ); void KbdFunc( void ); void BounceProc( void * MyID ); void ClearScreen( void ); void ShutDown( void ); void WriteTitle( int ThreadNum ); HANDLE hConsoleOut; HANDLE hRunMutex; HANDLE hScreenMutex; int ThreadNr; CONSOLE_SCREEN_BUFFER_INFO csbiInfo; // // // // // // // // // // // Thread 1: main Keyboard input, thread dispatch Threads 2 to n: display Screen clear Program shutdown Display title bar information Handle to the console "Keep Running" mutex "Screen update" mutex Number of threads started Console information

int main() // Thread One { // Get display screen information & clear the screen. hConsoleOut = GetStdHandle( STD_OUTPUT_HANDLE ); GetConsoleScreenBufferInfo( hConsoleOut, &csbiInfo ); ClearScreen(); WriteTitle( 0 ); // Create the mutexes and reset thread count. hScreenMutex = CreateMutex( NULL, FALSE, NULL ); hRunMutex = CreateMutex( NULL, TRUE, NULL ); ThreadNr = 0;

// Cleared // Set

// Start waiting for keyboard input to dispatch threads or exit. KbdFunc(); // All threads done. Clean up handles. CloseHandle( hScreenMutex ); CloseHandle( hRunMutex ); CloseHandle( hConsoleOut ); } void ShutDown( void ) // Shut down threads { while ( ThreadNr > 0 ) { // Tell thread to die and record its death. ReleaseMutex( hRunMutex ); ThreadNr--; } // Clean up display when done WaitForSingleObject( hScreenMutex, INFINITE ); ClearScreen();

} void KbdFunc( void ) // Dispatch and count threads. { int KeyInfo; do { KeyInfo = _getch(); if ( tolower( KeyInfo ) == 'a' && ThreadNr < MAX_THREADS ) { ThreadNr++; _beginthread( BounceProc, 0, &ThreadNr ); WriteTitle( ThreadNr ); } } while( tolower( KeyInfo ) != 'q' ); ShutDown(); } void BounceProc( void *pMyID ) { char MyCell, OldCell; WORD MyAttrib, OldAttrib; char BlankCell = 0x20; COORD Coords, Delta; COORD Old = {0,0}; DWORD Dummy; char *MyID = (char*)pMyID; // Generate update increments and initial // display coordinates. srand( (unsigned int) *MyID * 3 ); Coords.X = getrandom( 0, Coords.Y = getrandom( 0, Delta.X = getrandom( -3, Delta.Y = getrandom( -3, csbiInfo.dwSize.X - 1 ); csbiInfo.dwSize.Y - 1 ); 3 ); 3 );

// Set up "happy face" & generate color // attribute from thread number. if( *MyID > 16) MyCell = 0x01; // outline face else MyCell = 0x02; // solid face MyAttrib = *MyID & 0x0F; // force black background do { // Wait for display to be available, then lock it. WaitForSingleObject( hScreenMutex, INFINITE ); // If we still occupy the old screen position, blank it out. ReadConsoleOutputCharacter( hConsoleOut, &OldCell, 1, Old, &Dummy ); ReadConsoleOutputAttribute( hConsoleOut, &OldAttrib, 1, Old, &Dummy ); if (( OldCell == MyCell ) && (OldAttrib == MyAttrib)) WriteConsoleOutputCharacter( hConsoleOut, &BlankCell, 1, Old, &Dummy ); // Draw new face, then clear screen lock WriteConsoleOutputCharacter( hConsoleOut, &MyCell, 1, Coords, &Dummy ); WriteConsoleOutputAttribute( hConsoleOut, &MyAttrib, 1, Coords, &Dummy ); ReleaseMutex( hScreenMutex ); // Increment the coordinates for next placement of the block. Old.X = Coords.X; Old.Y = Coords.Y; Coords.X += Delta.X; Coords.Y += Delta.Y; // If we are about to go off the screen, reverse direction if( Coords.X < 0 || Coords.X >= csbiInfo.dwSize.X ) { Delta.X = -Delta.X; Beep( 400, 50 ); } if( Coords.Y < 0 || Coords.Y > csbiInfo.dwSize.Y ) { Delta.Y = -Delta.Y; Beep( 600, 50 ); } }

// Repeat while RunMutex is still taken. while ( WaitForSingleObject( hRunMutex, 75L ) == WAIT_TIMEOUT ); } void WriteTitle( int ThreadNum ) { enum { sizeOfNThreadMsg = 80 }; char NThreadMsg[sizeOfNThreadMsg]; sprintf_s( NThreadMsg, sizeOfNThreadMsg, "Threads running: %02d. Press 'A' " "to start a thread,'Q' to quit.", ThreadNum ); SetConsoleTitle( NThreadMsg ); } void ClearScreen( void ) { DWORD dummy; COORD Home = { 0, 0 }; FillConsoleOutputCharacter( hConsoleOut, ' ', csbiInfo.dwSize.X * csbiInfo.dwSize.Y, Home, &dummy ); }

Multithreading: programao dicas Multithread aplicativos exigem cuidado mais estrito do que os aplicativos de nico segmento quando estiver acessando os dados. Porque h vrios, independentes caminhos de execuo em usar simultaneamente em multithread aplicativos, os algoritmos, os dados ou ambos devem estar cientes que dados pode ser usada por mais de um segmento de cada vez. Este tpico explica as tcnicas para evitar possveis problemas ao programar aplicativos multithread com a biblioteca Microsoft Foundation Class (MFC). Acessando objetos de vrios segmentos Acessando objetos MFC de segmentos no-MFC Mapas do identificador do Windows A comunicao entre segmentos Acessando objetos de vrios segmentos Por razes de tamanho e o desempenho, objetos MFC so segmentos no-segurana no nvel do objeto, somente no nvel de classe. Isso significa que voc pode ter dois segmentos separados manipular dois objetos CString diferentes, mas no dois segmentos manipular o mesmo objeto CString. Se voc absolutamente deve ter vrios segmentos manipular o mesmo objeto, proteger esse tipo de acesso com mecanismos de sincronizao Win32 apropriados, como as sees crticas. Para obter mais informaes sobre as sees crticas e outros objetos relacionados, consulte S ynchronization na caixa Windows SDK. A biblioteca de classes usa as sees crticas internamente para proteger dados globais estruturas, como aqueles usados pela alocao de memria de depurao. Acessando objetos MFC de segmentos no-MFC Se voc tiver um aplicativo com vrios segmentos que cria um segmento de uma maneira diferente usando um objeto C WinThread, voc no poder acessar outros objetos MFC do segmento. Em outras palavras, se voc desejar acessar qualquer objeto MFC de um segmento secundrio, voc dever criar esse segmento com um dos mtodos descritos em multithreading: Interface de usurio Criar segmentos ou Multithreading: Criando segmentos de trabalho. Esses mtodos so os nicos que permitem a biblioteca de classes para inicializar as variveis internas necessrias para manipular aplicativos multithread. Mapas do identificador do Windows Como regra geral, um segmento pode acessar somente MFC objetos que ele criou. Isso ocorre porque temporria e permanente Windows ala mapas so mantidos no armazenamento local de segmento para ajudar a manter a proteo contra acesso simultneo de vrios segmentos. Por exemplo, um segmento de trabalho no possvel executar um clculo e, em seguida, chamamos um documento do UpdateAllViews funo de membro para que as janelas que contm modos de exibio nos novos dados modificados. Isso tem efeito algum, pois o mapa de objetos CWnd a HWND s local para o segmento primrio. Isso significa que um segmento pode ter um mapeamento de um identificador do Windows para um objeto C++, mas outro segmento pode mapear esse mesmo identificador para um objeto C++ diferente. As alteraes feitas em um segmento no poderiam ser refletidas no outro. H vrias maneiras resolver esse problema. A primeira passar identificadores individuais (como um HWND) em vez de C++ objetos para o segmento de trabalho. O segmento de trabalho, em seguida, adiciona esses objetos para seu mapa temporrio chamando o funo de membro FromHandle apropriado. Voc tambm pode adicionar o objeto para o segmento do mapa permanente chamando anexar,mas isso deve ser feito apenas se voc garantido que o objeto existir mais do que o segmento. Outro mtodo para criar novas mensagens definidas pelo usurio correspondente a diferentes tarefas os segmentos de trabalho ser executar e postar essas mensagens para janela principal do aplicativo usando ::

PostMessage. Este mtodo de comunicao semelhante aos dois aplicativos diferentes conversar com exceo de que os dois segmentos esto sendo executadas no mesmo espao de endereo. Para obter mais informaes sobre o identificador mapas, consulte observao tcnica 3. Para obter mais informaes sobre armazenamento local de segmento, consulte Armazenamento segmento local e armazenamento na caixa Windows SDK Usando o segmento local. A comunicao entre segmentos MFC fornece inmeras classes que permitem segmentos para sincronizar o acesso a objetos para manter segurana de segmentos. Uso dessas classes descrito na multithreading: Classes How to Use a sincronizao e Multithreading: Quando usar as classes de sincronizao. Para obter mais informaes sobre esses objetos, consulte Synchronization na caixa Windows SDK.

10.4 Tutorial de Sistema Distribudo com Visual Studio 2005 A criao de sistemas distribuidos, aplicaes que utilizem diversos servidores inclusive atravs da internet, um grande desafio para desenvolvedores e profissionais de infraestrutura. Desenvolvedores frequentemente conhecem pouco sobre a infraestrutura dos servidores. Profissionais de TI conhecem pouco sobre a rea de desenvolvimento. Integrar as duas reas para que as aplicaes faam uso adequado dos servidores um grande desafio para ambos os profissionais e o Visual Studio 2005 se prope a simplificar este desafio. Vamos ento ver o passo-a-passo de criao de um pequeno sistema distribuido e desta forma entender melhor de que forma o Visual Studio ir nos auxiliar nesta tarefa. No Visual Studio, selecione File->New Project e em Distributed System Solutions selecione um Logical DataCenter. O Logical DataCenter o diagrama que utilizamos para fazer o desenho da infraestrutura de rede da empresa e as conexes que existiro entre os servidores da empresa. Em geral este diagrama ser criado por profissionais de infraestrutura. Porm a criao do diagrama envolve conhecimentos em desenvolvimento de software que os profissionais de TI hoje no possuem. Ser um desafio aos profissionais de TI adquirirem este conhecimento. Na Toolbox, vemos elementos especficos para o desenho de uma infraestrutura de rede.

Vamos comear definindo as zonas da rede. As zonas da rede so reas de rede dentro das quais os servidores tem facilidade de se comunicarem, mas que so protegidas por firewalls, separando uma zona da outra. As zonas de rede mais comuns em um desenho de infraestrutura so a intranet de uma empresa, a rede interna da empresa, e a DMZ, rea onde so localizados os servidores que ficam visveis na web. Em uma grande empresa havero muitas outras zonas, tal como zonas isoladas por filiais, por exemplo. Para definir as zonas de rede basta inserir o objeto Zone e definir o nome da zona pela janela de propriedades. Vamos fazer isso para a intranet e a DMZ.

O objetivo da criao do desenho de infraestrutura que a equipe de TI especifique o que e o que no permitido no uso da infraestrutura disponvel. Isso feito atravs da especificao de constraints em cada objeto do diagrama de infraestrutura. Para ver as constraints, basta clicar com o boto direito sobre um objeto e selecionar a opo "Settings and constraints". Nas zonas, as constraints referem-se a quais servidores podem ser inseridos dentro de cada zona. Na intranet qualquer tipo de servidor pode ser inserido, mas na DMZ permitiremos a insero apenas se servidores web, a insero de outros servidores seria uma falha de segurana.

Cada zona tem 2 endPoints, um de entrada, outro de saida. Os endPoints so usados para comunicaes de entrada e saida da zona, justamente no sentido de que as zonas so protegidas por firewalls e portanto toda a comunicao de entrada e saida das zonas passa atravs dos firewalls. As constraints dos endpoints determinam que tipo de comunicao de entrada e saida pode existir em uma zona. Vejamos alguns exemplos especificando as constraints destes endPoints : Entrada na DMZ Apenas devemos permitir o uso de WebSiteEndPoint, nenhum outro. Assim estamos especificando que apenas sero permitidas comunicaes com sites web nesta zona. Marcando a opo User Defined podemos tambm limitar a URL do site web com o qual ser feita a comunicao, mas no faremos isso. Quando marcamos a opo User Defined aberta a opo WebSite, logo abaixo. Essa opo nos permite definir caractersticas de comunicao com o site web. So vrias caractersticas de infraestrutura do servidor web. No irei entrar em detalhes disso neste artigo, vamos deixar a opo "User defined" desmarcada. Saida da DMZ Neste endPoint vamos limitar a comunicao com banco de dados, mantendo apenas a opo DatabaseClientEndpoint selecionada. Eventualmente, em uma comunicao entre empresas, o HTTPClientEndpoint precisaria se manter selecionado para permitir que o servidor web consulte servidores de outras empresas. Mas no utilizaremos esse recurso neste exemplo. Entrada da intranet Vamos permitir apenas o contato com servidores de banco de dados contidos na intranet. Saida da Intranet Vamos permitir apenas a saida de clients HTTP, que em geral faro consultas a webServices ou sites web. Inserindo servidores Vamos inserir um servidor de banco na Intranet, vamos chama-lo de srvBanco. Vamos inserir um servidor web na DMZ. O servidor web j criado com dois endPoints, um WebSiteEndPoint e um HTTPClientEndPoint, assim sendo por default permite tanto a entrada de requisies (consulta a sites e webServiceS) como a saida de requisies (aplicaes consultando sites e webServices remotos).

Existe uma caracterstica muito importante na especificao do servidor web : A autenticao. Por default a autenticao do servidor web definida como NTLM. Isso bom para servidores web que estiverem atendendo uma intranet, mas para servidores expostos na web na maioria das vezes desejaremos que a autenticao seja annima. Assim sendo, para definirmos que a autenticao utilizada pelo servidor web dever ser autenticao annima devemos abrir a pasta "Logical Server Settings", "InternetInformationServices","WebSites", "Authentication", ento alteramos o item "AuthFlags" para Anonymous.

J na pasta um pouco mais acima, "Application Constraints", vemos que o administrador de rede pode criar limitaes para os itens de configurao mais crticos em um site ASP.NET, exatamente aqueles que envolvem infraestrutura : Membership, definindo qual ser o banco de membership, a segurana, etc., segurana, definindo a forma de autenticao que as aplicaes devero utilizar e Session State, definindo a forma de armazenagem do ambiente de sesso. Quando os itens esto desmarcados isso indica que no existem restries. Quando marcamos um dos itens estamos criando uma restrio. Vamos criar uma restrio para a configurao de segurana. A segurana dever ser Forms ou None, no utilizaremos segurana windows nas aplicaes contidas neste servidor.

Vamos alterar tambm as constraints do HTTPClientEndPoint. Por default ele pode ser client de sites web ou de servios web. Vamos limitar isso : Aplicaes contidas neste servidor apenas podem ser clients de webServices, no de sites.

Vamos inserir agora um windows client, fora das duas zonas, como se estivesse em qualquer local na web. Vamos chama-lo de winClient.

Vamos ento comear a realizar as conexes entre os servidores. As conexes desenhadas no diagrama de infraestrutura so conexes possveis de serem realizadas por quaisquer aplicaes que sejam inseridas nesses servidores. Assim sendo o profissional de TI desenha as conexes como possibilidades, o arquiteto de solues ir utiliza-las ou no. Vamos comear ligando o winClient ao srvWeb. Uma ligao feita entre zonas (o winclient est fora das zonas, o srvWeb na DMZ) precisa passar pelos pontos de conexo nas zonas, indicando a passagem por um firewall e sofrendo as restries aplicadas nessa passagem. Vamos inserir um HTTPClientEndPoint no WinClient e ento utilizar o Connection para fazer a conexo do WinClient at o srvWeb, passando pelo endPoint da DMZ. Precisamos tambm conetar o servidor web ao servidor de banco de dados, ento vamos inserir um DataBaseClientEndPoint no srvWeb e usar o Connection para fazer a ligao.

Application Designer Agora que fizemos o desenho da infraestrutura, vamos fazer o desenho da aplicao. Para isso vamos adicionar um novo Application Diagram, clicando com o boto direito sobre a solution, no solution explorer.

Neste application Diagram vamos adicionar as partes de nossa aplicao. Vamos adicionar o seguinte : External Database - Vamos chamar de NorthWind ASP.NET WebService - Vamos chamar de srvProdutos ASP.NET WebSite - Vamos chamar de webLoja Windows Application - WinVendas Vamos configurar cada uma das aplicaes, em especial as aplicaes web. Agora no estaremos simplesmente inserindo restries, estaremos realmente configurando o funcionamento da aplicao, criando visualmente o web.config que ser utilizado nestas aplicaes. Vamos comear pelo site Web. Entrando na janela "Settings and Constraints", abaixo da pasta "Application Settings" devemos comear a configurao de nossa aplicao web. Clicando com o boto direito sobre o item "Configuration", podemos utilizar o item "Add Resource" para adicionar uma sesso System.web (SystemWebSectionGroup).

Dentro da sesso System.Web deveremos fazer o mesmo para adicionar uma sesso authentication na qual definiremos a propriedade Mode como "Forms". O diagrama nos obrigar a adicionar a chave credentials. No falar nada agora, mas quando validarmos a aplicao reclamar da falta desta chave. Isso porque definimos, no servidor, a forma de criptografia de senha das credenciais.

De fato no usaremos a chave credentials para nada, mas essa configurao precisa estar ai para ser validada. Vamos ento repetir a mesma configurao para o webService, srvProdutos. Feitas as configuraes, vamos comear a conectar as aplicaes. Vamos comear a conectar o WebService com a base de dados. No momento em que criarmos esta conexo ser aberta uma tela para configurarmos as caractersticas de conexo com a base de dados. A string de conexo configurada ser armazenada no web.config do WebService, isso j feito automaticamente.

Vamos ligar tambm a aplicao web com o webService e a aplicao Windows com o webService. Ambas utilizaro os recursos oferecidos pelo servio. O servio ir oferecer mtodos para nossas aplicaes. Clicando com o boto direito sobre o endPoint do webService encontramos a opo Define Operations, pela qual podemos definir os mtodos que o servio ir oferecer para nossas aplicaes.

Imaginemos, porm que desejamos que um dos mtodos do servio faa a devoluo de um dataSet. O ideal seria que este dataSet fosse tipado. Porm na definio grfica da aplicao no temos como definir um dataset tipado diretamente no diagrama (o que uma pena - seria timo se fosse possvel a partir do banco fazer especificao de datasets direto no diagrama da aplicao). Pior que isso, a aplicao por default no tem references para System.Data, o que nos impede de definir at mesmo mtodos retornando dataSets no tipados.

Para resolver este problema precisaremos, neste momento, implementar o webService. Devemos clicar com o boto direito no webService e selecionar a instruo Implement Application.

Com isso o Visual Studio ir criar um projeto para nosso WebService com as caractersticas que j determinamos que ele deve ter. Feito isso aproveitamos para adicionar um references para system.Data e adicionamos um novo DataSet. Para simplificar podemos arrastar a tabela Products do Server Explorer para o dataSet. Observe neste ponto uma novidade : criado um TableAdapter junto com a dataTable. Alm de fazer o papel do antigo dataAdapter o tableAdapter tambm pode conter instrues para atualizao direta da base de dados, conforme solicitado durante o Wizard de criao deste objeto.

Retornando ao diagrama da aplicao observamos que j conseguimos visualizar tanto as classes de System.Data como nosso novo DataSet atravs da definio de operaes. O diagrama da aplicao mantido sempre em sincronia com o projeto. Vamos ento criar 3 mtodos nas operations de nosso WebService : ListarProdutos : Retornando o dataSet com todos os produtos AumentarPreo : Aplicar um % de aumento em um produto AtualizarProduto : Para fazer atualizaes nos dados do produto

Test Driven Development TDD uma tcnica que faz parte da metodologia XP para desenvolvimento de software. A idia do TDD que os testes dos softwares sejam criados antes dos prprios softwares e s depois seja criado o software para atender ao requisito do teste. Seria extremamente trabalhoso se no fosse uma grande novidade no Visual Studio 2005 : O VS j capaz de fazer a criao dos testes automaticamente. Porm estamos iniciando o exemplo pelo caso mais difcil, um webService. Um webService precisa estar hospedado em um servidor. Para execues individuais o VS coloca no ar o servidor dele, mas para criar o teste precisamos de uma integrao entre dois projetos distintos. A primeira questo a porta de comunicao. Quando rodamos o webService a porta de comunicao escolhida pelo servio aleatria. Para que a aplicao de testes que iremos criar consiga localizar o servio

precisamos fazer com que a porta de comunicaes se torne fixa. Basta uma alterao nas propriedades do projeto do servio.

Outra questo a forma de autenticao ao servidor que hospedar o servio. Por default ele exige autenticao windows. Porm configurando as start option do projeto do servio podemos facilmente alterar esta configurao para que ele passe a aceitar conexes annimas.

Feitas essas configuraes poderemos ento criar o novo projeto de teste, bastando clicar com o boto direito sobre a classe do servio. O VS criar um novo projeto, adicionar a webReference para nosso webService e criar, dentro de uma classe de teste, um mtodo de teste para cada um dos mtodos de nosso servio.

Como chamar os mtodos do servio o VS j sabe, o que ele no sabe quais valores de retorno demonstram o sucesso do servio. Sendo assim precisaremos fazer pequenas alteraes nos mtodos de teste para indicar isso ao VS. Veja como fica o cdigo :
48 <TestMethod()> _ 49 Public Sub AlterarProdutoTest() 50 51 Dim srv As New localhost.epSrvVendas 52 Dim ds As localhost.dsProdutos 53 54 srv.AlterarProduto(1, "Chai", 150, 7) 55 56 ds = srv.ListarProdutos 57 58 Assert.AreEqual(CType(150, Decimal), ds.Products.Rows.Find(1)("unitprice"), "Os dados no foram alterados")

59 60 61 62 End Sub 63 64 <TestMethod()> _ 65 Public Sub AumentarPrecoTest() 66 67 Dim srv As New localhost.epSrvVendas 68 Dim ds As localhost.dsProdutos 69 Dim patual As Decimal 70 71 ds = srv.ListarProdutos 72 73 patual = ds.Products.Rows.Find(1)("unitprice") 74 75 srv.AumentarPreco(1, 0.1) 76 77 ds = srv.ListarProdutos 78 79 Assert.AreEqual(CType(patual * 1.1, Decimal), ds.Products.Rows.Find(1)("unitprice"), "O preo no foi aumentado") 80 81 82 End Sub 83 84 85 <TestMethod()> _ 86 Public Sub ListarProdutosTest() 87 88 Dim srv As New localhost.epSrvVendas 89 Dim dados As localhost.dsProdutos 90 91 dados = srv.ListarProdutos() 92 93 Assert.IsNotNull(dados, "O conjunto de dados no foi retornado") 94 95 96 Assert.IsTrue(dados.Products.Rows.Count > 0, "No foram trazidos produtos") 97 98 99 End Sub

Observe o uso do atributo TestMethod para indicar que tratam-se de mtodos de teste. Observe tambm a forma como utilizado o Assert para indicar o resultado do teste, sucesso ou no. Coube a ns montar a lgica que determina se o teste teve ou no sucesso. Tendo construido os mtodos de teste, vamos executa-los e constatar o bvio : Todos eles iro falhar. Isso realmente bvio, j que ainda no produzimos os mtodos de nosso servio. Vamos ento produzir os mtodos de nosso servio e novamente executar o teste. Desta vez os testes indicaro sucesso. Assim sendo, antes de passar para as etapas seguintes ns garantimos que nosso servio encontra-se funcionando, e no s isso : Deixamos a disposio uma aplicao de teste para o servio de forma que, sempre que for necessrio alterar o servio, poderemos rapidamente identificar se a alterao funcionou ou se causou um problema.

System Diagram Agora que fizemos a montagem do servio, vamos completar o diagrama, indicando dentro de qual servidor as aplicaes sero inseridas. Dentro do application diagram clicamos com o boto direito e selecionamos a instruo Define Deployment. Ao escolhermos esta opo o Visual Studio cria um novo diagrama chamado de System Diagram. O System Diagram como um intermedirio entre o logical datacenter e o application diagram. Com o System Diagram iremos definir qual aplicao ser inserida em cada servidor.

Ao ser exibido o System Diagram veremos inicialmente os servidores, conforme desenhados no Logical dataCenter. Mas observando no lado esquerdo da tela encontraremos uma tela de visualizao das aplicaes. Poderemos ento arrastar as aplicaes para dentro dos servidores em que elas ficaro.

Feito isso, estando cada aplicao em seu devido local, podemos clicar com o boto direito no System Diagram e selecionar a opo Validate Diagram. O Visual Studio ir validar as restries definidas pela equipe de infraestrutura com as caractersticas das aplicaes definidas pelos arquitetos da aplicao.

Neste caso deixei propositalmente um erro para vermos a reao do diagrama. Ele ir reclamar pois a aplicao web est conectada ao webService, mas nos servidores no existe uma linha de conexo que possibilite isso.

simples : Os dois esto no mesmo servidor, ento para que isso seja realmente possvel devemos definir no logical datacenter uma linha de conexo do servidor para ele mesmo,assim essa conexo no ser mais um erro. Implementando as aplicaes Podemos agora clicar com o boto direito sobre o application diagram e selecionar a opo "Implement all applications". Ele ir implementar todas as aplicaes que no tenham sido implementadas at o momento, criando o relacionamento entre as aplicaes que, no nosso exemplo, trata-se da webReference da aplicao Windows e da aplicao Web para o WebService. 10.5 PVM - Parallel Virtual Machine Os arquivos do PVM esto disponveis no endereo http://www.netlib.org/pvm3/index.html. Em 1989, no Oak Ridge National Laboratory -ORNL, teve incio o projeto PVM. A verso 1.0 foi implementada por Vaidy Sunderam e Al Geist, sendo direcionada ao usos de laboratrio. A partir da verso 2.0 (1991), houve a participao de outras instituies (como a University of Tennissee, Carnegie Mellon University, entre outras). PVM uma abreviatura para Parallel Virtual Machine, ou Mquina Paralela Virtual. O PVM permite que um conjunto de mquinas heterogneas seja enxergado como uma nica mquina paralela virtual. O PVM lida transparentemente com o roteamento de mensagens, converso de dados e o escalonamento de processos em uma rede formada por arquiteturas antes incompatveis. uma ferramenta educacional que permite o ensino de programao paralela mesmo sem acesso a um computador paralelo. Usurios do PVM desenvolvem suas aplicaes como uma srie de tarefa PVM que trabalham juntas na resoluo de um problema. As tarefas tm acesso aos recursos do PVM atravs de uma interface padro composta de rotinas implementadas em uma biblioteca de funes que compilada juntamente com o cdigo do programa. As primitivas de troca de mensagens foram desenvolvidas para trabalhar em ambientes heterogneos. Antes de ser transmitido, um dado precisa ser empacotado, ou seja, transformado para uma forma cannica que possa ser entendida por todas as mquinas da rede. Assim, ao empacotar um valor inteiro para transmisso, o usurio no tem que se preocupar com o nmero de bytes usados para representar um inteiro em cada mquina nem com a ordem em que esses bytes so armazenados. O PVM permite SPMD e MPMD, como tambm um mtodo hbrido (uma mistura dos dois). A figura abaixo mostra um exemplo do modelo computacional do PVM e uma viso arquitetural destacando a heterogeneidade do sistema.
Entrada e Particionamento Computador 1 Computador 2 Grupo1 Ponte/ Roteador

MPP SPMD SPMD Grupo2 PVM: Viso Uniforme de uma Mquina Virtual Multiprogramada

Sada dos Dados (a)

Grupo3

(b)

Sistema PVM. (a) Modelo computacional e (b) viso arquitetural O PVM uma importante ferramenta de paralelizao para problemas que exijam um grande volume de processamento. Sua habilidade de trabalhar em redes heterogneas permitem obter o mximo dos recursos computacionais existentes sem exigir novos investimentos em hardware. A interface de programao simples e suporta duas linguagens de programao amplamente usadas na indstria e no meio acadmico: C e FORTRAN. A simplicidade do modelo de programao permite que mesmo programadores inexperientes com aplicaes paralelas consigam desenvolver programas que apresentem um aprecivel speedup em relao ao cdigo serial correspondente. O PVM gratuito e est disponvel online, possui uma grande base instalada de usurios e est muito bem documentado inclusive com referncias online.

A Mquina Virtual do PVM Para tratar um conjunto de mquinas interligadas por uma rede como um grande computador multiprocessado virtual, O PVM roda um programa daemon40 chamado pvmd em cada uma das mquinas componentes da MV (Mquina Virtual). Toda a comunicao entre duas mquinas da MV passam pelos processos pvmd que rodam nas mquinas em questo. Por exemplo, se um processo de uma mquina A quer mandar uma mensagem para um processo na mquina B, esta mensagem ser enviada para o pvmd da mquina A, passar para o pvmd da mquina B e s ento ser repassada para o processo destino na mquina B. Montar uma MV no PVM significa iniciar um pvmd em cada uma das mquinas que queremos presente na MV. O primeiro pvmd que iniciado numa MV funciona como mestre e o nico capaz de reconfigurar a MV como acrescentar ou remover mquinas. A partir do pvmd mestre, os demais pvmds so iniciados com status de escravo. Pedidos de reconfigurao da MV vindos de processos cujo pvmd local seja um pvmd escravo so repassados ao pvmd mestre e executados de l. Existem duas maneiras de montar uma mquina virtual, atravs de um programa feito pelo usurio ou usando o console do PVM, um programa chamado pvm que vem junto com a distribuio do PVM. Descreveremos inicialmente o uso do console do PVM e mais para frente discutiremos como controlar a configurao da MV alm de passar mensagens e gerenciar tarefas PVM no modo programado. Console do PVM A partir do console do PVM possvel executar diversas tarefas de gerenciamento da MV. Algumas tarefas comuns so: - acrescentar e remover mquinas na MV (comando add); - iniciar e encerrar tarefas em mquinas que fazem parte da MV; - listar parte ou todas as tarefas da MV; - eviar sinais para tarefas. Para iniciar a execuo do console do PVM, basta digitar pvm na linha de comando, para verificar a configurao atual da MV use o comando conf, para encerrar a execuo do console sem desativar a MV, use o comando quit. Antes de finalizar o programa, o console avisa o usurio que o daemon do PVM (pvmd) ainda est rodando, portanto a MV continua ativa. Para encerrar tanto o console quanto a MV o comando a ser usado halt. Programando com PVM A programao com PVM nada mais que uma aplicao desenvolvida a partir da biblioteca do PVM cuja funo fornecer uma interface para que o usurio modifique a configurao da MV e possa fazer algum gerenciamento de tarefas. Para explorar todas as capacidades do sistema PVM, necessrio programar um algoritmo paralelo que se adapte ao problema que est sendo estudado. A eficincia do algoritmo paralelo altamente dependente da decomposio do algoritmo serial em tarefas independentes. Essa decomposio em tarefas independentes (ou concorrentes) leva em conta questes como: - Qual ser o tamanho (tempo de execuo) das tarefas independentes em relao ao tamanho do algoritmo serial correspondente? Essa medida chamada de gro de paralelizao. - Quanto tempo ser gasto em transmisso dos dados de cada gro para os processadores envolvidos na paralelizao? O tamanho escolhido para o gro de paralelizao deve levar em conta os tempos de transmisso dos dados do gro em relao ao seu tempo de execuo. Quanto maior for o tempo de execuo do gro, menores sero os custos relativos comunicao. Os problemas tendem a apresentar um tempo de execuo que cresce exponencialmente com o tamanho do problema. Esta caracterstica facilita a decomposio das tarefas e permite bons ganhos de performance (speedup). Via de regra, o gro deve ser dimensionado de tal forma que a transmisso dos dados na rede no comprometa a performance do algoritmo paralelo, isto , o algoritmo paralelo deve fornecer ganhos suficientes para justificar o esforo de paralelizao. A Interface de Programao O PVM fornece duas interfaces anlogas de programao, uma em linguagem C/C++ e outra em linguagem FORTRAN. Estaremos descrevendo neste texto as rotinas da interface C/C++ mas todas as funes e conceitos so facilmente adaptados para a interface FORTRAN, muitas vezes apenas com a mudana do nome da funo (por exemplo, a funo C pvm_mytid() escrita em FORTRAN como pvmfmytid()). Todo programa escrito na linguagem C do PVM deve incluir a linha #include pvm3.h no incio do programa. Equivalentemente, programas PVM escritos em FORTRAN devem incluir a linha #include fpvm3.h em seu incio. Esses arquivos contm as definies das diversas funes do PVM e informam ao compilador como fazer a verificao de tipos e sintaxe das chamadas PVM. Se o arquivo pvm3.h (ou fpvm3.h) no estiver no diretrio onde seu programa fonte se localiza, preciso substituir o nome do arquivo pelo seu caminho completo ou informar ao compilador onde localiz-lo. Funes de Controle de Processos Toda aplicao paralela pressupe a existncia de diversos processos que rodam concorrentemente. O gerenciamento de processos, ou tarefas como os processos so comumente referenciados na documentao do PVM, feito atravs de um conjunto de funes de controle de processos. As mais importantes so:
40

Processo que roda em background e que desempenha uma srie de funes relacionadas com o sistema.

pvm_mytid() Devolve o identificador (um valor inteiro) pelo qual o processo chamador conhecido na MV. Este nmero usado pelos demais processos PVM para comunicar-se com o processo chamador. Esta funo normalmente a primeira funo PVM chamada no programa e tem a funo dupla registrar o processo na MV e informar ao processo o seu identificador na MV.3 pvm_exit() a ltima funo a ser chamada por um programa PVM. Ele informa ao pvmd local que o processo est se desligando da mquina virtual. A boa praxe de programao PVM exige que um programa comece com pvm_mytid() e termine em pvm_exit(). pvm_spawn() usado para iniciar novas tarefas na MV. No modelo de programao mestre/escravo, esta funo usada no programa mestre para lanar processos escravos para as mquinas constituintes da MV. pvm_kill() Tem por objetivo forar o trmino da execuo de algum processo PVM rodando na MV. Pode ser usada por um programa mestre para encerrar a execuo de escravos trabalhando em solues numricas que no esto convergindo. pvm_addhosts()/pvm_delhosts() Estas funes acrescentam e removem mquinas fsicas da MV do PVM. Funes de Informao O gerenciamento de tarefas concorrentes em uma aplicao muitas vezes necessita da aquisio de informaes adicionais sobre o estado da MV incluindo identificadores de outros processos, nome da mquina no qual uma tarefa est executando e outras informaes. Algumas rotinas de obteno destas informaes no PVM seguem: pvm_parent() Funo til em processos escravos. Esta funo retorna o identificador do processo que iniciou o processo atual. Este identificador ser necessrio se o escravo desejar trocar mensagens com o programa mestre. pvm_perror() Esta funo imprime para a sada padro uma mensagem indicando o tipo de erro retornado por uma funo PVM. Valores de retorno menores que 0 indicam um erro na funo. pvm_config() As informaes retornadas por esta funo so teis para detectar falhas em mquinas e tarefas da MV. Por exemplo, para saber se alguma mquina da MV foi desligada ou desconectada da rede. Funes de Gerenciamento de Buffers Os chamados buffers so regies de memria destinadas a armazenar mensagens que sero enviados para outras tarefas ou recebidas delas. Toda comunicao entre tarefas envolve o uso de buffers. A memria ocupada por um buffer de envio ou recebimento deve ser inicializada antes de ser usada e as funes abaixo tm este propsito. pvm_initsend() Deve ser invocada ao menos uma vez no programa, define a codificao a ser usada na transmisso de dados. Uma discusso sobre codificao de dados se encontra na seo Funes de Envio de Dados a seguir, mas as opes so: codificao XDR e sem codificao. pvm_mkbuf() Cria um novo buffer de dados. pvm_freebuf() Libera a memria alocada para o buffer. Funes de Envio de Dados A funcionalidade do PVM construda sobre um conjunto de diretivas de troca de mensagens. As aplicaes PVM funcionam trocando informaes que so empacotadas em mensagens. Cada mensagem possui um identificador de tipo, uma codificao e os dados propriamente ditos. Os identificadores de tipo de mensagem podem ser usados para implementar prioridades de recebimento das mensagens. Mensagens com dados marcados urgentes podem ser processados antes que outras mensagens com outros tipos. A codificao importante em ambientes heterogneos, onde cada processador pode ter convenes prprias para a representao interna dos dados. Um exemplo clssico das diferenas que podem surgir a representao interna de um nmero inteiro nas plataformas Intel x86 e Sun SPARC. A Intel costuma armazenar seus nmeros inteiros da direita para a esquerda seguindo a conveno little endian enquanto a Sun armazena nmeros inteiros da esquerda para a direita, conveno conhecida como big endian. Quando se quer que dois ou mais computadores de arquiteturas distintas (como Intel e Sun SPARC) se comuniquem, necessrio converter os dados para um formato intermedirio que todas as plataformas conheam, assim, s necessrio que cada computador saiba converter os dados de e para este formato intermedirio e sua prpria representao interna. O PVM adota a codificao XDR (External Data Representation), um padro criado pela Sun, para implementar a transparncia de arquitetura em suas mensagens. Quando a MV contm apenas mquinas de uma mesma arquitetura, possvel no codificar os dados o que implica em alguma economia de tempo na transmisso das mensagens uma vez que a codificao XDR sacrifica um pouco de espao de armazenamento em favor da portabilidade. As principais funes de envio de dados so: pvm_send() Envia os dados armazenados em um buffer de envio para uma dada tarefa. pvm_mcast() Envia os dados armazenados em um buffer de envio para um conjunto de tarefas (multicast). pvm_pk??() Este na verdade um conjunto de funes de empacotamento (codificao + armazenamento) de dados em um buffer de envio. A funo para empacotar um inteiro para transmisso se chama pvm_pkint() e assim por diante. Consulte a man page pvm_pk para saber todas as opes. Funes de Recepo de Dados Estas funes tem funcionamento inverso s funes de envio de dados. So elas:

pvm_recv() Recebe uma mensagem enviada por outro processo e a coloca no buffer de recebimento. Caso no existam mensagens a ser recebidas, o processo fica bloqueado at que uma mensagem se faa disponvel para recepo. pvm_nrecv() Anloga funo anterior com a diferena que a funo retorna um erro ao invs de bloquear o processo se no existirem mensagens para serem recebidas. pvm_upk??() Estas funes so anlogas s funes pvm_pk??(). Servem para desempacotar (decodificar + retirar do buffer) os dados armazenados no buffer de recebimento. Para desempacotar um inteiro use a funo pvm_upkint() e assim por diante. Uma descrio de todas as opes de desempacotamento est na man page pvm_upk. Balanceamento de carga Uma importante questo na programao de uma aplicao PVM a melhor maneira de distribuir os processos entre as mquinas que compem a MV do PVM. Esta distribuio de carga depende de diversos fatores como a homogeneidade dos gros de paralelizao obtidos na fase de decomposio do problema, a velocidade e performance das mquinas presentes na MV e o perfil de carga de cada mquina no decorrer do tempo dado que outros usurios podem us-las. Uma abordagem simples para o problema a alocao esttica de recursos. Nesta abordagem, o usurio elabora alguma heurstica de alocao de tarefas que busca balancear a carga entre as mquinas presentes levando em conta os fatores acima. A grande vantagem deste mtodo sua facilidade de projeto/implementao. Pode ser a soluo adotada para problemas cuja soluo no seja crtica ao funcionamento de um sistema e tudo que se quer obter um speedup utilizando capacidade ociosa da rede atual. Este mtodo pouco adaptvel a mudanas de configurao da rede ou do seu perfil de uso e apresenta melhores resultados em redes de comportamento bastante previsvel. O outro extremo do balanceamento de carga monitorar a carga em todas as mquinas da rede determinando qual mquina mais indicada para o lanamento de novos processos. Uma monitorao eficiente deve levar em conta um histrico recente de utilizao da mquina (1, 2, 5, a 10 minutos no passado) juntamente com dados estatsticos de utilizao em perodos maiores (perfis de uso semanal e mensal). Este mtodo difcil de implementar pois no existe uma forma portvel de se monitorar o desempenho instantneo (ou quase instantneo) das mquinas de modo que qualquer soluo pode precisar de adaptaes ao ser transferido para outras redes. Alm disso, existe uma complexidade de gerar modelos ideais de balanceamento de carga e o trfego das informaes de monitorao pode impor uma carga adicional nos ns e nos meios de transmisso da rede. Solues eficientes e de implementao mais fceis so obtidas fazendo um compromisso entre a eficincia e a adaptabilidade. Estas solues hbridas misturam lados positivos de ambos os mtodos buscando uma melhor adaptao para o problema sendo resolvido. PVM em Sistemas com Multiprocessadores Devido necessidade de seus usurios executarem aplicaes especficas, o PVM foi tambm adaptado para as mquinas com multiprocessadores. Baseando-se em sua portabilidade, o PVM foi reconfigurado e como resultado final, as aplicaes desenvolvidas para as estaes de trabalho puderam executar em computadores com MPP. A mquina virtual esconde os detalhes de configurao do usurio. Os processadores fsicos podem ser uma rede de estaes de trabalho ou ns de um computador com multiprocessadores. responsabilidade do PVM estabelecer quais tarefas iro executar em cada processador. Entretanto h a possibilidade de se especificar uma configurao desejada para determinadas tarefas, onde o objetivo atingir o mximo de desempenho possvel mesmo com o custo imposto pela portabilidade. Programa exemplo em PVM
#include pvm3.h #define NPROC 4 main() { int mytid, tids[NPROC], me, i; mytid = pvm_mytid(); tids[0] = pvm_parent(); if ( tids[0] < 0 ) { tids[0] = mytid; me = 0; pvm_spawn (spmd, (char **)0, 0, , NPROC-1, &tids[1]); pvm_initsend( PvmDataDefault ); pvm_pkint(tids, NPROC, 1); pvm_mcast(&tids[1], NPROC-1, 0); } else { pvm_recv(tids[0], 0); pvm_upkint(tids, NPROC, 1); for( i = 1; i < NPROC; i++ ) if (mytid == tids[i] ) { me = i; break; } } dowork( me, tids, NPROC); pvm_exit(); }

dowork( me, tids, nproc) int me, *tids, nproc; { int token, dest, count = 1, stride = 1, msgtag = 4; if(me == 0) { token = tids[0]; pvm_initsend (PvmDataDefault ); pvm_pkint( &token, count, stride ); pvm_send( tids[me+1], msgtag ); pvm_recv( tids[nproc -1], msgtag ); } else { pvm_recv( tids[me-1], msgtag); pvm_upkint( &token, count, stride ); pvm_initsend( PvmDataDefault ); pvm_pkint( &token, count, stride ); dest = ( me == nproc-1) ? tids[0] : tids[me+1]; pvm_send( dest, msgtag ); } }

10.6 MPI - Message Passing Interface O MPI uma tentativa de padronizao, independente da plataforma paralela, para ambientes de programao via troca de mensagens. Surgiu da necessidade de se resolver alguns problemas relacionados s plataformas de portabilidade, como restries em relao real portabilidade de programas, devido as grande nmero de plataformas, e o mau aproveitamento de caractersticas de algumas arquiteturas paralelas. O padro foi desenvolvido em 1993 por vrias indstrias (Cray, Convex, Meiko, IBM, NAG, J. Watson Research Center, Intel's NX/2, Express, nCUBE's Vertex e PARMACS, etc.); universidades e laboratrios de pesquisa. Outras contribuies importantes vieram do Zipcode, Chimp, PVM, Chameleon e PICL. um padro de troca de mensagens porttil que facilita o desenvolvimento de aplicaes paralelas. Utiliza o padro da programao paralela para troca de mensagens, permite a troca explicita de mensagens entre o cluster ou em redes computadores. uma biblioteca de funes utilizvel com programas escritos em C, C++ ou Fortran. O projeto do MPI procurou utilizar as melhores facilidades de um grande nmero de sistemas de troca de mensagem existentes, ao invs de selecionar um deles e utiliza-lo como padro. A filosofia da troca de mensagens simples de entender mas difcil de ser bem utilizada. Cada fabricante tem sua prpria biblioteca, otimizada para a arquitetura de uma mquina particular: no h portabilidade, isso dificultava a difuso do uso de troca de mensagens, havia ento a necessidade de uma biblioteca genrica, que definisse um conjunto de rotinas que pudessem ser implementadas, com eficincia, em diferentes arquiteturas (portabilidade e funcionalidade). Existem trs implementaes bsicas de MPI que podem ser utilizadas pelos usurios: mpich (ANL e MSU) CHIMP (Univ. Edinburgh) LAM (Ohio Supercomputers - (cancelado!)) O que est especificado no padro Comunicao ponto-a-ponto Comunicao coletiva Suporte a agrupamento de dados Utilizao com C e Fortran MPI especifica apenas a interface, e no como ela deve ser implementada. Diferenas com o PVM A biblioteca MPI, no entanto, s possui funes para tratamento de mensagens, no oferecendo suporte para criao ou eliminao de processos como o PVM. PVM mais voltado comunicao - Rotinas de baixo nvel - Pequenas funes de cada vez. MPI mais voltado aplicao - Rotinas de alto nvel - Funes complexas. Possibilidade de transmisso e recepo em uma s chamada de sub-rotina No h a necessidade de empacotar dados (a no ser que se queira enviar dados de tipos diferentes na mesma mensagem) Objetivos do MPI Um dos objetivos do MPI oferecer possibilidade de uma implementao eficiente da comunicao: Evitando cpias de memria para memria; Permitindo superposio de comunicao e computao. Permitir implementaes em ambientes heterogneos. Supe que a interface de comunicao confivel: Falhas de comunicao devem ser tratadas pelo subsistema de comunicao da plataforma.

Funcionamento do MPI No mpich e em outras implementaes de MPI, o usurio (e no o programador!), especifica quantos processos ele quer, e onde, no incio da execuo. Isso significa que MPI, ao contrrio do PVM, no pode mudar dinamicamente o nmero de processos sendo executados. Essa uma limitao que est tratada no padro MPI 2. Infelizmente, como muitas das implementaes de MPI ainda no disparam programas diferentes, aplicaes divididas em mais de um programa podem no ser portveis. Portanto, aplicaes que utilizam MPI possuem um nico arquivo executvel. A lgica de controle deve em funo do nmero de cpias desse programa sendo executado, definir a funo de cada uma. Na prtica, isso pode ser feito com um comando do tipo: if (mestre) then executa funes do mestre else executa funes do escravo mais fcil, portanto, utilizar programas MPI que implementem o modelo SPMD. Essa no uma restrio do MPI, mas enquanto as implementaes no tiverem suporte a disparo de processos, essa tcnica deixa os programas mais portveis. Cada rotina retorna um cdigo de erro, que em C em geral um int. No Fortran exige mais um parmetro para retornar o status da chamada. Os identificadores de todas as funes do MPI, em ambas as linguagens, comeam com MPI_. Em C, os identificadores possuem letras maius./min. A biblioteca mascara os detalhes internos das operaes, e todas as que as aplicaes podem precisar so extradas atravs de handles. Handles em Fortran so do tipo integer. Em C cada handle est associado a um typedef. Vetores em C comeam e 0 enquanto que, em Fortran, comeam em 1. No MPI, as mensagens s podem ser transmitidas dentro de um comunicador. Um comunicador um conjunto de processos que conseguem enxergar um ao outro. Semelhante a idia de grupos em PVM, cada processo dentro de um comunicador identificado por um nmero, chamado rank, que varia de 0 at n-1.

Cada mensagem transmitida deve indicar o comunicador para o qual a mensagem deve ser enviada. Um programa pode pertencer a mais de um comunicador simultaneamente, e, nesse caso, ter mais de um rank. O remetente deve indicar a qual processo do comunicador a mensagem se destina. Ele faz isso definindo o rank do processo destinatrio. Quando um programa chama a funo de inicializao MPI_COMM_WORLD, ele passa a pertencer ao comunicador padro, ao qual todos os processos pertencem. Os comunicadores servem para agrupar logicamente todos os processos de acordo com sua funo e evitar que um processo mande mensagem para outro, indevidamente (como pode acontecer em PVM) Programando em MPI A primeira rotina em MPI que deve ser chamada (somente uma vez) a MPI_INIT, essa chamada possibilita biblioteca MPI fazer as inicializaes necessrias, que podem variar entre implementaes. A linguagem C aceita os seguintes parmetros: int MPI_Init(int *argc, char **argv). J em Fortran: MPI_INIT(IERRO) integer IERRO MPI_INIT(Erro): rotina que inicializa o MPI. Tm como nico parmetro, a varivel ERRO que inteiro e que associa um nmero devolvido em caso de erro de execuo. MPI_COMM_SIZE(MPI_COMM_WORLD,Nproc,Erro): rotina que devolve o nmero de processadores utilizados tendo como parmetros: MPI_COMM_WORLD: uma definio de qual biblioteca padro est sendo usado pelo MPI. Nproc: varivel inteira que associa o nmero de processadores. Erro: varivel inteira que associa um nmero devolvido em caso de erro de execuo. MPI_COMM_RANK(MPI_COMM_WORLD,MyID,Erro): rotina que devolve a identificao do processador atual utilizado, tendo como parmetros: MPI_COMM_WORLD: uma definio de qual biblioteca padro est sendo usado pelo MPI. MyID: varivel inteira que associa o nmero do processador. Esse nmero varia de 0 p-1 igual ao total de processadores menos 1. Erro: varivel inteira que associa um nmero devolvido em caso de erro de execuo. MPI_SEND(Variable,QTD,MPI_TYPE,ID,MsgType,MPI_COMM_WORLD,Erro): rotina utilizada para se enviar uma mensagem do processador atual para outro. Possui como parmetros: Variable: a mensagem a ser enviada. Aqui generalizamos com o nome VARIABLE sendo que esta varivel pode ser de diversos tipos (INTEGER, REAL, DOUBLE,CHAR,etc....) QTD: Quantidade de variveis que esto sendo enviadas. MPI_TYPE: o tipo de dado que esta sendo enviado. Pode ser de vrios tipos e deve ser compatvel com a varivel enviada. ID: a especificao de para qual processador deve ser enviado. MsgType: um rtulo usado para a identificao de qual mensagem esta sendo enviada. MPI_COMM_WORLD: uma definio de qual biblioteca padro est sendo usado pelo MPI. Erro: varivel inteira que associa um nmero devolvido em caso de erro de execuo. ID: a especificao de para qual

processador deve ser enviado. MsgType: um rtulo usado para a identificao de qual mensagem esta sendo enviada. MPI_COMM_WORLD: uma definio de qual biblioteca padro est sendo usado pelo MPI. Erro: varivel inteira que associa um nmero devolvido em caso de erro de execuo. MPI_RECV(Variable,QTD,MPI_TYPE,ID,MsgType,MPI_COMM_WORLD,Erro): rotina utilizada para receber uma mensagem por um outro processador. Possui como parmetros: Variable: a mensagem a ser enviada. Aqui generalizamos com o nome VARIABLE sendo que esta varivel pode ser de diversos tipos (INTEGER, REAL, DOUBLE,CHAR,etc....) QTD: Quantidade de variveis que esto sendo enviadas. MPI_TYPE: o tipo de dado que esta sendo enviado. Pode ser de vrios tipos e deve ser compatvel com a varivel enviada. ID: a especificao de para qual processador deve ser enviado. MsgType: um rtulo usado para a identificao de qual mensagem esta sendo enviada. MPI_COMM_WORLD: uma definio de qual biblioteca padro est sendo usado pelo MPI. Erro: varivel inteira que associa um nmero devolvido em caso de erro de execuo. ID: a especificao de para qual processador deve ser enviado. MsgType: um rtulo usado para a identificao de qual mensagem esta sendo enviada. MPI_COMM_WORLD: uma definio de qual biblioteca padro est sendo usado pelo MPI. Erro: varivel inteira que associa um nmero devolvido em caso de erro de execuo. MPI_REDUCE(SBUF, RBUF, Nproc,MPI_TYPE,OP,ID,MPI_COMM_WORLD, Erro): rotina de computao global. Neste tipo de operao coletiva, o resultado parcial de cada processo em um grupo combinado e retornado para um especfico processo, utilizando-se algum tipo de funo de operao (mximo, mnimo, soma, produto). SBUF: endereo do dado que far parte da operao de reduo (send buffer) RBUF: endereo do dado que receber o resultado da operao de reduo. MPI_FINALIZE(Erro): rotina que finaliza o MPI. Tm como nico parmetro a varivel ERRO que inteira e que associa um nmero devolvido em caso de erro de execuo. Depois que o seu programa terminar de usar o MPI, ele deve avisar a biblioteca atravs da funo MPI_FINALIZE(), isto permite ao MPI remover mensagens pendentes. Nenhuma outra funo do MPI pode ser invocada aps essa chamada. Se um processo quiser terminar todos os outros processos em um mesmo comunicador, pode executar MPI_ABORT(comm, erro). Se o comunicador for o MPI_COMM_WORLD, todo o programa para. A comunicao ponto-a-ponto exige o rank dos processos destinatrio e remetente, o MPI prov duas funes para isso: MPI_COMM_RANK(comm, rank) que retorna o rank do processo que a chamou. A segunda especifica quantos processos fazem parte do comunicador MPI_COMM_SIZE(comm, size). Essas funes so, em geral, chamadas somente uma vez, aps MPI_INIT. Todos os programas que utilizam MPI devem incluir as bibliotecas: em C mpi.h ou em Fortan mpif.h. Programa Exemplo apresentado um programa simples em MPI, para que se tenha uma idia da sua programao. O programa escrito em C (o MPI possui bibliotecas para C e Fortran) e implementa a transferncia de uma mensagem entre dois processos.
# include <mpi.h> /*Biblioteca MPI*/ main(argc, argv) int argc; char *argv[ ]; { char msg[20]; /*Mensagem a ser enviada*/ int myrank; /*Rank de um processo/ int tag = 99; /*Identificador da mensagem (tag)*/ MPI_status status; /*Varivel status, utilizada pela rotina receive( )*/ MPI_Init(&argc,&argv); /*Inicia o PVM*/ MPI_Comm_rank(PMI_COMM_WORD, &myrank); /*Define o rank do processo*/ /*O processo com rank 0 envia a mensagem, o de rank 1 a recebe*/ if (myrank == 0) { strcpy(msg, Helo Word); MPI_Send(msg, strlen(msg,strln(msg) + 1, MPI_CHAR, 1, tag, MPI_COMM_WORD); } else { MPI_Recv(msg, 20, MPI_CHAR, 0, tag, MPI_COMM_WORD, &status); printf( % \ n, msg); } MPI_Finalize( ); /*Finaliza o MPI*/ }

Este programa executa de maneira SPMD em dois processadores. So gerados dois processos identificados por ranks 0 e 1, sendo que o processo de rank = 0 envia uma mensagem para o processo de rank = 1, que a recebe. O programa utiliza a rotina send( ) padro (MPI_Send), bloqueante. Este um exemplo muito simples; porm, geralmente s em casos isolados necessita-se da utilizao das rotinas mais avanadas do MPI. Um dos objetivos do MPI ser poderoso sem abrir mo da simplicidade, mas isso nem sempre possvel no caso de aplicaes mais complexas.

11 Referncias bibliogrficas [CAR] Cardoso, Bruno. Rosa, Svio. e Fernandes, Tiago. Multicore. Disponvel em: www.ic.unicamp.br/~rodolfo/Cursos/mc722/2s2005/Trabalho/g07-multicore.pdf Acessado em 10/03/2007. [COU] G. Coulouris, J. Dollimore, T. Kindberg, Distributed Systems: Concepts and Design, Third Edition, AddisonWesley, 2001. [CRU] Cruz, Adriano O. e Silva, Gabriel P. Programao Paralela e Distribuda PVM - Curso de Informtica DCCIM / UFRJ 2004. [FOR] Fortuna, Armando de Oliveira. Introduo ao MPI ICMC USP. [INT]. Processadores Intel. Disponvel em: www.intel.com/support/pt/processors/mobile/coreduo/sb/CS-022131.htm Acessado em 28/06/2007. [MAI] Maia, Renato Dourado. Programao em Tempo Real - Fundao Educacional Montes Claros - FACIT 2008. [MON] Monticelli, Alcir J., Souza, Sergio H. G. de. e Schiozer, Denis J. Uma Introduo ao PVM - FEM UNICAMP. [MOR] Morimoto, Carlos E. Brincando de cluster - Disponvel http://www.guiadohardware.net/artigos/cluster/ [MSDN] Microsoft. Biblioteca Microsoft Developer Network Disponvel em http://msdn.microsoft.com/ptbr/library/ms123401.aspx. [PIT] Pitanga, Marcos. Supercomputadores Caseiros: Construindo Clusters com o Linux - Disponvel em http://www.clubedohardware.com.br/artigos/162, 2002. [PIT] Pitanga, Marcos. Computao em Grade Uma viso Introdutria - Disponvel em http://www.clubedohardware.com.br/artigos/124, 2004. [OLI] Oliveira, Rmulo Silva. Carissimi, Alexandre da Silva. Toscani, Simo Sirineo. Sistemas Operacionais. Instituto de Informtica da UFRGS, 2004. [SAT] Sato, Liria Matsumoto. Midorikawa, Edson Toshimi e Senger, Hermes. Introduo a Programao Paralela e Distribuda: www.lsi.usp.br./~liria/jai96.html [SEI] Seixas Filho, Constantino Semforos, eventos e timers UFMG 2005 [SIL] Silva, Gabriel P. MPI Um curso prtico - Curso de Informtica DCC-IM / UFRJ 2004.

[SOU] Souza, P.S.L.; Mquina Paralela Virtual em Ambiente Windows; ICMSC-USP; Maio/1996. [TAN] M. Van Steen, A. Tanenbaum, Distributed Systems: Principles and Paradigms, Prentice Hall, 2002. [TEC] Tecnologia HyperThreading. Disponvel em: www.clubedohardware.com.br/artigos/163 Acessado em 27/06/2007. [TOD] Torres, Dennes. Criando sistemas distribuidos com o Visual Studio 2005. Disponvel em: http://www.bufaloinfo.com.br/default.aspx. Acessado em 29/03/2010 [TOG] Torres, Gabriel e Lima, Cssio. Tecnologia Tesla da NVIDIA Disponvel em http://www.clubedohardware.com.br/artigos/1424, 2007.