< Voltar    E-mail
sistemas operacionais distribuídos

INTRODUÇÃO

            Este trabalho tem o intuito de mostrar uma nova tecnologia de software de rede, que são os Sistemas Operacionais Distribuídos. Muito embora essa tecnologia não seja tão nova assim, atualmente vêm sendo feito muitos esforços no meio científico para que sejam vencidas algumas dificuldades que esta tecnologia ainda enfrenta.

            O trabalho tenta mostrar de uma forma simplificada as características principais, vantagens e desvantagens de um Sistema Operacional Distribuído e também mostrar dois dos principais que são o Sistema Mach e o Sistema Amoeba.
 
 
 
 

2  Tópicos sobre Sistemas Operacionais Distribuídos
 
 

2.1 Objetivos
 
 

Os Sistemas Distribuídos têm, por seu maior objetivo, melhorar a comunicação entre os computadores, ou melhor, propiciar a integração destes num sentido amplo que pode envolver facilidade de mudanças futuras, rapidez nas trocas de informações, confiabilidade na execução dos processos.

 Porém, no desenvolvimento de um sistema distribuído encontramos um pequeno problema: software. Devido ao elevado tamanho e complexidade de sistemas distribuídos, o seu desenvolvimento exige um conhecimento bastante profundo dessa área e a utilização de técnicas adequadas de concepção e projeto de sistemas.

O sistema distribuído é a existência de um relacionamento mais forte entre os seus componentes, onde geralmente os sistemas operacionais são os mesmos.
    Podem ser considerados também como a evolução para os sistemas fortemente acoplados, onde uma aplicação pode ser executada por qualquer processador. Os sistemas distribuídos permitem que uma aplicação seja dividida em diferentes partes, que se comunicam através de linhas de comunicação, e cada parte podendo ser processada em um sistema independente. O objetivo do sistema distribuído é criar na cabeça de seus usuários a ilusão de que toda rede de computadores nada mais é do que um único sistema de tempo compartilhado (time-sharing), em vez de um conjunto de máquinas distintas. Portanto um “Sistema Distribuído é aquele que roda em um conjunto de máquinas sem memória compartilhada, máquinas que mesmo assim aparecem como um único computador para seus usuários”.
 
 

2.2 Características

De uma forma mais específica, existem algumas características que fazem com que os sistemas distribuídos sejam indicados em muitos projetos de sistemas, como:

 a) Crescimento incremental: um sistema distribuído apresenta facilidades de expansão, ao contrário de outro sistema que não permitem expansão, a não ser por repetição. A repetição apresenta o inconveniente de produzir dois ou mais sistemas distintos,  em vez de um sistema maior;

 b) Confiabilidade: sistemas distribuídos podem ser potencialmente mais confiáveis devido à multiplicidade e a um certo grau de autonomia de suas partes. É notório que a distribuição física não é tão importante quanto a distribuição lógica. Esta última pode ser implementada tanto a um único processador quanto a vários processadores localizados num mesmo ambiente ou em ambiente distintos. A distribuição física está mais ligada a questões de desempenho, tempo de resposta, organização do sistema e principalmente à possibilidade de ter-se controle explicito sobre o processamento e informações locais.

c) Estrutura: sistemas distribuídos podem  refletir a estrutura organizacional à qual eles servem;

d) Proteção: sistemas distribuídos podem oferecer mais segurança do que sistemas centralizados. A segurança resulta muito mais da distribuição lógica do sistema do que  da sua  distribuição física.

2.3 Aspectos de tolerância a falhas

Pelo fato de sistemas distribuídos possuírem múltiplas partes de hardware e de software funcionando conjuntamente, as chances de algumas dessas partes falhar é bem maior do que ocorreria num sistema simples.

Um sistema distribuído pode apresentar falhas de vários tipos, dentre as quais aquelas provenientes de defeitos nas linhas de comunicação que interligam os processadores e aquelas referentes a colapsos nos processadores.

Em sistemas tolerantes a falhas, o efeito de defeitos e interferências indevidas pode ser superado através de redundância temporal e/ou redundância física. A redundância temporal corresponde à determinação de um resultado através de execuções repetidas da mesma operação pelo mesmo elemento, usando eventualmente métodos diferentes. A redundância física consiste em ter-se elementos repetidos capazes de executar a mesma operação. Esses elementos referem-se tanto ao hardware quanto ao software do sistema.

Um sistema, quando não funciona bem, apresenta como conseqüência resultados incorretos conhecidos por erros. A causa dos erros é a presença de defeitos ou interferências indevidas, conhecidos por falhas, que aparecem tanto a nível de hardware quanto de software. Ao evento que corresponde ao desvio de comportamento esperado do sistema denominamos falha.

Até hoje, quando um computador falha, existe uma forte torcida para que seus usuários aceitem este fato como "coisas da vida". Infelizmente, as pessoas estão ficando "mal acostumadas", na expectativa de que os serviços que lhe são oferecidos não falhem. Se um canal de televisão, ou sistema telefônico, ou sistema de distribuição de energia saírem do ar por meia hora, no dia seguinte haverá uma grita geral dos usuários contra a infeliz companhia concessionária. À medida que os sistemas distribuídos tornam-se mais difundidos, cresce a demanda por sistemas que nunca falham. Os sistemas atuais não preenchem esta necessidade.

Obviamente, como já foi dito, os sistemas tolerantes a falhas vão precisar de considerável redundância do hardware e da infra-estrutura de comunicação. Também será necessário a redundância do software e mais especificamente dos dados. A replicação de arquivos será uma questão essencial para os futuros sistemas. Os sistemas terão também de ser projetados de maneira a funcionar quando somente parte dos dados estiverem disponíveis, uma vez que a insistência em se ter todos os dados disponíveis todo o tempo não leva a sistemas tolerantes a falhas. Vale observar que o fato de se Ter o sistema indisponível por alguns instantes, hoje considerado aceitável, torna-se cada vez menos razoável, à medida que o computador vai sendo difundido e usado por não-especialistas.
 
 

2.4 Aspectos de Projeto

Existem alguns aspectos importantes que as pessoas envolvidas no projeto no sistema distribuído devem tratar necessariamente:

 Transparência:

Este aspecto faz com que um conjunto de máquinas seja visto por seus usuários como se fossem simplesmente um único sistema de tempo compartilhado.

            Tipos distintos de transparência em um sistema distribuído:

à             Migração: Os recursos podem mudar de lugar sem ter que mudar seus nomes.
à            Replicação: Os usuários não devem saber quantas cópias existem.
à             Concorrência: Vários usuários podem compartilhar automaticamente os recursos.
à             Paralelismo: Podem ocorrer atividades paralelas sem que os usuários venham a saber.

Flexibilidade:

É muito importante que o sistema seja flexível as decisões do projeto que hoje parecem bem razoáveis poderão revelar-se erradas mais tarde. A melhor maneira de se evitar problemas é mantendo várias opções em aberto (flexibilidade).

Confiabilidade:

Os dados confiados à guarda dos sistemas não podem de maneira nenhuma, sofrer qualquer tipo de adulteração ou perder-se . o aspecto da confiabilidade global é a segurança. Os arquivos e de mais recursos devem ser protegidos contra uso-não-autorizado. Isso se torna crítico no caso dos sistemas distribuídos.
Em geral, um Sistema Distribuído pode ser projetado para “mascarar” falhas ocorridas, esconder do seus usuários.

Performance:

O problema da performance é muito influenciada pela comunicação. O envio de uma mensagem e a obtenção da resposta correspondente demora em torno de um milissegundo, e a maior parte desse tempo é gasto no tratamento do protocolo, quando deveria ser gasto na transmissão dos bits propriamente ditos. A dificuldade dessa técnica é que para ganhar performance é preciso ter várias atividades rodando em paralelo em diferentes processadores, mas para isso é necessário a transmissão de muitas mensagens.

Escabilidade:

Um sistema verdadeiramente escalável deve ajustar-se às necessidades crescentes e permitir a adição de novos recursos.
 
 

2.5 Desempenho de um Sistema Distribuído

            O desempenho, considerado fator primordial de um Sistema Computacional Distribuído, é analisado sobre o ponto de vista do usuário através dos tempos de resposta obtidos a partir de uma requisição.

            Na Estação de Trabalho/Servidor, vários são os elementos que afetam o desempenho do Sistema. Entretanto, destacam-se os elementos Estação de Trabalho, Servidor e Rede de Comunicação, considerados os mais importantes para análise de desempenho.
 
 

2.6 Elementos que afetam o desempenho de um Sistema Distribuído

            Os elementos estação de trabalho, servidor e rede de comunicação são considerados os mais relevantes para análise de desempenho de um Sistema Distribuído. O desempenho individual de cada elemento é diretamente influenciado pelos demais, como pode ser observado nas seguintes situações:

à Servidores com grande capacidade de processamento, meio de comunicação de alta velocidade de estações de trabalho com baixa capacidade de processamento: as estações de trabalho não conseguem processar as informações na mesma velocidade em que estas chegam e, com isso, o tempo de resposta observado pelos usuários não é satisfatório, considerando-se as características dos servidores e do meio de comunicação.

à  Estações de trabalho com grande capacidade de processamento, meio de comunicação de alta velocidade e servidores com  baixa capacidade de processamento em relação à carga de trabalho: as estações de trabalho precisam esperar as informações requisitadas aos servidores para continuar o processamento do job e, com isso, o tempo de resposta observado pelo usuário também não é satisfatório, considerando-se as características das estações de trabalho e do meio de comunicação.

à Servidores e estações de trabalho com grande capacidade de processamento e meio de comunicação de baixa velocidade: o tempo gasto na transmissão das informações degrada o tempo de resposta, tornando-o pouco satisfatório considerando-se as características dos servidores e das estações de trabalho.
 
 

2.7 Processamento Distribuído (Cliente/ Servidor)

            É um tipo de processamento descentralizado em que os computadores comunicam-se uns com os outros através de vários meios de comunicação tais como barramentos de alta velocidade ou linhas telefônicas. Eles não compartilham nem a memória principal e nem o processamento das informações. Os processadores em um sistema distribuído podem variar em tamanho e função. Podem incluir pequenos microcomputadores, estações de trabalho, minicomputadores e sistemas de computadores de uso geral. Esses processadores são chamados por diversos nomes tais como: nós, locais(sites) e computadores.
 
 

2.8 Software Distribuído

Dos quatro elementos de um sistema que podem estar distribuído - hardware, dados, programas e controle -, os três últimos referem-se ao software. A distribuição de dados levou ao desenvolvimento de uma área bastante extensa, envolvendo sistemas de arquivos distribuídos, e sistemas de banco de dados distribuídos. A seguir, consideramos os aspectos de distribuição de controle, cuja influência no desenvolvimento de sistemas operacionais tem sido determinante.

Para iniciarmos o estudo da distribuição de programas (algoritmos), é necessário que sejam abordados os seguintes tópicos:

à um programa é dito distribuído se estiver espalhado por vários ambientes, ou seja, se alguns processadores (ambientes) não puderem executar alguns passos do programa, pelo fato de eles pertencerem a outros ambientes;

à qualquer programa seqüencial ou paralelo pode ser um programa distribuído.
Diante disso, um programa será distribuído se puder ser estruturado em partes, formadas por grupos de instrução e conhecidas como componentes do programa, colocadas de forma que cada parte só possa ser executada pelo processador a ela associado. Os componentes do programa separados pelo subsistema de comunicação são conhecidos como remotos uns aos outros. A troca de informações entre componentes remotos do sistema deverá ocorrer por transferência de mensagens, através do meio de comunicação.

Como exemplo de programa distribuído pode-se citar o programa seqüencial formado por um programa principal e sua sub-rotina, localizados de forma a serem remotos um ao outro.

2.9 Estruturação de Sistemas Distribuídos

2.9.1 Estruturação baseada na distribuição física
Dentre os vários modelos baseados da distribuição física, encontram-se o modelo hierárquico, o do cache de CPU, o usuário servidor e o modelo de conjunto de processadores.

 No modelo hierárquico, os computadores são dispostos em uma rede sob a forma de árvore, de maneira que quanto mais próximos estiverem da raiz, mais potentes deverão ser. O computador da raiz tratará, de forma geral, do sistema como um todo, enquanto que os computadores distantes da raiz tratarão de tarefas específicas e especializadas.

 O modelo de cache de CPU consiste na utilização de computadores de menor porte como elementos que interligam terminais com uma grande CPU. Nesse caso, uma parte do processamento será executada no computador ligado ao terminal, e a outra parte no computador central.

O modelo usuário-servidor surgiu na medida em que os computadores pequenos, crescendo em potência e tendo seus preços reduzidos, diminuíram gradativamente a importância do computador central do modelo cache de CPU.

2.9.2 Estruturação Lógica
Modelos de processos:

Esses processos podem encapsular tanto elementos ativos com natureza, consistindo dos programas referentes às atividades do sistema e do usuário quanto elementos naturalmente passivos correspondendo aos recursos e suas respectivas operações, confinados em gerenciadores de recursos. A comunicação entre os processos, implementada pelo sistema operacional, pode ocorrer de duas formas:

à Chamada remota de procedimento: este tipo de comunicação entre processos é bastante dependente da linguagem usada para implementação do sistema, devendo satisfazer suas restrições com relação a chamada de procedimento e a passagem de parâmetros.

à Troca explícita de mensagem: este já é mais flexível do que o anterior, suas restrições estão relacionadas com a existência de ligações implícitas ou explícitas entre os processos e com a interpretação da mensagem.

Modelos de objetos:
            O modelo de objetos baseia-se no encapsulamento das várias partes de um sistema em elementos denominados objetos que são estruturados de forma a apresentarem um conjunto de operações responsáveis pelo seu comportamento. Para conseguir acessar um objeto, um processo deve ter capacidade de fazê-lo, usando o conhecimento do nome do objeto e a posse da autorização para cessar algumas ou todas as suas operações.
 
 

Modelos de Sistemas:

            Os processadores em um sistema distribuído podem ser organizados de diversas maneiras. Nesta seção iremos mostrar duas das organizações mais comuns, modelo de estação de trabalho e o modelo de pool de processadores.

O modelo da estação de trabalho:

            É extremamente simples: o sistema é composto de estações de trabalho (computadores pessoais de alto desempenho), podendo estar espalhadas por um edifício. E em alguns sistemas as estações de trabalho têm um disco local, e em outros não. Esta última é conhecida como estações diskless. Se as estações forem diskless, o sistema de arquivos deverá ser implementado em um ou mais servidores. As requisições de leitura e escrita são enviadas ao servidor que realiza a operação solicitada e envia de volta o resultado.

O Modelo Pool de Processadores:

            Neste modelo é entregue ao usuário terminais gráficos de alta performance, a exemplo dos terminais X, apesar de poderem ser usadas estações de trabalho de pequeno porte. E todos os processadores pertencem igualmente a todos os usuários.

2.10 Vantagens dos Sistemas Distribuídos

Vantagens do Sistema Distribuído sobre Os Centralizados:
            Os sistemas distribuídos oferecem uma economia muito grande, pois os microprocessadores tem uma melhor relação preço/performance do que a oferecida  pelos mainframes , por isso  a descentralização está caindo continuamente.

Outra razão para se construir sistemas distribuídos é o fato de muitas aplicações serem eminentemente distribuídas. Em um sistema de automação industrial que controla robôs e máquinas ao longo de uma linha de montagem, é interessante que cada robô e cada máquina tenham seu próprio processador. Se todos estes processadores estiverem conectados, teremos um sistema distribuído de automação industrial. No caso de aplicações críticas, como controle de instalações nucleares, ou o controle do tráfego aéreo, o uso de sistemas distribuídos é de fundamental importância.

Vantagens do Sistema Distribuído sobre  PCs Independentes:

O compartilhamento é a maior vantagem que os sistemas distribuídos tem sobre os PCs independentes, pois o compartilhamento de dispositivos permite que vários usuários tenham acesso a periféricos muito caros, tais como as impressoras laser a cores, as máquinas de fotocomposição, e os dispositivos de armazenamento de alta capacidade, especialmente os óticos, são também candidatos.

Outra razão para se fazer a conexão de um grupo de máquinas isoladas, transformando-as em um sistema distribuído é conseguir melhorar a comunicação entre as pessoas. Como exemplo temos o correio eletrônico, que possui muitos atrativos em relação aos meios de comunicação tradicionais.
 

2.11 Desvantagens dos Sistemas Distribuídos

            Apesar das vantagens em relação aos sistemas distribuídos centralizados, existem algumas desvantagens que serão relacionadas neste item.

à O primeiro problema está relacionado com a falta de software no mercado.

à O segundo problema potencial é o das redes de comunicação. Aqui, o ponto principal é a possibilidade de que sejam perdidas mensagens na rede, o que nos obriga a utilizar um software especial para fazer a manipulação das mensagens. Outro aspecto relativo às redes é a possibilidade de elas ficarem sobrecarregadas com o tráfego gerado pelo intercâmbio de mensagens.

à O terceiro problema está relacionado com a segurança dos dados, pois os dados secretos podem ser acessíveis com grande facilidade.
 
 
 
 
 

3 O Sistema Operacional Distribuído Mach

3.1 História:

                O sistema operacional Mach surgiu, como um projeto da Universidade de Rochester em 1975 e se chamava RIG (Rochester Intelligent Gateway). O RIG foi escrito para uma máquina de 16 bits da Data General, o Eclipse. O objetivo principal do projeto era demonstrar que sistemas operacionais poderiam ser construídos de uma forma modular, como uma coleção de processos se comunicando com troca de mensagens, incluindo o uso de uma rede na implementação das comunicações entre processos.Quando um dos engenheiros que participaram do projeto, Richard Rashid, mudou-se para a universidade de Carnegie-Mellon, em 1979, ele continuou com o projeto de desenvolver tais sistemas operacionais, porém em hardware mais avançado. A máquina escolhida foi o PERQ, uma estação de trabalho com tela gráfica, mouse e conexão de rede. Esse novo sistema operacional foi chamado de Accent e adicionava proteção, a capacidade de operar transparentemente sobre a rede, memória virtual de 32 bits e outros recursos.

            Uma versão inicial do sistema ficou pronta em 1981, sendo que em 1984, uma média de 150 PERQs rodavam Accent. Entretanto, o sistema UNIX estava ganhando espaço gradativamente. Esse fato levou Rashid a iniciar uma nova versão do seu sistema operacional chamado de Mach.

            O sistema Mach era compatível com o UNIX e, portanto, a maioria do software poderia ser aproveitado. Além disso, o sistema Mach possuía alguns recursos a mais que o Accent, tais como threads, um mecanismo melhor para implementar comunicação entre processos, suporte a multiprocessadores e um sistema de memória virtual complexo.

            O projeto do Mach foi bastante impulsionado pela agência de defesa americana, DARPA, que estava atrás de um sistema operacional que suportasse multiprocessamento. O DARPA decidiu que o sistema deveria ser compatível com o UNIX 4.2 BSD, levando os projetistas a desenvolverem um sistema combinando o Mach com o UNIX 4.2 BSD em um único kernel. A primeira versão do Mach ficou pronta em 1986 e rodava em um computador VAX 11/784 com 4 CPUs (Unidade Central de Processamento) . Pouco tempo depois, ele foi portado para IBM PC/RT e Sun 3. Por volta de 1987, o Mach rodava em máquinas Encore e Sequent (ambas multiprocessadas).

            Logo em seguida, IBM, DEC e HP formaram a Open Software Fundation (OSF), que tinha como objetivo tomar o controle do UNIX. A AT&T, criadora desse sistema, havia aliado-se com a Sun Microsystems para desenvolver o System V Release 4, e isso despertou o medo nos demais fabricantes. Finalmente, a OSF escolheu o Mach 2.5 como base para o seu sistema operacional, o OSF/1. Apesar de ambos sistemas conterem muitas linhas de código de Berkeley e até mesmo da AT&T, o objetivo da OSF era, ao menos, controlar a direção para a qual o UNIX estava indo.

            Em 1988, o kernel do Mach 2.5 era grande e monolítico. Assim, nessa mesma época, a universidade de Carnegie-Mellon retirou todo código de Berkeley da AT&T de dentro do kernel e colocou-o no espaço do usuário. O que sobrou foi um sistema microkernel com todo o código pertencente ao Mach. Esta versão foi chamada de 3.0.

3.2 Características do Sistema Mach
Os objetivos do sistema Mach eram os seguintes:
 
 

à fornecer uma base para a construção de outros sistemas operacionais;

à Suportar espaços de endereçamento esparsos;

à Permitir acesso transparente a recursos em rede;

à Explorar o paralelismo tanto no sistema operacional quanto nas aplicações;

à Tornar o sistema portátil, permitindo sua instalação nas mais variados arquiteturas.
 
 

            O sistema Mach foi construído de forma que outros sistemas operacionais como UNIX ou DOS pudessem ser emulados em cima. Um dos objetivos também era fazer com que ele suportasse multiprocessadores e ainda assim fosse portável. A emulação de outros sistemas operacionais é realizada através de uma arquitetura de camadas. Assim, o emulador funciona como uma camada fora do kernel e roda independentemente das outras aplicações. Outro fato que deve ser notado é que vários servidores podem estar rodando simultaneamente na mesma máquina, o que permite com que o usuário rode programas 4.3BSD, System V e MS-DOS ao mesmo tempo. A seguir temos uma ilustração do que é o sistema operacional distribuído Mach.

Assim como outros sistemas microkernel, o sistema Mach apenas provê serviços básicos como gerenciamento de processos e memória, comunicação e serviços de E/S. Outros serviços que antes residiam no espaço do kernel, foram transformados em processos de usuário, tais como o sistema de arquivos e diretórios.
 
 

São 5 os recursos gerenciados pelo microkernel:

à Processos

à threads (linhas de controle)

à objetos de memória

à portas

à mensagens

3.3 Gerenciamento de Processos
A estrutura básica no sistema Mach é o processo. Cada processo é um ambiente onde a execução acontece e possui um espaço de memória a ele associado para guardar dados e código (text) e uma ou mais pilhas. Da mesma forma, um canal de comunicação (ou porta) é alocada a um processo. Uma thread é uma entidade de execução e a ela estão associadas um contador de programa e um conjunto de registradores. Além disso, cada thread é associada a um processo, mas um processo pode conter várias threads. Um processo com uma única thread no Mach pode ser comparado a um processo comum do UNIX.
 
 

3.4 Processos
Um processo no Mach consiste, basicamente, de um espaço de endereçamento e uma coleção de threads que executam nesse espaço. A idéia de processos como uma entidade ativa não existe no Mach. A execução (ou atividade) é exclusiva das threads. Dessa forma, processos são usados apenas para alocação de recursos relacionados a um conjunto de threads.

            Além do conjunto de threads e do espaço de endereçamento, aos processos também são associadas algumas portas de comunicação. Algumas portas são especiais e todos os processos as possuem:

à Porta do processo: serve para fazer a comunicação do kernel com o processo.

à Porta de bootstrap: Realiza a inicialização do processo quando ele é carregado.

à Porta de exceção: servem para reportar exceções causadas pelo processo como execução ilegal de instruções u divisões por zero.

à Portas registradas: são portas associadas a processos padrões do sistema como o servidor de nomes.
 
 

3.5 Threads
 
 

Como mencionado anteriormente, uma thread pertence a um único processo, entretanto, um processo pode conter várias threads. Dessa forma, um processo é uma entidade passiva até que contenha, ao menos, uma thread.

Todas as threads de um processo compartilham o espaço de endereçamento e os recursos alocados ao processo. Mas elas podem também ter recursos privados. Um desses recursos é uma porta de comunicação chamada "thread port", que é análoga à porta de processo, pois serve como ponto de acesso da thread às funções do sistema.

            Quem gerencia as threads é o kernel do Mach, portanto estruturas especiais de controle devem estar contidas dentro do mesmo. A criação e a destruição das threads são feitas pelo kernel.

            Em um sistema com uma única CPU (Unidade Central de Processamento), a execução das threads é realizada compartilhando-se o tempo do processador. Entretanto, em sistemas multiprocessados, várias threads podem estar executando ao mesmo tempo. Assim, o sistema deve prover mecanismos de sincronização e exclusão mútua necessários em sistemas com essas características.
 
 

3.6 Escalonamento
 

O sistema de escalonamento do Mach foi bastante influenciado pela sua característica de rodar em sistemas multiprocessados. Assim, pode-se assumir um sistema uniprocessado como um caso especial desse último, onde o número de CPU é igual a 1.

As CPU em um multiprocessador podem ser associadas a um "conjunto de processadores" por software. Assim, cada CPU pertence a um único conjunto. Da mesma forma, threads também podem ser associadas a grupos de processadores por software.

Assim, cada conjunto de processadores possui um conjunto de CPUs e outro de threads necessitando processamento. Logo, o trabalho do escalonador é atribuir threads a CPUs de uma maneira eficiente. Essa estrutura também dá grande poder aos processos, que podem atribuir threads às CPUs de forma a distribuir o trabalho entre todos os processadores.

O escalonamento de threads no Mach é baseado em prioridades que são valores inteiros e variam de 0 a 31 ou 127, com 0 sendo a mais alta prioridade. Existem três prioridades associadas a cada thread:

              à Prioridade básica: que é a prioridade que a thread pode ajustar por si só dentro de certos limites;

            à Prioridade baixa: que é a menor prioridade que a thread pode assumir;

à Prioridade corrente: é usada (e ajustada pelo escalonador) em função do tempo de execução da thread e é usada para definir o escalonamento da thread. Ela é calculada pelo kernel através da soma da prioridade básica com uma função baseada na utilização recente do processador pela thread.

As threads são visíveis ao kernel. Toda linha disputa os ciclos do processador com todas as demais, sem se preocupar com qual processo cada linha pertence.

3.7 Compartilhamento de Memória
            O compartilhamento de recursos entre threads de um mesmo processo no sistema Mach é automático e não precisa ser programado: elas vêem o mesmo espaço de endereçamento. Dessa forma, se uma thread quer acessar o espaço de endereçamento de outra, basta fazê-lo, pois é o mesmo que o seu. Existe também a possibilidade de dois ou mais processos compartilharem os mesmos objetos de memória, ou simplesmente compartilharem as mesmas páginas de dados.  Como exemplo, no caso de sistemas com um único processador, o problema clássico do produtor/consumidor pressupõe dois tipos diferentes de processos compartilhando um objeto de memória - um buffer comum - de forma que o produtor possa colocar dados nele e o consumidor possa retirar dados deste mesmo buffer.

            Outra forma de compartilhamento entre processos de uma mesma área de memória é na criação dos processos filhos. No Mach o processo filho pode ser um clone de um outro processo diferente do pai. Uma forma de criar o processo filho é através da cópia de todas as páginas necessárias, mapeando-as no seu espaço de endereçamento.

3.8 Memória Compartilhada Distribuída

            O sistema de gerenciamento de memória do Mach permite que se implemente um esquema de memória compartilhada distribuída sem que o kernel precise ser alterado. A idéia é ter um espaço de endereçamento global e linear que é compartilhado por várias máquinas diferentes que não possuam qualquer tipo de compartilhamento de memória física. Quando uma thread faz um acesso a uma página que não está carregada, é gerado um page fault. Quem trata esse page fault é o gerenciador de memória, que deve prover a página ao kernel. Entretanto, não há restrições quanto à maneira como essa tarefa é realizada, por isso é natural que se crie um tipo novo de gerenciador de memória para atender a estes tipos de aplicações que fazem uso de páginas compartilhadas.

3.9 Comunicação no Mach
            O objetivo do sistema de comunicação do Mach é suportar uma variedade bastante grande de estilos de comunicação de uma maneira precisa e confiável. O Mach suporta mensagens assíncronas, e outras formas de comunicação. O sistema de comunicação entre processos é ainda baseado no RIG e Accent. Apesar disso, ele foi otimizado para o caso local e não o remoto, ou seja, para comunicação entre duas máquinas diferentes é preciso que em cada máquina rode um Network Message Server - NMS (Servidor de Mensagens de Rede).

            A base do sistema de comunicação do Mach é uma estrutura de dados do kernel chamada porta. Quando uma thread T1 de um processo quer se comunicar com uma outra T2 de outro processo, T1 envia uma mensagem para a porta de T2 e, para receber a mensagem, T2 retira a mensagem da sua porta. Esse mecanismo suporta apenas portas unidirecionais.

O sistema de portas é seguro e confiável, pois, se uma thread envia uma mensagem por uma porta, o kernel garante que essa chegará ao seu destino. Entretanto, o sistema não garante nada em relação ao seqüenciamento dessas mensagens.

            Quando uma thread cria uma porta, ela recebe um inteiro que identifica aquela porta. Esse número é usado em acessos subsequentes àquela porta e é atribuído ao processo (pelo kernel) e não à thread.

Portas podem ser agrupadas em conjuntos de portas (até mesmo a mais de um grupo). Isso facilita o trabalho de enviar uma mensagem a várias portas ou para ler das mesmas.
 
 
 
 

4 O Sistema Operacional Distribuído Amoeba

4.1 História e características

            O amoeba é originário de Amsterdã na Holanda. O projeto teve início em 1981, como um projeto de pesquisa na área de computação paralela e distribuída. Foi criado por Andrew S. Tanenbaum. Em 1983, ficou pronto o primeiro protótipo do sistema, o Amoeba 1.0.

A partir de 1984, surgiram novos grupos de pesquisa do Amoeba, surgindo, então, o Amoeba 3.0, que se baseava em chamadas remotas a procedimentos. Isto possibilitou que clientes localizados em outras cidades pudessem acessar os servidores em Amsterdã, de maneira absolutamente transparente.

A maioria dos sistemas operacionais começaram baseados em um sistema operacional já existente. O amoeba, entretanto, começou do nada, desenvolvendo um sistema operacional a partir do zero. A idéia básica era experimentar novos conceitos, sem compromisso com qualquer sistema já existente.

O principal objetivo do projeto foi a construção de um sistema operacional distribuído, totalmente transparente. Todas as ações no amoeba utilizam diversas máquinas espalhadas ao longo da rede, incluindo servidores de processos, servidores de arquivo, servidores de diretórios, etc. Mas é claro, para o usuário, nada disso deve ser motivo de preocupação.

O amoeba não suporta o conceito de máquina hospedeira. Quando um usuário se loga no Amoeba, ele não é visto pelo sistema como uma máquina específica, pois as máquinas Amoeba não tem dono. O shell inicia, ativado quando do login, roda em alguma máquina arbitrária, mas os comandos submetidos ao shell, em geral, não rodam na mesma máquina que ele. Quando há submissão de um comando, o sistema procura automaticamente a máquina com menor carga de trabalho corrente e lhe entrega a execução do novo comando. Os processos que rodam sob determinado usuário, serão distribuídos de maneira mais ou menos uniforme por todas as máquinas do sistema, dependendo naturalmente da carga de cada uma delas.

Todos os recursos pertencem ao sistema como um todo, são gerenciados por ele. Os recursos estarão a disposição de processos individuais, salvo por certos intervalos de tempo. Tentando implementar a transparência.

O objetivo secundário do Amoeba é fornecer um ambiente de teste para experiências em programação paralela e em programação distribuída. Enquanto muitos usuários utilizam o Amoeba da mesma forma que fariam com um sistema tradicional de compartilhamento de tempo, outros estão especialmente interessados em experiências com algoritmos distribuídos e algoritmos paralelos, usando linguagens, ferramentas e aplicações voltadas para tais fins. O amoeba aceita esses dois tipos de usuários, tornando o paralelismo disponível a quem queira fazer uso dele.

4.2 Características de arquitetura do sistema
 
 

Todo o poder computacional está localizado em um ou mais grupos de processadores, cada processador com uma memória local e sua conexão à rede. Não há necessidade de memória compartilhada, mas, se existir poderá ser usada para otimizar a troca de mensagens.

Os processadores de um grupo podem pertencer a diferentes arquiteturas. O Amoeba foi projetado para lidar com múltiplas arquiteturas e com sistemas heterogêneos.

Quando, por exemplo, o usuário digita um comando, o sistema operacional aloca dinamicamente um ou mais processadores para tal comando. Os processadores do grupo não pertencem a nenhum usuário especifico. Se houver escassez de processadores no sistema, os processadores do grupo poderão ser alocados em regime de tempo compartilhado.

O segundo elemento da arquitetura do Amoeba é o terminal, pois é através dele que o usuário acessa o sistema. Tipicamente, um terminal Amoeba é um terminal X, com uma tela mapeada por bits e um mouse. Alternativamente, poderão ser usados como terminais, computadores pessoais ou estações de trabalho.

A arquitetura do Amoeba utilizando grupo de processadores se torna mais barata do que se fosse utilizado estações de trabalho.

Os processadores de um grupo não precisam estar em um mesmo local.

Outro componente da arquitetura do Amoeba é constituído por servidores especializados, como o servidor de arquivos, que por diversas razões precisam rodar em um processador separado. O servidor de arquivos pode rodar no mesmo grupo de processadores, mas por questões de desempenho, melhor seria ter um processador exclusivo.

Os servidores fornecem serviços. Um serviço é uma definição abstrata daquilo que um servidor está preparado para fazer por seus clientes. Essa definição mostra o que um cliente pode pedir e quais os resultados a serem obtidos, porém não especifica quais servidores estão trabalhando na execução do serviço. Nesse aspecto, o Amoeba tem um mecanismo para suportar serviços sujeitos a falhas, alocando servidores para a realização do mesmo trabalho.
 

4.3 Microkernel

            O software do Amoeba é constituído por dois módulos básicos: um microkernel, que roda em todos os processadores do sistema, e uma coleção de softwares para servidores. O microkernel tem quatro funções principais:

àGerenciar processos e linhas de controle.

à Fornecer suporte para gerência de memória.

à Suportar as comunicações entre processos.

à Manipular a entrada/saída.

O Amoeba suporta várias linhas de controle dentro de um único espaço de endereçamento, cada uma das linhas tem seus próprios registradores, seu contador de programa e sua própria pilha. Um conjunto de linhas de controle em um processo é similar a um conjunto de processos independentes em UNIX. A única diferença está no fato de todas as linhas de controle compartilharem um único espaço de endereçamento.

Assim como o sistema Mach, o Amoeba usa um conceito parecido de processos e threads.

A segunda função do Kernel é realizar a gerência de memória. As linhas de controle precisam alocar e desalocar blocos de memória, denominados segmentos. Um processo precisa ter no mínimo um segmento, podendo chegar a possuir vários.

A terceira atribuição do kernel é manipular a comunicação entre processos. Existem duas formas de se implementar a comunicação: ponto a ponto e em grupo.

A quarta função do kernel é gerenciar a entrada/saída. Para cada dispositivo de entrada/saída ligado à máquina, existe um driver no kernel, não podendo ser carregados dinamicamente, como ocorre no GNU/Linux por exemplo.

4.4 Os Servidores do Amoeba

            Tudo o que é realizado pelo Kernel é feito por processos servidores. A idéia básica dessa metodologia de projeto consiste em diminuir o tamanho do kernel e aumentar sua flexibilidade. O fato de não se colocar o sistema de arquivos e outros serviços dentro do kernel permite que eles possam ser facilmente modificados e que múltiplas versões possam rodar simultaneamente, atendendo a diversas comunidades de usuários.

O Amoeba é baseado no modelo cliente-servidor. Os objetos, por exemplo, os arquivos são gerenciados pelos servidores. Quando um processo cria um objeto, o servidor que gerencia tal objeto devolve ao cliente uma capacidade desse objeto, protegida criptograficamente. O uso posterior do objeto depende da apresentação da capacidade. Todos os objetos do sistema , seja de hardware, seja de software, são identificados, protegidos e gerenciados por capacidades. Entre os objetos suportados dessa forma estão os arquivos, os diretórios, os segmentos de memória, as janelas de tela, os processadores, os discos e os drivers de fitas.

O servidor mais importante é o servidor de arquivos, conhecimento como servidor bala, outro servidor importante é o servidor de diretórios cuja função é gerenciar os nomes dos diretórios e os nomes de caminho, mapeando-os em capacidades.
 

4.5 Processos

            Um processo em Amoeba nada mais é do que um objeto. Quando um processo é criado, o processo-pai recebe uma capacidade para o referente ao filho, da mesma maneira que com qualquer outro tipo de objeto criado. Com essa capacidade, o processo-filho pode ser suspenso, reiniciado ou destruído.

A maneira mais simples de criar um processo é com auxílio do servidor de processamento, que faz a maior parte do trabalho de determinar onde rodar o novo processo.
 
 

4.6 Linhas de controle (threads)

Um processo na inicialização possui no mínimo uma linha de controle, e provavelmente mais de uma. Durante sua execução, o processo pode criar linhas adicionais, como linhas já existentes podem findar, por isso, o número de linhas de controle ativas é inteiramente dinâmico.

O objetivo de se ter várias threads dentro de um processo é obter o aumento do desempenho através do paralelismo. A possibilidade de existirem várias threads dentro de cada processo se enquadra perfeitamente dentro das necessidades do modelo de computação distribuída e paralela. Por exemplo, um servidor de arquivos pode ter múltiplas threads. Inicialmente, cada thread espera pela chegada de uma requisição. Quando o pedido é recebido, ele é aceito por uma das threads, que então começa a processá-lo. Se, em seguida, a thread bloqueia-se esperando por alguma operação de entrada/saída, outras threads podem continuar executando. Todas as threads, embora tenham um controle de certa forma independente, podem acessar uma área de memória comum, e usar semáforos para prover a sincronização entre elas. Este projeto torna mais fácil programar servidores e aplicações paralelas.
 
 

4.7 Escalonamento

O escalonamento no sistema Amoeba é feito por um dos servidores do sistema, designado servidor de processamento. O servidor de processamento tem a função de decidir em que tipo de arquitetura o processo deve rodar, e qual dos processadores deve ser escolhido.

Ele verifica de acordo com a arquitetura, já que podem existir diferentes arquiteturas de processadores o tipo de processador que será usado, e verifica também qual processador deverá executar o processo, levando em conta carga do sistema, e a disponibilidade de memória.

O servidor de processamento gerencia grupos de processadores. Através do diretório pooldir. Este diretório contém subdiretórios para cada uma das arquiteturas de processadores que são suportadas pelo sistema. Assim cada subdiretório possui capacidades para acessar servidores de processo em cada uma das máquinas do grupo.
 
 

4.8 Comunicação no Amoeba

Sistemas operacionais distribuídos são estruturados, tipicamente, em torno do paradigma cliente/servidor. Neste modelo, um processo, denominado cliente, pede a outro processo, denominado servidor, que faça um trabalho para ele. O cliente então fica bloqueado até que o servidor lhe envie uma resposta. O mecanismo de comunicação normalmente utilizado para implementar o modelo cliente/servidor é o mecanismo de Chamada Remota a Procedimento (Remote Procedure Call - RPC).

            Embora a RPC seja uma boa abstração para o tipo de comunicação pedido/resposta, existe um grande número de aplicações que requer que um grupo de processos interaja de maneira fechada. A comunicação em grupo permite que uma mensagem seja enviada confiavelmente de 1 remetente para n receptores. Esta estratégia pode ser útil, por exemplo, para aplicações que replicam dados a fim de obter tolerância a falhas. Tal aplicação necessitará de comunicação em grupo para manter consistente os dados que estão replicados.
 
 

4.9 Protocolo Local de Internet Rápido

O Amoeba usa o protocolo FLIP (Fast Local Internet Protocol) para transmitir as mensagens. Trata tanto da chamada remota a procedimento quanto da comunicação grupal.

Características:

à O protocolo deve suportar tanto a chamada remota a procedimento quanto a comunicação grupal.

à Suporte a migração de processos, ou seja, um processo deve ser capaz de se deslocar de uma máquina para outra, mesmo que uma máquina esteja ligada numa rede diferente.

à Segurança. Os processos não devem ser capazes de importunar outros processos.. Deve existir, também, uma segurança no nível de pacotes, de forma que ele possa ser usado com sistemas operacionais que não tenham o esquema de criptografia do Amoeba.

à Gerência de rede, ou seja, o protocolo deve adaptar-se automaticamente à nova configuração.

à O protocolo também deve funcionar com redes de longa distância.

            Toda comunicação de baixo nível no Amoeba é baseada em endereços FLIP. Cada processo tem exatamente um endereço FLIP. Se o processo migrar, leva consigo seu endereço FLIP. Mesmo que a rede seja reconfigurada, de maneira que todas as máquinas recebam novos endereços, os endereços FLIP permanecem inalterados. Portanto conclui-se que o endereço FLIP identifica um processo e não uma máquina, o que torna a comunicação Amoeba transparente em relação a mudanças, tanto na topologia quanto no endereçamento da rede.
 
 
 
 
 

5 Conclusão
 
 
 
 
 
 

            O trabalho nos mostrou que esta nova tecnologia é muito promissora tendo em vista a relação custo/benefício de um Sistema Distribuído em relação a um Mainframe, porém ainda existem alguns grandes problemas nela como a baixa confiabilidade e a insegurança na troca das mensagens entre as máquinas (threads de um processo), este que seria ponto crucial em um SO distribuído.

            Ainda existe o problema da falta de software distribuído no mercado, mas pode ser que os estudos tragam muitos avanços nesta área e num futuro não muito distante possamos usufruir das qualidades de um grande, potente e o principal, confiável Sistema Operacional Distribuído que venha gradativamente a substituir com vantagens os mainframes.
 
 
 
 
 

6 Referências Bibliográficas
 
 
 

FRAGA, Josiel Adriano. Sistemas Operacionais Distribuídos.
    Taquaritinga: Fatec, 1997. 66 p. (Monografia).
 
 

FALCÃO, Manoel. Sistemas Operacionais Distribuídos.

    São Luís: UFMA, 1999. 82 p. (Monografia).
 
 

TANENBAUM, Andrew. Sistemas Operacionais Modernos.

     Universidade de Vrije - Amsterdam, Holanda. Trad. Nery Machado Filho.

     Rio de Janeiro: Editora Prentice Hall do Brasil LTDA, 1995.
 
 

< Voltar    E-mail