P. 1
APOSTILA - UNESP - Sistemas Operacionais Distribuídos

APOSTILA - UNESP - Sistemas Operacionais Distribuídos

5.0

|Views: 1.609|Likes:
Publicado porapi-26417123

More info:

Published by: api-26417123 on Oct 19, 2008
Direitos Autorais:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/09/2014

pdf

text

original

Sistemas Operacionais Distribuídos

Alunos: Wanderlei Pereira Alves Junior Júlio Cezar Estrella Orientação: Prof. Dr. Norian Marranghello

Sistemas Operacionais Distribuídos

UNESP/IBILCE

Sistemas Operacionais Distribuídos
Mecanismos de Linguagens e Threads
Tópicos Abordados Introdução: Classificação dos Sistemas Operacionais Surgimento dos Sistemas Operacionais Distribuídos O que é um Sistema Operacional Distribuído? Blocos de controle de ramificações (Threads) Comparação entre ramificações e processos Custo de criação e implementação de ramificações Ramificações no servidor ou no núcleo de sistemas operacionais Ramificações em multiprocessadores O modelo cliente/servidor Construções de linguagens Mecanismos de sincronização Especificação de atividades concorrentes Sincronização e comunicação entre processos Execução não deterministic de processos Estrutura de programas Estrutura de dados Estruturas de controle Sincronização de variáveis compartilhadas Semáforos Monitores Regiões criticas condicionais Path Expressions Sincronização por passagem de mensagens Chamada remota de procedimentos Ada Rendevouz Processos Concorrentes

2

Sistemas Operacionais Distribuídos

UNESP/IBILCE

1. Classificação dos Sistemas Operacionais
Os sistema operacionais podem ser classificados de acordo com seu grau de acoplamento, a saber: Redes Autômatos Centralizados Distribuídos Para classificá-los deste modo, são levados em consideração os seguintes fatores: Interoperabilidade Transparência Autonomia Apenas citaremos as funcionalidades de alguns sistemas referenciados acima, uma vez que a ênfase será dada aos Sistemas Distribuídos. 1.1. Sistemas Centralizados

Características: São fortemente acoplados, são do tipo monolítico, ou seja não há o particionamento do núcleo. Nos sistemas monolíticos os serviços do sistema e do núcleo fazem parte de um mesmo programa. 1.2. Sistemas em Rede

Características: É um multicomputador fracamente acoplado no qual não existe nenhum tipo de controle direto de uma máquina sobre as outras e no qual a comunicação entre as outras máquinas é bem mais lenta que dentro de uma dada máquina. O compatilhamento de recursos é o objetivo principal dos sistemas em rede. 1.3. Sistemas Autômatos

Tais sistemas mantém as noções de transparência e interoperabilidade que existem nos Sistemas Distribuídos, mas abolem a impressão de que existe somente um usuário no sistema.
3

Sistemas Operacionais Distribuídos

UNESP/IBILCE

1.4.

Sistemas Distribuídos

São aqueles que gerenciam as atividades e os recursos distribuídos, possibilitando um processamento descentralizado e melhorando o desempenho do sistema. Outra definição: Um conjunto de processos que são executados de forma concorrente, cada um dos quais acessando um subconjunto de receursos do sistema por meio de um mecanismo de troca de mensagens através de uma rede de comunicação, que nem sempre é confiável. As vantagens de um Sistema Distribuído em relação aos outros é sua maior disponibilidade, geralmente resultante da redundância de seus componentes Sistema Distribuído Mais transparente que os Sistemas em Rede

Essa transparência pode ser notada em vários aspectos: Transparência de acesso a arquivos Transparência de desempenho Transparência de localização Transparência de concorrência Aspectos importantes na construção de um sistema operacional: Eficiência Os parâmetros para medir o desempenho do sistema (eficiência) são diversos, tais como: vazão, tempo de execução de uma determinada tarefa, taxa de uso do sistema e de seus recursos. Obs: A eficiência em sistemas distribuídos é mais complexa em relação aos Sistemas Operacionais Convecionais, devido aos atrasos na comunicação. Obs: O tempo gasto na propagação dos dados depende fortemente do protocolo de comunicação utilizado, motivo pelo qual este deve ser bem projetado, como base em primitivas de comunicação eficientes. Fatores que afetam a eficiência: Tempo gasto na propagação dos dados Balanceamento de carga Ganulosidade das tarefas Tolerância a faltas

4

Sistemas Operacionais Distribuídos

UNESP/IBILCE

Flexibilidade Fatores associados: Interoperabilidade Modularidade Portabilidade Escalabilidade Consistência Um sistema é consistente se: Permite um uso uniforme E se possui um comportamento previsível Fatores que afetam a consistência do sistema: Ausência de um mecanismo global Inexistência de informações a respeito do desempenho global Robustez Para ser robusto um Sistema Distribuído tem que estar disponível a maior parte do tempo, apresentando dados confiáveis. A confiabilidade deste sistema também está associado aos mecanismos de proteção existentes. Transparência Capacidade que um Sistema apresenta, de esconder dos usuários, detalhes de implementação, em particular àqueles mais complexos, e apresentar na medida do possível um modelo lógico da máquina como os usuários gostariam de usar e não como o sistema é realmente.

2. O que são Threads?
Definição básica: “ Fluxo de controle seqüencial isolado dentro de um programa.” Outra denominação: LightWeight Processes (Processos Peso Pena) Ou processos leves que compartilham o espaço de endereços lógicos. Programas multithreaded: Múltiplos threads concorrentes de execução num único programa, realizando várias tarefas “ao mesmo” tempo.
5

Sistemas Operacionais Distribuídos

UNESP/IBILCE

Exemplo: programa do usuário + coleta de lixo Diferentes threads podem executar em diferentes processadores, se disponíveis, ou compartilhar um processador único Diferentes threads no mesmo programa compartilham um ambiente global (memória, processador, registradores, etc.) 2.1. Quais as funcionalidades dos threads?

Threads permitem que um programa simples possa executar várias tarefas diferentes ao mesmo tempo, independentemente umas das outras. Quando executado, um programa pode gerar ramificações no seu fluxo de controle. Tais ramificações (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 são processos leves, associados aos processos que os gerou, esses TCB possuem informações locais reduzidas (contador de programa, apontadores de pilha e conjunto de registradores). A mudança de contexto de um thread em relação a um processo é mais rápida pois os threads além possuem informações locais, compartilham o restante das informações com os processos que os gerou. Os processos funcionam como máquinas virtuais, pois compartilham seu espaço de endereçamento com os threads. 2.2. Onde são implementado os threads?

Depende!!! Agilidade Se o objetivo é agilidade, deve-se implementá-los no espaço do usuário. Neste caso o controle de processos é feito diretamente pelo sistema operacional, mas os threads são controlados por procedimentos em tempo de execução que serve como interface entre a máquina virtual (processos) onde rodam os threads e o sistema operacional. Obs: Neste caso, o sistema operacional não “enxerga” os threads, pois eles são implementados no espaço do usuário, sendo submissos ao processo que os criou. Os threads não podem usufruir do sistema de interrupções do sistema operacionais e portanto são não-preemptíveis.

6

Sistemas Operacionais Distribuídos

UNESP/IBILCE

Vantagens agilidade o gerenciamento é menos complicado Desvantagens não preempção impedidos de utilizar interrupções do sistema operacional

Eficiência Se o objetivo é eficiência, então os threads podem ser implementados no núcleo do sistema operacional, podendo serem vistos pelo SO e usufruindo de seu sistema de interrupções. Portanto passam a serem preemptíveis. Nesse sentido os threads passam a ser tratados como processos, possibilitando o bloqueio de outros threads e também eficiência no escalonamento. O leitor deve notar que agora não 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 também outras ramificações em execução. O thread também irá competir igualmente com os processos os ciclos do processador. Vantagens de implementação no núcleo Maior autonomia dos threads Desvantagens sistema perde em portabilidade, as mudanças de contexto dos threads tem agora a mesma complexidade dos processos e a concorrência fica reduzida a dois níveis (threads e processos). 2.3. Quando um thread deixa de existir?

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

7

Sistemas Operacionais Distribuídos

UNESP/IBILCE

2.4.

Aplicações Multithread

Programas multithread são programas que contém várias 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 página enquanto carrega uma imagem ou executa vários applets ao mesmo tempo. Exemplos: Programação Reativa : aplicação responde a eventos de entrada. Exemplo: interfaces com o usuário, onde cada evento corresponde a uma ação Programação Interativa: uma tarefa para fazer alguma interação com o usuário, outra para exibir mensagens, outra para fazer animação, etc.. Paralelismo físico/ distribuição: para tirar vantagem de múltiplas CPUs centralizadas ou distribuídas 2.5. Exemplo de aplicação utilizando ramificações

Implementação de processos servidores que prestam serviços a processos clientes. O emprego de ramificações na estrutura de controle do servidor, permite o agrupamento dos threads num mesmo espaço de endereçamento, admitindo acesso concorrente de vários clientes a um único servidor. Há dois tipos de ramificações: Ramificações Estáticas: Criadas em tempo de compilação Exemplo: Servidores de terminais Servidor cria ramificações

Essas ramificações são locais ao servidor

Ramificações atendem usuários enquanto estiverem conectados

8

Sistemas Operacionais Distribuídos

UNESP/IBILCE

Essas ramificações compartilham o mesmo espaço de endereço (dos processos pais), então quando precisam acessar algum recurso compartilhado, a exclusividade do acesso é feita via mecanismos de sincronização como os monitores e semáforos. Como a ramificação fica no sistema enquanto o usuário estiver conectado, ela ocupa o espaço de memória mesmo que o cliente não requisite nenhuma operação do servidor. Ramificações Dinâmicas: Criadas e destruídas de acordo com as necessidades. Exemplo: Servidores de arquivos Nesses servidores há diversas operações de leitura/escrita. Nesse contexto existe um processo que têm a função de coordenar essas atividades. Cada vez que um cliente solicita uma operação, o servidor cria uma ramificação que ficará responsável por determinada tarefa (leitura/escrita) e terminado sua execução o controle volta novamente ao processo que a criou. Por exemplo, se forem feitas várias operações de leitura, serão geradas várias ramificações do processo responsável pela operação de leitura. O mesmo acontece com a operação de escrita. Obs: É importante ressaltar novamente que essas ramificações (threads) serão executadas “independentes” uma das outras, e serão extintas assim que o serviço para qual foram criadas, também termine. Vantagens da implementação no servidor Aumenta a flexibilidade Agrupamento de threads no mesmo espaço de endereçamento Desvantagens Complica o gerenciamento das ramificações 2.6. Conclusão

A utilização do mecanismos de ramificações permite que a memória seja otimizada e também reaproveitada assim que essas terminem sua execução, levando a uma redução considerável no custo do sistema. Além da localização da implementação que descrevemos anteriormente serão mencionados nos próximos tópicos, a importância também dos mecanismos de gerenciamento de threads, o uso de regiões críticas e também o uso de variáveis globais.
9

Sistemas Operacionais Distribuídos

UNESP/IBILCE

3. Ramificações em Multiprocessadores
Se um programa corre em um multiprocessador, os processos leves executam em simultâneo, cada um no seu processador. Vantagens Mesmo em monoprocessadores o desempenho de uma aplicação pode ser melhorado usando esta técnica: se um dos processos se bloqueia numa chamada ao sistema, outro processo leve pode ocupar o processador.

4. Modelo Cliente – Servidor
O modelo cliente/servidor é um paradigma de programação que representa as interações entre o processos e estruturas do sistema. Esse modelo é usado para melhorar a estrutura do sistema operacional, movendo-se a maior quantidade possível de funções para níveis mais altos do sistema, reduzindo o tamanho do núcleo. O modelo cliente/servidor geralmente refere-se a um modelo onde dois ou mais computadores interagem de modo que um oferece serviços aos outros. Este modelo permite ao usuários acessarem informações e serviços de qualquer lugar. Cliente/Servidor é uma arquitetura computacional que envolve requisições de serviços de clientes para servidores. Portanto a definição para cliente/servidor seria a existência de uma plataforma base para que as aplicações, onde um ou mais clientes e um ou mais servidores, juntamente com o sistema operacional de rede, executem processamento distribuído. O modelo poderia ser entendido como a interação entre software e hardware em diferentes níveis, implicando na composição de diferentes computadores e aplicações. Para se entender o paradigma cliente/servidor é necessário observar que o conceito está na ligação lógica e não na física. Cliente e servidor pode ou não existir na mesma máquina, porém um ponto importante para uma real abordagem cliente/servidor é a necessidade de que a arquitetura definida represente uma computação distribuída. Caracteríscas Cliente Também denomidado de “front-end” e “workstation”, é um processo que interage com o usuário através de uma interface gráfica ou não, permitindo consultas ou comandos para a

10

Sistemas Operacionais Distribuídos

UNESP/IBILCE

recuperação de dados e análise, e representando o meio pela qual os resultados são apresentados. Além disso o processo cliente apresenta algumas características distintas: É um processo ativo na relação cliente/servidor Inicia e termina as conversações com os servidores, solicitando serviços distribuídos Não se comunica com outros clientes Torna a rede transparente ao usuário Servidor Também denominado servidor ou “back-end”, fornece um determinado serviço que fica disponível para todo cliente que o necessita. A natureza e o escopo dos serviços são definidos pelo objetivo da aplicação cliente/servidor. Suas propriedades distintas são: É o processo reativo na aplicação cliente/servidor Possui uma execução contínua Recebe e responde às solicitações dos clientes Não se comunica com outros servidores enquanto estiver fazendo o papel de servidor Presta serviços distribuídos Atende a diversos clientes simultaneamente Tipos de servidores Servidores de arquivos Servidores de impressão Servidores de Banco de Dados Servidor de Redes Vantagens do modelo Confiabilidade: Se uma máquina apresenta algum problema, ainda que seja um dos servidores,parte do sitema continua ativo. O sistema cresce facilmente: Torna-se fácil modernizar o sistema quando necessário Escalabilidade: Capacidade de responder ao aumento da procura de serviços sem degradar a performance. O Cliente e o Servidor possuem ambientes operacionais individuais: Pode-se misturar várias paltaformas para melhor atender às necessidades individuais de diversos setores e usuários.

11

Sistemas Operacionais Distribuídos

UNESP/IBILCE

Desvantagens do modelo Manutenção: 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, não raras as vezes obriga o desenvolvimento de ferramentas próprias. Em função do grande poderio das novas linguagens de programação, esta dificuldade está ser tornando cada vez menor. Gerenciamento: O aumenta da complexidade do ambiente e a escassez de ferramentas de auxílio tornam difícil o gerenciamento da rede. O processo Cliente requisita serviços ao Servidor:

Pedido

Resposta

É um modelo baseado no estabelecimento de uma conexão, sendo possível ser implementado sobre um canal de comunicação por meio de troca de mensagens. Primitivas de comunicação como send e receive são implementadas no núcleo, e não há preocupação se o serviço é orientado a conexão ou não orientado a conexão. Outras primitivas como connect e accept também são implementadas no núcleo do sistema. Essas primitivas são classificadas de acordo com os critérios abaixo: 1. O estado em que ficam os processos durante a transmissão de uma mensagem 2. A forma como as mensagens são disponibilizadas 3. Confiabilidade do mecanismo de troca de mensagens

12

Sistemas Operacionais Distribuídos

UNESP/IBILCE

Segundo o primeiro critério, as primitivas são classificadas como bloqueadoras e não bloqueadoras. Bloqueadoras quando o processo fica paralisado durante a transmissão de um mensagem. Não bloqueadoras quando o processo fornece uma cópia da mensagem ao sistema de comunicação, devido a solicitação de um seviço. De acordo com o segundo critério as primitivas podem ou nõ utilizarem de bbuffer para comunicação. O terceiro trata da confiabilidade das primitivas, que é não confiável, pois utiliza-se a resposta como confirmação do recebimento da solicitação. 5. Processos Concorrentes São vários processos executados em paralelo. Essa execução paralela não significa execução simultânea. A execução concorrente admite as seguintes possibilidades: Pseudo-paralela: Execução em um único processador; Paralela: Execução em vários processadores que compartilham uma memória; Distribuída: Execução em vários processadores independentes, sem compartilhamento de memória. Os objetivos da programação concorrente são: Reduzir o tempo total de processamento; Aumentar confiabilidade e disponibilidade; Obter especialização de serviços; Implementar aplicações distribuídas. Fluxo Único de Execução Vários Fluxos de Execução

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

13

Sistemas Operacionais Distribuídos

UNESP/IBILCE

6. Sincronização e Comunicação de Processos Uma forma de comunicação entre processos freqüentemente usada em Sistemas operacionais é feita através de variáveis compartilhadas onde os processos podem ler e escrever dados. Nesta forma de comunicação existe a possibilidade de ocorrer situações de corrida, que são situações onde dois ou mais processos atuam sobre dados compartilhados e o resultado final do processamento depende de quem executa quando. A análise de programas em que ocorrem condições de corrida não é uma tarefa fácil. Os resultados da maioria dos testes são consistentes com a estrutura do programa, mas de vez em quando ocorre algo imprevisto e inexplicável, em função do não-determinismo potencial, causado pelas condições de corrida. Para evitar estas situações de corrida, implementamos mecanismos para assegurar que quando um processo atua sobre uma variável compartilhada os demais serão impedidos de faze-lo (exclusão mútua). A parte do programa que pode levar a ocorrência de condições de corrida, é denominada região crítica. 6.1. Construtores Das Linguagens As linguagens concorrentes são obtidas pelo acréscimo de certas construções próprias para sincronização e comunicação de processos concorrentes a linguagens seqüenciais. Os principais construtores das linguagens, usados na implementação dos mecanismos de sincronização e comunicação entre processos concorrentes, são: Estrutura do programa: especifica a composição do programa (procedimentos, comandos, variáveis, etc.); Estrutura de dados: representam objetos do programa; Estrutura de controle: regulam o fluxo de execução do programa (if-then-else, while-do, etc.) Chamadas a procedimentos e ao sistema: ativam rotinas especiais ou serviços do sistema. 6.2. Semáforos Dijkstra introduziu a noção de semáforo para impor a exclusão mútua entre processos. É uma construção também usada para sincronizar processos concorrentes. Um semáforo S é uma variável inteira positiva sobre a qual os processos podem fazer duas operações primitivas (indivisíveis): P(S) e V(S). P e V têm sua origem das palavras parsen (passar) e e vrygeren (liberar). As operações P e V são assim definidas:

14

Sistemas Operacionais Distribuídos

UNESP/IBILCE

P(S) : se S > 0 então S:=S-1 senão Bloqueie o processo na fila do semáforo V(S) : se algum processo está bloqueado no semáforo S então desbloquear o processo senão S:=S+1 Os semáforos são classificados de acordo com o valor com que são inicializados como: Semáforos binários: o valor inicial é 1; Semáforos de contagem: o valor inicial é normalmente maior do que 1. Adicionar semáforos às linguagens de programação 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 semáforos. Para facilitar a escrita de programas paralelos, Hoare e Brinch Hansen propuseram uma primitiva de alto nível para sincronização de processos, denominada monitor. Um monitor é um conjunto de procedimentos, variáveis e estruturas de dados, todas agrupadas em um módulo especial. Os processos não podem acessar diretamente as estruturas de dados e variáveis internas do monitor a partir de procedimentos declarados fora do monitor. Os monitores têm uma propriedade muito importante: somente um processo pode estar ativo dentro do monitor em um dado instante. É tarefa do compilador implementar a exclusão mútua de execução sobre o monitor, sendo o caminho mais usual utilizar semáforos binários. Os monitores oferecem uma forma simples de se obter a exclusão mútua, mas ainda não é o suficiente, é preciso que haja uma forma de bloqueio de processos quando não houver condições lógicas para eles continuarem o processamento. Isto é feito com as variáveis de condição e duas operações sobre elas, WAIT e SIGNAL. Essas variáveis de condição permitem a sincronização entre processos. Ilustração de um monitor escrita em uma linguagem imaginária, parecida com Pascal: monitor exemplo integer i; condition c; procedure produtor(x); . . . end;
15

Sistemas Operacionais Distribuídos

UNESP/IBILCE

procedure consumidor(x); . . . end; end monitor; Para usar monitores, é necessário uma linguagem específica que suporte este conceito. Hoje, existem poucas linguagens com esta característica. 6.4. Regiões Críticas Condicionais Uma região crítica condicional (RCC) é uma versão estruturada da abordagem com semáforos. Códigos da região crítica são explicitamente nomeados e expressados por region-begin-end. Uma vez na região crítica uma condição pode ser testada pelo atributo when. Se a condição não for satisfeita, o processo é suspenso e outros processos poderão entrar em suas regiões críticas. Esta abordagem de estrutura de controle assume variáveis compartilhadas e requer compilação de regiões críticas dentro de primitivas de sincronização que são disponibilizadas pelo sistema operacional. A necessidade de um endereço comum e a impossibilidade de compilação separada não faz do RCC um bom candidato para adaptação em sistemas distribuídos. “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; 6.5. Expressões de Caminho É uma especificação de linguagem de alto nível que descreve como operações definidas por um objeto compartilhado podem ser invocadas de forma a satisfazer os requisitos de sincronização. Por esta razão, nós nos referimos a ela como uma estrutura de programa desde que ela lembra a descrição formal de um programa. Ex: path 1:([read], write) end

16

Sistemas Operacionais Distribuídos

UNESP/IBILCE

A constante 1 restringe o número de atividades simultâneas nos parênteses a apenas uma e então determina a exclusão mútua entre processo leitor e escritor. Os colchetes indicam que os leitores podem ser concorrentes. 6.6. Sincronização por Passagem de Mensagem Sem memória compartilhada, a passagem de mensagem é a única forma de comunicação em sistemas distribuídos. A passagem de mensagem é também uma forma de sincronização implícita desde que as mensagens só podem ser recebidas depois delas terem sido enviadas. Para a maioria das aplicações, é comum assumir que a primitiva receive bloqueia o processo e a primitiva send pode ou não bloquear o processo. Diremos que a passagem de mensagem é assíncrona quando a primitiva send não bloqueia o processo, e quando ela o bloqueia, diremos que a passagem de mensagem é síncrona. 6.6.1. Passagem de Mensagem Assíncrona Embora não haja variáveis compartilhadas, o canal de comunicação é compartilhado. O bloqueio proveniente da primitiva receive é equivalente à operação P em um semáforo e a primitiva send quando não bloqueia o processo é análoga à operação V. A passagem de mensagem assíncrona é uma extensão do conceito de semáforo em sistemas distribuídos. 6.6.2. Passagem de Mensagem Síncrona

Aqui, a primitiva send bloqueia o processo. Isto é necessário quando não há buffers no canal de comunicação. 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 compatíveis de send e receive se unam e troquem dados em um ponto de sincronização e continuem suas execuções separados a partir daí. Este tipo de sincronização é chamado de um ponto de encontro (rendezvous) entre send e receive. 6.7. Chamada Remota a Procedimentos Com o objetivo de facilitar a implementação de aplicações 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 comunicação providas pela rede de computadores. O mecanismo de RPC tem por objetivo possibilitar que procedimentos que se encontram em outras máquinas possam ser chamados da mesma forma como procedimentos que se encontram na máquina onde se encontra o código cuja execução resultou na chamada ao procedimento. Quando procedimentos locais são chamados, o fluxo de execução do programa é desviado para o procedimento, o procedimento é executado e o fluxo de execução retorna para a instrução seguinte à chamada do procedimento. Em uma aplicação cliente-servidor desenvolvida com o mecanismo de RPC, o procedimento chamado se encontra em uma máquina diferente daquela onde está sendo executado o

17

Sistemas Operacionais Distribuídos

UNESP/IBILCE

código que resultou na chamada ao procedimento. O programa cliente chama procedimentos que se fazem passar pelos procedimentos que serão executados no servidor. O código presente nos procedimentos esconde do restante do cliente os detalhes envolvidos na comunicação com os procedimentos remotos. O servidor contém o código que implementa a lógica da aplicação e o código inserido pelo ambiente de desenvolvimento. O código inserido recebe as solicitações do cliente, chama o procedimento local adequado e envia os resultados de volta para o cliente. Este código esconde do servidor os detalhes do processo de comunicação através da rede. Os ambientes de desenvolvimento que suportam RPC contêm um compilador que insere o código necessário tanto no cliente quanto no servidor. Para que a comunicação entre cliente e servidor seja realizada com sucesso, é necessário que o cliente chame os procedimentos remotos com a quantidade e tipos de parâmetros esperados pelo servidor. É também necessário que o cliente aguarde a mesma quantidade e tipos de resultados que serão retornados pelo servidor. A compatibilidade entre cliente e servidor é garantida por informações em um arquivo usado quando da compilação tanto do cliente quanto do servidor. Em tal arquivo são encontradas as definições dos procedimentos, as quais são compostas pelos nomes dos procedimentos, quantidades e tipos dos argumentos, quantidades e tipos dos valores retornados. Os arquivos de definição são escritos usando-se uma linguagem de definição própria do ambiente de desenvolvimento. Para que a compilação seja realizada com sucesso, o código no cliente e no servidor precisam aderir ao arquivo de definições. Após a compilação do cliente e do servidor, os programas serão instalados nas máquinas apropriadas e, quando da execução do cliente, será necessária a identificação da máquina na qual se encontra o servidor. A identificação pode ser feita através de informações inseridas no código do cliente ou através de um serviço de binding. Este serviço é provido pelo binder, responsável por armazenar informações que possibilitam aos clientes identificar onde se encontram os servidores. As informações armazenadas no binder são providas pelos próprios servidores quando iniciam a sua execução. Em outras palavras, os servidores se registram com o binder. Após identificar em que máquina o serviço é provido, o cliente se comunica com um processo que executa na mesma máquina onde se encontra o servidor. O processo é responsável por informar ao cliente em que porta de comunicação o servidor pode ser encontrado. Em uma rede de computadores, um servidor pode ser encontrado desde que se saiba o endereço da máquina onde se encontra e o número da porta de comunicação utilizada. Portanto a localização do servidor pelo cliente ocorre em duas etapas. Na primeira etapa é identificada a máquina e, na segunda, a porta onde o serviço é prestado. A porta usada pelo processo que informa as portas usadas pelos servidores é conhecida pelos clientes. Isto possibilita a localização do processo pelos clientes. 6.8. Ada Rendevouz A construção de monitores não moldam a sincronização em sistemas distribuídos, onde seria necessário a sincronização de unidades, na qual cada processador teria sua própria memória, em vez de uma única memória compartilhada. Para impor a exclusão mútua ou para sincronizar os processos independentes é comum a utilização de monitores, mas quando estamos em sistemas onde não há memória comum nem uma único processador, a implementação dos monitores se torna inviável, porque que

18

Sistemas Operacionais Distribuídos

UNESP/IBILCE

não existe nenhum meio físico central. A linguagem de programação Ada surge com a técnica de encontros (Rendez-Vous) para tratar estes casos. Na linguagem ADA é permitida a programação de atividades paralelas, que normalmente necessitam de sincronização. Referimo-nos a essa atividades como tarefas (tasks). Para a programação dessas tarefas utilizamos a técnica de encontros, que incorpora os mecanismos de exclusão mútua e de comunicação. Existem dois tipos de processos aos quais nos referiremos durante a explicação do funcionamento da técnica de encontros na linguagem ADA: Tarefa servidora: tarefa que contém operações definidas em seu código; Tarefa atuante: : tarefa que invoca as operações existentes na tarefa servidora. É denominada entrada cada conjunto de operações associada aos meios de comunicação existentes entre os processos. Uma entrada é definida dentro de uma tarefa, para acessá-la é necessário conhecer o nome da tarefa em tempo de programação. A estrutura do comando ACCEPT permite que a tarefa servidora implemente operações 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 pôr ordem de chegado. Quando a ordem de atendimento não for por ordem de chegada, utiliza-se o comando SELECT e os seus blocos contém comandos guardados que associados aos comandos ACCEPT, possibilitam encontros condicionais. O comando SELECT possui também uma cláusula ELSE, cujo código é executado quando não houver comandos com guarda atendida. O bloqueio de tarefas atuantes, pode ser evitado pôr meio de chamadas condicionais, que realiza o CALL somente se o encontro for possível imediatamente. Em tarefas servidoras, o bloqueio é evitado verificando, antes do ACCEPT, se existem tarefas aguardando para serem atendidas pôr aquela entrada.

19

Sistemas Operacionais Distribuídos

UNESP/IBILCE

Bibliografia
TANENBAUM, A. S. Modern Operating Systems, 1992.

MARRANGHELLO N. Apostila de Sistemas Operacionais Distribuídos, 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

You're Reading a Free Preview

Descarregar
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->