Notas de Aula - MAC 5755 - Sistemas Operacionais Distribuídos

Aula 25 - 23/11/2001

Sun Microsystems (1992 -> 1993)
Trouxe uma série de inovações que foram posteriormente incorporados nos sistemas operacionais da Sun: Solaris e Solaris-MC.
O primeiro SOD totalmente orientado a objetos

cada nó executa só duas pequenas componentes em modo protegido: VM manager e nucleus (o microkernel)
sistema de arquivos, paginação, nomes etc. são executados como serviços no nível do usuário

componentes do sistema são objetos cujas interfaces são definidas através de uma IDL (note que CORBA não existia ainda)
RMI pode ser implementada de diversas formas: mem. compartilhada, IPC, soquetes etc.
Segurança (proteção) é a propriedade mais importante.
Requisitos de segurança na chamada a objetos:

não se deve fazer uma autenticação completa do cliente a cada chamada
não se deve definir estaticamente quais clientes podem usar cada objeto
se quiser, um cliente deve poder repassar os seus direitos de acesso para outro cliente
Solução óbvia: capacidades (capabilities)

um domínio D1 pode criar uma porta de entrada para si mesmo e passá-la para outro domínio D2
um thread executando num domínio D2 passa por uma porta (door) e vai para outro domínio D1
se quiser, D2 pode repassar a porta para outro domínio D3
um domínio não consegue criar uma porta para um outro domínio que não si mesmo
associados a uma porta estão um PC no espaço de endereçamento destino e um número inteiro indicador de qual método deve ser executado no domínio destino.
em outras palavras: uma door é uma espécie de RPC implementada dentro do núcleo do SO
o nucleus conta o número de referências a portas e destroi a porta quando a conta chega a 1
Tipos de doors

rápida (fast-path): todos argumentos são tipos simples e a soma é menor do que 16 bytes
baunilha: <= 5KB de dados e algumas poucas portas: o nucleus copia os dados
a granel: > 5KB, usado quando se passa muitas portas, páginas e tabelas como parâmetro, a cópia é feita pelo sistema de memória virtual usando remapeamento da memória

fazer com que um único thread possa percorrer vários domínios e até mesmo várias máquinas
quando um thread passa por uma porta, um outro thread no outro domínio continua a sua execução e o primeiro fica bloqueado até que o outro thread volte pela porta

a segunda opção foi a escolhida por ser um pouco mais fácil de implementar e por permitir um controle mais fino do sistema (há mais threads, então podemos operar deles de forma individual)
para agrupar esses threads inter-relacionados, criou-se o conceito de shuttles, que se tornou a unidade de escalonamento do núcleo

quando um domínio servidor morre, todos os shuttles que entraram por suas portas, saem das portas com um código de erro
quando um cliente morre, o shuttle não é interrompido imediatamente: ele continua executando até o momento no qual ele retorna pela porta e daí é redirecionado para o nucleus que neste instante o destroi.
além disso, há um bit de alerta no shuttle que é setado quando um domínio no thread inicial morre. Os outros threads podem escolher olhar ou não para esse bit e abortar a sua execução se for o caso.
Caso interessante: se um domínio na metade do caminho de um shuttle morre. Cria-se um novo shuttle, um deles avisa o chamador imediatamente que a chamada falhou e o outro transmite o alerta aos chamados.

Experimento interessante em 92: implementaram o UNIX em cima do Spring rodando em espaço do usuário. Esse UNIX era capaz de executar todos os utilitários (make, ls, grep etc) e o XWindows.
O Sistema de Arquivos do Spring foi também muito inovador com sua estrutura orientada a objetos e diferentes possibilidades de configuração
Artigos interessantes (nota: eles contém muito mais informações do que você precisa)

Problema 1: manutenção de múltiplas contas por usuário em ambientes e máquinas diferentes
Solução: usuário reside na rede (Network-Centric User)
Problema 2: heterogeneidade do HW e do software
Solução: implementação como middleware
Problema 3: plataformas de middleware existentes não são flexíveis
Solução: middleware reflexivo (dynamicTAO, OpenORB, LuaORB )
Problema 4: plataformas de middleware são muito pesadas
Solução: ORBs configuráveis muito pequenos (LegORB e UIC CORBA)
Problema 5: configuração de sistemas é muito penoso e caro
Solução: configuração automática

Campbell, Univ. de Illinois em Urbana-Champaign (2000 ->)
Motivação: extender as idéias do 2K para computação ubíqua; um SO para espaços ativos.
Quais serviços adicionais são necessários?

federação de servidores de nomes para mapear os espaços físicos
federação de traders para guardar informações sobre o conteúdo dos espaços e permitir a busca de objetos, serviços, e recursos dentro dos espaços
arcabouço para representar e gerenciar dispositivos inseridos nos espaços físicos
serviço de localização para manter informação sobre objetos que se movem muito rapidamente
serviço de eventos para comunicação assíncrona entre os serviços
reconhecimento visual automatizado