Professional Documents
Culture Documents
Distribuídos
Tópicos Abordados
2
Sistemas Operacionais Distribuídos UNESP/IBILCE
Os sistema operacionais podem ser classificados de acordo com seu grau de acoplamento, a
saber:
9 Redes
9 Autômatos
9 Centralizados
9 Distribuídos
9 Interoperabilidade
9 Transparência
9 Autonomia
Apenas citaremos as funcionalidades de alguns sistemas referenciados acima, uma vez que
a ênfase será dada aos Sistemas Distribuídos.
Características:
Características:
3
Sistemas Operacionais Distribuídos UNESP/IBILCE
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.
4
Sistemas Operacionais Distribuídos UNESP/IBILCE
Flexibilidade
Fatores associados:
9 Interoperabilidade
9 Modularidade
9 Portabilidade
9 Escalabilidade
Consistência
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
5
Sistemas Operacionais Distribuídos UNESP/IBILCE
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.
6
Sistemas Operacionais Distribuídos UNESP/IBILCE
Vantagens
9 agilidade
9 o gerenciamento é menos complicado
Desvantagens
9 não preempção
9 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
Desvantagens
9 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).
7
Sistemas Operacionais Distribuídos UNESP/IBILCE
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:
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..
Ramificações Estáticas:
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:
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.
9 Aumenta a flexibilidade
9 Agrupamento de threads no mesmo espaço de endereçamento
Desvantagens
2.6. Conclusão
9
Sistemas Operacionais Distribuídos UNESP/IBILCE
3. Ramificações em Multiprocessadores
Vantagens
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.
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
10
Sistemas Operacionais Distribuídos UNESP/IBILCE
Servidor
Tipos de servidores
9 Servidores de arquivos
9 Servidores de impressão
9 Servidores de Banco de Dados
9 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.
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.
Pedido
Resposta
12
Sistemas Operacionais Distribuídos UNESP/IBILCE
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:
PROC 1
PROC 3
13
Sistemas Operacionais Distribuídos UNESP/IBILCE
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).
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:
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
senão S:=S+1
Os semáforos são classificados de acordo com o valor com que são inicializados como:
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.
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.
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.
“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;
É 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:
16
Sistemas Operacionais Distribuídos UNESP/IBILCE
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.
17
Sistemas Operacionais Distribuídos UNESP/IBILCE
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.
Existem dois tipos de processos aos quais nos referiremos durante a explicação do
funcionamento da técnica de encontros na linguagem ADA:
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
Links
Cliente/Servidor: http://www.whatis.com/clientse.htm
RPC: http://www.whatis.com/rpc.htm
Thread: http://www.whatis.com/thread.htm
20