Universidade Estadual Paulista

Instituto de Biocincias, Letras e Cincias Exatas

Departamento de Cincia da Computao e Estatstica

Apostila de Projeto de Sistemas Operacionais

Prof. Dr. Norian Marranghello

Outubro de 2001
norian@dcce.ibilce.unesp.br Rua Cirstvo Colombo, 2265 So Jos do Rio Preto, SP C.E.P.15054-000; Tel: +17 221 2215; Fax: +17 221 2203

ndice
ndice..................................................................................................................................... 2 Sistemas Distribudos ........................................................................................................... 4
Sistemas Centralizados.................................................................................................................5 Sistema em Rede ...........................................................................................................................7 Sistemas Distribudos ...................................................................................................................8 Sistemas Autnomos Cooperativos .............................................................................................9 Algoritmos Distribudos .............................................................................................................10

Projeto de Sistema Operacional ......................................................................................... 10

Eficincia ................................................................................................................................................ 10 Flexibilidade ........................................................................................................................................... 11 Consistncia ............................................................................................................................................ 12 Robustez ................................................................................................................................................. 12 Transparncia.......................................................................................................................................... 13

Servios ............................................................................................................................... 14 Modelos de Arquiteturas .................................................................................................... 16 Comunicao ...................................................................................................................... 18

O modelo de referncia da ISO .................................................................................................19 O modelo TCP/IP do DoD..........................................................................................................21

Aspectos de projeto ............................................................................................................. 23 Modelo Cliente/Servidor..................................................................................................... 25 Servios de Tempo .............................................................................................................. 27 Ramificaes no Fluxo de Controle de Processos ............................................................ 30 Mecanismos de Linguagem para Sincronizao............................................................... 33
Comunicao entre Processos....................................................................................................36
Passagem de Mensagens ......................................................................................................................... 37 Chamadas a Procedimentos Remotos ..................................................................................................... 40

Transaes .......................................................................................................................... 44
Protocolo de aceitao em duas fases........................................................................................44 Coordenao Distribuda ...........................................................................................................45
Por disputa .............................................................................................................................................. 45 Controlada............................................................................................................................................... 46

Algoritmos de Eleio......................................................................................................... 48 Acordo Distribudo ............................................................................................................. 49 Falhas Bizantinas ............................................................................................................... 49

Impossibilidade de Consenso .....................................................................................................51 Consenso Distribudo Aleatrio.................................................................................................51

Escalonamento de Processos.............................................................................................. 53
Modelos........................................................................................................................................53

Escalonamento Esttico..............................................................................................................54 Modelo de Precedncia...............................................................................................................55 Modelo de Comunicao ............................................................................................................57 Custo de Computao.................................................................................................................57 Custo de Comunicao ...............................................................................................................58 Escalonamento Dinmico...........................................................................................................58
Algoritmos Genticos ............................................................................................................................. 60

Compartilhamento de Memrias Distribudas ........................................................................61

Arquiteturas NUMA ............................................................................................................................... 63

Alocao, Migrao e Cpia de dados ......................................................................................65 Modelos de Consistncia de Memria.......................................................................................66 Sistemas de Memria Cache em Multiprocessadores..............................................................68 Estruturas de Memrias Cache .................................................................................................69 Protocolos de Coerncia .............................................................................................................70 Algoritmos de Gerenciamento de MCDs ..................................................................................71 Localizao de Dados .................................................................................................................72 Sistemas de Arquivos Distribudos............................................................................................73 Implementao de Sistemas de Arquivos Distribudos ...........................................................74 Compartilhamento de Arquivos................................................................................................75 Rplicas de Arquivos e Dados....................................................................................................77 Operaes de Leitura .................................................................................................................78 Operaes de Escrita ..................................................................................................................78

Bibliografia ......................................................................................................................... 79

Sistemas Distribudos
Segundo Tanenbaum (traduo, pgina 261), um sistema distribudo aquele que roda em um conjunto de mquinas sem memria compartilhada, mquinas essas que mesmo assim aparecem como nico computador para seus usurios. Por outro lado, Chow e Johnson [1 - pgina 27] definem um sistema operacional (SO) distribudo como uma integrao de servios, apresentando uma viso transparente de um sistema com vrios computadores, com controle e recursos distribudos. Este curso tratar de sistemas operacionais distribudos, cujo desenvolvimento tem sido motivado pela: - crescente necessidade de compartilhar recursos e informaes; - reduo rpida do custo de estaes de trabalho; - proliferao do uso de redes; e - maturao das tecnologias de software Inicialmente ser feita uma breve reviso de alguns conceitos importantes sobre sistemas operacionais. A seguir, sero mostradas as diferenas conceituais de quatro categorias de sistemas operacionais. Posteriormente, diversos aspectos de projeto de Sistemas operacionais distribudos sero analisados individualmente. Um sistema operacional um conjunto de programas que fazem a interface entre o hardware da mquina e seus usurios, com o objetivo de tornar seu uso mais eficiente, fcil e seguro. O hardware funciona base de sinais eltricos, os quais so trazidos para uma simbologia binria de modo a facilitar o trabalho dos projetistas dos circuitos lgicos. Esta linguagem de mquinas usada para escrever alguns programas, que executam certas funes bsicas, as quais tornam mais eficiente a manipulao do hardware. Tais funes so utilizadas pelos prprios projetistas de sistemas operacionais para criar outras funes, um pouco mais complexas, que alm de facilitar e tornar mais eficiente o trabalho de seus usurios, garantem que o acesso destes ao sistema no comprometa sua segurana, nem a dos demais usurios do sistema. As funes tratadas pelo sistema operacional so o escalonamento dos processos nos processadores, a coordenao da interao entre tais processos, o gerenciamento dos recursos do sistema, o controle de acesso a esses recursos (portanto sua proteo), a recuperao de erros e a interface com os usurios do sistema. Para suprir tais funes o sistema operacional fornece dois tipos de servios, quais sejam, servios de ncleo e os de sistema. Os servios de ncleo correspondem s funes essenciais, dependentes da arquitetura da mquina. Os servios do sistema correspondem s funes de alto nvel percebidas pelos programas de aplicao. Essas funes do sistema operacional, por um lado, visam ajudar os administradores do sistema a gerenciarem os seus recursos, por outro lado, visam apresentar aos usurios uma mquina estendida mais fcil de lidar. A nfase dos sistemas operacionais tradicionais era no aspecto administrativo, ou seja, em gerir os meios necessrios ao uso da mquina. J, os sistemas operacionais modernos enfatizam seus objetivos, isto , visam fornecer facilidades para sua utilizao. Os sistemas operacionais modernos podem ser classificados de acordo com seu grau de acoplamento em: centralizados, distribudos, em rede e autnomos. Para classific-los levam-se em considerao as trs caractersticas seguintes: 4

interoperabilidade: que a capacidade do sistema facilitar a troca de informao entre componentes heterogneos; transparncia: que a capacidade do sistema fornecer uma viso lgica nica ao usurio, independente do sistema fsico disponvel; e autonomia: que a capacidade dos elementos do sistema processarem tarefas independentemente uns dos outros, ao mesmo tempo que cooperam entre si para a soluo de um problema.

Sistemas Centralizados
Os sistemas operacionais tradicionais, utilizados tanto em arquiteturas com vrios processadores como em monoprocessadas, so centralizados. Estes sistemas so fortemente acoplados e a comunicao entre seus processos feita pelo compartilhamento de memria ou por interrupes. Nas fases iniciais, o projeto desses sistemas visavam o controle das interfaces com os usurios e do sistema de entrada e sada, atravs de interrupes e de um conjunto de acionadores de dispositivos. Frente necessidade de aumentar a eficincia do sistema de entrada e sada surgiram os conceitos de entrada e sada virtual e de spooling. Este correspondendo ao armazenamento temporrio, em disco, de operaes de entrada e sada, permitindo assim a minimizao das diferenas de velocidades de processamento entre a UCP e os perifricos; e aquele correspondendo abstrao dos dispositivos de entrada e sada de modo que o sistema operacional possa apresslos como se fossem arquivos, deixando a tarefa conversar diretamente com os dispositivos para os respectivos acionadores. Com o passar do tempo a necessidade de tratar programas grandes deu origem ao conceito de memria virtual, o que permite o tratamento de programas, que utilizem espao de endereamento maior do que o disponvel na memria real, atravs das tcnicas de paginao e segmentao. A contnua necessidade de otimizar o uso dos sistemas deu origem a vrios outros conceitos, que possibilitaram o acesso de diversos usurios simultaneamente. Tais conceitos incluem a multi-programao, o compartilhamento de tempo, o necessrio escalonamento de processos, o controle de concorrncia, o controle de acesso aos arquivos do sistema e a proteo aos arquivos compartilhados. Associado ao acesso de vrios usurios est a necessidade de tratar diversas tarefas o que originou uma srie de tcnicas para viabilizar seu processamento concorrente, incluindo a sincronizao de processos, a recuperao do sistema aps bloqueios fatais e a comunicao entre os processos concorrentes. O sistema operacional um sistema grande, podendo chegar a milhes de linhas de cdigo. Este programa deve ser estruturado em mdulos divididos vertical e horizontalmente. Cada mdulo pode ser entendido como um conjunto de instrues necessrias para executar determinado servio do sistema. Os mdulos so agrupados (horizontalmente) para formar componentes funcionais. Por outro lado, eles so agrupados (verticalmente) em vrias camadas, estrutura na qual s permitida a interao entre mdulos de camadas adjacentes. Todos os recursos do sistema inclusive arquivos e processos, podem ser abstrados como objetos de dados sendo sua representao fsica escondida por uma estrutura de dados abstrata. O modelo de orientao a objetos possibilita uma uniformidade dos mecanismos de acesso e proteo de mdulos do sistema. Devido, a esta uniformidade sua alterao mais fcil, o que melhora a portabilidade do sistema. Contudo, os sistemas operacionais tradicionais so do tipo monoltico, nos quais no h particionamento do ncleo, fora a modularidade normal do cdigo. Nos sistema monolticos os servios do sistema e do ncleo fazem parte de um mesmo programa. Todavia, em sistemas operacionais modernos a preocupao com a eficincia e a portabilidade maior. O ncleo deve ser mnimo, restrito apenas a servios dependentes do hardware ou queles cujo oferecimento fora do ncleo seja muito caro ou difcil. Dentre tais servios esto os ligados ao 5

tratamento de interrupes, ao acionamento de dispositivos e algumas primitivas bsicas para a sincronizao e a comunicao entre processos. Mdulos estes que, por serem dependentes do hardware, no podem ser transportados de uma mquina a outra sem serem recodificados. Servios que tipicamente so includos em um ncleo mnimo so: - mecanismos para a comunicao entre processos; - algumas funes bsicas para o gerenciamento de memria; - algumas primitivas para o gerenciamento e o escalonamento de processos em baixo nvel; e - primitivas para o tratamento de E/S em baixo nvel. As funes de um sistema operacional podem ser divididas em quatro categorias, conforme os recursos que gerenciam; so elas: processos e processadores, memria, entrada e sada, e dados ou arquivos. As funes para o gerenciamento de processos e processadores tem por finalidade bsica definir que processos devem ser executados em cada processador do sistema e quando a execuo deve iniciar. Elas so chamadas, respectivamente, de alocao e escalonamento. Definir quais processos devem ser executados, quando os recursos do sistema estiverem disponveis e/ou certas condies forem atingidas, tem por objetivos minimizar o tempo de resposta dos processos e maximizar a vazo do sistema. Esta definio pode ser feita de forma esttica levando-se em considerao as relaes de precedncia entre os processos, que indicam como os processos devem ser sincronizados. A definio pode tambm ser feita de forma dinmica considerando-se as relaes de dependncia entre processos, que indicam as interaes entre elas. Para permitir a coexistncia de vrios usurios e diversas tarefas no sistema, outras funes so necessrias. H as que viabilizam a multiprogramao, responsveis pela multiplexao espacial da memria onde residem os processos. H as que viabilizam o compartilhamento do tempo, responsveis pela multiplexao temporal do processador onde os processos so executados. A interao entre os processos necessita ainda de mecanismos para as suas comunicao e sincronizao, o que pode ser obtido atravs da excluso mtua, por exemplo. A excluso mtua pode ser obtida fazendo-se chamadas ao sistema e acionando operaes sobre variveis especiais, chamadas semforos, capazes de bloquear processos interativos, permitindo coordenar seu funcionamento. Uma forma muito usual de tratar a comunicao entre processos por meio do compartilhamento de reas de memria. Todavia, processos so geralmente assncronos e, via de regra, no compartilham espao de endereamento. Consequentemente, a alternativa natural a troca de mensagens, o que pressupe algum tipo de sincronizao. As funes para o gerenciamento de entrada e sada geralmente so fornecidas pelo sistema operacional via uma interface genrica, deixando para os fabricantes de perifricos o projeto dos acionadores e controladores desses dispositivos. Portanto, o sistema operacional enxerga dispositivos virtuais (arquivos lgicos) sobre os quais ele pode fazer operaes apenas de escrita, como no caso das impressoras, apenas de leitura, como no caso dos teclados, ou de leitura e escrita, como no caso dos discos. As funes para o gerenciamento de memria respondem pela alocao e desalocao de memria para mapear o espao lgico de endereamento dos programas na memria fsica. Para tanto criado um espao de endereamento virtual o qual permite que o tamanho do programa, mais seus dados e a pilha, seja maior que a memria fsica disponvel. Isto conseguido pela diviso do espao de endereamento lgico em pginas ou segmentos e o mapeamento destas entidades (pginas/segmentos) em blocos da memria fsica. Este mecanismo serve tambm para resolver discrepncias entre memria em disco (geralmente de grande capacidade, mas lenta) e a principal (usualmente de capacidade reduzida, mas rpida). Como o compartilhamento de memria uma

soluo relativamente fcil para sincronizao entre processos, muitos algoritmos foram desenvolvidos para este fim. Para aproveitar tais algoritmos vrios autores procuram simular a existncia de uma memria compartilhada em sistemas distribudos, o que levanta questes como a consistncia dos dados compartilhados e o desempenho do sistema assim estruturado. As funes para o gerenciamento de arquivos tm dois enfoques fundamentais, quais sejam, o acesso e o compartilhamento. De maneira genrica qualquer computao pode ser vista como processos operando sobre arquivos. Estes so entidades lgicas que agrupam dados e devem ser estruturadas e implementadas em algum dispositivo antes de serem manipuladas. As funes para manipulao de arquivos devem implementar mecanismos que garantam o acesso aos dados contidos no arquivo apenas a usurios autorizados protegendo-os contra uso indevido. Mecanismos para disciplinar o acesso garantem a integridade dos dados contidos nos arquivos so necessrios para a sua segurana. Mecanismos de sincronizao so necessrios para controlar o acesso correspondente ao contedo dos arquivos, permitindo o compartilhamento dos respectivos dados.

Sistema em Rede
um multicomputador fracamente acoplado no qual no existe qualquer tipo de controle direto de uma mquina sobre as outras e no qual a comunicao entre as outras mquinas bem mais lenta que dentro de uma dada mquina. O objetivo principal de sistemas em rede possibilitar o compartilhamento de seus recursos. Para tanto, as mquinas que compem o sistema trocam informaes via um canal de comunicao, que as interconecta. A principal caracterstica explorada nestes sistemas a sua interoperabilidade, para o que so necessrios alguns mecanismos de suporte, tais como: protocolos de comunicao devidamente padronizados e interfaces comuns para sistemas de arquivos e bases de dados. Nos sistemas em rede a troca de informaes dividida em nveis, por exemplo: no nvel de hardware trocam-se sinais fsicos via a rede de comunicao, no de sistema operacional tem-se os servios de transporte de dados que trocam grupos de bits entre si, e no nvel dos usurios so trocadas as mensagens atravs de processos de alto nvel que implementam a comunicao fim-a-fim orientada a aplicaes. Os principais modelos em camada, que sero estudados mais adiante, so o RM-OSI da ISO e o TCP/IP do DoD. Na origem dos sistemas operacionais em rede temos o conceito de sistemas abertos, que um sistema preparado para se comunicar com qualquer outro sistema aberto utilizando regras padro que governam o formato, o contedo e o significado das mensagens enviadas ou recebidas. Neste sentido, os sistemas operacionais em rede so extenses dos sistemas centralizados que facilitam o compartilhamento de recursos implementando servios de transporte para interfacear os processos aplicativos e a rede de comunicao. A maioria dos sistemas operacionais em rede usam interfaces de aplicao de alto nvel, tais como soquetes ou chamadas a procedimentos remotos, para que o servio de transporte possa sustentar a comunicao entre sistemas em domnios de rede diversos. Algumas classes de aplicaes de rede so: - login remoto: a capacidade do sistema permitir que um usurio use uma mquina como terminal de outra conectada rede, para poder utilizar o processador e outros recursos associados mquina hospedeira. Para poder fornecer este servio a mquina hospedeira deve ser capaz de compreender pacotes de dados vindos do teclado da mquina remota e de enviar pacotes de dados compreensveis para o seu monitor. Esta comunicao requer um protocolo de redes, sendo o mais comum o telnet. - transferncia de arquivos: a capacidade do sistema transferir dados estruturados na forma de arquivos, juntamente com seus atributos, entre mquinas do sistema. Como parte da operao de transferncia de arquivos h a necessidade do intercmbio e da 7

validao de informaes, tais como: atributos do arquivo, formato e fluxo dos dados e, controle de acesso ao arquivo. Este servio suportado por protocolos de transferncia de arquivos, como o ftp. mensagens: a capacidade do sistema transferir mensagens, incluindo documentos e arquivos, sem a necessidade de estabelecer uma conexo em tempo real. Ao contrrio da transferncia de arquivos, as mensagens so empacotadas e somente umas poucas informaes de controle so consideradas. Neste caso h servios para atender transaes comerciais em formatos especficos entre computadores com sistemas operacionais diversos (EDI - eletronic data interchange) e para troca de mensagens entre usurios de rede (correio eletrnico) que se servem de padres como o X.400 do CCITT e o SMTP do DoD. pesquisas em redes: um servio que permite a busca e a apresentao de documentos distribudos entre mquinas participantes da rede. O modelo de varredura mais comum o cliente/servidor, no qual um programa cliente busca objetos em sistemas servidores de arquivos remotos. O programa cliente mais popular o netscape. O sistema mais usado o www (world wide web) que um modelo de dados para a ligao de documentos hipermdia usando apontadores (URL - universal resource locators). A comunicao principal com o servidor se d atravs do hyper text transport protocol (http); em algumas ocasies so usados tambm o telnet e o ftp. Os documentos so tipicamente escritos usando-se a hyper text markup language (html). Execuo remota: a capacidade do sistema enviar mensagens para pedir a execuo de programas em mquinas remotas. A execuo remota se d, em geral, atravs da interpretao de scripts e no pela compilao de programas, devido a dependncia da arquitetura da mquina. Este servio costuma ser restrito a aplicaes nas quais a segurana do sistema no seja comprometida pela violao de protees. Aplicaes deste servio incluem o uso de linguagens intermedirias para a transmisso de imagens compactadas. Talvez uma aplicao mais popular atualmente seja JAVA, que uma linguagem orientada a objetos, derivada da C++, incorporando protocolos tais como o http e o ftp. Ela produz instrues compactas e independentes de mquinas, os applets, que so objetos que tanto podem conter URL (para apontarem/ativarem outros applets) como podem ser apontados por URL.

Sistemas Distribudos
Os sistemas distribudos representam um passo alm daqueles em rede, pois, alm de possibilitarem o compartilhamento de recursos eles viabilizam a coordenao de atividades distribudas. Os recursos fsicos costumam ser distribudos geograficamente dentro das empresas, entre outras razes por questes como eficincia no uso de certos recursos e segurana do sistema como um todo. Por outro lado, os recursos lgicos esto, por sua natureza, dispersos na empresa, pois representam as informaes que as pessoas possuem. A funo de um sistema operacional distribudo gerenciar as atividades e os recursos distribudos, possibilitando um processamento descentralizado e melhorando o desempenho do sistema. A principal diferena de um sistema distribudo para um sistema em rede sua caracterstica de transparncia, isto , enquanto num sistema em rede o usurio deve manipular operaes remotas explicitamente, o usurio de um sistema distribudo tem a impresso de estar trabalhando em um sistema centralizado de bom desempenho. A transparncia pode ser notada em vrios aspectos, alguns dos quais so exemplificados a seguir.

transparncia de concorrncia quando os usurios no tm conscincia do compartilhamento de tempo com outros; transparncia de localizao de programas quando o mapeamento do programa em memrias e processadores escondido do usurio; transparncia de acesso a arquivos quando os arquivos podem ser armazenados em qualquer lugar do sistema e por ele movido sempre que conveniente sendo o acesso ao arquivo feito via um caminho lgico para o usurio; e transparncia de desempenho quando os processos podem ser executados em qualquer processador e movidos dentro do sistema de acordo com suas necessidades, sem que o usurio perceba diferena de desempenho significativa.

Para atingir estes e outros aspectos, um sistema digital deve incluir mecanismos para tratar da coordenao das atividades de processos distribudos, gerenciando adequadamente o uso dos recursos dispersos pelo sistema, atravs da implementao de algoritmos distribudos, como ser visto mais adiante no curso.

Sistemas Autnomos Cooperativos

Estes sistemas mantm as noes de transparncia e interoperabilidade existentes nos sistemas distribudos, mas para permitir a existncia de processos autnomos capazes de exportar e solicitar servios, interagindo independentemente, abolem a necessidade de passar a impresso da existncia de um nico usurio no sistema. Ento, grupos de atividades podem resultar em servios de nvel mais elevado, atravs de composio de servios mais simples. Desta forma, pode-se formar qualquer sistema de software integrando vrios servios por meio de certas estruturas pr-estabelecidas. Um exemplo interessante de um sistema autnomo cooperativo pode ser emprestado da robtica evolutiva. Neste caso, um conjunto de robs usam tcnicas de algoritmos genticos para interagirem e criarem solues para problemas propostos. Os processos devem ser distribudos pelos robs, autnomos e assncronos. Trs classes de servios so implementadas em cada rob do sistema, quais sejam: auto-avaliao, seleo e reproduo. Auto avaliao consiste em mtricas para medida de desempenho do algoritmo executado no respectivo rob. Estas mtricas devem ser baseadas em parmetros que no dependem de agentes ou observadores externos. Por exemplo, deve medir a energia gasta para executar certa tarefa, o que pode ser materializado pelo tempo necessrio ou pelo nmero de operaes necessrias. A seleo visa reconhecer indivduos mais bem ajustados, para executar a tarefa em questo, os quais fornecero genes (isto , assumiro o papel de pais) para os menos ajustados. Estes, por sua vez, recebero os genes e se modificaro gerando novos entes (isto , filhos). No processo de reproduo no h reestruturao fsica dos robs, mas somente a troca de cdigo do programa de controle. Para colocar em prtica estes procedimentos cada um dos robs determina o seu nvel virtual de energia, ou seja, seu desempenho na execuo da tarefa a ele atribuda. Ento irradia sua informao gentica em uma freqncia proporcional ao seu nvel de energia. Esta informao gentica contm um gene escolhido aleatoriamente do seu genoma e que passou por um processo de mutao. Os demais robs podem ou no aceitar o gene irradiado. Os que aceitarem sobrescrevem seu gene correspondente com o gene recebido, caso contrrio o gene recebido simplesmente descartado. A receptividade de cada rob do sistema inversamente proporcional ao seu nvel de energia.

Robs com nvel de energia maior (melhor desempenho) tendem a disseminar mais seus genes e resistem mais a tentativas de reproduo dos outros. Todavia, este processo probabilstico e no garante que robs mais ajustados transfiram todos os seus genes para os menos ajustados.

Algoritmos Distribudos
O principal objetivo do desenvolvimento de algoritmos distribudos fornecer mecanismos que possibilitem contornar a falta de informao global sobre o estado de um sistema distribudo. Cada processador de um sistema distribudo possui o seu relgio interno, que no sincronizado com os relgios dos demais processadores, causando problemas de interao entre eles. Mesmo que se use um relgio global, centralizado, a propagao desta informao para os processadores do sistema est sujeita a atrasos diversos. Portanto, a tarefa de ordenar os eventos no sistema no trivial. Alm dos atrasos na comunicao, h falhas que podem tornar certas fontes de informao inexistentes, ou no confiveis. O sistema necessita de algoritmos capazes de identificar e contornar todos os tipos de falhas, evitando situaes que levem inoperncia do sistema ou, o que mais grave, sua operao defectiva. A arquitetura do sistema influi na implementao desses algoritmos. A topologia da rede (se completa, regular, fixa ou irregular, etc.) e o tipo de comunicao (se ponto-a-ponto ou multiponto) influem na sua implementao. Do ponto de vista do software a reproduo de cpias dos dados introduz o problema da coerncia e da consistncia dessas cpias, que tambm influi no algoritmo distribudo.

Projeto de Sistema Operacional

Ao projetar um sistema operacional distribudo deseja-se que a execuo de aplicativos no sistema resultante tenha um retorno melhor do que em sistemas monoprocessados centralizados, que o sistema distribudo seja capaz de se adaptar a variaes tecnolgicas e a necessidades de seus usurios, que seu comportamento seja, uniforme e previsvel, que ele seja, confivel, tolerante a falhas e devidamente protegido contra aes nocivas, e que os detalhes de sua implementao sejam escondidos do usurio final. Desta forma, pode-se dizer que os projetistas de sistemas operacionais distribudos tm cinco objetivos principais, como explicados a seguir.

Eficincia
A resposta de um sistema operacional distribudo, ao executar um aplicativo, deve ser melhor que a resposta de um sistema centralizado, ou no seria razovel investir em um sistema mais caro e complexo, cujo desempenho fosse inferior. O desempenho de um sistema operacional distribudo pode ser medido por diversos parmetros, tais como: tempo de resposta do sistema, sua vazo (o nmero de trabalhos executados por unidade de tempo), a taxa de uso do sistema (seus processadores) e de seus recursos. No caso de sistemas distribudos a questo da eficincia mais complexa que nos sistemas centralizados, em especial, devido aos atrasos na comunicao. Em sistemas distribudos geograficamente o tempo para a troca de mensagens pode superar o limiar dos segundos. Entretanto, mesmo em sistemas fisicamente prximos, no possvel eliminar os atrasos na propagao dos dados. Estes atrasos podem ser agravados por eventuais sobrecargas dos protocolos de comunicao e pela distribuio de carga no sistema.

10

O tempo gasto na propagao dos dados (na troca de mensagens) depende fortemente do protocolo de comunicao utilizado, motivo pelo qual ele deve ser bem projetado, com base em primitivas de comunicao (tanto da linguagem quanto do sistema operacional) eficientes. O balanceamento de carga deve ser cuidadosamente calculado para se evitar gargalos e congestionamentos no sistema de comunicao. Sempre que possvel deve-se cuidar para estruturar os processos distribudos para que haja uma sobreposio de cmputos e comunicao no nvel das aplicaes visando melhorar a eficincia do sistema. A granulosidade das tarefas concorre para tal balanceamento. Processos com muitas tarefas e processamento interno curto, ditos de granulosidade fina, requerem muita comunicao. Processos com tarefas relativamente grandes, que requerem bastante processamento interno, so ditos de granulosidade grossa, e requerem pouca comunicao. Portanto, quanto mais fina a granulosidade dos processos, menores as tarefas. Com tarefas menores torna-se mais fcil a distribuio de carga entre os processadores. Quanto mais bem distribuda a carga de processamento, melhor a taxa de uso do sistema e de seus recursos. Desta forma, pode-se dizer que quanto mais fina a granulosidade dos processos, melhor o desempenho do sistema. Paradoxalmente, quanto mais processos distribudos no sistema, maior o nmero de mensagens trocadas entre eles. Quanto maior o fluxo de mensagens, maior o tempo gasto com comunicao no sistema. Conseqentemente, menor a vazo e maior o tempo que o sistema requer para produzir as respostas desejadas. Por conseguinte podese inferir que quanto mais fina a granulosidade dos processos, pior o desempenho do sistema. O resultado disto que a granulosidade dos processos deve ser ajustada de forma a tornar o sistema o mais eficiente possvel. Outra questo que afeta a eficincia de um sistema operacional distribudo sua tolerncia a falhas. desejvel que um sistema operacional distribudo mantenha todos os processos em execuo, ainda que algum(s) de seus componentes falhem. Para tanto, quando uma tarefa atribuda a um processador ele deve comunicar isto a outro(s) processador(es) do sistema para que, caso o processador principal falhe, o outro possa continuar a execuo da tarefa. Entretanto, isto envolve comunicao sem utilidade para a computao, o que reduz o desempenho geral do sistema.

Flexibilidade
Um sistema operacional distribudo deve ser capaz de evoluir e migar, para se adaptar a variaes tecnolgicas. Deve ser possvel adicionar servios inexistentes e remover servios obsoletos, preferencialmente sem a necessidade de recompilar e reinstalar o sistema, ou seja, o sistema deve ser modular e escalonvel. Conforme mudam as plataformas de trabalho (o hardware) desejvel que se possa migrar o sistema a um baixo custo, isto , re-escrevendo e recompilando o menor nmero possvel de rotinas. Para atingir esta portabilidade o ncleo do sistema deve ser o menor possvel. Alm disto, o sistema deve ter interfaces comuns para suas bases de dados e seu sistema de arquivos, bem como deve fazer uso de protocolos de comunicao padronizados, resultando em um sistema capaz de administrar um conjunto heterogneo de mquinas. As quatro propriedades recm discutidas, quais sejam, escalabilidade, modularidade, portabilidade e interoperabilidade so de crucial importncia para garantir a capacidade de adaptao do sistema. Apesar dos sistemas operacionais com ncleo monoltico reinarem absolutos, suas caractersticas no favorecem ao requisito de flexibilidade. Estes sistemas so compostos por um sistema operacional centralizado, ao qual, so acrescidas funes para operao em rede e integrados servios para operao remota. Os principais exemplos so os sistemas operacionais distribudos derivados do UNIX. Por isto, a maioria dos sistemas operacionais distribudos projetados desde o incio, sem utilizar partes de sistemas pr-existentes, adota o modelo de microncleo, j que este, por no fazer quase 11

nada, mais flexvel. Todos os servios prestados pelo ncleo de um sistema operacional microncleo est l por ser muito difcil ou muito caro prest-lo fora do ncleo. Os sistemas microncleo fornecem, fundamentalmente, quatro categorias de servios, quais sejam: - mecanismos de comunicao de processos - mnimo de funes para gerncia de memria - mnimo de funes para gerncia de processos e escalonamento; e - funes de entrada e sada de baixo nvel. As demais funes do sistema so fornecidas fora do ncleo, atravs de troca de mensagens com este. Entre estas funes encontram-se aquelas para gerncia completa de processos, as de manipulao de chamadas ao sistema, e os sistemas de arquivos e de diretrios. Como praticamente todos os servios so fornecidos a partir de processos clientes em nvel de usurio, a alterao ou a ampliao de servios no implica a parada do sistema para a carga de um novo ncleo. Foi mostrado que mesmo a aparente vantagem que teriam os sistemas monolticos, qual seja, a de apresentar um melhor desempenho por no trabalhar a base de trocas de mensagens, no existe.

Consistncia
A operao de um sistema operacional distribudo envolve vrias mquinas, muitas vezes com caractersticas heterogneas, o que torna a interao entre os mdulos do sistema por vezes, bastante complexa. Do ponto de vista do usurio, um sistema consistente deve permitir um uso uniforme e ter um comportamento previsvel, apesar dessas possveis caractersticas heterogneas. Alm disto, para garantir uma boa eficincia no uso do sistema, freqentemente necessrio particionar os dados e fazer vrias cpias deles. Isto requer mecanismos que viabilizem o controle de uso das diversas cpias, de modo a mant-las sempre idnticas. A inexistncia de informao sobre o estado global do sistema, bem como a ausncia de um sincronismo geral, requer mecanismos especiais para o controle de concorrncia, de forma a manter a integridade do sistema. Outra possvel fonte de inconsistncia no sistema a possibilidade de falhas de seus componentes. O principal problema, neste caso, a dificuldade, quando no a impossibilidade, de identificao da falha. Os trs problemas mais comuns so: defeito em uma mquina, comprometimento de uma conexo e perda de uma mensagem. Exemplo (do Silberschatz): Sejam duas mquinas A e B, diretamente conectadas. Periodicamente elas enviam, uma outra, uma mensagem x, indicando que esto ativas. Se, aps um certo perodo, A no recebe a mensagem x de B, ela sabe que ocorreu algo, mas no sabe o que. Se enviar uma mensagem y para B, pela mesma conexo, e no receber resposta, continuar sem saber qual o erro. (se receber, provavelmente a mensagem x anterior havia se perdido). Se enviar a mensagem y por uma conexo alternativa e no receber resposta, novamente no tem como saber o que ocorreu. (se receber, provavelmente a conexo usual est com problemas). De qualquer forma so necessrios procedimentos especficos para, adequadamente, reconhecer a falha, tratar os processos de forma a manter o sistema consistente e posteriormente recuperar o estado do sistema anterior ocorrncia da falha.

Robustez
Para ser robusto um sistema operacional distribudo deve estar disponvel a maior parte do tempo, sempre apresentando dados confiveis. Na teoria, uma das grandes vantagens de um sistema operacional distribudo sua maior disponibilidade, geralmente resultante da redundncia de seus componentes. Se um processador se mantm operante em 98% do tempo, um sistema com 4

12

processadores idnticos a este teria uma probabilidade de falhas de (0,02)4 = 24 x (10-2)4 = 1,6 x 10-7 ~ 0,00002%, o que corresponde a uma disponibilidade em 99,99998% do tempo. Em outras palavras, se o monoprocessador falha uma hora para cada 50 horas de funcionamento, o quadriprocessador falharia uma hora para cada cinco mil horas de funcionamento, ou seja, estaria cem vezes mais disponvel. Evidentemente, estes nmeros so fictcios, apenas ilustrativos, para se ter uma idia da possibilidade de uma maior disponibilidade de sistemas distribudos, em relao a um monoprocessador. Esta maior disponibilidade s conseguida s custas de redundncia, como j foi dito, o que, por sua vez, aumenta o risco de inconsistncias no sistema. Falhas em canais de comunicao, em ns de processamento e perdas de mensagens so freqentes em um sistema operacional distribudo. A robustez do sistema do ponto de vista de tolerncia a falhas (sua confiabilidade) est vinculada sua capacidade de reinicializao, em um estado no qual sua integridade seja preservada e seu desempenho seja pouco degradado. Se uma mquina falha, o sistema deve: - tirar esta mquina de operao; - transferir as tarefas que eram realizadas por ela para outra mquina; - reconfigurar o sistema sem a mquina falha; e - re-integrar a mquina ao sistema, aps seu reparo. Tudo sem que os usurios percebam mais que uma, possivelmente pequena, variao no desempenho geral do sistema. Mesmo sem falhas explcitas, um sistema robusto deve poder tratar situaes especiais e erros, tais como, mudanas na sua topologia, longos atrasos em mensagens ou a impossibilidade de localizar um servidor. Em outras palavras, deve ser capaz de controlar o acesso aos elementos do sistema. Finalmente, a robustez de um sistema tambm diz respeito aos mecanismos de proteo existentes, isto , deve poder garantir a segurana das informaes nele contidas, resguardando sua integridade, bem como a confidencialidade dos dados dos usurios do sistema.

Transparncia
Segundo Leslie Lamport: um sistema distribudo aquele no qual eu no posso fazer meu trabalho, pois, uma mquina que eu no conheo, no sei onde est e sobre a qual nunca ouvi falar, encontra-se fora do ar. Para evitar este tipo de reao, os projetistas de sistemas operacionais distribudos enganam a todos, fazendo com que um conjunto de mquinas seja visto pelos usurios como se fosse um sistema nico, de tempo compartilhado. Neste contexto, pode-se dizer que transparncia de um sistema operacional distribudo sua capacidade de, por assim dizer, esconder dos usurios detalhes da implementao do sistema, em particular aqueles mais complexos (dependentes da mquina), na medida do possvel apresentando aos usurios um modelo lgico da mquina como eles gostariam de operar e no como ela realmente. Portanto, atravs do uso do conceito de transparncia deve-se apresentar ao usurio o sistema mais simples possvel sem, contudo, comprometer sua eficincia. A idia de propiciar ao usurio um sistema lgico mais amistoso que o sistema fsico, minimizando a necessidade dos usurios tomarem cincia do sistema fsico, anloga aos conceitos de virtualidade em sistemas convencionais e de abstrao em linguagens de programao. Na pgina 30 do Chow & Johnson h definies de 10 aspectos de transparncia, transcritos a seguir: 13

Access transparency refers to the ability to access both local and remote system objects in a uniform way. The physical separation of system objects is concealed from the user. Location transparency means that users have no awareness of object locations. Objects are mapped and referred to by logical names. This is sometimes called name transparency. Migration transparency is an added property of location transparency where an object is not only referred to by its logical name but can also be moved to a different physical location without changing the name. Migration transparency is also called location independence. Concurrency transparency allows the sharing of objects without interference. It is similar to the time-sharing concept in a broader sense. Replication transparency exhibits consistency of multiple instances (or partitioning) of files and data. It is closely related to currency transparency but is treated separately since files and data are special objects. Parallelism transparency permits parallel activities without users knowing how. Where, and when these activities are carried out by the systems. The parallelism might not be explicitly specified by the users. Failure transparency provides fault tolerance such that failures in the system can be transformed into graceful system performance degradation rather than disruptions, and damage to the users is minimized. Performance transparency attempts to achieve a consistent and predictable (not necessary equal) performance level even with changes of the system structure or load distribution. In addition, the users should not experience excessive delays or variations in remote operations. Size transparency is related to modularity and scalability. It allows incremental growth of a system without the users awareness. The size of the system has no effect on the users perception of the system. Revision transparency refers to the vertical growth of system as opposed to the horizontal growth in system size. Software revisions of the system are not visible to users. Flexibilidade Acesso Localizao Migrao Tamanho Reviso Consistncia Robustez Falha Replicao Tamanho Reviso

Objetivos do sistema Eficincia operacional distribudo Concorrncia Paralelismo Desempenho

Transparncias

Acesso Replicao Desempenho

Servios
Um sistema operacional um provedor de servios. Servios Primitivos: servios fundamentais, os quais devem ser implementados no ncleo. - comunicao: primitivas send/receive (passagem de mensagens) - sincronizao: semntica de comunicao ou servidor de sincronizao. - servidor de processos: criao, eliminao e rastreamento de processos, alocando recursos tais como memria e tempo. Os servidores de processos interagem via primitivas de sincronizao e comunicao para garantir a transparncia do sistema.

14

Servios de Sistema: servios que podem ser implementados em qualquer lugar do sistema, mas que ainda desempenham funes bsica da operao do sistema. - Servidor de nomes: mapeamento de nomes lgicos em endereos fsicos. Relacionandoos com usurios, processos e mquinas. - Servidor de diretrios: relacionado com arquivos e portas de comunicao. - Servidor de rede: traduz e seleciona caminhos e faz roteamento da informao. - Servidor de tempo: relgios lgicos ou fsicos, necessrio para ordenao dos eventos. - Servidores de arquivos e de impresso. Servios de Valor Agregado: so servios no essenciais na implementao de um sistema distribudo, mas que so teis no suporte a aplicaes distribudas. - servidor de grupos - servidor de web

15

Modelos de Arquiteturas
De forma abstrata os modelos de arquitetura de sistemas distribudos podem ser definidos com base em trs entidades que so fundamentais para o seu funcionamento, quais sejam: - Arquivos, que so todos os conjuntos de dados que podem sofrer manipulao dentro do sistema. - Processos, que so todos programas em execuo, os quais so responsveis pela mudana de estado do sistema. - Portas, que so os caminhos disponveis para a comunicao de dados entre os diversos processos do sistema. Os arquivos e os processos residem em estaes de trabalho e trocam informaes atravs de uma rede de comunicao. A forma como as estaes de trabalho e a rede de comunicao so estruturadas define a arquitetura do sistema distribudo. Todavia, o usurio no se preocupa com o sistema fsico propriamente dito, salvo com seu custo, com a aparncia de alguns de seus componentes e com o desempenho geral do sistema, ainda que este nem sempre seja determinado pelo seu hardware. De qualquer forma, tem-se processos no sistema que utilizam servios fornecidos por outros processos. Dependendo de especificidades geogrficas ou caractersticas de desempenho necessrias, algumas estaes de trabalho do sistema podem ser dedicadas prestao de certos servios especiais. As demais estaes podem servir preferencialmente para processamento local, como um computador de uso exclusivo para determinado usurio, e ocasionalmente interagir, via malha de comunicao, com as demais estaes que compem o sistema distribudo. H tambm o caso de estaes sem disco, que servem apenas como terminais de servidores remotos e que dependem em tudo dos servios prestados pela rede, inclusive para inicializao (boot). Este modelo chamado de estao-servidor (wokstation-server) e pode ser esquematizado como apresentado na Figura 1. E s t a e s S e r v i d o r a

Estaes

Portas

de

Servidores dedicados

Figura 1 Modelo Estao-Servidor O caso do modelo estao-servidor apresenta uma srie de vantagens, como a possibilidade de realizar ao menos parte do processamento localmente. Desta forma, o volume de comunicao gerado no sistema relativamente pequeno e o dimensionamento da malha de comunicao pode ser relaxado. Conseqentemente, o custo do sistema reduzido neste quesito. Por outro lado, o uso 16

de processamento localizado faz com que a maioria das estaes estejam ociosas ao longo do tempo. Uma soluo para este problema concentrar todo o poder de processamento do sistema e deixar os usurios apenas com terminais, cuja inteligncia se restrinja ao hardware/software necessrios ao funcionamento eficiente do terminal de vdeo e da interface com a rede de comunicao. Neste caso, todo o restante do processamento fornecido por um conjunto de processadores com base na demanda real dos usurios do sistema. Este modelo dito poo de processadores (processor-pool) e pode ser esquematizado como mostrado na Figura 2.

Terminais

Portas

de

Servidores dedicados

Poo de processadore

Figura 2 Modelo Poo de Processadores

Entretanto, se por um lado a utilizao de um reservatrio com processadores, no qual realizado todo o processamento do sistema, otimiza o uso dos processadores, por outro lado, aumenta consideravelmente a sobrecarga na malha de comunicao. Resultados gerais mais adequados talvez possam ser obtidos por intermdio de um modelo hbrido, no qual h estaes de trabalho com capacidade de processamento local as quais, formam um reservatrio de processamento distribudo geograficamente. Os processos sendo executados em qualquer dessas estaes podem migrar para outras estaes que estejam ociosas ou com carga de trabalho menor. Esta migrao deve ser controlada por alguma estratgia de compartilhamento de carga pr-definida para o sistema.

17

Comunicao
Como o desempenho de um sistema distribudo est diretamente ligado possibilidade de migrao dos dados, sua rede de comunicao tem papel muito importante. Esta rede engloba elementos fsicos utilizados na interconexo dos equipamentos e protocolos para disciplinar a comunicao entre os processadores. A Comunicao pode ser feita ponto-a-ponto, quando se estabelece uma ligao direta entre um par de processadores, ou multi-ponto, quando um conjunto de processadores interligado atravs de um barramento ou chaves eletrnicas. Os barramentos so mais baratos, mas permitem apenas o compartilhamento no tempo. J, as chaves, embora formem um sistema mais caro e complexo, possibilitam no somente a multiplexao no tempo como tambm no espao. As redes de comunicao locais so restritas ao mbito de empresas e geralmente tm um raio de abrangncia de alguns poucos quilmetros. Estas redes normalmente utilizam a interconexo por algum tipo de barramento e fundamentam sua comunicao em protocolos, como o padro 802.X do IEEE, como o caso das redes Ethernet, token bus, token ring, FDDI (fiber distributed data interface) e DQDB (distributed queue dual buses). Por outro lado, as redes dos servios pblicos de comunicao utilizam a ligao por chaves de barramentos cruzados ou de mltiplos estgios. Estas redes, incluem o ISDN (integrated services digital network), o SMDS (switched multimegabit data service) e o ATM (asynchronous transfer mode). O roteamento que no caso anterior feito pela anlise das mensagens que circulam no barramento, neste caso feito pela programao das chaves que compem a rede. A comunicao em sistemas distribudos se d em camadas, buscando propiciar a comunicao entre entidades de um mesmo nvel (peer-to-peer). Por exemplo, usurios do sistema precisam trocar mensagens para se comunicar e devem ter a impresso de estarem falando diretamente um com o outro. Entretanto, como a distncia no permite eles fazem uso do sistema. Para tanto, sem que o usurio perceba, o servio do sistema que o atende passa a mensagem desejada para uma mquina hospedeira, a qual estabelecer um canal de comunicao com uma mquina remota, servidora do interlocutor, a qual, por sua vez, providenciar para que a mensagem chegue ao seu destino. Contudo, as mquinas tambm no so capazes de se comunicarem a distncia. Para que isto ocorra elas devem utilizar portas de comunicao, as quais encapsularo as mensagens das mquinas servidoras e estabelecero uma comunicao ordenada atravs do sistema fsico de comunicao. Neste rpido exemplo introdutrio pode-se notar que foram estabelecidos trs nveis (ou camadas) de comunicao, quais sejam: o de troca de mensagens entre os usurios; o de comunicao entre as respectivas mquinas hospedeiras; e o de coordenao pelas portas do sistema de comunicao. Mundo real Sistemas de comunicao computacional Exemplo de aplicaes Nvel de rede Nvel de hardware Telefonemas Orientando a conexo Transferncia de arquivos circuito virtual Chaveamento de circuito Cartas Sem conexo Divulgao do estado do sistema Datagramas Chaveamento de pacotes

As estruturas em camadas referidas no pargrafo anterior so chamadas de protocolos de comunicao. Protocolos de comunicao so conjuntos de regras que regulam a troca de mensagens, para prover um fluxo de informao ordenado e confivel, entre os processos comunicantes. Nos protocolos, camadas inferiores fornecem servios usados para comunicao

18

entre camadas imediatamente superiores. Os principais protocolos so, como foi dito anteriormente, o RM-OSI da ISO e o TPC/IP do DoD. A seguir eles so descritos mais detalhadamente.

O modelo de referncia da ISO

Em 1977, sentindo a necessidade de padronizar a conexo de sistemas computacionais heterogneos, a International Standards Organization (ISO), atravs de seu comit tcnico de processamento de dados (TC97), criou um subcomit (SC16), para estudar o problema. No ano seguinte, o SC16 apresentou uma proposta, aceita pelo TC97 em 1979. Esta proposta foi chamada de reference model for open system interconnection (RM-ISO) e foi aprovado como padro ISO7498 em maio de 1983. Em setembro do ano anterior, o RM-OSI foi adotado como recomendao X.200 pelo CCITT. Este modelo dividido em sete camadas, contemplando diversos nveis de abstrao de um sistema distribudo, desde o nvel fsico at o de aplicaes voltadas para o usurio. A seguir, apresenta-se uma descrio sucinta das sete camadas que compem o RM-OSI. A camada mais baixa do RM-OSI a fsica. Ela a responsvel pela interface entre os ns da rede e o meio fsico de transmisso. Portanto, nela existe a preocupao com a transferncia de bits (unidade de dados desta camada) diretamente atravs de uma conexo fsica. Desta forma, h um interesse especial na definio das caractersticas eltricas, mecnicas e funcionais necessrias para a transferncia adequada de informaes. Algumas caractersticas eltricas consideradas so a amplitude, o perodo e a freqncia dos sinais, o esquema de modulao e o modo de operao usados. Dentre as caractersticas mecnicas esto o nmero de pinos usados nos conectores, o tamanho dos conectores e de seus pinos, bem como a distribuio destes naqueles. J as caractersticas funcionais tm a ver com os procedimentos necessrios para o estabelecimento e o encerramento de conexes, por exemplo. Resumindo: Na camada fsica a preocupao recai sobre as caractersticas eltricas, mecnicas e funcionais necessrias para ativar, manter e desativar conexes fsicas para a transmisso de bits entre ns da rede. A camada seguinte a de enlace de dados. Uma vez que a camada fsica trata apenas da transmisso de seqncias de bits, a camada de enlace a primeira do RM-OSI a dar alguma ateno ao significado de tais bits. Nesta camada, a unidade de dados o quadro. Os quadros so compostos por conjuntos de bits, normalmente uns poucos milhares. A camada de enlace a principal responsvel pela transmisso confivel dos quadros. Para tanto, ela deve ser capaz de detectar e possivelmente corrigir erros que aconteam eventualmente, o que viabilizado pela incluso de alguns bits de controle nas extremidades dos quadros, os quais permitem a identificao de seus limites e o tratamento dos erros. Como existe a possibilidade de perda de quadros durante a transferncia, esta camada deve oferecer mecanismos que permitam o reconhecimento dos quadros corretos e a retransmisso dos incorretos e dos faltantes. Neste caso, como possvel a recepo de quadros duplicados, a camada de enlace deve estar apta a identificar esta situao. Em resumo: A camada de enlace de dados deve oferecer um servio de transferncia confivel de dados entre os ns da rede, suportada pela camada fsica subjacente. A camada de rede a terceira no RM-OSI. A funo principal desta camada controlar o funcionamento da malha de comunicao. Ela responsvel pelo estabelecimento e pela manuteno do fluxo de pacotes atravs da rede. Devido a uma falta de consenso no mbito da ISO, foram adotados dois tipos de servios oferecidos por esta camada, quais sejam: circuitos virtuais e datagramas. Como no h necessidade de uma ligao fsica direta entre os usurios, uma tarefa importante desta camada o roteamento de pacotes. Outras questes relativas ao trfego so o tratamento de congestionamentos, o controle da vazo e a contabilidade dos servios. Congestionamentos ocorrem quando um n da rede forado a trabalhar no seu limite de capacidade, causando um engarrafamento das informaes que por ela trafegam. O controle de vazo refere-se ao controle do desequilbrio entre as velocidades de transmisso de um n e de 19

recepo de outro. A contabilidade deve-se necessidade de contagem dos pacotes enviados pelos diversos usurios, de maneira a produzir informaes que permitam a cobrana dos servios prestados. Em suma: a camada de rede responsvel pelo controle das operaes de comunicao da rede, incluindo o empacotamento de mensagens, o roteamento dos pacotes e o controle de fluxo. O RM-OSI tem como quarta camada a de transporte. Esta camada inicia uma mudana de nfase da ISO. Inicialmente, preocupada com as funes de hardware e software necessrias para garantir a transmisso adequada de pacotes, quadros e bits, a partir desta camada a ISO passa a dirigir sua ateno s funes mais voltadas garantia de uma transferncia de dados entre os usurios finais, sem que estes tenham que preocupar com detalhes de operao da rede em nveis mais baixos de abstrao. A funo bsica desta camada consiste da eventual necessidade de diviso das mensagens oriundas da camada superior em pacotes e do envio destes rede, garantindo sua transmisso adequada e sua chegada correta ao destinatrio desejado. Nesta camada a ISO define apenas servios orientados a conexo. Portanto, ela pode ser bastante simples se a camada de rede oferecer um servio de circuitos virtuais, mas ser bastante mais complexa se o servio oferecido pela camada de rede for do tipo datagrama. Pode-se usar qualquer dos trs tipos de correspondncias entre as conexes de sesso e de transporte. Entretanto, tudo deve ser feito de modo que as camadas superiores fiquem isoladas das trocas inevitveis na tecnologia de hardware subjacente. A camada de transporte a primeira realmente fim-a-fim, isto , as camadas inferiores tm, digamos, conscincia de que suas unidades de dados passam por vrios ns intermedirios antes de chegarem ao seu destino, j, do ponto de vista das camadas superiores, as mensagens vo diretamente da fonte ao destino, sem a interveno de elementos intermedirios. Sintetizando: a camada de transporte controla a transferncia de dados do sistema-fonte ao sitema-destino, atravs do estabelecimento, da manuteno e da liberao de conexes bidirecionais entre um par de entidades de sesso, para aliviar as entidades das camadas superiores das tarefas de transporte de dados entre elas. A camada seguinte a de sesso. Nesta camada h uma maior preocupao com as aplicaes propriamente ditas, do que com a mera comunicao. Esta camada administra a sesso, unindo e desunindo duas entidades para relacionamento. Para isto, verifica a autenticidade das entidades que desejam se comunicar. Desta forma, serve de interface entre os usurios e a rede. Controla a troca de dados, delimita e sincroniza as operaes sobre estes dados e decide sobre o tipo de comunicao a ser usado (simplex, semi-duplex ou duplex). Em sntese: a camada de sesso organiza e sincroniza o dilogo e gerencia a troca de dados entre duas entidades da camada de apresentao. A prxima camada na hierarquia do RM-OSI a de apresentao. Esta camada ocupa-se da interpretao da sintaxe dos dados, transformando-os e formatando-os sempre que necessrio, para resolver problemas de diferenas entre as sintaxes dos diversos sistemas interligados. Nesta camada so usadas tcnicas de compresso de dados, para reduzir o nmero de bits transmitidos, e de criptografia, para aumentar a privacidade na transferncia destes. Resumindo: a camada de apresentao visa gerenciar as estruturas de dados abstratas (como letras, nmeros e smbolos) convertendo-as da representao interna ao computador, para aquela na rede e vice-versa. A camada de aplicao a mais alta do RM-OSI. Todas as outras camadas existem para dar suporte a esta. Seus servios so diretamente observados pelos usurios. As entidades desta camada so janelas que viabilizam a representao de cada usurio final, dentro da rede. As funes desta camada so totalmente dependentes das aplicaes. Alguns exemplos clssicos de aplicaes so: - terminais virtuais: fazem a converso de informaes transferidas entre dois terminais de modo a possibilitar sua legibilidade em ambos, independentemente de suas diferenas fsicas; - transferncia de arquivos: faz a converso do contedo dos arquivos transferidos entre dois equipamentos de forma a compatibilizar as diferenas de representao existentes, oferecendo mecanismos bsicos para a manipulao de arquivos a distncia, como abertura, edio e fechamento de arquivos;

20

tratamento de mensagens: permite a preparao, disseminao (remessa e recebimento) e o armazenamento de mensagens ou arquivos, entre os usurios, incluindo-se neste servio o correio eletrnico o teletexto e o facsmile; e Submisso remota de tarefas: servio que permite submeter tarefas a mquinas diferentes, utilizando sistemas operacionais distintos, compartilhando recursos e capacidade de processamento, de forma transparente.

O modelo TCP/IP do DoD

Em dezembro de 1969 o departamento de defesa (DoD Department of Defense) norte americano colocou em operao a rede Arpanet. Inicialmente consistia de quatro ns, chamados de IMPs (Inerface Message Processors). Originalmente, os IMPs eram minicomputadores Honeywell DDP516, com memria de 12k palavras de 16 bits. Atualmente, constitui-se de muitos milhares de IMPs espalhados pelo mundo todo. Como a Arpanet anterior ao RM-OSI, ela no segue esta padronizao. Contudo, ela possui protocolos que correspondem, aproximadamente, s camadas do modelo da ISO. Com o passar do tempo e com sua internacionalizao, a Arpanet deu origem Internet e os protocolos de comunicao nela utilizados passaram a ser conhecidos pela sigla TCP/IP, correspondente s duas camadas principais do conjunto de protocolos da Arpanet, como ser visto em seguida. O nvel fsico no definido pela Arpanet pois baseia-se em ligaes telefnicas alugadas. Vista em mbito da Internet, sua camada fsica corresponde quelas das redes locais a ela conectadas. O protocolo mais baixo, IMP-IMP, uma mistura aproximada das camadas dois e trs do RM-ISO, incluindo um mecanismo de roteamento bastante elaborado e um mecanismo para a verificao da recepo pelo IMP-destino, de cada pacote enviado pelo IMP-fonte, o que no existe no ambiente da ISO. A camada de rede chamada, na Arpanet, de IP (Internet Protocol), sendo um servio do tipo datagrama, projetado para ligar um vasto nmero de redes locais e de longa distncia. camada de transporte corresponde o TCP (Transmission Control Protocol), que embora eqivalha, genericamente, ao modelo da ISO, pouco tem em comum com aquele, no que se refere a formatos e demais detalhes. As camadas de sesso e apresentao inexistem na Arpanet, j que sua falta nunca foi sentida nestes mais de 30 anos de funcionamento. Tambm, no existe uma camada de aplicao propriamente dita, como entendida no mbito do RM-OSI. O que existe uma srie de servios oferecidos por meio de vrios protocolos bem estabelecidos, tais como: o ftp (file transfer protocol) para transferncia de arquivos; o SMTP (simple mail transfer protocol) para correio eletrnico; e o telnet (terminal emulation) para terminais virtuais. A Figura 3 mostra a arquitetura bsica do modelo TCP/IP do DoD, em comparao com a RM-OSI/ISO.

21

aplicao apresentao sesso transporte rede enlace fsica

ftp

smtp

telnet

outras

TCP IP IMP IEEE 802 X.25 outros

RM-OSI da ISO

TCP/IP do DoD

Figura 3 Comparao entre o RM-OSI da ISO e o TCP/IP do DoD

22

Aspectos de projeto
De modo geral, um sistema distribudo pode ser visto como um conjunto de processos que so executados de forma concorrente, cada um dos quais acessando um sub-conjunto de recursos do sistema por meio de um mecanismo que envolve a troca de mensagens atravs de uma malha de comunicao a qual, nem sempre, confivel. A partir desta observao pode se identificar uma srie de aspectos, que devem ser considerados durante o projeto desses sistemas. O primeiro desses aspectos conduz questo da identificao e da modelagem dos objetos no sistema. Tais objetos so os processos, os arquivos, a memria, os dispositivos perifricos, a rede de comunicao e os processadores. A cada objeto do sistema associado um conjunto de operaes que possibilita o acesso a ele. Para organizar tal acesso, a cada objeto associado um processo, o qual fica de responsvel pela manipulao do objeto. Esses processos que gerenciam o acesso aos objetos so as nicas entidades visveis no sistema digital e so chamados de servidores dos respectivos objetos. Eles so ditos as nicas entidades visveis, porque quando um processo qualquer precisa que algum servio seja executado por outro objeto do sistema ele o solicita enviando uma mensagem de requisio ao servidor do objeto. Este recebe as requisies vindas de diversos processos do sistema, organiza-as e aciona o objeto adequado no seu devido tempo. Aps a execuo da tarefa solicitada, ele retorna a resposta ao processo que originou o pedido. Portanto, em um sistema digital h servidores de processos, servidores de arquivos, servidores de rede, servidores de impresso, e assim por diante. Por outro lado, os objetos podem residir nas mais diferentes partes do sistema e a referncia a cada um deles deve ser inequivocamente distinguida. A identificao dos objetos pode ser feita por nome, que mais fcil e intuitiva, por endereos, que mais precisa e contm informao estrutural embutida, e por servios, que pouco usada. Como foi mencionado anteriormente, do ponto de vista dos elementos do sistema, a rede de comunicao pode ser abstrada por suas portas. Estas portas correspondem a endereos lgicos de objetos no sistema. Num nvel de abstrao mais elevado estes endereos lgicos so associados a nomes de objetos do sistema distribudo. Ao contrrio, num nvel de abstrao mais baixo os endereos lgicos correspondem a endereos fsicos dos objetos. Os processos responsveis pelo mapeamento de nomes em endereos lgicos do sistema, e vice-versa, so chamados de servidores de nomes e os processos responsveis pelo mapeamento entre endereos lgicos e fsicos so ditos servidores de rede. Outro aspecto relevante do projeto de um sistema distribudo diz respeito ao modo como feita a coordenao da interao entre os objetos do sistema e como eles fazem para se comunicar. Para que eles possam interagir necessrio sincronizar o funcionamento dos objetos, caso contrrio corre-se o risco de solicitar algo a determinado objeto quando ele no mais capaz de executar a tarefa solicitada ou de receber informaes de objetos quando esta no faz mais sentido para o objeto que a solicitou. O grande problema para a sincronizao em sistemas digitais a ausncia de conhecimento sobre o estado global do sistema. Portanto, necessrio impor certos requisitos para a sincronizao, tais como: - Barreira de Sincronizao: um conjunto de processos deve atingir um ponto de sincronizao comum antes de continuar. - Condio de coordenao: um processo deve esperar por uma condio que outro processo iterativo ajustar assincronamente, para manter uma ordem de execuo. - Excluso Mtua: processos concorrentes devem ter acesso exclusivo a certos recursos compartilhados do sistema. Alm disto, o uso de mecanismos para prevenir e evitar bloqueios fatais, isto , a ocorrncia de uma espera circular de processos por objeto do sistema, mesmo atendendo aos requisitos de sincronizao mencionados, pode no ser praticvel. s vezes, at mesmo a deteco e a recuperao do sistema aps a ocorrncia de um bloqueio fatal no trivial, devido falta de 23

conhecimento sobre o estado global do sistema. Uma forma de contornar este problema utilizando protocolos de entendimento. Tais protocolos usam algoritmos com troca de mensagens contendo informaes sobre estados locais do sistema, para atingir um consenso sobre seu estado global. A comunicao no sistema, que em seu nvel mais baixo se d atravs de mecanismo de troca de mensagens, em seus nveis mais altos, para atingir a transparncia desejada no sistema distribudo, lana mo de modelos como cliente/servidor e chamadas a procedimentos remotos. Estes modelos usam o conceito de solicitao de servios a servidores do sistema em moldes semelhantes aos usados para fazer chamadas a rotinas, das quais recebem os resultados. Resolvida a questo do compartilhamento, ou da multiplicao de cpias dos objetos, vem baila a questo de como gerenci-los de forma controlada e como distribuir a carga de processamento pelo sistema. Como a memria est distribuda pelos processadores do sistema, deseja-se manter a transparncia apresentando-a ao usurio como uma grande memria compartilhada sem sobrecarregar o sistema de comunicao de forma significativa. Alm disto, os protocolos de comunicao utilizados devem manter a consistncia dos dados compartilhados e a coerncia dos dados para os quais existam vrias cpias no sistema, sempre considerando que h uma migrao dos processos pelo sistema. Por sua vez, a carga de processamento pode ser distribuda esttica ou dinamicamente. No primeiro caso, a distribuio esttica, dita escalonamento e visa minimizar o tempo necessrio para completar as tarefas de um conjunto de processos. O principal problema a ser equacionado uma forma de reduzir este tempo, mantendo o mnimo de sobrecarga no sistema de comunicao. No segundo caso, a distribuio dinmica, dita compartilhamento de carga e visa maximizar o uso de um conjunto de processadores. O principal desafio aqui ajustar os mecanismos que implementam a estratgia considerada mais adequada para efetuar a migrao dos processos. Finalmente, h o aspecto de como proteger os objetos do sistema e garantir sua segurana. A segurana de um sistema distribudo est sempre ameaada, porque o sistema aberto, isto , permite o acesso de vrios usurios, em certos casos e com certas restries, mesmo usurios no cadastrados podem acessar o sistema. Alguns usurios podem violar intencionalmente a segurana do sistema, causando problemas para os demais. Todavia, h tambm os problemas causados aos sistema pelo seu mau uso, no intencional, provocando falhas no sistema. O problema da ocorrncia de falhas no sistema pode ser amenizado pelo emprego de objetos redundantes no sistema. J a questo da segurana passa pela autenticao e autorizao dos usurios do sistema. A autenticao requer a identificao correta de clientes, servios e mensagens que circulam no sistema. A autorizao tem a ver com o controle de acesso rede fsica, controle este que dificultado por lidar com computadores heterogneos, sujeitos administraes de caractersticas diversas e, por conseguinte, usando modelos de segurana diferentes.

24

Modelo Cliente/Servidor
O modelo cliente/servidor um paradigma de programao, que representa as interaes entre processos e estruturas do sistema. Este modelo pode ser usado para melhorar a estrutura do sistema operacional, movendo-se a maior quantidade possvel de funes para nveis mais altos do sistema, reduzindo o tamanho do ncleo. Processos do sistema so chamados de clientes, quando usam servios, e de servidores, quando fornecem servios. Para pedir um servio um processo cliente solicita-o a um processo servidor o qual, aps realizar o servio solicitado, envia a resposta ao cliente. Desta forma, o ncleo precisa apenas gerenciar a comunicao entre clientes e servidores. Como tudo o que o usurio percebe a comunicao lgica entre cliente e servidor, este modelo facilita a implementao do conceito de transparncia. O modelo cliente/servidor no baseado no estabelecimento de uma conexo. Portanto, pode ser implementado sobre um canal de comunicao real por passagem de mensagens. Tudo que deve ser implementado no ncleo so as primitivas de comunicao send e receive, no importando se o servio de transporte utilizado ou no orientado a conexo, ou se a mensagem transferida para um servidor na mesma mquina ou em uma mquina remota. A simplicidade deste modelo tal que, para maior eficincia, pode ser implementado sobre um protocolo que corresponde apenas s trs camadas inferiores do modelo OSI. Tamanha a simplicidade do modelo que a prpria resposta do servidor usada como confirmao do recebimento da solicitao. As primitivas de comunicao podem ser classificadas segundo trs critrios, quais sejam: o estado em que ficam os processos durante a transmisso de uma mensagem, a forma como as mensagens so disponibilizadas, e a confiabilidade do mecanismo de troca de mensagens. De acordo com o primeiro critrio as primitivas podem ser classificadas em bloqueadoras, quando o processo fica paralisado durante a transmisso da mensagem, e no bloqueadoras, quando o processo fornece uma cpia da mensagem ao sistema de comunicao, por ocasio da solicitao do servio, e segue seu processamento, enquanto o sistema de comunicao se encarrega de tratar da solicitao. De acordo com o segundo critrio, as primitivas podem ou no se utilizarem de buffers para comunicao. Caso no utilizem buffers, cada processo deve informar ao processo remoto, atravs da primitiva receive, um endereo onde este processo deve armazenar a mensagem enviada. O problema que se a mensagem chega antes do processo que deve receb-la emitir o comando receive, a mensagem que est chegando pode ser perdida. Para reduzir o risco de perda de mensagens por no saber onde armazen-las, pode-se criar um buffer durante o estabelecimento da comunicao. Este buffer usualmente conhecido como caixa postal. Desta forma, o processo que enviar uma mensagem sabe, de ante mo, onde armazen-la e o processo receptor tambm sabe onde deve procur-las. Ainda h o risco de perda de mensagens se um processo tentar acessar uma caixa postal cheia, mas este risco muito reduzido se o tamanho da caixa postal for definido adequadamente. O terceiro critrio diz respeito confiabilidade das primitivas. Em princpio, devido simplicidade do modelo cliente/servidor, admite-se que ele no confivel, pois usa-se a resposta como confirmao do recebimento da solicitao, ficando o servidor, sem qualquer confirmao do recebimento da resposta. Esta confiabilidade pode ser aumentada se ao receber a resposta e repass-la ao cliente, o ncleo do cliente confirmar seu recebimento ao ncleo do servidor. Todavia, ainda h margem para dvidas, pois ao utilizar a resposta como confirmao do recebimento da solicitao, o sistema abre a possibilidade do cliente receber uma mensagem do 25

servidor que no a resposta sua solicitao e interpret-la como se fosse. Para melhorar mais ainda a confiabilidade do sistema, reduzindo o risco de falsas interpretaes, pode-se determinar que os recebimentos tanto da solicitao de servio quanto da resposta do servidor sejam explicitamente reconhecidos pelos ncleos correspondentes.

26

Servios de Tempo
Em qualquer sistema necessrio que se possa determinar quando um evento ocorre e quanto tempo ele demora, para que se possa definir que evento ocorre primeiro. importante saber a ordem de ocorrncia dos eventos em um sistema, por exemplo, para saber qual evento requisitou acesso a algum recurso do sistema primeiro. Imagine-se que dois processos compartilham uma varivel; um deles deseja ler o valor da varivel e outro deseja atualizar este valor. Imagine-se que a varivel represente a existncia ou no de incndio nos tanques de um posto de combustveis. Imagine-se que um processo A leia esta varivel periodicamente e, caso haja algum problema, tome as providncias cabveis para combater o incndio. Imagine-se que um processo B escreva nesta varivel sempre que detectar perigo de incndio no compartimento dos tanques. Imagine-se que o processo B tenha detectado um problema instantes antes do processo A tentar ler a varivel, mas que por algum defeito no servio de tempo do computador seja concedido acesso varivel ao processo A antes do B. Ento o processo A verificar que no h problemas com o tanques e aguardar a prxima ocasio para ler a varivel. Logo em seguida o processo B atualizar a varivel, indicando a existncia de fogo no compartimento dos tanques, mas nenhuma ao de combate ser tomada enquanto o processo A no voltar a ler a varivel, o que poder ocorrer tarde demais. Certamente, este exemplo um pouco exagerado, pois h outras formas mais seguras de se noticiar um evento de alto risco como o mencionado. Todavia, ele ilustra a necessidade de se garantir o correto ordenamento dos eventos em um sistema de computao. Entretanto, isto pode ser uma tarefa difcil, sobretudo em sistemas distribudos, nos quais as informaes relevantes esto espalhadas pelas mquinas. Os processos em um sistema distribudo tomam decises baseados exclusivamente em informaes disponveis na mquina em que esto sendo executadas. Cada mquina tem o seu relgio, no existindo uma fonte comum de tempo ou qualquer outra fonte precisa, que fornea um tempo global confivel. Por mais precisos que sejam os relgios internos de cada mquina e ainda que se conseguisse sincroniz-los no incio do funcionamento do sistema, h uma discrepncia entre os perodos de oscilao dos seus cristais a qual, com o transcorrer do tempo, aumenta sistematicamente a diferena entre os tempos instantneos reais das diversas mquinas. Suponham-se dois processos sendo executados em mquinas diferentes, que devem cooperar entre si. Suponha-se que as informaes a serem trocadas dependam do exato ordenamento, por exemplo, suponha-se que os processos estejam cooperando para montar uma ponte, utilizando estruturas pr-fabricadas. Um processo A responsvel por colocar parte do leito da ponte sobre um pilar, a ser colocado por outro processo B. Suponha-se que o pilar seja colocado pelo processo B aps 5 intervalos de tempo e que o processo A seja programado para colocar o leito sobre este pilar no final do sexto intervalo de tempo. Se cada processo seguir o seu relgio interno, os quais foram calibrados com um relgio mestre no incio do funcionamento, e que devido s diferenas nos respectivos cristais funcionam segundo o diagrama abaixo, a ponte vai cair, com certeza. Notese, no diagrama, que o instante previsto para a instalao do pilar corresponde ao quinto perodo do tempo real e o instante previsto para a instalao do leito da ponte corresponde ao sexto perodo do tempo real. Todavia, o instante real da instalao do leito corresponde ao sexto perodo da linha correspondente ao relgio do processo A e o instante real da instalao do pilar corresponde ao quinto perodo da linha correspondente ao relgio do processo B. Os dois instantes reais de instalao esto atrasados em relao ao tempo real e, pior que isto, o momento real da instalao do pilar ocorre depois da instalao do leito, o que significa que provavelmente o pilar ser colocado sobre o leito da ponte e no por baixo deste, como previsto.

Tempo real Relgio de A Relgio de B

1 1 1

2 2

3 3 2

4 3

5 4

6 5 4

7 6

8 7 5

9 6

10 8

27

Portanto, embora os relgios fsicos permitam uma boa aproximao do tempo real tanto para medir instantes quanto intervalos de tempo eles devem concordar com determinada marcao de tempo a qual no pode diferir do relgio real mais do que um determinado valor. Usam-se ento temporizadores compostos por um cristal, um contador e um registrador de reteno. A cada oscilao o cristal decrementa o contador em uma unidade. Ao atingir o valor zero, o contador provoca uma interrupo de tempo e o valor armazenado no registrador de reteno recarregado no contador. Este processo pode ser repetido indefinidamente. O sinal de interrupo pode ser transmitido para o restante do sistema e, periodicamente, re-sincronizar os relgios. Desta forma, poder-se-ia concordar com uma marcao de tempo, ainda que ela no fosse necessariamente correspondente ao tempo real. Este relgio lgico poderia, ao menos, preservar o ordenamento dos eventos. Contudo, este relgio lgico sofre de outro problema que o atraso de comunicao. Para sincronizar os relgios das mquinas do sistema uma delas, eleita como servidora de tempo, deve transmitir periodicamente uma informao de sincronismo s demais. No obstante, ela est a distncias diferentes das outras mquinas e o volume de comunicao de cada uma tambm distinto. Conseqentemente, o atraso para que a informao com o sincronismo de tempo chegue a cada uma das mquinas diferente o que provoca a incerteza nas marcaes individuais de tempo. Desta forma, no adianta utilizar um relgio atmico (de Csio 133) como marcador de tempo fsico, pois sua preciso seria perdida na disseminao da informao pelo sistema. Para contornar este problema Leslie Lamport sugeriu um esquema que possibilita a ordenao total de eventos no sistema, baseado em uma relao de acontecimento/anterioridade. Sejam trs processos P1, P2 e P3 cujos tempos seguem conforme tabela abaixo. Suponha que no instante 6, P1 envia uma mensagem A para P2. Suponha que no instante 24, P2 envie uma mensagem B para P3. As mensagens levam a informao do instante de tempo em que foram emitidas. O tempo de trnsito depender do relgio considerado. No caso das mensagens A e B, levando em conta o relgio da mquina receptora das mensagens, tem-se tempos de trnsito iguais a 10 e 16 unidades de tempo, respectivamente. No instante 60 o processo P3 envia uma mensagem C para o processo P2. Contudo, esta mensagem ser recebida pelo processo P2 quando seu relgio marcar 56 unidades de tempo. Isto corresponde a um tempo de trnsito negativo. Como se sabe no ser possvel tratar tempos negativos, o receptor (no caso P2) incrementa seu relgio. Como P2 sabe que a mensagem C partiu de P3 no instante 60 e que ela levou algum tempo para transitar entre os dois processos, P2 atribui a seu relgio o valor 61, correspondendo ao instante de sada da mensagem mais um intervalo de comunicao mnimo de uma unidade de tempo. A partir da ele volta a incrementar seu relgio com seu perodo normal. Situao semelhante ocorre se no instante 69, P2 enviar uma mensagem D para P1, o qual a receber no instante 54 e atualizar seu relgio para 70. Para evitar ambigidades, caso um processo receba mais de uma mensagem no mesmo instante, ele associar ao tempo de cada mensagem o nmero do processo que a originou. Desta forma, se duas mensagens forem recebidas pelo processo P3 no instante de tempo 50, uma originria de P1 e outra de P2, elas recebero o identificador de tempo 50.1 e 50.2, respectivamente.

28

P1 0 6 12 18 24 30 36 42 48 54 60

P2 0 8 16 24 32 40 48 56 64 72 80

P3 0 10 20 30 40 50 60 70 80 90 100

P1 0 6 12 18 24 30 36 42 48 70 76

P2 0 8 16 24 32 40 48 61 69 77 85

P3 0 10 20 30 40 50 60 70 80 90 100

29

Ramificaes no Fluxo de Controle de Processos

Processos so as entidades mais fundamentais num sistema operacional. Processos concorrentes so programas em execuo assncrona que interagem, cada qual com seu prprio espao de endereos. Para estender a concorrncia internamente aos processos, muitos sistemas operacionais modernos possibilitam ramificaes no fluxo de controle dos processos, as quais so mais conhecidas pelo termo ingls threads. Threads so processos leves que compartilham um espao de endereos lgicos. Threads podem ser implementados tanto no espao de usurio quanto no ncleo do sistema. A implementao de threads no espao de usurios flexvel, pois suas incorporaes e posterior atualizao em sistemas existentes relativamente simples, mas para se obter eficincia deve-se implement-los no ncleo. O mecanismo de threads funciona como descrito a seguir. Ao ser executado, um programa pode gerar ramificaes no seu fluxo de controle. Essas ramificaes tm seus estados locais individuais, mas permanecem associados ao processo que as gerou. Cada um desses sub-processos, os threads, possui um bloco de controle (TCB Thread Control Block) semelhante ao que existe para processos. Todavia, como os threads so processos leves, associados aos processos geradores, seus TCBs incluem informaes locais reduzidas, tais como o contador de programa, apontadores de pilha e o conjunto de registradores. Como s possuem informaes locais, armazenadas em certos registradores da UCP, compartilhando o restante das informaes de contexto com o processo gerador, a mudana de contexto de threads mais rpida que a do processo principal. Exemplificando o que foi mencionado no pargrafo anterior, o bloco de controle de processos deve conter informaes completas sobre o processo. Tais informaes podem ser divididas em dois grupos: o das informaes compartilhadas com os threads e o das informaes especficas sobre o processo. Por compartilharem seu espao de endereamento com os threads, os processos funcionam como se fossem mquinas virtuais onde rodam os threads. Desta forma, os blocos de controle destas ramificaes armazenam apenas as informaes individualizadas, que no podem ser compartilhadas com o processo que as gerou. Ento as informaes mencionadas poderiam ser divididas como sugerido na tabela a seguir. Todas a informaes especficas contidas no TCB so equivalentes s contidas no PCB. Uma diferena marcante entre processos e suas ramificaes que, enquanto os processos oscilam entre trs estados, os threads incluem um quarto estado, o concludo. Portanto, os threads podem assumir qualquer um dos seguintes estados: - pronto: em condies de ser executado, aguardando o momento adequado para usar o processador; - ativo: em execuo no processador; - bloqueado: sem condies de ser executado, esperando que outra ramificao libere algum recurso que necessita, para poder voltar ao estado de pronto para execuo; e - concludo: terminou o processamento e aguarda a leitura de resultados obtidos pelo processo gerador. Quando o objetivo a agilidade no processamento, os threads devem ser implementados no espao de usurios. Desta forma, ao contrrio dos processos, que tm seu funcionamento controlado diretamente pelo sistema operacional, o funcionamento dos threads supervisionado pelo procedimento de tempo de execuo, que serve como interface entre a mquina virtual (processos) onde rodam os threads e o sistema operacional.

30

Nos Processos (PCB) Informaes Compartilhadas Espao de Endereamento Variveis Globais Arquivos Abertos Temporizadores Sinais Semforos Contabilizao de Recursos Informaes Especficas Processos Filhos Contador de Programa Pilha Conjunto de Registradores Estado

Nas Ramificaes (TCB) Informaes Compartilhadas Informaes Especficas Processos Filhos Contador de Programa Utiliza informaes do processo que a gerou Pilha Conjunto de Registradores Estado

Como, ao serem implementados no espao de usurios o sistema operacional no enxerga os threads, cada processo tem que multiplexar entre seus threads a quota de tempo que recebe do processador. O escalonamento dos threads e as respectivas chamadas ao sistema so tratados pelo procedimento de tempo de execuo. Como a chamada efetiva ao sistema operacional provocaria uma interrupo na execuo do processo gerador e, conseqentemente, de todos os demais threads, quando uma ramificao faz uma chamada ao sistema operacional sua requisio colocada em uma fila FIFO e o thread bloqueado, ativando-se outra ramificao que esteja pronta para execuo. Quando se esgotarem os threads executveis ou a quota de tempo ao sistema operacional na ordem em que foram feitas e o processo ento bloqueado. Deste modo, as ramificaes no podem usufruir do sistema de interrupes do sistema operacional e, por conseguinte, no so preemptivas. Isto significa que uma vez ativadas elas s param de executar se solicitarem algum recurso do sistema, se a quota de tempo do processo se esgotar ou se terminarem sua execuo. Por outro lado, se a questo eficincia os threads podem ser implementados diretamente no ncleo de modo que possam ser vistos pelo sistema operacional. Neste caso, eles passam a ser tratados como processos, possibilitando maior flexibilidade no bloqueio dos threads e mais eficincia em seu escalonamento. Como as ramificaes passam a poder fazer chamadas diretas ao sistema elas tambm passam a ser sensveis ao sistema de interrupes passando, desta feita, a ser preemptveis, sem que para tanto seja necessrio interromper a execuo do processo que as gerou, isto , o sistema operacional pode interromper um thread mantendo o processo que o gerou e suas outras ramificaes em execuo. Ento os threads competem em p de igualdade com os processos por ciclos do processador; em contrapartida, o sistema perde em portabilidade, as mudanas de contexto dos threads passam a ter a mesma complexidade das dos processos e a concorrncia fica reduzida a dois nveis, quais sejam, processos e threads. Uma aplicao deste mecanismo na implementao de processos servidores que prestam servios semelhantes a vrios processos clientes. Se o servidor for nico e deve esperar por uma operao ou por um resultado, as requisies feitas a ele devem ser bloqueadas, prejudicando o processamento de alguns clientes. Se forem usadas vrias cpias do servidor, para minimizar o problema de bloqueio de requisies, tais cpias utilizam espaos de endereamento diferentes, criando problemas de consistncia. O emprego de ramificaes na estrutura de controle do servidor permite o agrupamento dos threads num mesmo espao de endereamento admitindo o acesso

31

concorrente de vrios clientes e um nico servidor. Destacam-se dois tipos de ramificaes, como descritas nos prximos dois pargrafos. O primeiro exemplo envolve ramificaes estticas idnticas, como nos servidores de terminais. Quando um cliente (usurio) chama um servidor, este cria uma ramificao que passa a atender aquele usurio enquanto ele estiver conectado. Como as ramificaes so locais ao servidor elas no necessitam chamar o ncleo do sistema operacional para sincroniz-las. Como elas compartilham o mesmo espao de endereamento, quando precisam acessar algum recurso compartilhado a exclusividade do acesso feita via monitores ou semforos. Como a ramificao fica no sistema enquanto o usurio estiver conectado, ela ocupa espao de memria ainda que o usurio no requisite nenhuma operao do servidor. O segundo exemplo envolve ramificaes dinmicas, como nos servidores de arquivos. Nestes servidores tm-se vrias operaes como leitura ou escrita. Tm-se ainda um processo principal que serve como coordenador das atividades. Para cada operao solicitada ele cria uma ramificao, que lhe devolve o controle logo aps sua criao. Se, por exemplo, forem solicitadas diversas operaes de leitura, sero geradas vrias ramificaes do processo responsvel pela operao de leitura. Estas ramificaes sero executadas independentemente umas das outras e se extinguiro to logo terminem o servio para o qual foram criadas. Desta forma, a utilizao do espao de memria pode ser otimizada, reaproveitando-se a poro de memria liberada pelos threads, para uso por novos threads, permitido a reduo no custo do sistema. Resumindo, podem se destacar quatro aspectos no projeto de mecanismos de ramificaes do fluxo de controle de processos, so eles: a gerncia, o uso de regies crticas, o emprego de variveis globais e a localizao da implementao. Sob o ponto de vista gerencial as ramificaes podem ser criadas esttica ou dinamicamente. No caso esttico so criadas em tempo de compilao, com pilha de tamanho fixo, o que torna esta abordagem simples, mas inflexvel. No caso dinmico so criadas e destrudas conforme a necessidade, aumentando a flexibilidade, mas complicando consideravelmente o gerenciamento. Sob o ponto de vista posicional o mecanismo pode ser implementado na rea de usurio o ambiente de execuo guarda valores dos registradores em tabletes, quando deve mudar de contexto, sem chamar o sistema operacional. O principal problema que como chamadas ao sistema no so repassadas de imediato, para no bloquearem o processo, os threads no so preemptveis. Quando implementados no ncleo do sistema operacional os problemas se revertem, pois aumenta a autonomia dos threads na mesma proporo em que se reduz sua agilidade.

32

Mecanismos de Linguagem para Sincronizao

Uma linguagem de programao concorrente permite especificar atividades concorrentes, tais quais o modo como os processos so sincronizados e como eles se comunicam. As linguagens concorrentes so obtidas, via de regra, pelo acrscimo de certas construes prprias para sincronizao e a comunicao de processos concorrentes a linguagens seqenciais. Os principais construtores das linguagens so: - Estrutura do programa: especifica a composio do programa (procedimentos, comandos, variveis...); - Estrutura de dados: representam objetos no programa; - Estrutura de controle: regulam o fluxo de execuo do programa (if-then-else, while-do, ...); - Chamadas a procedimentos e ao sistema: ativam rotinas especiais ou servios do sistema; - Estruturas de entrada e sada: recebem dados de entrada e produzem resultados da execuo dos programas; e - Estruturas de atribuio: afetam o estado da execuo do programa. A tabela a seguir apresenta os principais mtodos para a sincronizao de processos e as caractersticas das linguagens que os implementam. Como pode ser visto, estes mtodos se dividem em dois grupos: um que emprega variveis compartilhadas; e outro que utiliza o mecanismo de passagem de mensagens. O primeiro grupo mais indicado para processos que compartilham um espao de endereamento, enquanto, o segundo mais usado em processos concorrentes entre os quais o acoplamento mais fraco. MTODOS DE SINCRONIZAO Semforo Sincronizao Monitor por Variveis Regio Crtica Condicional Compartilhadas Serializador Expresso de Caminho Sincronizao Processamento Seqencial Concorrente por Passagem Chamada a Procedimentos Remotos de Mensagens Rendezvous TIPOS CARACTERSTICAS DAS LINGUAGENS Chamadas ao Sistema e Variveis Abstrao de Tipos de Dados Estruturas de Controle Tipos de Dados e Estruturas de Controle Tipos de Dados e Estruturas de Programa Estruturas de Entrada e Sada Chamadas a Procedimentos Chamadas a Procedimentos e Comunicao

Os mtodos de sincronizao do primeiro grupo foram vistos durante o estudo de sistemas centralizados. Portanto, a seguir so apenas apresentados algoritmos para a implementao distribuda do problema dos leitores e escritores. SEMFORO var mutex, db: semforo; rc: inteiro processo leitor P(mutex); rc:=rc+1; if rc=1 then P(db); V(mutex); <l base de dados> P(mutex); rc:=rc-1; if rc=0 then V(db); V(mutex);

<obtm chave>

<libera chave>

33

processo escritor P(db); <escreve na base> V(db); MONITOR rw: monitor var rc: inteiro; busy: booleano; toread, towrite: condio; procedure startread begin if busy then toread.wait; rc:= rc+1; toread.signal; end procedure endread begin rc:= rc-1; if rc=0 then towrite.signal; end procedure startwrite begin if busy or rc0 then towrite.wait; busy:=true; end procedure endwrite begin busy:=false; toread.sinal or towrite.signal; end begin rc:=0; busy:=false; end processos leitores rw.startread <l base de dados> rw.endread processos escritores rw.starwrite <escreve na base de dados> rw.endwrite REGIO CRTICA CONDICIONAL var db: compartilhada; rc: inteiro

34

processo leitor region db begin rc:=rc+1 end; <l base de dados> region db begin rc:=rc-1 end; processo escritor region db when rc=0 begin <escreve na base de dados> end; SERIALIZADOR rw; serializador var readq, writeq: filas; rcrowd, wcrowd: grupos; processo leitor begin enqueue (readq) until empty (wcrowd); joincrowd (rcrowd) then begin <l base de dados> end; end processo escritor begin enqueue (writeq) until (empty (wcrowd) and empty (rcrowd)); joincrowd (wcrowd) then begin <escreve na base de dados> end; end EXPRESSO DE CAMINHO path1 ([read], write) end

A primeira linguagem a considerar mecanismo de sincronizao foi a CSP, que usa o conceito de encontrar comandos de entrada de um processo ao de sada de outro. Um processo transmissor P envia um comando de sada explicitando que deseja transmitir uma expresso, por exemplo exp, ao processo Q, isto , Q!exp. O processo receptor Q envia um comando de entrada informando que est apto a receber uma varivel, por exemplo var, do processo P, isto , P?var. No encontro destes comandos, a expresso exp atribuda remotamente varivel var. Como leitores e escritores no tm a menor idia que o outro existe, necessrio um processo servidor que receba solicitaes de leitura e escrita e providencie leituras concorrentes e escritas exclusivas. O problema principal com este mtodo que se necessita saber os nomes dos possveis leitores e escritores de antemo, de forma a encapsular a leitura e a escrita no servidor. Estendendo a idia de comandos de entrada e sada sncronos de CSP para o de chamada de procedimentos, resultam os mtodos de chamada a procedimentos remotos (RPC) e de rendezvous. O mtodo RPC baseia-se na comunicao entre clientes e servidores, em parte, j visto anteriormente, e que ser visto com mais detalhes oportunamente. O rendezvous semelhante ao RPC, mas os procedimentos so ativos e devem expressar sua disposio para receber chamadas. Uma implementao do problema dos leitores e escritores com o mtodo rendezvous apresentada a seguir.

35

RENDEZVOUS task rw is entry startread; entry endread; entry startwrite; entry endwrite; end; task body is rc: integer:=0; busy: boolean:=false; begin loop select when busy=false accept startread do rc:=rc+1 end; or accept endread do rc:=rc-1 end; or when rc=0 and busy=false accept startwrite do busy:=true end; or accept endwrite do busy:=false end; end loop end;

Exemplos da implementao de alguns mtodos de sincronizao nas linguagens OCCAM, LINDA, ORCA e JAVA foram compilados pelos alunos da disciplina projeto de sistemas operacionais no primeiro semestre letivo de 2001 e seus trabalhos podem ser consultados no seguinte URL: http://www.dcce.ibilce.unesp.br./~norian/cursos/pso/trabalho1.html

Comunicao entre Processos

Durante o seu funcionamento muitos processos precisam trocar informaes com outros processos. Para que esta comunicao ocorra, os sistemas distribudos necessitam de um mecanismo especfico. Como j visto, podese considerar um sistema distribudo estratificado em diversos nveis de abstrao. Nos nveis inferiores temos conexes para o transporte de mensagens, as quais so devidamente empacotadas e roteadas atravs da malha de comunicao. Estes nveis menos abstratos do sistema, que incluem o sistema operacional e a rede fsica, devem permanecer transparentes aos processos. Para tanto, no nvel da camada de transporte do sistema oferecido um servio de troca de mensagens, que se constitui o menor nvel de comunicao entre processos de um sistema. Utilizando este mecanismo, no nvel de apresentao implementado um servio de solicitao e resposta via chamada de rotinas, como se fossem pontos de interface de programas de amplificao para a camada de transporte. Tal mecanismo conhecido por chamada a procedimentos remotos e serve como mecanismo de conduo das transaes da camada de aplicao. Traduzindo em outras palavras, transaes so seqncias de solicitaes e/ou respostas que requerem tratamento atmico da comunicao. Seqncias de solicitaes ou respostas acionam chamadas a procedimentos remotos as quais passam as solicitaes por meio de

36

mensagens aos processos comunicantes. Segue-se uma tabela que exemplifica a estratificao mencionada.

Comunicao

Aplicao Apresentao Transporte S.O. (rede) Enlace/Fsico

Transaes Chamadas a Procedimentos Remotos Passagem de Mensagem Conexes de Transporte Chaveamento de Pacotes

No texto a seguir sero vistos cada um dos nveis de abstrao superiores, que possibilitam a comunicao entre processos. Inicialmente ser analisado o mecanismo de passagem de mensagens, sobre o qual se baseiam os demais. Na seqncia sero apresentadas as chamadas a procedimentos remotos e, para concluir esta seo, ser visto o mecanismo de transaes.

Passagem de Mensagens
Uma mensagem um conjunto de objetos com estrutura semntica definida pelos processos cooperantes. Somente estes processos interpretam a informao contida no corpo da mensagem. O restante do sistema manipula somente o cabealho da mensagem, que contm as informaes de controle. Um processo, para enviar uma mensagem, utiliza primitivas do servio de transporte. O mais comum so as primitivas send(destino,msg) e receive(fonte,msg), onde msg significa mensagem. Os processos usam uma de quatro formas para trocar mensagens entre si, quais sejam: por nome, por ligao, utilizando caixas de correio e atravs de portas. Quando a troca de mensagens entre processos feita por nome, ou seja, um processo identifica seu interlocutor pelo seu nome, se estabelece um caminho de comunicao bidirecional entre eles. Este caminho lgico e o fato de existir no implica nenhuma conexo fsica. Portanto, s pode haver um caminho por vez entre dois processos. Para ser nico, o nome do processo formado pelo endereo da sua mquina hospedeira concatenado com a identificao do processo. Esta formulao do nome dos processos permite que um processo X que estiver sendo executado em uma mquina A, converse com outro processo X que estiver sendo executado em uma mquina B. Ela tambm permite que um processo Y sendo executado em uma mquina C, se comunique com qualquer dos processos X mencionados, sem confundi-los. Sendo a troca de mensagens feita por ligao, elimina-se a limitao de uma conexo por par de processos. Neste caso, podem ser estabelecidos vrios caminhos de dados (circuitos virtuais) unidirecionais, os quais so gerenciados pelo ncleo do sistema operacional. Os caminhos podem ser estabelecidos, por exemplo, em tabelas de ligao armazenadas nas mquinas que participam do sistema. Sempre que h uma solicitao de um processo para se comunicar com outro estas tabelas so consultadas e a melhor rota estabelecida para a comunicao. As mensagens contm o endereo da mquina destino e as tabelas contm informaes sobre a(s) melhor(es) rotas para se atingir cada destino possvel. Tais tabelas so atualizadas dinamicamente, para incluir informaes sobre rotas e mquinas defeituosas, que no podem ser acessadas, e sobre mquinas e rotas que voltaram a fazer parte ativa do sistema. Alm destas, outras informaes sobre as condies de trfego so atualizadas dinamicamente nestas tabelas. No caso de se estabelecerem caixas de correio para serem usadas na comunicao entre os processos a ligao se torna mais flexvel, por assim dizer. As caixas de correio seguem o modelo dos produtores e consumidores, permitindo ligaes multiponto e multicaminho. No caso de

37

ligaes multiponto, se estabelece uma caixa de correio e informa-se aos processos comunicantes a localizao desta caixa. Sempre que um processo desejar transferir uma mensagem ele a coloca na caixa de correio. Quando qualquer um dos demais processos estiver pronto para receber alguma mensagem ele examina a caixa de mensagens e verifica se alguma mensagem lhe foi enviada. Se houver mensagem o processo a l, caso contrrio ele continua seu processamento normal, o qual pode incluir uma fase para o processo aguardar a chegada de uma mensagem. Note-se que este mecanismo permite a divulgao de informaes para todos os processos comunicantes, basta que o processo emissor deposite uma mensagem com um endereo genrico que permita sua leitura por todos os demais processos. As ligaes multicaminho servem, por exemplo, para aumentar a capacidade de comunicao entre dois processos. Para que isto ocorra, basta que um dos processos comunicantes abra duas (ou mais) caixas de correio para determinada ligao. Enquanto nos dois casos anteriores a comunicao precisa ser feita diretamente entre os dois processos comunicantes, neste caso a comunicao pode ser indireta, devido possibilidade de se estabelecer ligaes multiponto por meio deste mecanismo. A troca de mensagens feita por intermdio de portas , em verdade, um caso especial de caixa de correio, que utiliza uma abstrao de uma fila FIFO, de tamanho finito, mantida pelo ncleo. Enquanto as caixas de correio utilizam elementos de armazenamento intermedirio que podem ser acessados aleatoriamente, as portas fazem uso de filas cujo acesso deve ser feito ordenadamente. Os sistemas podem ou no utilizar elementos de armazenamento intermedirio para as mensagens. Quando estes elementos de armazenamento intermedirio so utilizados no sistema, possvel tratar mensagens com outras aguardando na fila e reduzir as diferenas de velocidade entre os processos comunicantes. Aqueles processos que utilizam tais elementos de armazenamento intermedirio implementam o modelo dos produtores e consumidores, enquanto aqueles que no utilizam esses elementos implementam o modelo rendezvous. Alm da questo da utilizao de elementos para o armazenamento temporrio de mensagens, o seu envio pode ser sncrono ou no. As consideraes sobre a forma de comunicao feitas a seguir referem-se Tabela I.

Tabela I Formas de Comunicao entre Processos Processo 1 envia ncleo fonte 1 8 2 7 Processo 2 ncleo destino recebe 3 6 4 (pedido) (servio) 5 (resposta)

canal de comunicao mensagem reconhecimento

O primeiro caso consiste no envio assncrono, sem bloqueio, ou seja, o processo liberado to logo a mensagem seja montada e repassada para o ncleo fonte. Neste caso o processo que origina a mensagem fica envolvido apenas nas etapas 1 e 8 da Tabela I. Os outros casos referem-se a formas de envio sncrono. Portanto, o segundo caso consiste no envio sncrono com bloqueio simples. Neste caso, o processo s liberado aps a mensagem ser transmitida ao canal de comunicao. Isto porque se houver algum problema com o envio da mensagem e o ncleo do sistema fonte perd-la antes dela ser transmitida ao canal ela no poder mais ser recuperada, pois o processo que solicitou o envio a deu por enviada. Ento esta abordagem mantm o processo bloqueado at que o ncleo tenha sucesso na sua transmisso para o canal de comunicao. Desta forma o processo que origina a mensagem fica envolvido nas etapas 1, 2, 7 e 8 da Tabela I.

38

O terceiro caso consiste no envio sncrono com bloqueio, dito, confivel. Agora o processo s liberado aps a mensagem ser recebida pelo ncleo do processo destino. Isto garante que se houver algum problema com o canal de comunicao o processo transmissor poder retransmitir a mensagem. Este procedimento aumenta a confiabilidade da comunicao, pois o canal de comunicao costuma ser um meio no confivel. Desta feita o processo que origina a mensagem fica envolvido nas etapas 1, 2, 3, 6, 7 e 8 da Tabela I. O quarto e ltimo caso considerado o de envio sncrono com bloqueio explcito, quando o processo transmissor fica bloqueado durante toda a transmisso, s sendo liberado aps o recebimento da solicitao pelo processo destino e durante o perodo em que este estiver computado a resposta desejada. Portanto, o processo que origina a mensagem fica paralizado durante todas as etapas da comunicao, envolvendo as etapas 1, 2, 3, 4, 5, 6, 7 e 8 da Tabela I. H outro mecanismo bloqueante que o modelo de solicitao/resposta, no qual o processo que origina a mensagem fica bloqueado durante todo o processo de comunicao, inclusive pelo tempo necessrio para o processo receptor da mensagem gerar a resposta solicitada, ou seja, durante o cmputo no servidor. Este mecanismo faz com que o processo que origina a mensagem fique paralizado, no somente durante as etapas 1 a 8, mas tambm durante o perodo de servio, indicado na Tabela I. At aqui foi visto o mecanismo bsico de passagem de mensagens entre processos. Agora sero consideradas duas estruturas de comunicao, atravs das quais as mensagens podem ser transferidas de um processo para outro. Estas estruturas so interfaces para programas de aplicao conhecidas por pipes e sockets. Elas servem para poupar usurio da preocupao com detalhes de implementao, tais como o tamanho da memria para armazenamento intermedirio das mensagens, a capacidade do canal de comunicao e a sincronizao de acessos. Para que este mascaramento do sistema possa ser feito define-se uma interface para utilizao pelos programas aplicativos, ficando o gerenciamento da comunicao por conta do ncleo do sistema. Incialmente, tratar-se- da materializao do modelo de produtores e consumidores em uma estrutura chamada de pipe. Cria-se uma fila FIFO, de tamanho finito, mantida pelo ncleo. Esta fila criada atravs de uma chamada ao sistema, que devolve dois descritores, um de leitura e outro de escrita na fila. O processo que deseja se comunicar utiliza o descritor de escrita para escrever suas mensagens no final da fila (entrada do pipe). O processo com o qual ele deseja se comunicar utiliza o descritor de leitura para ler as mensagens depositadas no incio da fila (sada do pipe). Pipes existem somente enquanto os processos leitores e escritores estiverem ativos, pois, como s permitem comunicao unidirecional e exclusivamente entre os processos chamador e chamado no teria sentido manter filas FIFO ativas no sistema aps o encerramento das atividades de qualquer dos processos comunicantes. possvel criar named-pipes, que so arquivos FIFO especiais associados a um nome e um caminho, atravs dos quais processos no relacionados podem utilizar pipes. Os pipes tratam os dados como seqncias de bits, sem interpret-los. A interpretao do contedo semntico das mensagens fica por conta do processo que as recebe. Por questes de confiabilidade da transmisso, ou se escrevem todos os bytes de uma mensagem no pipe ou nada se escreve. O uso de pipes restringe-se a um s domnio dentro de um sistema de arquivos. Para viabilizar a comunicao entre domnios diversos, onde nem estruturas de dados nem arquivos podem ser compartilhados e nomeados de forma inequvoca, usam-se sockets. Eles so pontos finais de canais de comunicao, gerenciados pelo servio de transporte. Atravs deles as operaes de entrada e sada na rede so modeladas como entrada e sada em arquivos. O sistema cria um descritor, que um ponto de comunicao lgico, local ao processo. Este descritor, que deve ser associado (pelo sistema) a um ponto de comunicao fsico, utilizado para enviar e receber dados atravs da camada de transporte do sistema. Isto possvel porque feito um mapeamento entre o descritor lgico, na interface de aplicao, e o descritor fsico, na interface de rede. Este mapeamento pode ou no ser feito atravs de uma conexo. Se for feito por meio de uma

39

conexo explcita, o processo que inicia a comunicao identifica o processo com quem deseja se comunicar e o sistema estabelece uma ligao entre seu ponto lgico de comunicao (local) e o ponto de comunicao fsico do processo remoto. Esta associao permanece enquanto os processos estiverem trocando informaes, no sendo mais necessrio identificar os processos comunicantes durante esta transmisso. Um problema com este tipo de comunicao a necessidade de um conjunto de protocolos para manter a segurana da comunicao. Tipicamente usado um protocolo em duas camadas: uma camada que pretende garantir a privacidade dos dados transmitidos por meio da criptografia simtrica dos dados; e outra para garantir a integridade e a autenticidade dos dados, utilizando mecanismos de verificao de erros e promovendo em clientes e servidores uma criptografia assimtrica com uso de chave pblica.

Chamadas a Procedimentos Remotos

O mecanismo de chamadas a procedimentos remotos uma abstrao, no nvel de linguagens, do mecanismo de comunicao por solicitao/resposta, baseado na passagem de mensagens. Sintaticamente, uma chamada a um procedimento remoto idntica a uma chamada a um procedimento local. Entretanto, a semntica diferente, pois envolve atrasos e eventualmente algum tipo de tratamento de falhas. Chamadas a procedimentos remotos escondem dos clientes detalhes de chamadas ao sistema, de converses de dados e de comunicao na rede. O cliente aquele que inicia a chamada para execuo de algum servio em uma mquina remota. A solicitao passada a um ordenador, na mquina do cliente, que agrega os parmetros necessrios transmisso da mensagem. Aps a devida parametrizao a mensagem passada ao ncleo, que se encarrega de sua transmisso utilizando o mecanismo de transporte da rede. A mensagem enviada ao servidor, que aquela mquina na qual o procedimento ser executado. Ao receber uma mensagem o ncleo do servidor a repassa para o respectivo ordenador, o qual far a devida extrao dos parmetros e encaminhar a solicitao ao servidor. Aps processada, o servidor retornar uma resposta ao cliente, por um caminho simtrico, isto , a resposta ser repassada ao ordenador do servidor, que empacotar a mensagem agregando-lhe parmetros. Esta mensagem empacotada ser repassada ao ncleo do servidor, que se comunicar com o ncleo do cliente e efetivar o transporte da mensagem com a resposta pela rede. Ao receb-la, o ncleo do cliente a repassar para o ordenador do cliente, que desempacotar a mensagem, finalmente entregando a resposta para quem a solicitou. Um exemplo de chamada a procedimento remoto a chamada a uma rotina para a leitura de algum arquivo em uma mquina remota. O cliente solicita o servio executando a atribuio arquivo = l (da, pos, nbytes), em que da um descritor do arquivo, pos a posio do arquivo onde a leitura deve ser iniciada e nbytes o nmero de bytes a serem lidos do arquivo. Ao iniciar o procedimento os dados so colocados na pilha do servidor, juntamente com as variveis locais, para serem usadas durante a execuo. Ao concluir a execuo estes dados so eliminados da pilha. Para que os dados de controle, como os mencionados no exemplo do pargrafo anterior, possam ser utilizados pelo servidor, permitindo a execuo correta do procedimento desejado, necessrio transferir estes parmetros entre o cliente e o servidor. Esta passagem de parmetros pode ser efetuada de diversas formas, como as quatro vistas a seguir. O cliente pode passar diretamente o(s) valor(es) do(s) parmetro(s) a ser(em) utilizadas pelo servidor. Ao receber o(s) parmetro(s) o servidor o(s) copia para uma (ou mais) varivel local, conforme necessrio. Modificaes feitas pelo servidor nas variveis locais no afetam o valor das variveis do cliente. Desta forma, o servidor pode trabalhar livremente sem interferir no processo que o chamou. Todavia, muitas vezes o que se quer exatamente a alterao controlada de algumas variveis. Neste caso, h um duplo trabalho, pois o servidor dever fazer as alteraes necessrias

40

durante o processamento, enviar uma cpia dos valores obtidos para o cliente, que ento dever efetuar as modificaes cabveis nas cpias locais das variveis. Uma alternativa para o problema levantado no pargrafo anterior seria o cliente enviar o nome da varivel local, em vez do seu valor. Desta forma, o servidor poderia atuar diretamente sobre as cpias das variveis existentes no cliente. Entretanto, em um sistema distribudo este acesso a variveis em mquinas remotas no um processo fcil, requerendo a avaliao de expresses sintticas em tempo de execuo. Portanto, este mtodo no muito utilizado na prtica de sistemas distribudos. Outra alternativa ao problema mencionado nos dois pargrafos anteriores seria a passagem de um ponteiro (endereo) para servir de referncia varivel, ou s variveis, que se deseja tratar. Neste caso o problema que o espao de endereamento em mquinas diferentes , tambm, diferente. Portanto, no tem sentido a passagem de parmetros por referncia em um sistema distribudo. A terceira alternativa, e ltima a ser apresentada neste texto, uma mescla das chamadas por valor e por referncia. Ao fazer uma chamada o cliente cria um vetor com os valores dos parmetros que deseja transferir ao servidor e passa o endereo deste vetor, e seu tamanho, para o ordenador do cliente. Com estas informaes, o ordenador copia os valores adequados em uma mensagem e a envia ao ordenador do servidor. Este, ao receb-la, copia os valores para um vetor na memria do servidor e chama-o, passando-lhe um ponteiro para o vetor criado. Note-se que este ponteiro nada tem a ver com o utilizado pelo cliente. Durante o processamento no servidor, todas as modificaes feitas refletem-se nos valores contidos no vetor presente em sua memria. Ao concluir o procedimento, com as informaes no vetor eventualmente modificadas, o servidor aciona seu ordenador, devolvendo-lhe o ponteiro para o vetor utilizado. A mensagem segue ento seu caminho de volta ao ordenador do cliente que, de posse do vetor modificado, atualiza o vetor na memria do cliente. Esta alternativa razoavelmente eficiente para estruturas simples, como arranjos. Todavia, seu tratamento no trivial para estruturas mais complexas, como rvores e grafos. Uma vez estabelecidos os mecanismos para a troca de mensagens, outro problema que surge a localizao do servidor. Para solicitar um servio o cliente deve saber a quem faze-lo. Isto s pode ser feito se ele puder identificar cada servidor existente no sistema. Uma maneira de viabilizar esta espcie de conscincia gravar, em cada cliente, os nmeros das mquinas e as verses de cada um dos programas servidores. Um problema com esta abordagem que qualquer mudana deve ser comunicada a todos os clientes em potencial. Se um servidor for transportado de uma mquina A para outra mquina B, porque esta est temporariamente menos carregada do que aquela, esta mudana deve ser comunicada a todos os clientes. Se for feita uma cpia de um servidor em uma mquina diferente, para ampliar as possibilidades de servio e melhorar a distribuio de carga do sistema, esta mudana tambm deve ser comunicada a todos os clientes. Em fim, qualquer modificao em qualquer dos servidores deve ser comunicada a todos os possveis clientes. Este procedimento causar um grande congestionamento no sub-sistema de comunicao do sistema distribudo. Uma soluo para este problema apresentada no pargrafo a seguir. Cria-se um processo de ligao dinmica, responsvel pela coordenao dos servios do sistema. Um servidor, ao iniciar suas atividades envia para o processo de ligao uma mensagem contendo seu nome, sua verso, um identificador e um manipulador (seu endereo ethernet ou IP, por exemplo). Este processo corresponde ao registro do servio no processo de ligao. O servidor pode cancelar seu servio enviando outra mensagem ao processo de ligao com seu nome, sua verso e seu identificador. Quando um cliente solicita um servio, seu ordenador verifica se j est ligado ao servidor. Se no estiver, manda uma mensagem ao processo de ligao contendo o nome e a verso do servidor desejado. Se o servio no estiver disponvel, o processo de ligao retorna uma indicao de falha ao ordenador do cliente. Se houver um servidor adequado, o processo de ligao retorna o manipulador e o nmero de identificao do servidor. O ordenador do cliente ento envia mensagens ao endereo contido no manipulador, contendo os parmetros e a identificao do servidor. Esta identificao necessria para que o ncleo do servidor possa

41

direcionar a solicitao para o servidor correto. As vantagens na utilizao de processos de ligao incluem: a distribuio de carga; a tolerncia a falhas; e a autenticao. Havendo vrios servidores o processo de ligao pode auxiliar na distribuio da carga de trabalho respondendo aos clientes de acordo com algum critrio de distribuio dos servios entre os possveis servidores. Periodicamente, ou quando houver suspeita de falha, o processo de ligao pode pedir confirmao do servio para o servidor suspeito e, caso no obtenha esta confirmao em um prazo aceitvel pode cassar o registro do servidor. O servidor pode determinar ao processo de ligao quais clientes admite servir, desta forma, ao receber uma solicitao de servio o processo de ligao verifica se o requerente est na relao de possveis clientes do servidor requisitado. Caso no esteja, em vez de enviar os dados do servidor, o processo de ligao envia ao pretenso cliente uma mensagem de falha no servio. A principal desvantagem deste esquema a sobrecarga de trabalho no processo de ligao, especialmente se o sistema apresentar muitos clientes que buscam servios rpidos e muitas cpias dos servidores. Para reduzir, ou distribuir melhor a carga de trabalho no processo de ligao a soluo natural seria criar cpias do processo de ligao. Entretanto, esta soluo recai no problema de sobrecarga da rede de comunicao, devido necessidade de manter todas as cpias coerentes. Como mencionado anteriormente, embora as chamadas a procedimentos remotos sejam semelhantes conceitual e sintaticamente, elas diferem semanticamente das chamadas locais devido a falhas e excees na rede. As falhas so problemas causados por defeitos em clientes, servidores ou na rede de comunicao. Excees so condies anormais geradas na execuo de procedimentos dos servidores e ordenadores. Por exemplo, se um cliente no capaz de localizar um servidor pode ser que o servidor esteja fora do ar, mas tambm pode ser que ele esteja tentando acessar uma verso desatualizada do servidor. A queda do servidor caracteriza uma falha do sistema, o qual pode ou no ser alertado do ocorrido, dependendo das caractersticas de projeto do servidor e da razo de sua queda. Quando o servidor avisa sobre a falha o ncleo do cliente pode tentar solicitar o servio novamente at conseguir ao menos uma resposta de algum servidor, ou desistir assim que identifica o problema ao receber uma resposta atrasada ou mesmo nenhuma resposta. Quando o servidor no avisa nada o cliente pode tentar novamente at cansar, neste caso podendo receber de zero a um nmero indeterminado de respostas. A tentativa de acesso a uma verso desatualizada do servidor caracteriza uma exceo do sistema. Esta desatualizao pode ser causada pela compilao de um cliente antes de uma atualizao do ordenador de um servidor. Quando este cliente tentar utilizar o servio deste servidor ele solicitar ao processo de ligao acesso verso antiga do servidor. Entretanto, o processo de ligao j ter retirado de sua lista de servios disponveis, a pedido do servidor, sua verso antiga. Portanto, o processo de ligao retornar para o cliente uma mensagem indicando a inexistncia do servio solicitado. Pode ocorrer, tambm, do cliente solicitar um servio e quebrar antes de receber a resposta. Neste caso, o servidor fica com sua memria ocupada, e eventualmente outros recursos bloqueados, por no poder enviar a resposta. Estes procedimentos so ditos rfos, pois o servidor no tem como saber o que ocorreu com o cliente. Algumas solues para este problema so: (a) Extermnio: Quando um cliente que falhou volta a funcionar ele explicitamente elimina todos seus rfos. Isto requer que o cliente tenha conhecimento de suas atividades passadas e seja capaz de localizar os processos rfos. Para tanto, as informaes sobre cada chamada devem ser gravadas em disco. Alm disto, se os rfos tambm realizarem chamadas a procedimentos remotos criaro novos rfos, cuja localizao muito difcil, quando no impossvel. H ainda o problema da rede ser seccionada, pela queda de um gateway, por exemplo, deixando alguns rfos inacessveis. (b) Reencarnao: As solicitaes seguem com identificao do instante em que foram emitidas. Quando um cliente se recupera de uma falha ele faz uma transmisso geral, indicando o instante no qual ele re-iniciou suas atividades. Cada servidor verifica se possui algum processo de execuo remota iniciado anteriormente quele instante e, caso possua, tenta localizar seu proprietrio. Se no conseguir localiz-lo o servidor

42

descarta o processo. Esta soluo requer a inverso de papis entre clientes e servidores, complicando um projeto que, de outra forma, seria simples. (c) Expirao: A cada operao remota solicitada atribudo um perodo de tempo para sua execuo. Se no for concluda neste perodo o cliente deve solicitar explicitamente sua prorrogao. Se um servidor encontrar processos de execuo remota com perodo de execuo expirado ele os elimina. Para que isto funcione, quando um cliente quebrar, ele deve esperar um certo tempo antes de retornar, para garantir a eliminao dos rfos que, por ventura, tenha deixado no sistema. As chamadas a procedimentos remotos so a base de comunicao para aplicativos. Portanto, devem ser seguras, de forma a evitar a vulnerabilidade dos sistemas a ataques. Um dos aspectos que concorrem para a segurana dos sistemas que permitem a execuo de procedimentos solicitados remotamente a autenticao dos solicitantes, isto , a capacidade do sistema de verificar a identidade dos processos clientes e servidores. Outro aspecto importante questo da integridade, quando o sistema deve poder garantir que mensagens contendo solicitaes e respostas sejam entregues inalteradas aos respectivos destinatrios. Um terceiro aspecto a ser levado em considerao a questo da confidencialidade das informaes, neste caso o sistema deve garantir que mensagens de solicitao e de resposta no tenham seu contedo revelado a terceiros. Note-se que enquanto o segundo aspecto diz respeito no modificao do contedo da mensagem, o terceiro corresponde no visualizao do contedo das informaes. Finalmente, o quarto aspecto que deve ser levado em conta a originalidade das mensagens, isto , a garantia pelo sistema de que as mensagens no apaream mais do que uma vez. O principal mecanismo para garantir os aspectos de segurana nos sistemas, mencionados acima, a criptografia. Resumidamente, consiste na utilizao de um conjunto de chaves pblicas e privadas (secretas). As pblicas so geradas a partir das secretas atravs de um algoritmo, de tal sorte que mesmo conhecendo o algoritmo a recuperao da informao seja computacionalmente intratvel sem o conhecimento da chave secreta.

43

Transaes
um conjunto de comunicaes assncronas tipo solicitao/resposta que satisfazem s propriedades de atomicidade, seriao e durabilidade. Estas propriedades visam a transparncia de concorrncia em sistemas distribudos, isto , permitem o compartilhamento de objetos sem interferncia. Elas so descritas nos pargrafos seguintes. A atomicidade tem por objetivo garantir a consistncia de objetos replicados. Para tanto, ou todas as operaes de uma transao so executadas ou nenhuma delas o , mesmo em presena de falhas. A transao deve parecer indivisvel para o mundo externo. Atravs da propriedade de seriao busca-se manter a consistncia dos resultados. A execuo de transaes entrelaadas equivalente execuo das transaes em alguma ordem serial. Transaes concorrentes no podem interferir entre si. Com a propriedade de isolamento deseja-se proporcionar a consistncia de percepo do estado do sistema. Os resultados parciais de uma transao incompleta no so visveis a outras, antes que os participantes da transao entrem em acordo a seu respeito. Por meio da propriedade de durabilidade procura-se complementar a idia de consistncia de percepo do estado do sistema. Neste caso, o sistema garante que os resultados de uma transao, para as quais j se tenha chegado a um acordo, se tornaro permanentes, mesmo que ocorra uma falha depois da concordncia das partes. Uma vez que (e somente quando) as partes envolvidas numa transao entrem em acordo, as mudanas efetuadas passam a ser permanentes. Todas as propriedades dizem respeito consistncia, motivo pelo qual a segunda foi chamada de seriao. As duas ltimas propriedades (isolamento e durabilidade) poderiam ser combinadas em uma s, dita permanncia dos resultados. Neste caso, juntando-se as iniciais das propriedades: permanncia, atomicidade e seriao, tem-se PAS. Para viabilizar a coordenao das atividades, o processador que iniciar uma transao tomado como coordenador, os demais como participantes. Inicialmente, o coordenador informa a todos os processadores participantes sobre as solicitaes. A transao se encerra quando todos os participantes concordarem com a deciso de efetivar os resultados obtidos ou de abortar a transao. Esta deciso tomada em funo da possibilidade ou no de satisfazer as propriedades PAS.

Protocolo de aceitao em duas fases

Este protocolo envolve um coordenador, aquele que inicia uma transao, e os demais processos, ditos participantes da transao. Na primeira fase o coordenador registra a sua concordncia prvia com a transao e distribui a todos os participantes uma solicitao. Cada um dos participantes recebe a mensagem de solicitao. Se o participante estiver pronto para concordar com a transao ele registra sua concordncia (em carter precrio) e envia ao coordenador uma mensagem indicando sua concordncia. Caso contrrio, ele envia uma mensagem indicando sua discordncia e aborta o processamento interno. Durante esta fase o coordenador permanece coletando as respostas dos diversos participantes. Na segunda fase o coordenador computa a deciso final. Se houver unanimidade, isto , todos os votos recebidos forem favorveis concordncia com a transao, ele confirma sua concordncia (at ento prvia) e envia uma mensagem confirmando a transao. Caso no haja unanimidade, o coordenador envia uma mensagem informando a desistncia da transao e aborta seu

44

processamento interno. Cada participante recebe a informao sobre a deciso final. Se houve acordo geral o participante muda o status de sua concordncia, de precrio para efetivo, e procede qualquer processamento eventualmente relacionado com esta transao, enviando a resposta ao coordenador. Se no houve acordo geral o participante aborta o processamento desta transao. Durante o restante desta fase, se necessrio, o coordenador aguarda eventuais respostas dos participantes. Toda operao deve ser gravada em disco, em um arquivo log de atividades. Recuperao de falhas ocorre em trs situaes: - Quando as falhas ocorrem antes de um acordo prvio, o processo s necessita abortar a transao. - Quando as falhas ocorrem aps um acordo definitivo, o coordenador reenvia a mensagem de confirmao do acordo aos participantes, os quais devem atualizar os resultados. - Quando as falhas ocorrem entre um acordo prvio e um definitivo o coordenador pode abortar ou tentar retransmitir a mensagem de confirmao do acordo. Esta retransmisso s pode se efetivar se os participantes forem capazes de identificar duplicatas. No caso do participante falhar deve contatar outro, para verificar o estado da transao.

Coordenao Distribuda
Quando no h varivel compartilhada ou controlador comum, como quando processos tm que trocar informaes para chegar a uma concluso sobre o sistema ou entrar em alguma acordo, processos tm que coordenar seu funcionamento. A excluso mtua garante que processos concorrentes tenham acesso serial a recursos e dados. A excluso mtua entre processos pode ser controlada ou pode se dar atravs de disputas. Quando controlada, uma permisso de acesso nica circula entre possveis usurios e a circulao regulada, podendo o detentor da permisso acessar o recurso desejado. Quando se d por meio de disputa, cada processo compete livremente e de maneira eqnime pelo direito de acesso ao recurso do sistema. Esta competio baseada num critrio de resoluo, por exemplo, antigidade do pedido prioridade.

Por disputa
(a) MUTEX com prioridade temporal: - Cada processo que quer acessar um recurso envia um pedido com o tempo lgico (tempo de Lamport) em que o fez. - Cada processo, ao receber um pedido proceda da seguinte forma: se no fez pedido envia um pur (pedido de uso de recurso); se fez pedido, e o seu mais recente que o recebido envia um pur; se estiver usando recurso adia o envio do pur; se fez um pedido, e o seu mais antigo que o recebido adia envio do pur. - Quem receber pur de todos estar liberado para acessar o recurso. - Aps usar o recurso o processo envia uma nlr (notificao de liberao de recurso) para todos e um pur para os demais na fila. - Ao receber uma nlr cada processo: tira o processo que liberou o recurso da fila de requisies. se for o prximo da fila e tiver todos os pur acessa o recurso.

45

(b) Votao: - Encarando um pur como um voto, ao receber um pedido o processo vota somente naquele candidato. - Para evitar bloqueios (por exemplo, cada candidato com 01 voto) se um processo receber um pedido de um candidato com tempo inferior quele no qual ele j votou pode tentar mudar seu voto. Neste caso, envia uma solicitao de desistncia ao candidato em que votou. - Se o candidato no estiver usando o recurso, devolve-lhe uma confirmao de desistncia, caso contrrio, usa o recurso e posteriormente envia uma nlr. - Ao receber um uma confirmao de desistncia o processo pode confirmar a mudana de voto, desmarcando o processo que enviou a confirmao de desistncia e enviando seu voto para o processo mais atrativo. - Ao receber uma nlr, o processo remove aquele que enviou a mensagem, da fila de pendncias e vota no prximo da fila, isto , o mais antigo. - Um processo usa o recurso quando tiver a maioria dos votos.

Controlada
A excluso mtua controlada evita a sobrecarga de mensagens das abordagens por disputa. Usando uma mensagem de sinalizao para controlar o acesso ao recurso faz com que a circulao da mensagem seja garantida pela organizao lgica dos processos. As estruturas topolgicas possveis so em anel, em rvore e por irradiao, como discutidas a seguir. A estrutura em anel configura os processos segundo um anel ordenado logicamente. A posse de uma mensagem de controle d o direito, a determinado processo, de usar o recurso desejado. Esta organizao simples e no sujeita a bloqueios e justa, pois, a menos que algum processo esteja usando o recurso, a mensagem de controle fica circulando na rede para quem desejar usar. Um problema que este esquema gera trfego na rede mesmo que ningum queira usar recurso algum. Outro problema uma possvel demora para o recebimento da mensagem de controle, uma vez que o anel pode ser grande e todos os processos podem querer usar o recurso. Para compensar isto, a mensagem de controle pode levar informaes de status, por exemplo, nvel de prioridade definido pelo usurio ou uma marca de tempo. A estrutura em rvore configura os processos como uma rvore dinmica lgica. Cada processo mantm uma fila FIFO e um ponteiro para seu antecessor na rvore. A mensagem de controle fica com o processo na raiz da rvore. O processo que quer a mensagem de controle a solicita ao processo imediatamente anterior. Quando um processo recebe uma solicitao ele a coloca em sua FIFO e, se no possuir a mensagem de controle, a solicita para seu antecessor. Se ele possuir a mensagem de controle e a estiver usando aguarda, se no envia a mensagem de controle ao processo que a solicitou e corrige seu ponteiro para apontar para quem ele enviou a mensagem de controle. Se um processo possuir a mensagem de controle e no a estiver usando e sua fila no estiver vazia, ele envia a mensagem de controle para a primeira entrada na fila. A abordagem por irradiao utiliza um vetor, T, de marcas, indexadas pelo nmero do processo, as quais representam o nmero de vezes que o processo usou o recurso. Utiliza tambm uma fila, Q, de pedidos, que uma fila FIFO com os pedidos feitos. Cada processo mantm um nmero de seqncia local, com o nmero de vezes que solicitou o recurso, este nmero segue com todas as solicitaes. Cada processo mantm um vetor de seqncia, S, que contm o nmero de seqncia mais alto de cada processo, que tenha chegado ao seu conhecimento. Alm disto, cada processo mantm uma varivel com o nmero de seqncia da sua ltima solicitao. O algoritmo de funcionamento da excluso mtua controlada por irradiao o seguinte: 1- processo i requer uso de recurso irradiando uma solicitao (i, seq) 2- processo j recebe mensagem e atualiza a i-sima posio de seu vetor Sj[i]=max (Sj[i], seq) e coloca o nmero de i no fim da fila Q.

46

3- Se j possui a marca e no est usando, ele remove o processo no incio da fila (digamos k) e lhe envia a marca, desde que Sj[k] = Tj[k] + 1. 4- O processo k ento utiliza o recurso ao receber a marca. 5- Aps usar o recurso, k atualiza T fazendo Tk[k] = Sk[k] e compara seus vetores T e S, acrescentando a Q todo o processo r para o qual Sk[r]=Tk[r]=1, rk, que no esteja em Q. 6- Se Q no estiver vazia, volta ao passo 3. 7- Se Q estiver vazia, aguarda nova solicitao. Exemplo (emprestado do livro do Chow & Jonson [1]): Considerem-se quatro processos cuja situao inicial corresponde a todos os vetores S=[15,20,10,8], estando a marca de posse do processo P1, valendo T=[15,20,10,8] e Q=[]. Considerem-se a seguinte seqncia de eventos a partir desta situao inicial. Uma ilustrao deste exemplo pode ser vista no esquema includo logo aps esta listagem da seqncia de eventos. 1. P2, P3 e P4 solicitam a marca, emitindo mensagens do tipo (pid, seq) em que pid representa o identificador do processo que solicitou a marca e seq o nmero de seqncia da solicitao. Neste caso, os nmeros de identificao dos processos sero 1 para o processo P1, 2 para P2, 3 para P3 e 4 para P4. Ento as solicitaes irradiadas, de acordo com estas informaes e com a situao inicial, sero: (2,21), (3,11) e (4,9) para as solicitaes oriundas de P2, P3 e P4, respectivamente. 2. Suponhamos que a solicitao de P2 se atrase e que P3 tenha chegado instantes antes de P4. Todos atualizam seus vetores S nas posies correspondentes aos processadores P3 e P4, isto , Sj[3] e Sj[4]. P1 coloca os pid, na ordem em que foram recebidos, na fila Q. 3. P1 remove o pid=3 da fila, compara S1[3]=11 com T1[3]=10+1 e envia a marca (T e Q) para P3. 4. P3 usa o recurso. 5. P3 atualiza o vetor T, fazendo T3[3]= S3[3]=11. Neste instante todos recebem a solicitao de P2 e atualizam S1[2]. 6. P3 compara T e S e atualiza Q, incluindo pid=2 no fim da fila. 7. P3 remove pid=4 da fila, compara S3[4]=9 com T3[4]=8+1 e envia a marca (T e Q) para P4. 8. P4 usa o recurso. 9. P4 atualiza o vetor T, fazendo T4[4]= S4[4]=9. 10. P4 compara T e S e constata que Q est atualizado (no h novas solicitaes para serem includas na fila). 11. P4 remove pid=2 da fila, compara S4[2]=21 com T4[2]=20+1 e envia a marca (T e Q) para P2. 12. P2 usa o recurso. 13. P2 atualiza o vetor T, fazendo T2[2]= S2[2]=21. 14. P2 compara T e S e constata que Q est atualizado. 15. Como Q est vazia, P2 retm a marca at a chegada de nova solicitao. 1 P1 P2 P3 P4 15 15 15 15 2 21 21 21 21 3 11 11 11 11 4 9 9 9 9 1 15 15 15 15 2 20 21 20 20 3 10 11 11 11 4 8 9 8 9 4 2 Fila (Q) de Solicitaes 2

incio da fila 4

Vetor de Seqncia (S)

Vetor de Marcas(T)

47

Algoritmos de Eleio
Num sistema distribudo necessrio um processo capaz de coordenar diversas atividades, tais como, o acesso a certos recursos para garantir a exclusividade de uso, mecanismos para a deteco de impasses e a sincronizao de processos. Todavia, este processo coordenador costuma ser um ponto fraco do sistema, pois, sua falha pode impedir o seu funcionamento correto. A soluo vem a ser o desenvolvimento de algoritmos que possibilitem a eleio de um novo coordenador, to logo a falha do atual for detectada. Os mecanismos usados para a eleio podem ser divididos segundo o tipo de topologia do sistema em que atuam. Pode-se ter algoritmos adequados a topologias fixas, sejam elas arranjadas fsica ou logicamente, como as topologias em anel, em estrela ou em malha completamente conectada. Tambm pode-se identificar algoritmos adequados para topologias variveis, como aqueles utilizados em rvores dinmicas. Como exemplo de algoritmo para topologias fixas apresenta-se, a seguir, o algoritmo da fora bruta [8]. Cada processo tem sua identidade como sendo sua prioridade. O processo de maior prioridade o coordenador. Quando um processo nota a falta do coordenador, ele inicia a eleio do novo coordenador. A eleio procede de acordo com a seguinte lgica: 1- O processo que notou a falta do coordenador envia uma mensagem de eleio para todos os processos com identidade maior que o seu. Esta mensagem tem por finalidade identificar se algum dos processos de maior prioridade est ativo. 2- Se nenhum responder, o processo que iniciou a eleio se considera vencedor e se torna o novo coordenador. Neste ponto ele avisa os processos de menor prioridade sobre sua nova situao. Como possvel que vrios processos tentem se eleger o novo coordenador, antes deste status se definir, o processo deve aguardar o recebimento do reconhecimento de todos os processos de menor prioridade. 3- Se algum processo de maior prioridade responder, ele assume o controle da eleio e o que a iniciou aguarda. A seguir apresenta-se um exemplo de um algoritmo utilizado para topologias de estrutura varivel. Este algoritmo v o sistema como uma rvore cuja organizao pode ser modificada. Uma rvore um grafo acclico, com N ns interligados por N-1 canais de comunicao de forma que o custo de comunicao entre cada par de ns o mnimo possvel. O n coordenador a raiz da rvore. Para eleger um coordenador um ou mais processos irradiam para todos os ns da rvore uma mensagem de campanha para lder (CPL), incluindo o instante em que a mensagem foi gerada. Quando a mensagem recebida por um n-folha ele responde ao seu n-pai com um reconhecimento do CPL (um voto para determinado CPL). Uma vez que tenham votado os ns no aceitam outras mensagens CPL e aguardam o anncio de novo coordenador. Como podem haver vrias mensagens CPL, oriundas de processos diversos, transitando, caso um n receba mais de uma, ele vota naquele mais antigo (de menor tempo). Caso haja empate, o de maior pid, o escolhido. Quando todos os ns-filhos tiverem votado, o n-pai envia seu voto para o n-av, e assim por diante. Este algoritmo elege como novo coordenador aquele que iniciou o processo de eleio primeiro (com identificao de tempo menor), pois, ele ser o nico n que receber os votos de todos os seus filhos.

48

Acordo Distribudo
Este problema talvez o fundamental em sistemas distribudos. Consiste em determinar uma forma de fazer com que um conjunto de processadores cheguem a consenso sobre determinada informao. Formalmente, tem-se um conjunto de M processadores P = {p1, p2, ..., pM}, um subconjunto F dos quais no esto funcionando adequadamente F = {f1, f2, ..., fN}. Cada processador pi armazena um conjunto de valores V, baseado nos quais calculado um valor de acordo Ai. Para cada par de processadores pi e pj, funcionando normalmente, Ai=Aj o valor de consenso. O objetivo obter um algoritmo distribudo capaz de resolver este problema. Para testar estes algoritmos, utilizam-se adversrios. O adversrio um deamon que tem muito controle sobre o ambiente no qual o protocolo que estiver sendo testado executado. O adversrio tenta criar as piores situaes para a execuo do protocolo em teste, por exemplo, destruindo ou modificando mensagens ou alterando o protocolo de alguns dos processadores.

Falhas Bizantinas
Um protocolo bsico para resolver o problema de consenso conhecido como acordo bizantino e seu funcionamento pode ser explicado pela seguinte estria: Certa vez um sulto turco liderou uma invaso cidade de Bizncio. O imperador de Bizncio reuniu seus exrcitos para enfrentar os invasores. O comando de cada exrcito foi confiado a um general. Os exrcitos bizantinos marcharam ao encontro dos turcos e tinham fora suficiente para resistir a eles se agissem coordenadamente, isto , ou todos atacassem ou todos recuassem. Aps alguns dias de marcha, os exrcitos bizantinos acamparam perto dos turcos. Os generais bizantinos pretendiam atacar ao amanhecer, mas cada um tinha a sua prpria opinio sobre o poderio do exrcito turco. Conseqentemente, tambm tinha sua preferncia sobre quando atacar e quando se retirar. Portanto, eles deveriam tomar uma deciso de consenso para definir se e quando atacar. Ento eles mandaram mensageiros para os acampamentos ao longo da noite para tentar definir esta deciso de consenso. Contudo, este esquema tinha dois problemas: Por um lado os mensageiros podiam ser simplesmente assassinados e a mensagem nunca chegar. Por outro lado, os generais bizantinos eram facilmente corrompveis e o sulto poderia pag-los para enviarem mensagens falsas a seus parceiros para tentar evitar que eles chegassem a um acordo coerente. Sabendo destes problemas, os generais concordaram em analisar todas as mensagens recebidas e tomar como deciso de consenso a opinio da maioria. Caso houvesse empate, a deciso seria a de defender seus exrcitos, no atacando. Para organizar a comunicao estabelecida uma ordem para que cada general distribua sua opinio aos demais generais. Para que este consenso seja possvel, necessrio que o nmero total de generais seja no mnimo igual ao triplo de generais corrompidos mais um. Embora seja possvel chegar em um acordo, o nmero de mensagens necessrio grande, pois cada general alm de enviar sua opinio aos demais deve transmitir as informaes que recebeu dos demais a todos os outros. Imagine que se tem M generais, N dos quais foram corrompidos. Cada general tem sua opinio Oi e recebe dos demais as respectivas opinies Oj, j i. Cada general forma um conjunto de decises da seguinte maneira: Di = {di1, di2, ..., diM} dii = Oi dij = Oj se os valores recebidos do j-simo general forem majoritariamente Oj, caso contrrio fazem dij = recuar.

49

Finalmente, a deciso com maior nmero de votos em Di tomada. Caso haja um empate a deciso no atacar. Por exemplo, supondo quatro generais, trs dos quais esto sob o comando geral do outro. Supondo que um dos generais foi corrompido. Neste caso possvel chegar a um consenso porque h generais suficientes. Inicialmente o general no comando manda sua opinio aos demais. Em seguida cada um dos trs generais comandados envia aos outros dois a mensagem que recebeu do comandante. Por fim, cada um dos generais determina a deciso de consenso, baseado nas informaes recebidas. Esta situao est esquematizada na figura abaixo. Como pode ser visto, neste caso, cada general recebe trs comandos para atacar e um para recuar. Ento, mesmo com um general desonesto tentando ludibriar os outros, atravs da retransmisso de mensagem com as ordens alteradas, possvel chegar a um consenso sobre o valor correto.

A C A A A A G2 G1 A A A G1

A G2

R R ? R G2

desonesto

G3 A G3 R G1

G3

Para tornar o problema mais geral e dar-lhe um aspecto computacional, tornar-se-o os generais por processadores e se usar um parmetro t para representar o nmero mximo de traidores aceitvel. Desta forma, o protocolo dos generais bizantinos parametrizado a t traidores, GB(t) chegar a um consenso correto se M > 3t e N t. Isto significa que para poder admitir at N = t processadores falhos e ainda assim chegar a concluses corretas, o sistema necessitar de pelo menos M = 3t+1 processadores. Este algoritmo tem um custo computacional exponencial em t, ou seja, o nmero de mensagens no sistema O(Mt). possvel fazer algumas restries ao problema, para reduzir o nmero de mensagens em trnsito, reduzindo seu custo computacional. De qualquer forma, processadores que no funcionam corretamente no costumam atuar com tanta eficincia para obstruir o bom funcionamento do sistema. Portanto, de um ponto de vista de engenharia, no compensa tentar tornar o sistema imune a falhas bizantinas. Geralmente vale mais a pena empregar os recursos necessrios para tanto na melhoria dos componentes do sistema e no desenvolvimento de tcnicas de engenharia de programas aplicadas a sistemas distribudos. Ainda assim, o estudo do protocolo dos generais bizantinos interessante, do ponto de vista computacional, devido ao grande volume de trabalho desenvolvido para torn-lo eficiente. Estes trabalhos geraram solues computacionais importantes.

50

Impossibilidade de Consenso
O modelo de falhas bizantinas subentende consenso em um ambiente bastante adverso. Mesmo assim, apesar do esforo computacional exigido, foi mostrado que possvel aos processadores entrarem em acordo a cerca de informaes existentes no sistema. Entretanto, ao analisar as falhas bizantinas supunha-se um sistema sncrono, no qual todos os processadores que estivessem em condies de funcionamento transmitiriam suas opinies dentro de um perodo de tempo pr-estabelecido. Ao tratar sistemas distribudos assncronos no se tem esta garantia de resposta em tempo pr-definido. De fato no h algoritmo capaz de garantir que todos os processadores em funcionamento cheguem a um consenso em tempo finito. Diante desta incapacidade, pode-se demonstrar que impossvel para um sistema distribudo assncrono chegar a um consenso, mesmo na ausncia de falhas bizantinas. Fischer, Lynch e Patterson [9] demonstraram formalmente esta impossibilidade. Esta demonstrao consiste em provar que h casos nos quais o protocolo fica impedido de chegar a um consenso. O problema com esta demonstrao abrir espao para se argumentar que sendo impossvel chegar a um consenso os sistemas distribudos so inteis. No obstante, para contradizer estes resultados tericos os sistemas distribudos assncronos tm sido desenvolvidos e amplamente utilizados. Ento a teoria estaria errada? No, em verdade o que ocorre que sistemas reais no garantem 100% de funcionamento correto. Ao produzir um sistema admite-se o uso de protocolos parcialmente corretos, desde que sejam suficientemente robustos e falhem apenas em algumas situaes raras. Quando isto ocorrer lana-se mo de interveno humana para identificar o problema e resolv-lo. Como s vezes as situaes supostamente raras no so to raras como se espera, uma alternativa dotar o protocolo de um certo grau de indeterminismo de tal sorte que ao ser executado com os mesmos dados, ele no recaia sempre no mesmo ponto de falha. Embora ele possa vir a falhar por razes menos nobres, as falhas passam a ser menos freqentes e no sistemticas. Uma terceira alternativa admitir uma consistncia parcial, isto , em vez de exigir que todos os processadores entrem em acordo sobre determinada informao, exige-se apenas daqueles processadores que desejem cooperar. Desta forma, somente as opinies de processadores que estiverem respondendo suficientemente rpido sero consideradas.

Consenso Distribudo Aleatrio

A facilidade de entrar em acordo inversamente proporcional aos obstculos enfrentados pelos algoritmos. A dificuldade de se chegar a um consenso motivou vrias pesquisas recentes para o desenvolvimento de protocolos que incorporam no determinismo na busca pelo consenso. Estes protocolos, ao invs de manterem processadores aguardando indefinidamente pela resposta de seus pares, param aps um certo nmero de passos. O mais bsico destes protocolos usa o conceito de memria compartilhada. Tem-se M processadores, N dos quais pode falhar. Tem-se um vetor V com a preferncia de cada processador. Se em algum instante vi for igual para todos os processadores, tem-se um consenso. Se no houver um consenso, o i-simo processador tira cara ou coroa e escolhe seu novo valor de preferncia. Eventualmente todos vo concordar com o mesmo valor. Infelizmente, h alguns problemas com este protocolo. O primeiro problema que ele admite que o sistema sncrono, pois requer que os processadores do sistema aguardem a sua vez para testar V e decidir sobre o consenso. Uma alternativa para tornar o algoritmo assncrono seria associar a vi o

51

nmero de ciclos que o processador pi j executou. Quando todos os processadores estiverem no mesmo ciclo e preferirem a mesma coisa, o consenso foi encontrado. O segundo problema que processadores podem falhar e, conseqentemente, no atualizaro seu nmero de ciclos, inviabilizando o acordo. Uma alternativa para isto se concentrar nos processadores mais rpidos. Permitindo-se que apenas os processadores mais rpidos e aqueles com um ciclo a menos que os mais rpidos discordem e obrigando os mais lentos a concordarem com os mais rpidos possvel contornar o problema com os processadores que vierem a falhar durante a execuo do algoritmo.

52

Escalonamento de Processos
Para que um processo possa ser executado em um sistema qualquer, deve-se determinar quando ele poder usar a CPU e quais recursos estaro disponveis. Se o sistema for distribudo, alm disso, deve-se definir em qual processador ele dever ser executado. O objetivo do escalonamento resolver estas questes melhorando, na medida do possvel, as mtricas de desempenho global do sistema, tais como tempo de execuo dos processos e a taxa de uso dos processadores. Contudo, estas melhorias no devem comprometer muito os aspectos de transparncia de desempenho e de posio. Os sistemas tradicionais foram projetados para mquinas cujas arquiteturas tinham pouca, ou nenhuma, capacidade de reconfigurao. O uso de diversas mquinas e de malhas de comunicao configurveis traz outras questes baila. Por exemplo, passa a haver a necessidade de se considerarem atrasos de comunicao, a capacidade do meio de comunicao para a migrao de processos e a sincronizao de processos.

Modelos
As estratgias de escalonamento seguem modelos que podem ser classificados segundo o grau de interao entre os processos no sistema, os quais podem necessitar de troca significativa de informaes durante sua execuo ou podem rodar de forma essencialmente desconexa. Portanto, tem-se dois modelos bsicos, quais sejam: de processos interativos e de processos disjuntos. Os modelos de processos interativos podem ser ainda subdivididos em modelos de precedncia e de comunicao. Os modelos interativos de precedncia tm por objetivo principal minimizar o tempo total para a execuo das tarefas, incluindo-se o tempo necessrio ao cmputo dos procedimentos internos aos diversos processos cooperantes e o tempo devido comunicao entre eles. Por outro lado, os modelos interativos de comunicao tm como meta otimizar os custos devido comunicao e aos cmputos. Enquanto nos modelos de precedncia os processos concorrentes so gerados por construtores de linguagens e por via de conseqncia resultam em processos cujo interao se d na forma sncrona, nos modelos de comunicao os processos que coexistem se comunicam de forma assncrona. J no modelo de processos disjuntos, a interao se d de forma implcita e os processos podem ser executados de forma independente. No caso deste modelo, o objetivo maximizar o uso dos processadores, minimizando o tempo de resposta (tempo de servio + tempo na fila de espera) dos processos. Para atingir seus objetivos, os modelos de escalonamento podem incluir estratgias migratrias ou no. Por migrao, neste escopo, refere-se possibilidade de um processo mudar de mquina durante sua execuo. A migrao de processos busca reduzir o tempo gasto pelos processos na fila de espera por processamento. O custo mais importante para se conseguir isto uma sobrecarga no sistema de comunicao. A migrao facilita o compartilhamento de carga entre os processadores. Distribuir mais eqitativamente a carga, respeitando as oscilaes na capacidade de processamento do sistema, pode melhorar seu desempenho. Todavia, se os processos no forem disjuntos sua migrao pode resultar na colocao de processos fortemente conexos, isto , com grande necessidade de comunicao, em processadores diferentes, aumentando os requisitos do subsistema de comunicao e, conseqentemente, comprometendo o ganho obtido com o compartilhamento da carga de processamento. Resumindo o que foi visto at agora, os modelos de escalonamento tm por objetivo maximizar a utilizao dos processadores do sistema para minimizar o tempo mdio e a taxa de resposta dos

53

processos a ele submetido. O grau de utilizao do processador medido atravs do nmero de ciclos da UCP gastos efetivamente com servios para o usurio. O tempo mdio de resposta, uma das variveis a serem minimizadas, corresponde ao quociente entre a soma dos tempos de processamento mais os tempos de espera de todos os processos e o nmero total de processos considerados. O outro parmetro a ser minimizado a taxa de resposta, a qual corresponde relao entre o tempo efetivamente gasto por um processo para ser executado em determinada mquina e o tempo gasto pelo mesmo processo para ser executado sozinho na mesma mquina. De modo geral, exceto para casos muito simples, o escalonamento para otimizar o tempo total necessrio para completar a execuo de um conjunto de processos iterativos (dito makespan) NP-Completo. Alm de ter soluo muito difcil, a utilizao de algoritmos determinsticos requer o conhecimento prvio das necessidades de todos os processos do sistema, tais como seus requisitos de comunicao, os arquivos que cada um precisar e quando cada arquivo ser usado, a carga de processamento de cada processo e suas necessidades de utilizao de outros recursos. No sendo possvel um conhecimento exato destas necessidades, no mnimo devem estar disponveis aproximaes estatsticas muito precisas. Quando isto no possvel, porque os requisitos dos processos podem mudar radicalmente de uma hora para outra, necessrio usar mtodos heursticos para proceder o escalonamento. Tambm, a busca da soluo tima pode ser muito cara devido complexidade do algoritmo necessrio, quantidade de informaes que devem estar disponveis e ao rigor requerido do processamento. O bom senso ainda diz que, se um algoritmo relativamente simples puder fornecer resultados suficientemente prximos dos obtidos com algoritmos mais complexos recomendvel a utilizao do mais simples. Como os bons algoritmos heursticos para escalonamento distribudo conseguem fazer um balanceamento da carga de processamento de forma aceitvel, bem como sobrepor comunicao e computao escondendo ao mximo os detalhes de comunicao e atingindo a maior concorrncia possvel, usualmente os algoritmos utilizados para o escalonamento de processos so heursticos, distribudos e sub-timos. Pode-se dividir os algoritmos de escalonamento em dois grandes grupos: os de distribuio esttica e os de distribuio dinmica. Os estticos tratam do problema de compartilhamento de carga, isto , procuram distribuir eqitativamente a carga de processamento antes mesmo do incio da execuo dos processos. Os dinmicos tratam do problema de balanceamento de carga, ou seja, procuram ajustar as oscilaes na carga de processamento durante a execuo dos processos, para que todos os processadores tenham suas potencialidades exploradas ao mximo possvel.

Escalonamento Esttico
Para fazer a partilha da carga de processamento os algoritmos de escalonamento estticos procedem o mapeamento de processos em processadores antes da execuo dos processos. Por princpio estes algoritmos consideram os processos no preemptveis, ou seja, uma vez iniciado o processo s deixa o processador aps concluda sua execuo. Para obter um bom resultado estes algoritmos devem dispor de dados sobre o comportamento dos processos, tais como: tempo estimado de execuo, relaes de precedncia e padres de comunicao.

54

As principais desvantagens so que as decises sobre o escalonamento so centralizadas e imutveis. Alguns algoritmos de escalonamento esttico levam em considerao as relaes de precedncia entre os processos e outros seus padres de comunicao, como visto a seguir.

Modelo de Precedncia
Neste modelo so usados dois grafos com informaes sobre os processos e os processadores. O grafo de informaes sobre os processadores indica o custo da comunicao entre eles, considerando nulo o custo de comunicao entre processos alocados a um mesmo processador. Um exemplo com trs processadores pode ser visto no grafo da figura a seguir, em que os ns representam os processadores do sistema e os nmeros associados s arestas representam o custo de comunicao entre os processadores.

P1

P3

1
P2

0
O grafo de informao sobre os processos representa, em seus ns, os processos e os respectivos tempos estimados para sua execuo. As arestas deste grafo so dirigidas, representando as precedncias entre os processos. Isto significa que se um processo A estiver na origem de uma aresta e um processo B em seu destino, o processo B s poder ter sua execuo iniciada aps receber os resultados do processo A, pois aquele depende destes. Alm desta relao de precedncia, s arestas so associados nmeros indicativos da quantidade de mensagens, com resultados, a serem transferidos de um processo a outro. Um exemplo de grafo de precedncia com 7 processos apresentado na prxima figura. Pode-se ver, por exemplo, que o processo G depende, para sua execuo, de resultados oriundos dos processos D, E e F. Tambm pode-se ver que o processo E leva seis unidades de tempo para ser executado e que o incio de sua execuo depende da recepo de quatro mensagens vindas do processo A e uma outra do processo C. A/6 B/5 C/4

4 1 3
D/6 E/6

F/4

2 1
G/4 55

Como primeira aproximao pode-se usar a estratgia de escalonamento por lista, isto , tomando por base o grafo de precedncias e sem considerar o custo de comunicao, procura-se alocar os processos de modo que nenhum processador fique ocioso se houver alguma tarefa que ele possa processar. Para o caso do grafo de precedncia da figura anterior o escalonamento por lista resulta na seguinte distribuio:

P1 P2 P3

A/6 B/5 C/4 2

D/6 F/4 E/6 7

G/4

Note-se que neste caso o makespan de 16 unidades de tempo, sendo o caminho crtico ADG ou AEG. Todavia, para que se tenha um escalonamento realista necessrio levar em considerao os tempos de comunicao entre os processos. Neste caso pode-se usar o escalonamento por lista estendido, mostrado na figura a seguir, e que resulta num makespan de 28 unidades de tempo. P1 A/6 P2 B/5 P3 C/4 2 2 10 F/4 D/6 17 E/6 8 10 G/4

Nota-se da figura acima que o makespan aumentou muito devido ao tempo de comunicao entre processos. Principalmente pelo fato do processo E ter sido alocado a um processador (P3) diferente daquele ao qual foram alocados os processos A e G (P1). Pior que isto o fato do custo de comunicao entre P1 e P3 ser o mais elevado do sistema. Quando no for possvel, como neste caso, alocar de forma eficiente todos os processos em caminhos crticos a um mesmo processador deve-se, ao menos, tentar aloc-los a processadores com menor custo de comunicao. Procurando otimizar este aspecto utiliza-se o algoritmo ETF (Earliest Task First) que computa o tempo de comunicao durante o escalonamento, alocando inicialmente a tarefa escalonvel primeiro. A figura abaixo ilustra o resultado deste algoritmo para o exemplo utilizado at aqui. P1 P2 P3 A/6 B/5 C/4 4 2 E/6 D/6 F/4 6 1 G/4 6

Neste caso verifica-se um makespan de 18 unidades de tempo, bem prximo do ideal. Note-se que, inicialmente, somente A, B e C podem ser executados, sendo cada um alocado a um processador. Ao concluir a execuo de B e C libera-se F para execuo. Alocando F em P2, correspondendo execuo de F o mais breve possvel, forar-se- a alocao de D e E a P1 e P3, respectivamente, ou vice-versa. Entretanto, isto levaria a situao semelhante ao resultado do escalonamento por lista estendida. A melhor soluo atrasar o incio da execuo de F em uma unidade de tempo, o suficiente para aloc-lo ao processador P3. Neste meio tempo conclui-se o processamento de A, liberando D e E para execuo. Se D for alocado a P1 e a E a P2, suas execues iniciaro nos instantes correspondentes a 8 e 10 unidades de tempo, respectivamente, devido aos atrasos relativos comunicao dos resultados entre P1 e P2. Por outro lado, se a alocao for invertida, isto , D em P2 e E em P1, o processamento de E pode iniciar imediatamente aps a concluso de A (no

56

instante 6) e o de D pode iniciar uma unidade de tempo depois. Nota-se assim que a soluo apresentada a melhor possvel para o problema em questo.

Modelo de Comunicao
Freqentemente, processos so independentes e no necessitam obedecer relaes de precedncia, precisam apenas trocar informaes, isto , se comunicar. Neste caso o algoritmo pode levar em conta a minimizao de uma funo de custo cujos parmetros so o custo de execuo de um processo em um dado processador, representado por ej(pi), e o custo de comunicao entre dois processadores, representado por ch,k (ph, pk), considerando-se nulo o custo de comunicao entre dois processos que estiverem sendo executados no mesmo processador, ou seja, ci,i (pi, pi) = 0. A funo a ser minimizada : Custo (G,P) =

ej(pi) +

ch,k (ph, pk),

h,k A(G)

onde G(V,A) um grafo em que

j V(G)

os vrtices (V) representam os processadores do sistema e s arestas (A) esto associados pesos referentes ao custo de comunicao entre os processos em seus extremos. Um exemplo apresentado na tabela e grafo a seguir:

Processo

Custo no Processador A B 10 4 3 2 4

1 2 3 4 5 6

5 2 4 6 5

Custo de Computao

6 2 8

1 4 3

12 6

12 3 4 5 5 11

57

Custo de Comunicao
Neste exemplo tem-se dois processadores A e B e seis processos. O custo de computao de cada processo em cada processador mostrado na tabela acima, em unidades de tempo genricas. H de se notar que o processo 2 tem um tempo de execuo infinito no processador B. Situao anloga ocorre com o processo 6 no processador A. Isto significa que o processo 2 no pode ser executado no processador B, assim como o processo 6 no pode ser executado no processador A. Estas situaes podem ocorrer, por exemplo, devido falta de recursos nos processadores para executar determinados processos. Para casos com o deste exemplo, onde se tem dois processadores, h uma soluo obtenvel em tempo polinomial. Aumentando-se o grafo de comunicao com os ns referentes aos processadores e incluindo arestas com os custos respectivos, obtm-se um grafo de trabalho. Neste grafo, uma aresta entre um processador e um processo tem o peso correspondente execuo do processo no outro processador. Por exemplo, o processo 4 leva 3 unidades de tempo para ser executado no processador B. Ento aresta entre o n correspondente ao processo 4 e o n correspondente ao processador A associado o peso 3. Situao simtrica ocorre com a aresta entre o n correspondente ao processo 4 e o n correspondente ao processador B, ou seja, a ela associado o peso 6; que o tempo necessrio para executar o processo 4 no processador A. Esta inverso se faz necessria, pois, uma vez obtido este grafo de trabalho o objetivo achar um corte no grafo, que minimize a funo de custo. O grafo de trabalho para o exemplo aqui apresentado, juntamente com o corte de custo mnimo, mostrado na figura abaixo.

10 4 A 4 3 2 2

1 4 8 3 12 3 4

12 6 2 4 6 5 11 5

Custo de Corte = 38

Observe-se que o custo de corte obtido somando-se os pesos das arestas interceptadas pela linha de corte e, neste caso, corresponde a 38 unidades de tempo. Este tempo obtido alocando-se o processo 6 no processador B e os demais em A. Ressalva-se que conforme os nmeros de processos e de processadores crescem, o problema torna-se NP-Completo e sua soluo computacional torna-se invivel.

Escalonamento Dinmico

58

O principal problema do escalonamento esttico a necessidade do conhecimento das informaes sobre os processos antes do procedimento ser aplicado.

O escalonamento dinmico ataca os problemas de balanceamento e de compartilhamento de carga durante a execuo dos processos, considerando que eles podem migrar de uma mquina a outra. A questo do compartilhamento de carga busca reduzir a ociosidade dos processadores atribuindo processos queles com filas de espera menores. A questo do balanceamento de carga tenta reduzir o tempo de resposta e atingir um certo grau de justia no sistema atravs da equalizao do tamanho das filas de espera. A idia chave para o funcionamento do escalonamento dinmico a poltica utilizada para a migrao dos processos. A transferncia de processos entre mquinas do sistema pode ser baseada em informaes locais, caso em que os algoritmos costumam ser simples porm muito distantes da otimalidade, ou baseada em informaes globais, quando a qualidade da alocao costuma ser melhor mas o custo computacional cresce significativamente. Uma poltica de transferncia baseada em informaes locais pode calcular periodicamente a carga da mquina em que o processo for criado. Quando esta carga estiver abaixo de um limiar pr-estabelecido, o processo executado na mquina em que foi criado, caso contrrio ele dever encontrar outra mquina para rodar. Uma poltica de transferncia baseada em informaes globais deve coletar informaes sobre a carga nas outras mquinas do sistema e, em funo destas informaes, decidir em qual mquina o novo processo deve ser executado. O procedimento de migrao pode ser iniciado pelo transmissor ou pelo receptor. No primeiro caso o processo que se considera sobrecarregado busca outro que esteja mais livre. No segundo caso o processador que estiver ocioso anuncia sua disponibilidade e aguarda que outro processador lhe envie servio. O procedimento de migrao sofre do problema de estabilidade, que consiste no fato do tempo necessrio aos algoritmos para atualizarem suas informaes sobre os processadores no ser nulo. Dessa forma possvel que processos fiquem pulando entre dois processadores devido ao assincronismo nestas atualizaes. Quando a carga de processamento relativamente baixa, a transferncia iniciada pelo transmissor produz resultados melhores. Ao iniciar um processo, nas transferncias iniciadas pelo transmissor, incrementa-se o tamanho da sua fila de processos. Se ele estiver abaixo de um limiar pr-fixado coloca-se o processo na fila de espera para execuo do processador transmissor. Caso o tamanho da fila seja maior que o limiar estabelecido, o transmissor testa possveis receptores. Se encontrar algum processador cuja fila esteja menor que a sua, ele transfere o processo para o receptor, caso contrrio ele mantm o processo na sua prpria fila.

59

O maior problema, neste caso, que quando a carga sobe muito todos os processadores se consideraro sobrecarregados e procuraro receptores para seus processos, o que sobrecarregar o sistema de comunicao, prejudicando o funcionamento do sistema. Em contraposio, pode-se deixar a tarefa de busca para os possveis receptores. Neste caso, sempre que a carga em um processador cair abaixo do limiar ele busca a carga em outros processadores. Para que este esquema funcione os processos devem ser preemptveis, pois sero inicializados, primeiramente, nos processos em que forem criados. Estes algoritmos so mais estveis quando a carga de processamento alta, mas deve-se tomar cuidado para transferir processos somente quando os benefcios obtidos com a migrao forem maiores que o custo com sua transferncia. Alm disso, os algoritmos de transferncia iniciados pelo receptor podem gerar muita sobrecarga no sub-sistema de comunicao quando a carga de processamento no sistema distribudo for muito baixa. Todos os tipos de distribuio de carga discutidos necessitam ativar a execuo de processos remotamente. Isto pode ser feito segundo o modelo cliente/servidor. Toda a comunicao feita indiretamente atravs de um elo lgico, fazendo os limites fsicos entre os processos local e remoto transparentes. Dependendo de como as mensagens de solicitao so interpretadas, podem-se Ter trs cenrios de aplicaes importantes, quais sejam:
(1) servio remoto: a mensagem interpretada como a solicitao de um servio conhecido em um local remoto, como em uma chamada a procedimentos remotos; (2) execuo remota: a passagem contm um programa para ser executado em local remoto. Mantm a viso da mquina que solicitou a execuo, usando a mquina remota s para aliviar a carga computacional. No preemptvel; (3) migrao de processos: a mensagem representa um processo sendo transferido a um local remoto, para continuar sua execuo. um mecanismo preemptivo.

Algoritmos Genticos
O funcionamento de um algoritmo gentico comea com uma populao inicial cujos indivduos evoluem atravs das geraes, tentando imitar a natureza biolgica. A populao inicial gerada aleatoriamente e a habilidade de seus indivduos se reproduzirem e propagarem suas caractersticas pelas vrias geraes depende do ajuste de cada um deles. No caso de algoritmos para o escalonamento de processos o juste de um indivduo definido como a diferena entre o makespan do indivduo com o maior makespan da populao e o makespan do indivduo considerado. Ressalte-se que o melhor indivduo, dito o melhor adaptado, aquele com o menor makespan e, consequentemente, com o maior ajuste. A transformao de geraes obtida por meio de alguns operadores genticos, tais como seleo, cruzamento e mutao, aplicados aos indivduos de cada populao. O funcionamento destes operadores visto a seguir. O operador de seleo torna possvel ao algoritmo tomar decises, de certa forma tendenciosas, para favorecer os bons indivduos na mudana de geraes. Para que isto ocorra so feitas rplicas dos indivduos melhor adaptados e os menos adaptados so eliminados. Conseqentemente, aps a seleo a populao tende a ser dominada pelos indivduos melhor adaptados. Iniciando com uma populao P1, esta transformao ocorre pela gerao iterativa de uma nova populao P2, com o mesmo tamanho de P1. Entende-se por tamanho de uma populao o nmero total de seus indivduos. Esta transformao se d da seguinte forma: Inicialmente, o melhor indivduo de P1 selecionado e uma rplica deste indivduo colocada em P2 (o indivduo mantido em P1). Ento 60

so feitas iteraes e, em cada uma delas, seleciona-se aleatoriamente um indivduo de P1. A probabilidade de escolha proporcional ao grau de ajuste do indivduo ao problema. feita uma rplica do indivduo escolhido e, a exemplo do caso inicial, o indivduo mantido em P1 enquanto sua rplica inserida em P2. O processo iterativo repetido at que P2 atinja o tamanho de P1. Observe-se que por este processo de seleo cada indivduo pode ser escolhido mais de uma vez ou mesmo nenhuma vez. Desta forma, os indivduos no selecionados (os quais devero ser com grande probabilidade os menos adaptados) so eliminados nas novas geraes. Os algoritmos genticos baseiam-se no princpio que o cruzamento de dois indivduos pode gerar rebentos com caractersticas melhores que ambos os pais. O operador de cruzamento parte de dois indivduos de uma populao e gera dois novos indivduos trocando parte das caractersticas genticas dos pais. Supondo que se tem dois pais, p1 e p2, cujas caractersticas genticas so dadas pelos binmios (p1a, p1b) e (p2a, p2b), respectivamente. Supondo que cada parte dos genes de um dos pais tenha o mesmo nmero de genes da parte correspondente do outro, isto , |p1a | = |p2a | e |p1b | = |p2b |. ento o cruzamento se d trocando as partes correspondentes dos pais, para gerar os filhos f1 (p1a, p2b) e f2 (p2a, p1b). Deste modo, cada rebento mantm algumas caractersticas dos pais. O problema que se uma das partes tiver genes correspondentes iguais em ambos os pais, as caractersticas correspondentes quele gene no sero alteradas pelo processo de cruzamento. Por exemplo, imagine-se as caractersticas genticas dos pais p1 e p2 representadas por (a1, a2, a3) e (b1, b2, b3), respectivamente. Imagine-se a1b1, a2b2 e a3=b3. Ento qualquer ponto que se use para cruzamento no produzir mudana no efeito do gene na terceira posio da seqncia. No pior caso, se os binmios para cruzamento forem ([a1,a2],[a3]) e ([b1,b2],[b3]), ao efetuar o cruzamento obtm-se os filhos f1 = (a1,a2,b3) e f2 = (b1,b2,a3). Entretanto, f1 = p1 e f2 = p2, pois a3 = b3. A forma de se introduzir diversidade nos indivduos da populao e evitar a situao recm descrita atravs do operador de mutao. Este operador produz uma pequena alterao em alguma caracterstica gentica de alguns indivduos. Tanto o gene a ser alterado quanto o indivduo so escolhidos aleatoriamente, com baixa taxa de probabilidade. Retomando o exemplo citado no pargrafo anterior, o operador de mutao seria aplicado a f1 e a f2, para escolher algum de seus genes ao acaso. Eventualmente, a terceira posio de f1 poderia ser escolhida, por exemplo. Neste caso, b3 seria modificado, ficando diferente de a3. Portanto, f1 passaria a ser diferente de f2 e, mais importante do que isto, os rebentos produzidos pelo cruzamento de f1 e f2 seriam diferentes dos pais, podendo resultar em possveis melhoramentos genticos. A estrutura de um algoritmo gentico um lao composto por uma seleo seguida por uma seqncia de cruzamentos e outra seqncia de mutaes. Aps a diviso aleatria da populao em pares de indivduos, os elementos destes pares so cruzados. Aps o cruzamento, cada indivduo da nova populao (ou no) modificado por um processo de mutao com baixa probabilidade. Esta probabilidade determinada no incio do processo e mantm-se constante durante toda a execuo do algoritmo. A condio para o trmino do algoritmo pode ser o estabelecimento de um nmero mximo de iteraes, a definio de um tempo mximo de execuo, a verificao da estabilidade dos resultados, etc. Um exemplo de aplicao de um algoritmo gentico puro aplicado ao escalonamento de tarefas em um sistema multiprocessador descrito por Hou et al. [10] e algumas melhorias feitas sobre este algoritmo so discutidas por Corra et al. [11].

Compartilhamento de Memrias Distribudas

H trs paradigmas importantes para a troca de informaes entre processos em sistemas distribudos, quais sejam, a passagem de mensagens, a chamada a procedimentos remotos e o compartilhamento de memria.

61

A comunicao via passagem de mensagens feita atravs da interpretao de dados transferidos no sub-sistema de comunicao. A chamada a procedimentos remotos uma comunicao em um nvel mais alto de abstrao que possibilita a troca de informaes atravs da passagem de parmetros entre processos utilizando o mecanismo de passagem de mensagens. O compartilhamento de memria possibilita a comunicao direta entre os processos em sistemas fortemente acoplados, ou seja, viabiliza a troca de informaes entre processos atravs de uma memria de uso comum ligada ao sub-sistema de comunicao. O problema da utilizao direta do mecanismo de passagem de mensagens a falta de transparncia. Por outro lado, embora a chamada a procedimentos remotos possibilite a comunicao de dados com transparncia, sua eficincia limitada pelo mecanismo utilizado. Como no possvel acessar diretamente o espao de endereamento de mquinas remotas, o compartilhamento real de informaes difcil, em particular quando se trata de estruturas de dados grandes e complexas, abarrotadas de apontadores. Por fim, o compartilhamento de memria, que poderia resolver os problemas de acesso transparente informaes reais restrito, em sua forma original, a sistemas fortemente acoplados. O objetivo primordial do compartilhamento de memrias distribudas viabilizar o compartilhamento direto de informaes entre processos comunicantes por meio da simulao de um espao de endereamento lgico compartilhado, sobre um conjunto de memrias locais distribudas fisicamente. Este conjunto de memrias chamar-se- Memria Compartilhada Distribuda (MCD). Para sua implementao utiliza-se o mecanismo de passagem de mensagens, o qual fica transparente por ser encapsulado em uma camada com programas para o gerenciamento e o mapeamento entre a MCD e o sistema de passagem de mensagens. Dependendo da localizao dos dados, a forma de acesso a eles deve ser diferente, isto , em um sistema distribudo fracamente acoplado, onde tenha sido implementado um sistema para compartilhamento de memria, os dados podem ser armazenados localmente, na memria do processador onde o processo estiver sendo executado, ou remotamente, na memria de algum outro processador. A forma para acessar os dados em um e no outro caso diferente. Em sistemas multiprocessadores de grande porte convm manter a parte do espao de endereamento mais freqentemente acessada por um conjunto de processos mais prxima do(s) processador(es) em que estiverem sendo executados, deixando o restante do espao de endereamento mais afastado. Os multiprocessadores com arquiteturas que permitem este tipo de hierarquia de acessos memria em vrios nveis so ditos sistemas com forma irregular de acesso memria ou, do ingls, sistemas NUMA (Non-Uniform Memory Access) [12]. Como este tpico, vrios outros aspectos do projeto e da implementao de MCDs so muito semelhantes aos que devem ser considerados para sistemas de memria cache de multiprocessadores (MCM). Por exemplo, a informao tratada em cada acesso memria pode consistir em uma palavra, um bloco de palavras, uma pgina ou um segmento. Esta dimenso corresponde granularidade do procedimento de acesso. A escolha da granularidade um item importante a ser considerado em ambos os casos. Outro aspecto importante em sistemas NUMA a possibilidade de mover pginas de memria compartilhada entre os mdulos de memria do sistema, ou copiar alguma pgina muito concorrida para diversos mdulos em processadores diferentes. Esta multiplicao de pginas em sistemas distribudos requer a manuteno do coerncia no sistema de memria. O controle de consistncia (ou da coerncia de memria) um aspecto muito estudado em MCDs e muito importante no projeto de MCDs.

62

Devido a esta analogia entre MCMs e MCDs e tendo em vista a quantidade de estudos j realizados para MCMs, que podem ser aplicados a MCDs, a seguir sero analisados alguns aspectos desses sistemas, quando aplicados em arquiteturas NUMA.

Arquiteturas NUMA
Para iniciar, a configurao genrica de uma arquitetura NUMA apresentada na Fig. 1, juntamente com suas verses para implementao de MCMs e MCDs. Na fig. 1-a v-se que uma mquina NUMA genrica composta por um conjunto de processadores, cada um dos quais com um mdulo de memria local. Alm deste conjunto de pares (processador, memria) h uma malha de comunicao interligando todos os conjuntos e, na interface entre cada par processador-memria e a malha de comunicao h um controlador cujo objetivo manter a coerncia do sub-sistema de memria. Nas Fig. 1-b e 1-c tem-se, respectivamente, as implementaes de MCMs e MCDs, como mencionado anteriormente e descrito nos dois pargrafos seguintes. Na fig. 1-b tem-se o diagrama do que seria uma implementao, sobre uma mquina NUMA genrica, de um sistema MCM. Neste caso, os mdulos de memria local so caches utilizadas principalmente para reduzir o tempo mdio de espera nos acessos memria e minimizar o trfego de acessos memria global. A memria global pode ser uma grande memria RAM compartilhada por todos os processadores, mas tambm pode ser um conjunto de mdulos de memria distribudos pelo sistema. O barramento, por sua vez, pode ser um barramento comum, mas isto tende a gerar grande disputa pelo seu uso. Alternativamente, possvel utilizar vrios barramentos, ou uma rede de conexo. Isto recomendvel, principalmente se o sistema for composto por muitos processadores e tiver vrios mdulos de memria compondo a memria global. Na fig. 1-c tem-se o diagrama do que seria a implementao, sobre uma mquina NUMA genrica, de um sistema MCD. Neste caso, no h uma memria global fsica. Os mdulos de memria locais so utilizados para formar um espao de endereamento global, correspondendo a uma grande memria virtual. Este espao de endereamento compartilhado por todos os processadores do sistema. Os processadores acessam cada poro no local deste espao de endereamento atravs de uma rede de conexo, geralmente formada como uma LAN (local area network) ou WAN (wide area network).

Processador (P1)

Mdulo de memria (MM1)

P2

MM2

...

Pn

MMn

CCM2 Controlador de coerncia de memria (CCM1)

CCMn

Malha de comunicao

Fig. 1-a: Diagrama em blocos de uma mquina NUMA Genrica

63

Memria Global Barramento Comum CCM 1 P1 M 1 P2 CCM 2 M 2 P3 CCM 3 M 3 processadores ... Pn CCM n M n caches locais Controladores de Coerncia

Fig. 1-b: Implementao de uma MCM Memria Virtual ... M 3 processadores

Rede de conexo Controladores de coerncia M n Memrias locais

CCM 1 P1 M 1 P2

CCM 2 M 2 P3

CCM 3

CCM n Pn

Fig. 1-c: Implementao de uma MCD Os atrasos para acesso aos dados nas memrias variam de acordo com a organizao hierrquica da memria e com as polticas de atualizao de dados. S para constar, pode-se citar o exemplo da mquina NUMA de Stanford, DASH[4], que consiste em 16 ns de processamento, cada um dos quais com quatro processadores. Cada processador possui uma memria cache de 64 Kbytes no primeiro nvel, as quais formam um segundo nvel com 256 Kbytes. A rede de conexo uma malha bidimensional roteada como rosca sem fim. A coerncia na memria mantida por um protocolo que se reporta a uma estrutura especial de diretrio para invalidar cpias dos dados aps a escrita em uma delas. O acesso a dados se d em quatro estgios possveis, quais sejam: local, remoto em dois passos, remoto em trs passos ou ausente. Nos trs primeiros casos o dado encontrado na cache e no quarto necessrio um acesso memria global. As latncias tpicas so, respectivamente, de 1, 30, 100 e 135 ciclos de relgio do processador. O principal objetivo das MCDs alcanar transparncia do sistema e o das MCMs e melhorar o acesso memria. Para atingir seu objetivo as MCMs exploram as localidades temporal (freqncia de referncia) e espacial (proximidade das instrues) de programas aplicativos. Apesar dito, aplicaes distribudas precisam compartilhar informaes e conforme aumenta o nmero de processadores o barramento se torna o gargalo do sistema. A soluo de hardware para este problema o aumento da banda de passagem da memria utilizando-se vrios barramentos ou uma rede de ligaes

64

escalonvel. A soluo por software fazer vrias cpias da mesma informao em mdulos de memrias locais, para evitar a necessidade de acessos globais. Em MCDs implementadas sobre redes fracamente acopladas a abordagem por software parece ser a nica vivel. As MCDs conseguem prover a transparncia na comunicao de dados usando o mecanismo de passagem de mensagens. Com isto os usurios no precisam se preocupar com o movimento e eventuais converses de dados, com o tratamento de parmetros necessrios troca das mensagens ou com a manipulao dos detalhes dos protocolos de comunicao. Outras vantagens das MCDs so que o trfego entre o processador e o sistema de memria fica menos sensvel ao tamanho da rede de comunicao; que a compreenso do sistema e sua implementao se tornam relativamente fceis devido grande quantidade de coisas feitas para uniprocessadores; e que o sistema pode ser facilmente escalado, uma vez que para aumentar o espao de endereamento basta aumentar a quantidade de mdulos de memria.

Alocao, Migrao e Cpia de dados

O objetivo de se alocar, migrar ou copiar dados no sistema de memria minimizar o tempo mdio de acesso aos dados. Para isto, deve-se colocar a maior quantidade possvel de dados na memria local em MCMs ou em MCDs. Quanto maior a quantidade de dados disponveis nas memrias locais, maior ser a taxa de sucesso nas buscas (TSB) locais e, consequentemente, menor ser a necessidade de buscas em mdulos remotos. Portanto, quanto maior a memria local, melhor a TSB. Alm do tamanho da memria local h outros dois tamanhos que influem na TSB, so eles: o da unidade bsica para o compartilhamento de dados; e o da unidade buscada quando h um insucesso na busca local. Embora possam ser diferentes (palavras, linhas, pginas,...), o uso de blocos iguais em ambos os casos facilita tanto a implementao do sistema quanto a discusso a seguir. O tamanho do bloco influencia significativa e dicotomicamente a TSB. Quanto maior for o bloco, maior ser a cobertura na localidade das referncias e, portanto, maior ser a TSB. Por outro lado, blocos muito grandes trazem consigo muita informao irrelevante para o processamento atual, podendo remover informaes teis j presentes na memria local, para lhe abrir espao, reduzindo assim a TSB. Alm disto, o sistema de controle de coerncia necessita que as referncias a blocos sejam armazenadas em uma estrutura de diretrios (ou uma tabela) para a localizao e eventual gerenciamento das cpias. Se forem utilizados blocos grandes haver menos blocos no sistema e o espao de memria necessrio para armazenar esta estrutura ser menor, isto significa menos sobrecarga no sub-sistema de memria. Entretanto, blocos grandes gastam mais recursos para serem transferidos, representando maior sobrecarga para o sub-sistema de comunicao. Todavia, por consideraes diametralmente opostas a estas, o uso de blocos pequenos geram pouca sobrecarga no sub-sistema de comunicao e muita sobrecarga no sub-sistema de memria. Quando ocorre um insucesso na busca local os dados desejados devem ser acessados remotamente, isto pode ser feito por migrao ou cpia do bloco correspondente. A migrao corresponde eliminao do bloco de um mdulo de memria seguido da sua implementao no mdulo requisitante. A cpia consiste na criao de rplicas do bloco em vrios mdulos de memria. Quando se utiliza o processo de migrao o problema de coerncia se restringe coerncia entre a nica cpia do bloco no sistema e seu original na memria principal. A migrao pode se dar por iniciativa do processador que detm a cpia do bloco, o qual ao detectar que determinado bloco no lhe tem mais serventia no momento ele o oferece a outro processador na expectativa de que o outro 65

use o bloco em futuro prximo. Este esquema no muito usado por requerer uma carga de gerenciamento e uma sobrecarga no sub-sistema de comunicao, muitas vezes desnecessrias. O mais usado a migrao sob demanda, na qual o processador que detm a cpia a mantm at que ela seja solicitada por outro processador ou eliminada para dar lugar a outro bloco. O problema com o esquema de migrao o efeito pingue-pongue, que ocorre quando um processador A solicita um bloco que est armazenado em outro processador B. O bloco transferido de B para A, mas em seguida o processador, que cedeu o bloco, necessita dele novamente, requisitando a transferncia do bloco de A para B. Logo aps esta Segunda transferncia o processador A requer novamente o bloco. Desta forma h uma seqncia de transferncias do mesmo bloco entre os dois processadores, provocando uma sobrecarga no subsistema de comunicao. Este problema pode ser agravado quando ocorre um falso compartilhamento, isto , quando o processador A necessita de uma informao no incio do bloco e o processador B necessita de outra informao no final do bloco. Isto ocorre principalmente com blocos muito grandes e poderia ser evitado se o tamanho do bloco fosse reduzido. Para evitar o problema do efeito pingue-pongue pode-se fazer diversas cpias de certos blocos compartilhados, melhorando a concorrncia no sistema, alm de reduzir a sobrecarga do subsistema de comunicao. Ressalte-se que alm da sobrecarga no subsistema de comunicao, pode haver um problema de latncia na transferncia dos blocos, isto , um processador pode ser obrigado a esperar que o outro termine de usar o bloco, caso o tempo entre dois acessos consecutivos por um mesmo processador seja menos que o tempo necessrio para a transferncia e o uso do bloco pelo outro processador. O principal inconveniente do uso de rplicas o custo computacional acrescido pelo sistema de controle de coerncia de dados.

Modelos de Consistncia de Memria

Nas MCDs o compartilhamento das informaes se d na prpria memria em que os processadores so tambm armazenados. Isto significa que se esta memria no estiver totalmente consistente, no s os resultados dos processos, mas suas prprias integridades, podem ser comprometidas. Por exemplo, se alguma varivel utilizada para a sincronizao dos processos for afetada, os processos podem no ser sincronizados adequadamente e podem, at mesmo, falhar. Os termos consistncia e coerncia so, geralmente, utilizados como sinnimos. Todavia, Chow e Johnson [1] sugerem uma distino entre eles. Coerncia seria utilizado com um sentido mais restrito, enquanto consistncia teria uma conotao mais relaxada no que se refere ao ordenamento temporal de eventos. Desta forma, a definio destes termos com base nas operaes de escrita e leitura seriam: (a) um sistema coerente quando uma operao de leitura sempre retorna o valor dado pela ultima escrita na mesma varivel compartilhada; e (b) um sistema consistente se todas as cpias de uma varivel compartilhada contiverem a mesma informao, quando todas as operaes de escrita forem completadas em algum instante no tempo. A seguir apresentam-se alguns modelos de consistncia ordenados segundo sua restritividade. Elas esto agrupadas em duas categorias: os de acesso geral e os de acesso sincronizado. Os da primeira categoria podem no ser to restritivos se a exigncia de ordenamento das operaes de escrita for relaxado, com relao aos processadores ou s posies de memria. Os da segunda limitam a coerncia apenas a acessos de sincronizao. Um diagrama em blocos com esta classificao apresentado na Figura 2.

66

Consistncia Atmica: Este modelo requer que a MCD se comporte como a memria em um sistema centralizado sem cpias de dados. Todos os processadores devem executar os eventos na mesma ordem, os quais devem parecer executados em seqncia (atomicamente). o modelo mais restritivo e geralmente s usado como base para a avaliao de outros modelos de consistncia. Consistncia Atmica Relaxamento de Ordem de Tempo-Real Consistncia Seqencial Relaxamento Relativo ao Processador Consistncia Causal Relaxamento Relativo ao Processador Consistncia de Processador Relaxamento Relativo a Posio Memria Lenta Consistncia de Entrada Consistncia de Liberao Consistncia Fraca

Nenhum Suporte de Coerncia no Sistema

Fig. 2 - Uma Taxonomia de Modelos de Consistncia Consistncia Seqencial: Como operaes de acesso podem sofrer atrasos diferentes e, portanto, ser observadas em ordem diversa por processadores diferentes, no se exige o ordenamento real dos eventos, mas apenas que o resultado das operaes seja observado pelos processos na ordem e que forem solicitados.
P1 P2 P3 W(x)1 W(y)2 R(y)2 R(x)0 R(x)1

Consistncia Causal: Somente escritas com relao de causa precisam ser observadas na mesma ordem por todos os processadores.
P1 P2 P3 W(x)1 R(x)1 R(x)1 W(x)2 R(x)3 R(x)2 W(x)3

67

P4

R(x)1

R(x)2

R(x)3

Consistncia de Processador: Apenas escritas solicitadas pelo mesmo processador precisam ser executados e observados na ordem em que foram emitidos.
P1 P2 P3 P4 W(x)1 R(x)1 W(x)2 R(x)1 R(x)2 R(x)2 R(x)1

W(x)1 e W(x)2 esto relacionados causalmente porque R(x)1 e seus efeitos burlam a regra da causalidade, pois so observados em ordens diferentes por P3 e P4.

Consistncia de Memria Lenta: Apenas escritas mesma posio na memria solicitadas pelo mesmo processador precisam ter sua ordem respeitada. Seus efeitos so visveis localmente, imediatamente, e demoram para ser propagados (da o nome) pelo sistema.
P1 P2 W(x)1 W(y)2 R(y)2 W(x)3 R(x)1 R(x)3

Consistncia Fraca: Somente acessos a variveis de sincronizao precisam seguir um ordenamento seqencial. Nenhum acesso a variveis de sincronizao solicitado enquanto todas as operaes de leitura e escrita pendentes no estiverem atendidas. Nenhuma solicitao de leitura ou escrita emitida enquanto os acessos a variveis de sincronizao pendente, no forem resolvidos. Consistncia de Liberao: A sincronizao pode ser divida em obtm varivel e libera varivel. Admite-se que uma operao para obter varivel bloqueia acessos at que a operao seja completada. Quando a operao de liberao, todas as operaes anteriores devem ter sido executadas antes da liberao da varivel. Pode-se melhorar a concorrncia se a operao para obteno do semforo no atrasar (bloquear) acessos anteriores e se a operao para liberao no retardar acessos futuros. Consistncia de Entrada: Este modelo bloqueia objetos em vez de sees crticas para a excluso mtua na sincronizao. chamado de consistncia de entrada porque a varivel compartilhada consistente na entrada da regio crtica. Sistemas de Memria Cache em Multiprocessadores
Apesar de serem conceitualmente semelhantes MCMs e MCDs tm alguma diferenas de implementao. Enquanto as MCMs pressupem uma memria global compartilhada por um conjunto de mdulos de memria cache atravs de um barramento comum, as MCDs consistem de um conjunto de mdulos de memria que formam um espao de endereamento global virtual compartilhado via uma rede de comunicao fracamente acoplada. Contudo, as MCMs so estudas h muito tempo e suas semelhanas com MCDs faz com que a anlise do problema de coerncia dos dados nessas memrias seja bastante oportuno neste texto.

68

Estruturas de Memrias Cache

As memrias cache so buffers de alta velocidade cujo objetivo primordial minimizar a diferena de velocidade entre a UCP e o sistema de memria. Seu funcionamento tem por base o princpio da localidade, que pode ser enunciado da seguinte forma: a informao a ser utilizada no futuro prximo provavelmente aquela que est sendo processada atualmente (localidade no tempo) e que est adjacente quela em uso corrente (localidade no espao). De acordo com este princpio, a UCP necessita que apenas uma poro do espao de endereamento de um processo esteja ao seu alcance imediato em dado intervalo de tempo. Como a memria principal tem um tempo de acesso muito alto em relao ao funcionamento da UCP, justifica-se transferir a parte relevante das informaes sobre o processo em execuo, para uma memria que consiga fornece-las velocidade de processamento da UCP. No caso de um sistema multiprocessador, h vrias UCPs e cada uma delas ter seu mdulo de memria cache. Neste caso, cada UCP poder ter sua cpia de determinada poro do espao de endereamento. Para manter a consistncia vrias cpias e evitar que algum processador utilize informaes desatualizadas, deve-se adotar uma estrutura que permita o gerenciamento destas informaes dispersas. Uma estrutura possvel envolve o estabelecimento de uma cpia principal do bloco de informao. Esta cpia deve permanecer na memria principal ou em algum mdulo de memria que possa ser acessado por qualquer processador do sistema. Ao bloco de informao deve se associar um conjunto com tantos bits quantos forem os processadores do sistema, chamado de diretrio, mais alguns bits para armazenar informaes de estado. As demais cpias, armazenadas nas memrias cache dos diversos processadores, necessitam apenas de alguns bits de estado. Cada um dos bits do diretrio da cpia principal, quando no valor lgico 1, indica que o processador correspondente possui cpia do bloco associado ao diretrio. Alm do diretrio, pelo menos dois bits de estados so necessrios: um para indicar se o bloco compartilhado ou no e outro para indicar se a informao contida no bloco vlida ou no. O primeiro bit chamado de bit de exclusividade (E) e o segundo de bit de validade (V). Admitindose que toda a alterao de informao seja transcrita imediatamente para a memria principal, a cpia principal do bloco no necessita do bit de validade, pois seu contedo estar sempre atualizado. Por outro lado, cada uma das demais cpias de informao precisaro de um bit de validade o qual, ao ser colocado no nvel lgico zero, indica que a informao contida naquele bloco est desatualizada. Quando a UCP correspondente tentar acessar alguma informao no bloco marcado como invlido haver uma falha de acesso cache e a informao correta ser buscada na memria principal. J, o bit de exclusividade usado em todas as cpias do bloco, inclusive na principal. Quando o valor lgico deste bit for um, ele indicar que o processador pode fazer operaes de escrita no bloco. Quando seu valor lgico for zero, ele indicar que o bloco compartilhado e, portanto, apenas operaes de leitura so permitidas. Cada um dos bits do diretrio representa um processador do sistema. Quando o i-simo bit do diretrio tiver valor lgico um, significar que o processador correspondente possui uma cpia do bloco. Quando o valor lgico do i-simo bit do diretrio for zero, indicar que o respectivo processador no possui cpia do bloco em questo.

69

Protocolos de Coerncia
H duas classes de protocolos para estabelecer a coerncia de dados em sistemas de memria cache de multiprocessadores, quais sejam, por hardware e por software. As abordagens por software geralmente se baseiam em solues estticas adotadas em tempo de compilao, quando acessos compartilhados so automaticamente convertidos em primitivas de coerncia e sincronizao, aliadas a alguns procedimentos de programao e a providncias na implementao do sistema operacional, que alcanam compartilhamento e coerncia por meio de mecanismos de gerenciamento de memria virtual. Estas abordagens so mais baratas que as de hardware, as quais usam tcnicas tradicionalmente usadas na manipulao de memrias cache estendidas para arquiteturas escalveis, e alguns autores a reputam como mais facilmente escalonvel com o nmero de processadores da mquina. Todavia, so menos eficientes, pois, por no poderem prever o comportamento exato dos programas durante sua execuo elas so obrigadas a usar solues conservativas. Por exemplo, uma soluo consiste em evitar a existncia de cpias inconsistentes de dados nos mdulos de memria cache. Isto conseguido se a possibilidade de copiar certos dados cache for limitada aos perodos em que tais dados no forem compartilhados. Para que isto seja possvel o compilador deve ser capaz de identificar, pela anlise do cdigo do programa, quando cada varivel ser compartilhada e quando seguro permitir que se faam cpias dessas variveis na cache. A partir desta anlise o compilador pode ento marcar as variveis como possveis ou no de cpia em cada intervalo, providenciando para que, no final destes intervalos, a memria principal esteja consistente com os dados nas caches e invalidando as cpias. Um bom compilador poder fazer esta anlise, mas como ele faria a marcao das variveis e a invalidao das cpias? Uma possvel soluo para este problema a diviso do programa em unidades computacionais, com caractersticas prprias de acesso variveis. Por exemplo, os tipos de acesso podem ser separados em: (1) (2) (3) (4) apenas leitura por diversos processos; apenas leitura por vrios processos e leitura/escrita por um nico processo; leitura/escrita por um nico processo; e leitura/escrita por diversos processos.

Considerando-se que os processos em questo estejam em processadores diferentes. No primeiro caso, no j problema e a informao pode ser copiada em todos os mdulos de memria desejados. No segundo caso, somente o processo de leitura/escrita pode copiar a varivel e deve-se usar uma poltica de atualizao write-through para manter os dados consistentes. No terceiro caso, o dado pode ser copiado para a cache e, como o processo o nico a acess-lo, pode ser atualizado com uma poltica copy-back. No quarto e ltimo caso, no permitido copiar a informao na cache. Estas unidades computacionais devem ser identificadas pelo programador, para facilitar o trabalho do compilador. Isto pode ser feito utilizando-se construes tipo fork/join, laos for paralelos, etc. As abordagens por hardware so mais populares e mais freqentemente utilizadas em sistemas multicomputadores comerciais. Isto deve-se a algumas vantagens, tais como: a possibilidade do reconhecimento dinmico das inconsistncias em tempo de execuo; a possibilidade de melhor desempenho devido gerao de sobrecarga somente quando se d o compartilhamento da informao; e por liberarem tanto o programador quanto o compilador desta responsabilidade.

70

Os protocolos desta classe podem ser subdivididos em dois grupos, quais sejam, os de diretrio e os espies. Os protocolos de diretrio mantm nos mdulos de cache as cpias e alguma informao de estado e as informaes globais do estado do sistema so mantidas por um controlador central em algum tipo de diretrio. Os protocolos espies mantm a coerncia de forma totalmente distribuda. Para isto, cada controlador de cache tem informao sobre o estado local dos dados e tem a responsabilidade de divulgar a todo o sistema qualquer alterao ocorrida em dados compartilhados. Todos os controladores ficam espionando o barramento do sistema e quando detectam informao sobre alterao em varivel compartilhada eles so capazes de corrigir suas cpias conforme as necessidades. As duas principais polticas para manuteno da coerncia so write-update e write-invalidate. Naquela, todas as cpias so atualizadas, sempre que um processo escrever em uma delas. Nesta, todas as cpias so marcadas como invlidas. A atualizao da memria principal pode ser, como anteriormente, write-through ou copy-back.

Algoritmos de Gerenciamento de MCDs

H quatro algoritmos de gerenciamento para MCDs principais, identificados de acordo com o tratamento que dispensam aos blocos de dados, por ocasio de solicitaes de operaes de escrita e leitura. As possibilidades so de (no) copiar ou (no) migrar o bloco. Ao migrar o bloco, o sistema procura explorar a localidade das referncias do processo. Ao copiar, o objetivo facilitar a concorrncia. Em qualquer caso, as operaes de leitura e escrita no devem ser capazes de observar que os acessos no so feitos mesma cpia dos dados. O primeiro dos quarto algoritmos chamado de algoritmo do servidor central, pois mantm uma mquina responsvel por responder a todos os pedidos de acesso a variveis compartilhadas. Todos os acessos, tanto de leitura quanto de escrita so feitos remotamente. Em ambos os casos envia-se uma solicitao de leitura/escrita do cliente ao servidor; o servidor recebe o pedido, executa a operao solicitada e envia a resposta ao cliente; no caso de operao de leitura o cliente recebe como resposta o dado solicitado, no caso de operao de escrita o cliente recebe de resposta um sinal de reconhecimento do sucesso da operao. Esta a estratgia mais simples, mas sofre de um problema grave, qual seja, o servidor passa a ser um ponto fraco do sistema, um possvel gargalo que limita o nmero de mquinas no sistema ou faz o desempenho cair. O segundo algoritmo denominado algoritmo de migrao, pois, sempre que um bloco acessado ele transferido para a mquina que o solicitou. Neste caso, todos os acessos de leitura/escrita so feitos localmente. A vantagem deste algoritmo, alm de no ter um servidor nico para servir de gargalo do sistema, que o custo de comunicao to menor quanto maior for o nmero de acessos ao contedo de um bloco, entre uma transferncia e outra deste bloco. A deficincia deste algoritmo o efeito pingue-pongue, caso o nmero de acessos entre transferncias seja pequeno. Problema este que agravado se houver falso compartilhamento. O terceiro algoritmo dito cpia na leitura, pois quando solicitada uma operao de leitura copia o bloco para o processo que solicitou. No caso de uma operao de escrita a pgina migra para o processo solicitante. Desta forma obtm-se boa concorrncia na leitura e garante-se a coerncia dos dados na escrita. Sempre que for necessrio escrever em um bloco que no est armazenado localmente, o processo o localiza e envia uma solicitao ao hospedeiro remoto. Recebendo o pedido ele envia o bloco solicitado. Quando o cliente recebe o bloco, ele transmite uma mensagem para invalidar todas as outras cpias daquele bloco, aps o que ele atualiza a informao desejada. O algoritmo de cpia na leitura, juntamente com o protocolo write-invalidate, uma opo popular para muitas implementaes de sistemas MCDs. O quarto e ltimo algoritmo a ser tratado aqui o algoritmo de cpia total, pois ele copia o bloco solicitado tanto em operaes de leitura quanto de escrita. Neste caso h um grande problema de 71

consistncia nos dados, pois o algoritmo permite vrios escritores simultneos. Uma possibilidade de manter a consistncia dos dados nas vrias cpias fazer o seqenciamento global das operaes de escrita, mantendo o seqenciamento apenas local das operaes de leitura em relao s escritas locais. Devido a este problema, o algoritmo de cpia na leitura mais utilizado que o de cpia total para sistemas MCD. Uma discusso destes algoritmos, incluindo a anlise de seu desempenho, apresentada por Stumm e Zhou [13]. Outra fonte de informao sobre estes algoritmos o artigo de Nitzberg e Lo [14].

Localizao de Dados
Sistemas MCDs no usam servidores centralizados, para evitar a limitao do paralelismo devido conseqente serializao no tratamento das solicitaes e para evitar o gargalo resultante da reduo na velocidade geral do sistema devido sobrecarga nos servidores. Uma alternativa seria a irradiao das solicitaes de dados, para atingir diversos servidores distribudos. Contudo, neste caso todos os ns de processamento devem processar o pedido irradiado. Desta forma, a latncia de rede pode resultar em uma longa espera at que o acesso ao dado desejado seja feito. Todavia, sistemas para gerenciamento de MCDs precisam localizar as informaes. Para que isto possa ser feito, com uma melhor distribuio de carga pelo sistema e evitando a necessidade de irradiao das solicitaes de acesso, muitos sistemas MCD usam um esquema distribudo baseado na propriedade de estruturas de dados para executar duas tarefas essenciais: (1) localizar o proprietrio atual de um bloco, aps algumas migraes; e (2) identificar todas as cpias de um bloco para invalidao ou atualizao. Diversos esquemas so utilizados para localizar os blocos no sistema. Um deles mantm uma estrutura de diretrio distribuda onde cada entrada do diretrio representa um bloco naquele n. Caso o bloco seja compartilhado o diretrio tambm mantm informao sobre a localizao das cpias do bloco. Somente o n proprietrio do bloco tem informao sobre ele. Acessos para leitura a blocos remotos devem ser solicitados ao seu proprietrio.

Exemplo de write-invalidate: Para dado compartilhado remoto Pedido de escrita Envia dados e contador invlido
2) Controlador do diretrio (CD) envia dados e invalida contador de blocos para o solicitante. CD envia pedido de invalidao da cpia no cluster B. 2c) Nova entrada do bloco no diretrio. dirty remote | cpia em C 3) Cpia invalidada Pedido para invalidar cpia Reconhece Invalidao da cpia

(Conceito de diretrio DASH)

1) UCP solicita escrita para home cluster 4) Completa escrita

cluster B

cluster C: solicitante

Cluster A: home cluster

72

Outro esquema utiliza uma tabela, na qual cada entrada contm um indicador da posio provvel do bloco. O bloco localizado seguindo estes ponteiros. Um esquema semelhante pode ser implementado usando-se uma lista ligada, chamada de lista de cpias, ou uma rvore spanning, chamada de conjunto de cpias. Nestes casos cada processador mantm um conjunto de apontadores para cada bloco compartilhado que ele conhece. Um endereo aponta para o processador do qual o bloco foi copiado (suposto dono do bloco) e os demais endereos apontam para os processadores para os quais foi enviada uma cpia do bloco. Por ocasio de uma operao de escrita uma mensagem repassada pela lista/conjunto para a invalidao de todas as cpias.

Exemplo de write-invalidate: Para dado remoto sujo

Retransmisso do pedido de escrita Solicitao de escrita 2) CD retransmite pedido para proprietrio 4) Nova entrada do bloco no diretrio
dirty remote | cpia em B

1) UCP solicita escrita para home cluster Atualizao de propriedade reconheci6) Completa Escrita mento dados

5) CD envia reconhecimento para novo proprietrio

3) CD envia dados para solicitante e atualizao de propriedade para home cluster

Cluster A: home cluster

Cluster B: solicitante

Cluster C: proprietrio

Sistemas de Arquivos Distribudos

Alguns dados em sistemas de computao precisam ser armazenados por longos perodos. A posterior recuperao destes dados requer que a eles sejam associados localizadores. Tais parmetros de localizao, em um contexto mais abstrato, so associados com nomes. Os objetos de dados aos quais foram associados nomes so chamados de arquivos do sistema de computao. Um sistema de arquivos a estrutura organizacional dos arquivos no sistema de computao. O sistema de arquivos responsvel por atribuir nomes, criar, remover, modificar e proteger todos os arquivos do sistema. Um sistema de arquivos distribudo um sistema de arquivos que possibilita a disperso geogrfica de mdulos da sua estrutura. Apesar desta disperso a viso passada aos usurios a de um sistema centralizado. O compartilhamento dos arquivos do sistema por vrios usurios para facilitar o trabalho cooperativo, a reproduo de diversas cpia de alguns arquivos para facilitar o acesso a seus dados, e a migrao de arquivos pelos mdulos de memria do sistema so aspectos que devem passar desapercebidos para os usurios. As principais caractersticas de um sistema de arquivos distribudos so: (1) Disperso de clientes, o que corresponde ao fato de que sistemas distribudos so compostos de vrias mquinas, heterogneas, as quais devem apresentar aos seus usurios um procedimento 73

de ingresso no sistema uniforme, e devem possibilitar que o usurio enxergue o sistema de arquivos da mesma forma, independentemente da mquina na qual ele entrou no sistema. Alm disto, o mecanismo de acesso aos arquivos deve ser nico, independente do fato do arquivo estar na mquina em que o usurio est trabalhando ou em alguma outra mquina do sistema. (transparncia de acesso). (2) Disperso de arquivos, que diz respeito localizao dos arquivos. Por um lado, os nomes atribudos aos arquivos no devem conter informao sobre sua localizao (transparncia de localizao/posio), para que os acessos a arquivos em diferentes partes do sistema possam ser homogneos. Por outro lado, ao se mover um arquivo de uma posio geogrfica do sistema de computao para outra, sem alterar sua posio na estrutura organizacional do sistema de arquivos seu nome no deve ser alterado (independncia de posio). (3) Diversidade de usurios, corresponde ao problema de manter a coerncia dos dados e a correta execuo dos processos. Como o sistema admite vrios usurios, os quais podem acessar, compartilhadamente, um mesmo arquivo do sistema, quando um desses usurios atualiza algum dado do arquivo isto no deve afetar negativamente a execuo de outros processos do sistema (transparncia de concorrncia). Nos casos em que o acesso ao arquivo entrelaado os usurios devem achar que o arquivo est sendo acessado isoladamente. (4) Diversidade de arquivos, refere-se ao fato de existirem rplicas de arquivos no sistema, para facilitar a disponibilidade de alguns deles atravs da redundncia, bem como para permitir acessos concorrentes de modo a aumentar a eficincia do sistema (transparncia de rplicas). O que se deseja, neste caso, possibilitar aos clientes fazerem atualizaes nas rplicas sem que os demais percebam a existncia de vrias cpias dos arquivos.

Implementao de Sistemas de Arquivos Distribudos

A principal questo a ser considerada na implementao de sistemas de arquivos distribudos a manuteno da transparncia tanto durante o compartilhamento dos arquivos por processos do sistema quanto por ocasio da proliferao de cpias de arquivos em diversas estaes do sistema. Inicialmente, sero vistos alguns conceitos bsicos sobre a implementao de arquivos e sistemas de arquivos em geral. Posteriormente, este estudo ser direcionado para a anlise dos protocolos utilizados com o fim de garantir a transparncia mencionada no pargrafo anterior. Arquivos consistem em trs componentes: nome, atributos e dados. O nome um nome simblico atribudo inicialmente ao arquivo, o qual mapeado em uma identificao nica pelo servio de diretrio. As informaes tpicas armazenadas como atributos so a identificao do proprietrio do arquivo, seus tipos e tamanhos, os instantes de criao e da ltima atualizao e as autorizaes de acesso ao arquivo. Os dados podem ser seqncias de bytes, de blocos ou de registros indexados e o tipo de acesso depende da estrutura utilizada. De modo geral os acessos podem ser: seqencial, usando apontadores para o prximo byte; direto, no qual os pedidos de leitura e escrita tragam o endereo do bloco; e indexado seqencial, que se utiliza uma chave ndice. Os componentes principais em um sistema de arquivos so os servios de diretrio, de autorizao, de arquivos e de sistema. Os trs primeiros so responsveis pela interface do usurio com o sistema de arquivos e o ltimo transparente para o usurio. A funo do servio de diretrio o mapeamento de nomes simblicos dos arquivos do sistema em seus endereos exclusivos, bem como a adio e remoo de arquivos do sistema. A funo do servio de autorizao controlar a lista de permisses de arquivos. O sistema de arquivos pode ser dividido em um conjunto de servios bsicos e outro de servios para o gerenciamento de transaes. A funo do servio de arquivos bsico controlar a leitura e a escrita nos arquivos do sistema, bem como ajustar e recuperar os atributos dos arquivos. J, a funo do servio de transao em arquivos gerenciar as rplicas e a concorrncia nos arquivos. A funo do servio

74

do sistema gerenciar dispositivos, cache e blocos, como por exemplo, interfacear os acionadores de dispositivos para alocar espao e realizar operaes reais de leitura e escrita. Sendo os diretrios estruturados hierarquicamente, a operao de anexao de um diretrio remoto ao sistema de arquivos de um cliente a partir de uma determinada posio dita montagem de arquivos ou diretrios. A montagem til na construo de um sistema de arquivos grande a partir de diversos dispositivos de armazenamento localizados em vrios servidores de arquivos. Uma vez montados, os arquivos anexados podem ser acessados como se fizessem parte do sistema de arquivos do cliente. H trs formas de montagem: explcita, na inicializao do sistema e automtica. A montagem explcita flexvel, mas de difcil gerenciamento; ela no transparente porque requer que o usurio monte explicitamente todo o sistema de arquivos. A montagem na inicializao do sistema uniforme e esttica, porque feita pelo sistema durante o processo de inicializao e no modificada posteriormente, mas gasta espao do sistema montando coisas desnecessrias. A montagem automtica feita durante o funcionamento do sistema, sob demanda; ela dinmica e transparente, montando os arquivos somente quando eles forem acessados. Para acessar um arquivo necessrio estabelecer uma conexo entre um cliente e um servidor de modo a possibilitar o fluxo de pedidos e respostas. Esta conexo foi chamada de sesso. H certas informaes necessrias para o bom andamento de uma sesso, quais sejam: indicao dos arquivos abertos e por quem; os descritores e manipuladores de arquivos; ponteiro para a posio de arquivos seqenciais; informaes sobre montagem; informaes de estado; e chaves de bloqueio de variveis e de segurana.

As informaes sobre os arquivos que esto abertos e quem abriu cada arquivo podem ser armazenadas tanto no servidor quanto no cliente, bem como a chave de segurana utilizada para transferncias durante a sesso. Por outro lado, os descritores e os manipuladores dos arquivos, os ponteiros para a posio atual de acesso a arquivos seqenciais e as informaes sobre a montagem, isto , as ligaes pertinentes, devem ser armazenadas no cliente. Finalmente, as chaves para a proteo das variveis compartilhadas devem ser armazenadas no servidor. O servidor pode manter as informaes de estado tornando o processamento mais rpido e o trfego leve, uma vez que estas informaes esto prontamente disponveis. Embora o controle seja mais flexvel o retorno de falhas mais complexo e lento, uma vez que o servidor precisa recuperar as informaes de estado anteriores falha. Ao contrrio, possvel no manter qualquer informao de estado no servidor. Neste caso o servidor mais simples, mais confivel e mais tolerante a falhas, mas as mensagens so maiores e o seu processamento mais lento, uma vez que elas devem contem as informaes de estado.

Compartilhamento de Arquivos
Isto significa que o(s) arquivo(s) pode(m) ser acessado(s) por vrios usurios ao mesmo tempo. Para isto ser vivel o arquivo e as operaes sobre ele devem ser multiplexadas no espao ou no tempo. No primeiro caso h vrias cpias do arquivo e portanto os acessos a ele se sobrepem. H duas vantagens em manter cpias de um arquivo em pontos distintos do sistema, so elas: aumenta a disponibilidade dos dados e melhora o desempenho do sistema, pois o tempo para atender uma requisio ser menor quando for usada um cpia mais prxima do cliente; e s vezes interessante manter um cpia de trabalho do arquivo para armazenar alteraes temporrias, at que as 75

alteraes definitivas sejam definidas e possam ser efetuadas no arquivo. Todavia, nestes casos ocorre o problema de controle de coerncia dos dados, isto , deve-se decidir se a cpia na memria local coerente com a cpia original, ou no. No segundo caso os acessos ao arquivo so entrelaados, ou seja, permitem que vrias seqncias de operaes oriundas de diversos clientes sejam executadas como em um sistema de compartilhamento do tempo. O problema neste caso, evitar que as seqncias de operaes interfiram umas com as outras evitando inconsistncias e a gerao de resultados errados, problema este conhecido por controle de concorrncia. O acesso a arquivos compartilhados pode ser remoto, via cache ou por carga e descarga. Em cada caso pode ser feito para simples leitura ou escrita, para transaes ou para sesses. Cada leitura/escrita, para transaes ou para sesses. Cada leitura/escrita uma solicitao/resposta ao/do servidor de arquivos. Transaes so seqncias de operaes de leitura/escrita, tratadas atenciosamente, ao mesmo arquivo. Geralmente, estas seqncias so delimitadas por construtores tipo begin/end. Sesses so seqncias de transaes e operaes de leitura e escrita. O acesso remoto no mantm arquivos no cliente, todo o pedido de acesso enviado ao servidor remoto via rede. Deste modo, s h uma cpia do arquivo e os acessos a ela so serializados pelo servidor. O problema que esta serializao impede a concorrncia e provoca atrasos. No caso de solicitaes simples de leitura/escrita no h compartilhamento real e no caso de transaes necessrio um controle de concorrncia. No acesso via cache parte do arquivo mantido localmente para leitura e operaes de escrita, assim como falhas no acesso cache local, resultam em acesso remoto e a correspondente atualizao da cache. Este procedimento reduz os atrasos e melhora a concorrncia no sistema. O controle de concorrncia usado tanto para operaes simples de leitura e escrita quanto para transaes, mas nestas tambm controlada a coerncia dos dados. No acesso para carga ou descarga todo o arquivo carregado para acesso local. Quando atualizado, o arquivo e carregado remotamente. Nos casos de leitura/escrita simples e de transaes, os controles so os mesmos que os utilizados no acesso via cache. No caso de sesses, o compartilhamento ignorado, por se tratar de composies dos casos anteriores. Como foi visto, o compartilhamento de arquivos cria problemas de coerncia e de consistncia dos dados, cuja soluo depende do modelo semntico utilizado no procedimento de atualizao dos dados nos arquivos compartilhados. Trs modelos populares so: (1) Modelo semntico do UNIX: o resultado de uma operao de escrita propagado para o arquivo principal e suas cpias, imediatamente. O problema que neste modelo supe-se que no h atrasos alm dos de propagao na rede de comunicao, que os arquivos compartilhados no so copiados e que todas as operaes de leitura e escrita so dirigidas e podem ser serializadas pelo servidor de arquivos. Como em um sistema distribudo isto no possvel, deve-se utilizar uma poltica de controle write-through associada a um protocolo write-invalidate ou write-update para garantir a coerncia das cpias obtendo, assim, um modelo funcionalmente equivalente semntica do UNIX. (2) Semntica de transaes: Os resultados de operaes de escrita so armazenados temporariamente em uma memria de trabalho e s so efetivados no final da transao, quando determinadas condies de consistncia forem satisfeitas. Neste caso, as cpias dos dados no so necessariamente sempre coerentes, mas garante-se a consistncia dos resultados segundo alguma ordem de execuo das transaes. Caso algo de errado durante a execuo de determinada transao os resultados parciais so descartados e o sistema mantido no estado em que se encontrava antes do incio da transao. (3) O modelo semntico de sesses: o cliente utiliza uma cpia do arquivo na qual todas as alteraes so feitas temporariamente. O resultado s escrito permanentemente no final da

76

sesso, isto , as atualizaes permanentes so atrasadas mais do que no caso do modelo de transaes. Neste caso, essencialmente no h compartilhamento de arquivos abertos simultaneamente por clientes diferentes, uma vez que as atualizaes s so efetivadas quando do encerramento das sesses. O problema do modelo de sesses como fazer com que as cpias de arquivos escritos em seqncia sejam coerentes. Uma possibilidade exigir que a toda operao de escrita corresponda um fechar arquivo, forando sua atualizao. Isto equivaleria semntica do UNIX com poltica write-through. Outra possibilidade criar cpias apenas para leitura. Quando se desejar escrever algo no arquivo, deve-se criar uma nova verso do mesmo, para atualiz-lo. O controle destas verses pode ser feito por uma funo do servio de diretrio, o qual est em um nvel hierrquico superior ao do servio de arquivos. As atualizaes seriam mantidas em um local temporrio at a finalizao da sesso. Quando algum quiser escrever algo no arquivo criada um nova verso, que se torna a verso corrente. Quando algum quiser abrir um arquivo, sempre lhe dada a verso mais recente. H vrios esquemas para a resoluo de conflitos pelo controle de verso, quando da escrita de um arquivo. Estes esquemas devem ser utilizados quando um processos tenta atualizar um arquivo, baseado em uma verso desatualizada, devido atualizao da verso corrente por outro processo. Trs possveis esquemas so: (a) ignora conflito: Cria-se uma nova verso independentemente do que possa ter ocorrido no sistema (b) resolve conflito de verso: Se o conjunto de dados atualizado no arquivo temporrio e aquele gravado na verso corrente forem disjuntos possvel combinar os dois arquivos, mantendo todas as atualizaes feitas. (c) Resolve conflito de seriao: Se houver interseo entre o conjunto de dados no arquivo temporrio e os j atualizados na verso corrente, as atualizaes podem ser descartadas e o processo pode ser recomeado com a cpia corrente do arquivo. Isto fora uma ordenao serial e aleatria das atualizaes.

Rplicas de Arquivos e Dados

O objetivo do uso de rplicas a melhoria do desempenho e o aumento da disponibilidade dos objetos copiados no sistema. O melhor desempenho se d porque a manuteno de rplicas possibilita o acesso concorrente de vrios processos ao mesmo conjunto de informaes. Analogamente, a existncia de vrias cpias de objetos do sistema, produz uma redundncia que os torna disponveis a diversos processos. Todavia, esta redundncia deve ser implementada de tal forma que os usurios no percebam a existncia de vrias cpias. Alm disto, as transaes sobre os objetos devem ser operadas de tal modo que ao final ou ela se completa integralmente ou o estado resultante idntico ao estado anterior ao incio da transao, isto , as atualizaes nas cpias devem ser atmicas. Alm disto, as atualizaes so propagadas para todas as cpias do objeto e so serializadas. Genericamente uma arquitetura para o gerenciamento de cpias deve utilizar um agente servidor de arquivos (ASA) que serve de front end para os gerenciadores de cpias (GC). O ASA pode acessar qualquer GC, provendo, com isto, a transparncia das cpias para os clientes. H vrias formas de se fazer operaes de leitura e escrita, utilizando-se diversos algoritmos. A seguir sero vistas algumas destas formas e, para concluir, sero apresentados dois algoritmos para implementar estes mecanismos. Os algoritmos so de votao por quorum e de propagao de atualizaes por gossip.

77

Operaes de Leitura
A cpia primria: ASA l apenas do gerenciador primrio, para forar a consistncia. A alguma cpia: ASA l de qualquer GC, para propiciar concorrncia. A um quorum: ASA l de um grupo de GCs, para decidir sobre a concorrncia, mantendo a consistncia.

Operaes de Escrita
A cpia primria: tudo escrito em uma cpia primria e seu GC propaga o resultado para os demais. A todos os GCs: todas as atualizaes a todos os GCs so atmicas e as atualizaes subseqentes devem aguardar. A todos disponveis: atualiza todos os CGs que estiverem operacionais. Quando um GC se recuperar de uma falha, ele deve se atualizar antes de tornar seus dados disponveis. A um quorum: atualizao atmica a um grupo de GCs. Por gossip: as atualizaes so dirigidas a qualquer GC, o qual as propagar para os demais, na hora que lhe aprouver.

Para a descrio dos algoritmos ver pginas 222 a 226 do livro-texto[1].

78

Bibliografia
[1] Randy Chow and Theodore Johson, Distributed Operating Systems & Algotithms, Addison Weley Longman, Inc. 1997. Repinted with corrections, February, 1998. [2] Andrews and Schneider, Concepts and Notation for Current Programming, ACM Computing Surveys, 15(1) 3-43, 1983. [3] ACM SigPlan Notices, 18(4) 69-79, 1983. [4] Gelernter, Generative Communication in Linda, ACM Transactions on Programming Languages, 7(1) 80-112,1985. [5] ACM Computing Surveys, 21(3) 261-322, 1989. [6] IEEE Transactions on Software Engineering, 18(3) 190-205, 1992 [7] http://java.sun.com/ [8] H.GarciaMolinal, Elections in a Distributed Computer System, IEEE Transactions on Computers, C-31(2)48-59, 1982. [9] M. J. Fischer, N. A. Lynch, e M. S. Patterson. Impossibility of Distributed Consensus with one Faulty Processor. JACM, 32(2)374-382, 1985. [10] E. Hou, N. Ansari, and H. Ren. A Genetic Algorithm for Multiprocessor Scheduling. IEEE Trans. on Parallel and Distributed Systems, 5 (2) 113-120, Feb. 1994; [11] R. Corra, A. Ferreira, and P. Rebreyend. Scheduling Multiprocessor Tasks with Genetic Algorithms. IEEE Trans on Parallel and Distributed Systems, 10 (8) 825-837, Aug. 1999. [12] P. Stenstrm, T. Joe, and A. Gupta. Comparative Performance Evaluation of Cache-coherent NUMA and COMA Architectures. Proc. Of the 19th ACM Intl Symp. On Computer Arch., pp. 8091, 1992. Reprinted by permission of the ACM, Inc. in M. Momasevic e V. Milutinovic The cache Cohence Problem in Shared-Memory Multiprocessors; Hardware Solutions IEEE CS Press, pp. 399-410, 1993. [13] M. Stumm, and S. Zhou. Algorithms Implementating Distributed Shared Memory. IEEE Computer Mag., 23 (5) 54-64, May 1990. [14] B. Nitzberg, and V. Lo. Distributed Shared Memory: A Survey of Issues and Algorithms. IEEE Computer Mag., 24 (8)52-60, Aug. 19991. [15] H. S. Stone. High-Performance Computer Arquiteture. 3rd Ed., Chapter 2, (pp.32-102), Addison-Wesley Pub. Co., 1993. [16] M. Tomasevic, and V. Milutinovic. The Cache Coherence Problem in Shared Memory Multiprocessors: Hardware Solutions. IEEE CS Press, 1993.

79