Sistemas operacionais

Sistemas OperacionaisDistribuídos

Alunos: Wanderlei Pereira Alves Junior Júlio Cezar Estrella

Orientação: Prof. Dr. Norian Marranghello

Sistemas Operacionais Distribuídos UNESP/IBILCE

2

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 processosCusto de criação e implementação de ramificaçõesRamificações no servidor ou no núcleo de sistemas operacionaisRamificações em multiprocessadoresO modelo cliente/servidorConstruções de linguagensMecanismos de sincronizaçãoEspecificação de atividades concorrentesSincronização e comunicação entre processosExecução não deterministic de processosEstrutura de programasEstrutura de dadosEstruturas de controleSincronização de variáveis compartilhadasSemáforosMonitoresRegiões criticas condicionaisPath ExpressionsSincronização por passagem de mensagensChamada remota de procedimentosAda RendevouzProcessos Concorrentes


3

1. Classificação dos Sistemas Operacionais

Os sistema operacionais podem ser classificados de acordo com seu grau de acoplamento, asaber:

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 quea ê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 donúcleo. Nos sistemas monolíticos os serviços do sistema e do núcleo fazem parte de ummesmo programa.

1.2. Sistemas em Rede

Características:

É um multicomputador fracamente acoplado no qual não existe nenhum tipo de controledireto 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 nosSistemas Distribuídos, mas abolem a impressão de que existe somente um usuário nosistema.


4

1.4. Sistemas Distribuídos

São aqueles que gerenciam as atividades e os recursos distribuídos, possibilitando umprocessamento 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 ummecanismo 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 seusrecursos.

Obs: A eficiência em sistemas distribuídos é mais complexa em relação aos SistemasOperacionais Convecionais, devido aos atrasos na comunicação.Obs: O tempo gasto na propagação dos dados depende fortemente do protocolo decomunicação utilizado, motivo pelo qual este deve ser bem projetado, como base emprimitivas 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


5

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çãoexistentes.Transparência

Capacidade que um Sistema apresenta, de esconder dos usuários, detalhes deimplementação, em particular àqueles mais complexos, e apresentar na medida do possívelum 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 únicoprograma, realizando várias tarefas “ao mesmo” tempo.


6

Exemplo: programa do usuário + coleta de lixo

Diferentes threads podem executar em diferentes processadores, se disponíveis, oucompartilhar 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 aomesmo tempo, independentemente umas das outras.Quando executado, um programa pode gerar ramificações no seu fluxo de controle. Taisramificações (threads) tem seus estados locais individuais, mas permanecem associados aoprocesso que as gerou.

Cada um desse processos possui um TCB (Thread Control Blocks), semelhante ao PCB dosprocessos. Como os threads são processos leves, associados aos processos que os gerou,esses TCB possuem informações locais reduzidas (contador de programa, apontadores depilha e conjunto de registradores).

A mudança de contexto de um thread em relação a um processo é mais rápida pois osthreads além possuem informações locais, compartilham o restante das informações com osprocessos que os gerou.

Os processos funcionam como máquinas virtuais, pois compartilham seu espaço deendereç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 osthreads são controlados por procedimentos em tempo de execução que serve como interfaceentre 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ãoimplementados 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 eportanto são não-preemptíveis.


7

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 sistemaoperacional, 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 bloqueiode 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 processopai, e também outras ramificações em execução. O thread também irá competir igualmentecom 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 amesma 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


8

2.4. Aplicações Multithread

Programas multithread são programas que contém várias threads, executando tarefasdistintas, simultaneamente. O browser HotJava, implementado em Java, é um exemplo. Damesma forma que o Netscape, o HotJava poderá fazer um scroll em uma página enquantocarrega 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 paraexibir mensagens, outra para fazer animação, etc..

Paralelismo físico/ distribuição: para tirar vantagem de múltiplas CPUs centralizadas oudistribuí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 agrupamentodos threads num mesmo espaço de endereçamento, admitindo acesso concorrente de váriosclientes 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


9

Essas ramificações compartilham o mesmo espaço de endereço (dos processos pais), entãoquando precisam acessar algum recurso compartilhado, a exclusividade do acesso é feitavia 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 oespaç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 umprocesso 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 controlevolta novamente ao processo que a criou.

Por exemplo, se forem feitas várias operações de leitura, serão geradas várias ramificaçõesdo 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 foramcriadas, 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 etambém reaproveitada assim que essas terminem sua execução, levando a uma reduçãoconsiderável no custo do sistema.

Além da localização da implementação que descrevemos anteriormente serão mencionadosnos 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.


10

3. Ramificações em Multiprocessadores

Se um programa corre em um multiprocessador, os processos leves executam emsimultâneo, cada um no seu processador.

Vantagens

Mesmo em monoprocessadores o desempenho de uma aplicação pode ser melhoradousando esta técnica: se um dos processos se bloqueia numa chamada ao sistema, outroprocesso leve pode ocupar o processador.

4. Modelo Cliente – Servidor

O modelo cliente/servidor é um paradigma de programação que representa as interaçõesentre o processos e estruturas do sistema. Esse modelo é usado para melhorar a estruturado sistema operacional, movendo-se a maior quantidade possível de funções para níveismais altos do sistema, reduzindo o tamanho do núcleo.

O modelo cliente/servidor geralmente refere-se a um modelo onde dois ou maiscomputadores interagem de modo que um oferece serviços aos outros. Este modelopermite ao usuários acessarem informações e serviços de qualquer lugar.

Cliente/Servidor é uma arquitetura computacional que envolve requisições de serviços declientes para servidores.

Portanto a definição para cliente/servidor seria a existência de uma plataforma base paraque as aplicações, onde um ou mais clientes e um ou mais servidores, juntamente com osistema operacional de rede, executem processamento distribuído.

O modelo poderia ser entendido como a interação entre software e hardware em diferentesní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á naligaçã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 parauma real abordagem cliente/servidor é a necessidade de que a arquitetura definidarepresente uma computação distribuída.

Caracteríscas

Cliente

Também denomidado de “front-end” e “workstation”, é um processo que interage com ousuário através de uma interface gráfica ou não, permitindo consultas ou comandos para a


11

recuperação de dados e análise, e representando o meio pela qual os resultados sãoapresentados.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 ficadisponível para todo cliente que o necessita. A natureza e o escopo dos serviços sãodefinidos 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 dosservidores,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 degradara performance.

O Cliente e o Servidor possuem ambientes operacionais individuais: Pode-se misturarvárias paltaformas para melhor atender às necessidades individuais de diversos setores eusuários.


12

Desvantagens do modelo

Manutenção: As diversas partes envolvidas nem sempre funcionam bem juntas. Quandoalgum erro ocorre, existe uma extensa lista de itens a serem investigados.

Ferramentas: A escassez de ferramentas de suporte, não raras as vezes obriga odesenvolvimento de ferramentas próprias. Em função do grande poderio das novaslinguagens de programação, esta dificuldade está ser tornando cada vez menor.

Gerenciamento: O aumenta da complexidade do ambiente e a escassez de ferramentas deauxílio tornam difícil o gerenciamento da rede.

O processo Cliente requisita serviços ao Servidor:

É um modelo baseado no estabelecimento de uma conexão, sendo possível serimplementado 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. Outrasprimitivas 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 mensagem2. A forma como as mensagens são disponibilizadas3. Confiabilidade do mecanismo de troca de mensagens

Pedido

Resposta


13

Segundo o primeiro critério, as primitivas são classificadas como bloqueadoras e nãobloqueadoras. Bloqueadoras quando o processo fica paralisado durante a transmissão deum mensagem. Não bloqueadoras quando o processo fornece uma cópia da mensagem aosistema 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 paracomunicação.

O terceiro trata da confiabilidade das primitivas, que é não confiável, pois utiliza-se aresposta 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 significaexecuçã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


14

6. Sincronização e Comunicação de Processos

Uma forma de comunicação entre processos freqüentemente usada em Sistemasoperacionais é feita através de variáveis compartilhadas onde os processos podem ler eescrever dados. Nesta forma de comunicação existe a possibilidade de ocorrer situações decorrida, que são situações onde dois ou mais processos atuam sobre dados compartilhadose o resultado final do processamento depende de quem executa quando. A análise deprogramas em que ocorrem condições de corrida não é uma tarefa fácil. Os resultados damaioria dos testes são consistentes com a estrutura do programa, mas de vez em quandoocorre algo imprevisto e inexplicável, em função do não-determinismo potencial, causadopelas condições de corrida.

Para evitar estas situações de corrida, implementamos mecanismos para assegurar quequando um processo atua sobre uma variável compartilhada os demais serão impedidos defaze-lo (exclusão mútua).

A parte do programa que pode levar a ocorrência de condições de corrida, é denominadaregião crítica.

6.1. Construtores Das Linguagens

As linguagens concorrentes são obtidas pelo acréscimo de certas construções próprias parasincronização e comunicação de processos concorrentes a linguagens seqüenciais. Osprincipais construtores das linguagens, usados na implementação dos mecanismos desincronizaçã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çõesprimitivas (indivisíveis): P(S) e V(S). P e V têm sua origem das palavras parsen (passar) ee vrygeren (liberar). As operações P e V são assim definidas:


15

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+1Os 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 relativamentesimples, 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 deprogramas paralelos, Hoare e Brinch Hansen propuseram uma primitiva de alto nível parasincronização de processos, denominada monitor. Um monitor é um conjunto deprocedimentos, 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 domonitor a partir de procedimentos declarados fora do monitor. Os monitores têm umapropriedade muito importante: somente um processo pode estar ativo dentro do monitor emum dado instante. É tarefa do compilador implementar a exclusão mútua de execução sobreo 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 é osuficiente, é preciso que haja uma forma de bloqueio de processos quando não houvercondições lógicas para eles continuarem o processamento. Isto é feito com as variáveis decondição e duas operações sobre elas, WAIT e SIGNAL. Essas variáveis de condiçãopermitem 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;


16

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 comsemáforos. Códigos da região crítica são explicitamente nomeados e expressados porregion-begin-end. Uma vez na região crítica uma condição pode ser testada pelo atributowhen. Se a condição não for satisfeita, o processo é suspenso e outros processos poderãoentrar em suas regiões críticas.

Esta abordagem de estrutura de controle assume variáveis compartilhadas e requercompilação de regiões críticas dentro de primitivas de sincronização que sãodisponibilizadas pelo sistema operacional. A necessidade de um endereço comum e aimpossibilidade de compilação separada não faz do RCC um bom candidato para adaptaçãoem 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 = 0begin<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 porum objeto compartilhado podem ser invocadas de forma a satisfazer os requisitos desincronização. Por esta razão, nós nos referimos a ela como uma estrutura de programadesde que ela lembra a descrição formal de um programa.Ex:

path 1:([read], write) end


17

A constante 1 restringe o número de atividades simultâneas nos parênteses a apenas uma eentão determina a exclusão mútua entre processo leitor e escritor. Os colchetes indicam queos 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çãoem sistemas distribuídos. A passagem de mensagem é também uma forma de sincronizaçãoimplí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 oprocesso e a primitiva send pode ou não bloquear o processo. Diremos que a passagem demensagem é assíncrona quando a primitiva send não bloqueia o processo, e quando ela obloqueia, 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. Obloqueio proveniente da primitiva receive é equivalente à operação P em um semáforo e aprimitiva send quando não bloqueia o processo é análoga à operação V. A passagem demensagem 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 nocanal de comunicação. Um send deve aguardar que o receive correspondente ocorra, e oreceive deve esperar pelo send correspondente. Este mecanismo permite que dois processoscom pares compatíveis de send e receive se unam e troquem dados em um ponto desincronização e continuem suas execuções separados a partir daí. Este tipo desincronizaçã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 decomputadores, ambientes de desenvolvimento passaram a suportar a Chamada aProcedimentos Remotos (RPC - Remote Procedure Call). Os ambientes dedesenvolvimento que suportam o mecanismo de RPC escondem do programador boa partedos detalhes envolvidos no uso das facilidades de comunicação providas pela rede decomputadores. O mecanismo de RPC tem por objetivo possibilitar que procedimentos quese encontram em outras máquinas possam ser chamados da mesma forma comoprocedimentos que se encontram na máquina onde se encontra o código cuja execuçãoresultou na chamada ao procedimento. Quando procedimentos locais são chamados, o fluxode execução do programa é desviado para o procedimento, o procedimento é executado e ofluxo de execução retorna para a instrução seguinte à chamada do procedimento. Em umaaplicação cliente-servidor desenvolvida com o mecanismo de RPC, o procedimentochamado se encontra em uma máquina diferente daquela onde está sendo executado o


18

código que resultou na chamada ao procedimento. O programa cliente chamaprocedimentos 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 envolvidosna comunicação com os procedimentos remotos. O servidor contém o código queimplementa a lógica da aplicação e o código inserido pelo ambiente de desenvolvimento. Ocódigo inserido recebe as solicitações do cliente, chama o procedimento local adequado eenvia os resultados de volta para o cliente. Este código esconde do servidor os detalhes doprocesso de comunicação através da rede. Os ambientes de desenvolvimento que suportamRPC contêm um compilador que insere o código necessário tanto no cliente quanto noservidor. 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 deparâmetros esperados pelo servidor. É também necessário que o cliente aguarde a mesmaquantidade e tipos de resultados que serão retornados pelo servidor. A compatibilidadeentre cliente e servidor é garantida por informações em um arquivo usado quando dacompilação tanto do cliente quanto do servidor. Em tal arquivo são encontradas asdefinições dos procedimentos, as quais são compostas pelos nomes dos procedimentos,quantidades e tipos dos argumentos, quantidades e tipos dos valores retornados. Osarquivos de definição são escritos usando-se uma linguagem de definição própria doambiente de desenvolvimento. Para que a compilação seja realizada com sucesso, o códigono cliente e no servidor precisam aderir ao arquivo de definições. Após a compilação docliente e do servidor, os programas serão instalados nas máquinas apropriadas e, quando daexecução do cliente, será necessária a identificação da máquina na qual se encontra oservidor. A identificação pode ser feita através de informações inseridas no código docliente ou através de um serviço de binding. Este serviço é provido pelo binder, responsávelpor armazenar informações que possibilitam aos clientes identificar onde se encontram osservidores. As informações armazenadas no binder são providas pelos próprios servidoresquando iniciam a sua execução. Em outras palavras, os servidores se registram com obinder. Após identificar em que máquina o serviço é provido, o cliente se comunica comum 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 serencontrado. Em uma rede de computadores, um servidor pode ser encontrado desde que sesaiba o endereço da máquina onde se encontra e o número da porta de comunicaçãoutilizada. Portanto a localização do servidor pelo cliente ocorre em duas etapas. Naprimeira etapa é identificada a máquina e, na segunda, a porta onde o serviço é prestado. Aporta usada pelo processo que informa as portas usadas pelos servidores é conhecida pelosclientes. 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, ondeseria necessário a sincronização de unidades, na qual cada processador teria sua própriamemória, em vez de uma única memória compartilhada.Para impor a exclusão mútua ou para sincronizar os processos independentes é comum autilização de monitores, mas quando estamos em sistemas onde não há memória comumnem uma único processador, a implementação dos monitores se torna inviável, porque que


19

não existe nenhum meio físico central. A linguagem de programação Ada surge com atécnica de encontros (Rendez-Vous) para tratar estes casos.

Na linguagem ADA é permitida a programação de atividades paralelas, que normalmentenecessitam de sincronização. Referimo-nos a essa atividades como tarefas (tasks). Para aprogramação dessas tarefas utilizamos a técnica de encontros, que incorpora os mecanismosde exclusão mútua e de comunicação.

Existem dois tipos de processos aos quais nos referiremos durante a explicação dofuncionamento 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çãoexistentes 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çõesdiferentes para chamadas a uma mesma entrada, usando comandos ACCEPT paraprocedimentos distintos. O comando ACCEPT atende chamadas originadas de qualqueroutra 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 porordem de chegada, utiliza-se o comando SELECT e os seus blocos contém comandosguardados que associados aos comandos ACCEPT, possibilitam encontros condicionais. Ocomando SELECT possui também uma cláusula ELSE, cujo código é executado quandonão houver comandos com guarda atendida.

O bloqueio de tarefas atuantes, pode ser evitado pôr meio de chamadas condicionais, querealiza o CALL somente se o encontro for possível imediatamente. Em tarefas servidoras, obloqueio é evitado verificando, antes do ACCEPT, se existem tarefas aguardando paraserem atendidas pôr aquela entrada.


20

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

Sistemas operacionais

Education

Transcript of Sistemas operacionais