(2) APOSTILA - UNESP - Sistemas Operacionais Distribudos

Sistemas Operacionais Distribudos

Alunos: Wanderlei Pereira Alves Junior Jlio Cezar Estrella Orientao: Prof. Dr. Norian Marranghello


UNESP/IBILCE

Sistemas Operacionais DistribudosMecanismos de Linguagens e ThreadsTpicos Abordados Introduo: Classificao dos Sistemas Operacionais Surgimento dos Sistemas Operacionais Distribudos O que um Sistema Operacional Distribudo? Blocos de controle de ramificaes (Threads) Comparao entre ramificaes e processos Custo de criao e implementao de ramificaes Ramificaes no servidor ou no ncleo de sistemas operacionais Ramificaes em multiprocessadores O modelo cliente/servidor Construes de linguagens Mecanismos de sincronizao Especificao de atividades concorrentes Sincronizao e comunicao entre processos Execuo no deterministic de processos Estrutura de programas Estrutura de dados Estruturas de controle Sincronizao de variveis compartilhadas Semforos Monitores Regies criticas condicionais Path Expressions Sincronizao por passagem de mensagens Chamada remota de procedimentos Ada Rendevouz Processos Concorrentes

2


UNESP/IBILCE

1. Classificao dos Sistemas OperacionaisOs sistema operacionais podem ser classificados de acordo com seu grau de acoplamento, a saber: Redes Autmatos Centralizados Distribudos Para classific-los deste modo, so levados em considerao os seguintes fatores: Interoperabilidade Transparncia Autonomia Apenas citaremos as funcionalidades de alguns sistemas referenciados acima, uma vez que a nfase ser dada aos Sistemas Distribudos. 1.1. Sistemas Centralizados

Caractersticas: So fortemente acoplados, so do tipo monoltico, ou seja no h o particionamento do ncleo. Nos sistemas monolticos os servios do sistema e do ncleo fazem parte de um mesmo programa. 1.2. Sistemas em Rede

Caractersticas: um multicomputador fracamente acoplado no qual no existe nenhum 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 compatilhamento de recursos o objetivo principal dos sistemas em rede. 1.3. Sistemas Autmatos

Tais sistemas mantm as noes de transparncia e interoperabilidade que existem nos Sistemas Distribudos, mas abolem a impresso de que existe somente um usurio no sistema.3


UNESP/IBILCE

1.4.

Sistemas Distribudos

So aqueles que gerenciam as atividades e os recursos distribudos, possibilitando um processamento descentralizado e melhorando o desempenho do sistema. Outra definio: Um conjunto de processos que so executados de forma concorrente, cada um dos quais acessando um subconjunto de receursos do sistema por meio de um mecanismo de troca de mensagens atravs de uma rede de comunicao, que nem sempre confivel. As vantagens de um Sistema Distribudo em relao aos outros sua maior disponibilidade, geralmente resultante da redundncia de seus componentes Sistema Distribudo Mais transparente que os Sistemas em Rede

Essa transparncia pode ser notada em vrios aspectos: Transparncia de acesso a arquivos Transparncia de desempenho Transparncia de localizao Transparncia de concorrncia Aspectos importantes na construo de um sistema operacional: Eficincia Os parmetros para medir o desempenho do sistema (eficincia) so diversos, tais como: vazo, tempo de execuo de uma determinada tarefa, taxa de uso do sistema e de seus recursos. Obs: A eficincia em sistemas distribudos mais complexa em relao aos Sistemas Operacionais Convecionais, devido aos atrasos na comunicao. Obs: O tempo gasto na propagao dos dados depende fortemente do protocolo de comunicao utilizado, motivo pelo qual este deve ser bem projetado, como base em primitivas de comunicao eficientes. Fatores que afetam a eficincia: Tempo gasto na propagao dos dados Balanceamento de carga Ganulosidade das tarefas Tolerncia a faltas

4


UNESP/IBILCE

Flexibilidade Fatores associados: Interoperabilidade Modularidade Portabilidade Escalabilidade Consistncia Um sistema consistente se: Permite um uso uniforme E se possui um comportamento previsvel Fatores que afetam a consistncia do sistema: Ausncia de um mecanismo global Inexistncia de informaes a respeito do desempenho global Robustez Para ser robusto um Sistema Distribudo tem que estar disponvel a maior parte do tempo, apresentando dados confiveis. A confiabilidade deste sistema tambm est associado aos mecanismos de proteo existentes. Transparncia Capacidade que um Sistema apresenta, de esconder dos usurios, detalhes de implementao, em particular queles mais complexos, e apresentar na medida do possvel um modelo lgico da mquina como os usurios gostariam de usar e no como o sistema realmente.

2. O que so Threads?Definio bsica: Fluxo de controle seqencial isolado dentro de um programa. Outra denominao: LightWeight Processes (Processos Peso Pena) Ou processos leves que compartilham o espao de endereos lgicos. Programas multithreaded: Mltiplos threads concorrentes de execuo num nico programa, realizando vrias tarefas ao mesmo tempo.5


UNESP/IBILCE

Exemplo: programa do usurio + coleta de lixo Diferentes threads podem executar em diferentes processadores, se disponveis, ou compartilhar um processador nico Diferentes threads no mesmo programa compartilham um ambiente global (memria, processador, registradores, etc.) 2.1. Quais as funcionalidades dos threads?

Threads permitem que um programa simples possa executar vrias tarefas diferentes ao mesmo tempo, independentemente umas das outras. Quando executado, um programa pode gerar ramificaes no seu fluxo de controle. Tais ramificaes (threads) tem seus estados locais individuais, mas permanecem associados ao processo que as gerou. Cada um desse processos possui um TCB (Thread Control Blocks), semelhante ao PCB dos processos. Como os threads so processos leves, associados aos processos que os gerou, esses TCB possuem informaes locais reduzidas (contador de programa, apontadores de pilha e conjunto de registradores). A mudana de contexto de um thread em relao a um processo mais rpida pois os threads alm possuem informaes locais, compartilham o restante das informaes com os processos que os gerou. Os processos funcionam como mquinas virtuais, pois compartilham seu espao de endereamento com os threads. 2.2. Onde so implementado os threads?

Depende!!! Agilidade Se o objetivo agilidade, deve-se implement-los no espao do usurio. Neste caso o controle de processos feito diretamente pelo sistema operacional, mas os threads so controlados por procedimentos em tempo de execuo que serve como interface entre a mquina virtual (processos) onde rodam os threads e o sistema operacional. Obs: Neste caso, o sistema operacional no enxerga os threads, pois eles so implementados no espao do usurio, sendo submissos ao processo que os criou. Os threads no podem usufruir do sistema de interrupes do sistema operacionais e portanto so no-preemptveis.

6


UNESP/IBILCE

Vantagens agilidade o gerenciamento menos complicado Desvantagens no preempo impedidos de utilizar interrupes do sistema operacional

Eficincia Se o objetivo eficincia, ento os threads podem ser implementados no ncleo do sistema operacional, podendo serem vistos pelo SO e usufruindo de seu sistema de interrupes. Portanto passam a serem preemptveis. Nesse sentido os threads passam a ser tratados como processos, possibilitando o bloqueio de outros threads e tambm eficincia no escalonamento. O leitor deve notar que agora no h necessidade de interromper o processo que o gerou (processo pai), uma vez que o thread um processo. Com isso o Sistema Operacional pode interromper um thread sem interromper o processo pai, e tambm outras ramificaes em execuo. O thread tambm ir competir igualmente com os processos os ciclos do processador. Vantagens de implementao no ncleo Maior autonomia dos threads Desvantagens sistema perde em portabilidade, as mudanas de contexto dos threads tem agora a mesma complexidade dos processos e a concorrncia fica reduzida a dois nveis (threads e processos). 2.3. Quando um thread deixa de existir?

Quando terminam sua execuo Quando o tempo alocado a seu processo pai foi esgotado Ou se solicitou algum recurso do sistema

7


UNESP/IBILCE

2.4.

Aplicaes Multithread

Programas multithread so programas que contm vrias threads, executando tarefas distintas, simultaneamente. O browser HotJava, implementado em Java, um exemplo. Da mesma forma que o Netscape, o HotJava poder fazer um scroll em uma pgina enquanto carrega uma imagem ou executa vrios applets ao mesmo tempo. Exemplos: Programao Reativa : aplicao responde a eventos de entrada. Exemplo: interfaces com o usurio, onde cada evento corresponde a uma ao Programao Interativa: uma tarefa para fazer alguma interao com o usurio, outra para exibir mensagens, outra para fazer animao, etc.. Paralelismo fsico/ distribuio: para tirar vantagem de mltiplas CPUs centralizadas ou distribudas 2.5. Exemplo de aplicao utilizando ramificaes

Implementao de processos servidores que prestam servios a processos clientes. O emprego de ramificaes na estrutura de controle do servidor, permite o agrupamento dos threads num mesmo espao de endereamento, admitindo acesso concorrente de vrios clientes a um nico servidor. H dois tipos de ramificaes: Ramificaes Estticas: Criadas em tempo de compilao Exemplo: Servidores de terminais Servidor cria ramificaes

Essas ramificaes so locais ao servidor

Ramificaes atendem usurios enquanto estiverem conectados

8


UNESP/IBILCE

Essas ramificaes compartilham o mesmo espao de endereo (dos processos pais), ento quando precisam acessar algum recurso compartilhado, a exclusividade do acesso feita via mecanismos de sincronizao como os monitores e semforos. Como a ramificao fica no sistema enquanto o usurio estiver conectado, ela ocupa o espao de memria mesmo que o cliente no requisite nenhuma operao do servidor. Ramificaes Dinmicas: Criadas e destrudas de acordo com as necessidades. Exemplo: Servidores de arquivos Nesses servidores h diversas operaes de leitura/escrita. Nesse contexto existe um processo que tm a funo de coordenar essas atividades. Cada vez que um cliente solicita uma operao, o servidor cria uma ramificao que ficar responsvel por determinada tarefa (leitura/escrita) e terminado sua execuo o controle volta novamente ao processo que a criou. Por exemplo, se forem feitas vrias operaes de leitura, sero geradas vrias ramificaes do processo responsvel pela operao de leitura. O mesmo acontece com a operao de escrita. Obs: importante ressaltar novamente que essas ramificaes (threads) sero executadas independentes uma das outras, e sero extintas assim que o servio para qual foram criadas, tambm termine. Vantagens da implementao no servidor Aumenta a flexibilidade Agrupamento de threads no mesmo espao de endereamento Desvantagens Complica o gerenciamento das ramificaes 2.6. Concluso

A utilizao do mecanismos de ramificaes permite que a memria seja otimizada e tambm reaproveitada assim que essas terminem sua execuo, levando a uma reduo considervel no custo do sistema. Alm da localizao da implementao que descrevemos anteriormente sero mencionados nos prximos tpicos, a importncia tambm dos mecanismos de gerenciamento de threads, o uso de regies crticas e tambm o uso de variveis globais.9


UNESP/IBILCE

3. Ramificaes em MultiprocessadoresSe um programa corre em um multiprocessador, os processos leves executam em simultneo, cada um no seu processador. Vantagens Mesmo em monoprocessadores o desempenho de uma aplicao pode ser melhorado usando esta tcnica: se um dos processos se bloqueia numa chamada ao sistema, outro processo leve pode ocupar o processador.

4. Modelo Cliente ServidorO modelo cliente/servidor um paradigma de programao que representa as interaes entre o processos e estruturas do sistema. Esse modelo 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. O modelo cliente/servidor geralmente refere-se a um modelo onde dois ou mais computadores interagem de modo que um oferece servios aos outros. Este modelo permite ao usurios acessarem informaes e servios de qualquer lugar. Cliente/Servidor uma arquitetura computacional que envolve requisies de servios de clientes para servidores. Portanto a definio para cliente/servidor seria a existncia de uma plataforma base para que as aplicaes, onde um ou mais clientes e um ou mais servidores, juntamente com o sistema operacional de rede, executem processamento distribudo. O modelo poderia ser entendido como a interao entre software e hardware em diferentes nveis, implicando na composio de diferentes computadores e aplicaes. Para se entender o paradigma cliente/servidor necessrio observar que o conceito est na ligao lgica e no na fsica. Cliente e servidor pode ou no existir na mesma mquina, porm um ponto importante para uma real abordagem cliente/servidor a necessidade de que a arquitetura definida represente uma computao distribuda. Caracterscas Cliente Tambm denomidado de front-end e workstation, um processo que interage com o usurio atravs de uma interface grfica ou no, permitindo consultas ou comandos para a

10


UNESP/IBILCE

recuperao de dados e anlise, e representando o meio pela qual os resultados so apresentados. Alm disso o processo cliente apresenta algumas caractersticas distintas: um processo ativo na relao cliente/servidor Inicia e termina as conversaes com os servidores, solicitando servios distribudos No se comunica com outros clientes Torna a rede transparente ao usurio Servidor Tambm denominado servidor ou back-end, fornece um determinado servio que fica disponvel para todo cliente que o necessita. A natureza e o escopo dos servios so definidos pelo objetivo da aplicao cliente/servidor. Suas propriedades distintas so: o processo reativo na aplicao cliente/servidor Possui uma execuo contnua Recebe e responde s solicitaes dos clientes No se comunica com outros servidores enquanto estiver fazendo o papel de servidor Presta servios distribudos Atende a diversos clientes simultaneamente Tipos de servidores Servidores de arquivos Servidores de impresso Servidores de Banco de Dados Servidor de Redes Vantagens do modelo Confiabilidade: Se uma mquina apresenta algum problema, ainda que seja um dos servidores,parte do sitema continua ativo. O sistema cresce facilmente: Torna-se fcil modernizar o sistema quando necessrio Escalabilidade: Capacidade de responder ao aumento da procura de servios sem degradar a performance. O Cliente e o Servidor possuem ambientes operacionais individuais: Pode-se misturar vrias paltaformas para melhor atender s necessidades individuais de diversos setores e usurios.

11


UNESP/IBILCE

Desvantagens do modelo Manuteno: As diversas partes envolvidas nem sempre funcionam bem juntas. Quando algum erro ocorre, existe uma extensa lista de itens a serem investigados. Ferramentas: A escassez de ferramentas de suporte, no raras as vezes obriga o desenvolvimento de ferramentas prprias. Em funo do grande poderio das novas linguagens de programao, esta dificuldade est ser tornando cada vez menor. Gerenciamento: O aumenta da complexidade do ambiente e a escassez de ferramentas de auxlio tornam difcil o gerenciamento da rede. O processo Cliente requisita servios ao Servidor:

Pedido

Resposta

um modelo baseado no estabelecimento de uma conexo, sendo possvel ser implementado sobre um canal de comunicao por meio de troca de mensagens. Primitivas de comunicao como send e receive so implementadas no ncleo, e no h preocupao se o servio orientado a conexo ou no orientado a conexo. Outras primitivas como connect e accept tambm so implementadas no ncleo do sistema. Essas primitivas so classificadas de acordo com os critrios abaixo: 1. O estado em que ficam os processos durante a transmisso de uma mensagem 2. A forma como as mensagens so disponibilizadas 3. Confiabilidade do mecanismo de troca de mensagens

12


UNESP/IBILCE

Segundo o primeiro critrio, as primitivas so classificadas como bloqueadoras e no bloqueadoras. Bloqueadoras quando o processo fica paralisado durante a transmisso de um mensagem. No bloqueadoras quando o processo fornece uma cpia da mensagem ao sistema de comunicao, devido a solicitao de um sevio. De acordo com o segundo critrio as primitivas podem ou n utilizarem de bbuffer para comunicao. O terceiro trata da confiabilidade das primitivas, que no confivel, pois utiliza-se a resposta como confirmao do recebimento da solicitao. 5. Processos Concorrentes So vrios processos executados em paralelo. Essa execuo paralela no significa execuo simultnea. A execuo concorrente admite as seguintes possibilidades: Pseudo-paralela: Execuo em um nico processador; Paralela: Execuo em vrios processadores que compartilham uma memria; Distribuda: Execuo em vrios processadores independentes, sem compartilhamento de memria. Os objetivos da programao concorrente so: Reduzir o tempo total de processamento; Aumentar confiabilidade e disponibilidade; Obter especializao de servios; Implementar aplicaes distribudas. Fluxo nico de Execuo Vrios Fluxos de Execuo

PROC 1 PROC 2 PROC 3 PROC 1 PROC 2 PROC 3

13


UNESP/IBILCE

6. Sincronizao e Comunicao de Processos Uma forma de comunicao entre processos freqentemente usada em Sistemas operacionais feita atravs de variveis compartilhadas onde os processos podem ler e escrever dados. Nesta forma de comunicao existe a possibilidade de ocorrer situaes de corrida, que so situaes onde dois ou mais processos atuam sobre dados compartilhados e o resultado final do processamento depende de quem executa quando. A anlise de programas em que ocorrem condies de corrida no uma tarefa fcil. Os resultados da maioria dos testes so consistentes com a estrutura do programa, mas de vez em quando ocorre algo imprevisto e inexplicvel, em funo do no-determinismo potencial, causado pelas condies de corrida. Para evitar estas situaes de corrida, implementamos mecanismos para assegurar que quando um processo atua sobre uma varivel compartilhada os demais sero impedidos de faze-lo (excluso mtua). A parte do programa que pode levar a ocorrncia de condies de corrida, denominada regio crtica. 6.1. Construtores Das Linguagens As linguagens concorrentes so obtidas pelo acrscimo de certas construes prprias para sincronizao e comunicao de processos concorrentes a linguagens seqenciais. Os principais construtores das linguagens, usados na implementao dos mecanismos de sincronizao e comunicao entre processos concorrentes, so: Estrutura do programa: especifica a composio do programa (procedimentos, comandos, variveis, etc.); Estrutura de dados: representam objetos do programa; Estrutura de controle: regulam o fluxo de execuo do programa (if-then-else, while-do, etc.) Chamadas a procedimentos e ao sistema: ativam rotinas especiais ou servios do sistema. 6.2. Semforos Dijkstra introduziu a noo de semforo para impor a excluso mtua entre processos. uma construo tambm usada para sincronizar processos concorrentes. Um semforo S uma varivel inteira positiva sobre a qual os processos podem fazer duas operaes primitivas (indivisveis): P(S) e V(S). P e V tm sua origem das palavras parsen (passar) e e vrygeren (liberar). As operaes P e V so assim definidas:

14


UNESP/IBILCE

P(S) : se S > 0 ento S:=S-1 seno Bloqueie o processo na fila do semforo V(S) : se algum processo est bloqueado no semforo S ento desbloquear o processo seno S:=S+1 Os semforos so classificados de acordo com o valor com que so inicializados como: Semforos binrios: o valor inicial 1; Semforos de contagem: o valor inicial normalmente maior do que 1. Adicionar semforos s linguagens de programao existentes, uma tarefa relativamente simples, basta programar duas rotinas em linguagem de montagem, adicionando-as biblioteca de chamadas de sistema. 6.3. Monitores Deve-se tomar muito cuidado ao trabalhar com semforos. Para facilitar a escrita de programas paralelos, Hoare e Brinch Hansen propuseram uma primitiva de alto nvel para sincronizao de processos, denominada monitor. Um monitor um conjunto de procedimentos, variveis e estruturas de dados, todas agrupadas em um mdulo especial. Os processos no podem acessar diretamente as estruturas de dados e variveis internas do monitor a partir de procedimentos declarados fora do monitor. Os monitores tm uma propriedade muito importante: somente um processo pode estar ativo dentro do monitor em um dado instante. tarefa do compilador implementar a excluso mtua de execuo sobre o monitor, sendo o caminho mais usual utilizar semforos binrios. Os monitores oferecem uma forma simples de se obter a excluso mtua, mas ainda no o suficiente, preciso que haja uma forma de bloqueio de processos quando no houver condies lgicas para eles continuarem o processamento. Isto feito com as variveis de condio e duas operaes sobre elas, WAIT e SIGNAL. Essas variveis de condio permitem a sincronizao entre processos. Ilustrao de um monitor escrita em uma linguagem imaginria, parecida com Pascal: monitor exemplo integer i; condition c; procedure produtor(x); . . . end;15


UNESP/IBILCE

procedure consumidor(x); . . . end; end monitor; Para usar monitores, necessrio uma linguagem especfica que suporte este conceito. Hoje, existem poucas linguagens com esta caracterstica. 6.4. Regies Crticas Condicionais Uma regio crtica condicional (RCC) uma verso estruturada da abordagem com semforos. Cdigos da regio crtica so explicitamente nomeados e expressados por region-begin-end. Uma vez na regio crtica uma condio pode ser testada pelo atributo when. Se a condio no for satisfeita, o processo suspenso e outros processos podero entrar em suas regies crticas. Esta abordagem de estrutura de controle assume variveis compartilhadas e requer compilao de regies crticas dentro de primitivas de sincronizao que so disponibilizadas pelo sistema operacional. A necessidade de um endereo comum e a impossibilidade de compilao separada no faz do RCC um bom candidato para adaptao em sistemas distribudos. processo leitor region db begin rc:= rc + 1 end; region db begin rc := rc 1 end; processo escritor region db when rc = 0 begin end; 6.5. Expresses de Caminho uma especificao de linguagem de alto nvel que descreve como operaes definidas por um objeto compartilhado podem ser invocadas de forma a satisfazer os requisitos de sincronizao. Por esta razo, ns nos referimos a ela como uma estrutura de programa desde que ela lembra a descrio formal de um programa. Ex: path 1:([read], write) end

16


UNESP/IBILCE

A constante 1 restringe o nmero de atividades simultneas nos parnteses a apenas uma e ento determina a excluso mtua entre processo leitor e escritor. Os colchetes indicam que os leitores podem ser concorrentes. 6.6. Sincronizao por Passagem de Mensagem Sem memria compartilhada, a passagem de mensagem a nica forma de comunicao em sistemas distribudos. A passagem de mensagem tambm uma forma de sincronizao implcita desde que as mensagens s podem ser recebidas depois delas terem sido enviadas. Para a maioria das aplicaes, comum assumir que a primitiva receive bloqueia o processo e a primitiva send pode ou no bloquear o processo. Diremos que a passagem de mensagem assncrona quando a primitiva send no bloqueia o processo, e quando ela o bloqueia, diremos que a passagem de mensagem sncrona. 6.6.1. Passagem de Mensagem Assncrona Embora no haja variveis compartilhadas, o canal de comunicao compartilhado. O bloqueio proveniente da primitiva receive equivalente operao P em um semforo e a primitiva send quando no bloqueia o processo anloga operao V. A passagem de mensagem assncrona uma extenso do conceito de semforo em sistemas distribudos. 6.6.2. Passagem de Mensagem Sncrona

Aqui, a primitiva send bloqueia o processo. Isto necessrio quando no h buffers no canal de comunicao. Um send deve aguardar que o receive correspondente ocorra, e o receive deve esperar pelo send correspondente. Este mecanismo permite que dois processos com pares compatveis de send e receive se unam e troquem dados em um ponto de sincronizao e continuem suas execues separados a partir da. Este tipo de sincronizao chamado de um ponto de encontro (rendezvous) entre send e receive. 6.7. Chamada Remota a Procedimentos Com o objetivo de facilitar a implementao de aplicaes cliente-servidor em uma rede de computadores, ambientes de desenvolvimento passaram a suportar a Chamada a Procedimentos Remotos (RPC - Remote Procedure Call). Os ambientes de desenvolvimento que suportam o mecanismo de RPC escondem do programador boa parte dos detalhes envolvidos no uso das facilidades de comunicao providas pela rede de computadores. O mecanismo de RPC tem por objetivo possibilitar que procedimentos que se encontram em outras mquinas possam ser chamados da mesma forma como procedimentos que se encontram na mquina onde se encontra o cdigo cuja execuo resultou na chamada ao procedimento. Quando procedimentos locais so chamados, o fluxo de execuo do programa desviado para o procedimento, o procedimento executado e o fluxo de execuo retorna para a instruo seguinte chamada do procedimento. Em uma aplicao cliente-servidor desenvolvida com o mecanismo de RPC, o procedimento chamado se encontra em uma mquina diferente daquela onde est sendo executado o

17


UNESP/IBILCE

cdigo que resultou na chamada ao procedimento. O programa cliente chama procedimentos que se fazem passar pelos procedimentos que sero executados no servidor. O cdigo presente nos procedimentos esconde do restante do cliente os detalhes envolvidos na comunicao com os procedimentos remotos. O servidor contm o cdigo que implementa a lgica da aplicao e o cdigo inserido pelo ambiente de desenvolvimento. O cdigo inserido recebe as solicitaes do cliente, chama o procedimento local adequado e envia os resultados de volta para o cliente. Este cdigo esconde do servidor os detalhes do processo de comunicao atravs da rede. Os ambientes de desenvolvimento que suportam RPC contm um compilador que insere o cdigo necessrio tanto no cliente quanto no servidor. Para que a comunicao entre cliente e servidor seja realizada com sucesso, necessrio que o cliente chame os procedimentos remotos com a quantidade e tipos de parmetros esperados pelo servidor. tambm necessrio que o cliente aguarde a mesma quantidade e tipos de resultados que sero retornados pelo servidor. A compatibilidade entre cliente e servidor garantida por informaes em um arquivo usado quando da compilao tanto do cliente quanto do servidor. Em tal arquivo so encontradas as definies dos procedimentos, as quais so compostas pelos nomes dos procedimentos, quantidades e tipos dos argumentos, quantidades e tipos dos valores retornados. Os arquivos de definio so escritos usando-se uma linguagem de definio prpria do ambiente de desenvolvimento. Para que a compilao seja realizada com sucesso, o cdigo no cliente e no servidor precisam aderir ao arquivo de definies. Aps a compilao do cliente e do servidor, os programas sero instalados nas mquinas apropriadas e, quando da execuo do cliente, ser necessria a identificao da mquina na qual se encontra o servidor. A identificao pode ser feita atravs de informaes inseridas no cdigo do cliente ou atravs de um servio de binding. Este servio provido pelo binder, responsvel por armazenar informaes que possibilitam aos clientes identificar onde se encontram os servidores. As informaes armazenadas no binder so providas pelos prprios servidores quando iniciam a sua execuo. Em outras palavras, os servidores se registram com o binder. Aps identificar em que mquina o servio provido, o cliente se comunica com um processo que executa na mesma mquina onde se encontra o servidor. O processo responsvel por informar ao cliente em que porta de comunicao o servidor pode ser encontrado. Em uma rede de computadores, um servidor pode ser encontrado desde que se saiba o endereo da mquina onde se encontra e o nmero da porta de comunicao utilizada. Portanto a localizao do servidor pelo cliente ocorre em duas etapas. Na primeira etapa identificada a mquina e, na segunda, a porta onde o servio prestado. A porta usada pelo processo que informa as portas usadas pelos servidores conhecida pelos clientes. Isto possibilita a localizao do processo pelos clientes. 6.8. Ada Rendevouz A construo de monitores no moldam a sincronizao em sistemas distribudos, onde seria necessrio a sincronizao de unidades, na qual cada processador teria sua prpria memria, em vez de uma nica memria compartilhada. Para impor a excluso mtua ou para sincronizar os processos independentes comum a utilizao de monitores, mas quando estamos em sistemas onde no h memria comum nem uma nico processador, a implementao dos monitores se torna invivel, porque que

18


UNESP/IBILCE

no existe nenhum meio fsico central. A linguagem de programao Ada surge com a tcnica de encontros (Rendez-Vous) para tratar estes casos. Na linguagem ADA permitida a programao de atividades paralelas, que normalmente necessitam de sincronizao. Referimo-nos a essa atividades como tarefas (tasks). Para a programao dessas tarefas utilizamos a tcnica de encontros, que incorpora os mecanismos de excluso mtua e de comunicao. Existem dois tipos de processos aos quais nos referiremos durante a explicao do funcionamento da tcnica de encontros na linguagem ADA: Tarefa servidora: tarefa que contm operaes definidas em seu cdigo; Tarefa atuante: : tarefa que invoca as operaes existentes na tarefa servidora. denominada entrada cada conjunto de operaes associada aos meios de comunicao existentes entre os processos. Uma entrada definida dentro de uma tarefa, para acess-la necessrio conhecer o nome da tarefa em tempo de programao. A estrutura do comando ACCEPT permite que a tarefa servidora implemente operaes diferentes para chamadas a uma mesma entrada, usando comandos ACCEPT para procedimentos distintos. O comando ACCEPT atende chamadas originadas de qualquer outra tarefa, mas apenas uma tarefa pode conter comandos ACCEPT a uma mesma entrada. O atendimento feito pr ordem de chegado. Quando a ordem de atendimento no for por ordem de chegada, utiliza-se o comando SELECT e os seus blocos contm comandos guardados que associados aos comandos ACCEPT, possibilitam encontros condicionais. O comando SELECT possui tambm uma clusula ELSE, cujo cdigo executado quando no houver comandos com guarda atendida. O bloqueio de tarefas atuantes, pode ser evitado pr meio de chamadas condicionais, que realiza o CALL somente se o encontro for possvel imediatamente. Em tarefas servidoras, o bloqueio evitado verificando, antes do ACCEPT, se existem tarefas aguardando para serem atendidas pr aquela entrada.

19


UNESP/IBILCE

BibliografiaTANENBAUM, A. S. Modern Operating Systems, 1992.

MARRANGHELLO N. Apostila de Sistemas Operacionais Distribudos, 2001 CHOW e JOHNSON, Distributed Operating Systems, 1997 Links Cliente/Servidor: http://www.whatis.com/clientse.htm RPC: http://www.whatis.com/rpc.htm Thread: http://www.whatis.com/thread.htm

20

(2) APOSTILA - UNESP - Sistemas Operacionais Distribudos

Documents

Transcript of (2) APOSTILA - UNESP - Sistemas Operacionais Distribudos