Usuário:Dbastro/Sistema operativo distribuido

Um sistema operativo distribuído é a união lógica de um grupo de sistemas operativos sobre uma colecção de nós computacionais independentes, ligados em rede, comunicando-se e fisicamente separados. A cada nó contém de forma individual um subconjunto específico dos programas que compõem o sistema operativo distribuído. A cada subconjunto é uma combinação de dois provedores de serviços diferentes. O primeiro é um núcleo ubicuo mínimo ou micro núcleo, que controla o hardware do nó. O segundo é uma colecção de componente de administração do sistema de alto nível que coordenam as actividades individuais e colaborativas do nó. Estes componentes são uma abstracção das funções do micro núcleo e dão suporte aos aplicativos de usuário. O micro núcleo e as componentes de administração trabalham em conjunto. Ambos dão suporte ao objectivo do sistema o qual é integrar múltiplos recursos e capacidade de processamento num sistema eficiente e estável. [4] Esta integração sem fisuras de nós individuais num sistema global é conhecido como transparência, ou sistema de imagem única; fazendo referências à ilusão que se lhe brinda aos utentes de que o sistema global luze como uma entidade computacional única.

Um sistema operativo distribuído provê as funcionalidades essenciais requeridas por um sistema distribuído, agregando atributos e configurações para dar suporte aos requerimentos adicionais, tais como aumento de escala e disponibilidade.

Desde o ponto de vista do utente o SO funciona de forma similar a um Sistema operativo monolítico de um sozinho nó. Ou seja que, ainda que está composto por múltiplos nós, para os utentes e aplicativos luze como um sozinho nó.

Separando as funcionalidades mínimas a nível de sistema dos serviços modulares adicionais a nível de utente provê “uma separação de mecanismos e políticas”. Mecanismos e políticas podem ser interpretados da seguinte maneira “como algo se faz” contra “por que algo se faz” respectivamente. Esta separação incrementa a escalabilidad e a flexibilidade.

O núcleo

Na cada unidade (tipicamente um nó), o núcleo provê um conjunto mínimo mas completo de utilidades necessárias para operar com os recurso e hardware subjacentes do nó. Estes mecanismos incluem a atribuição, manejo e disposição dos recursos de um nó, os processos, a comunicação e as funções de administração a entrada/saída.[5] Dentro do núcleo o subsistema de comunicação é de soma importância para o sistema distribuído.[3]

Num sistema distribuído o núcleo comunmente suporta um conjunto mínimo de funções que incluem administração de direcções de baixo nível, administração de fios e comunicação entre processos. Um núcleo com este desenho conhece-se como micro-núcleo. [6][7] Sua natureza modular melhora a segurança e a confiabilidade, características fundamentais para um sistema distribuído. [8] É comum que todos os nós num sistema tenham réplicas de um mesmo núcleo e por tanto que todos os nós usem hardware similar. [9] A combinação de desenho minimalista e cobertura ubicua dos nós melhora a extensibilidade do sistema global bem como sua habilidade de agregar novos nós ou serviços de maneira dinâmica. [10]

Componentes de administração do sistema

As componentes de administração do sistema são processos de software que definem as políticas do nó. Estas componentes são a parte do SO fosse do núcleo. Provêem comunicação de alto nível, administração de processos e recursos, fiabilidade, rendimento e segurança. Estas componentes têm as mesmas funcionalidades de um sistema formado por uma sozinha entidade, adicionando a transparência requerida num sistema operativo distribuído.

A natureza distribuída do sistema distribuído requer serviços adicionais para suportar as responsabilidades do nó no sistema global. Ademais as componentes de administração do sistema aceitam as responsabilidades “defensivas” de fiabilidade, disponibilidade e persistência. Estas responsabilidades podem entrar em conflito uma com outra. A separação de políticas e mecanismos podem mitigar ditos conflitos.

Trabalhando juntos como um sistema operativo

A arquitectura e desenho de um sistema operativo distribuído devem compreender tanto as metas do nó individual, como as do sistema. O desenho e a arquitectura devem ser concebidos de forma que se mantenham separados as políticas e os mecanismos. Deste modo, um sistema operativo distribuído tenta proporcionar um marco de computação distribuída eficiente e fiável que permita aos utentes ter em conta o menos possível os esforços necessários subjacentes para logarlo. [8] A colaboração multi-nível entre o núcleo e as componentes do sistema de gestão, e a sua vez entre os diferentes nós num sistema operativo distribuído é o desafio funcional do mesmo. Este é o ponto no sistema que deve manter uma perfeita harmonia de propósito, e ao mesmo tempo manter uma desconexão completa da intenção da implementação. Este desafio é a oportunidade do sistema operativo distribuído para produzir a base e o marco para um sistema fiável, eficiente, disponível, robusto, extensible e escalable. No entanto, esta possibilidade tem um custo muito alto em complexidade.

O preço da complexidade

Num sistema operativo distribuído, o excepcional grau de complexidade inerente facilmente poderia fazer de todo o sistema uma maldição para qualquer utente. Como tal, o preço lógico de realização de um sistema de operação distribuída se deve calcular em termos de superar grandes quantidades de complexidade em muitas áreas, e em muitos níveis. Este cálculo inclui a profundidade, a amplitude e o alcance do investimento em desenho arquitectónico e o planejamento necessário para conseguir inclusive o aplicativo mais modesto. [11] Estas considerações de desenho e desenvolvimento são fundamentais e implacáveis. Por exemplo, um entendimento profundo do desenho e detalhes da arquitectura de um sistema operativo distribuído é fundamental desde o início. [1] Uma quantidade esgotadora de considerações de desenho são inerentes ao desenvolvimento de um sistema operativo distribuído. A cada uma destas considerações de desenho pode afectar potencialmente a muitas das outras num grau significativo. Isto conduz a um esforço em massa em conseguir um enfoque equilibrado, em termos das considerações de desenho individuais, e muitos de seus permutaciones. Como apoio para esta tarefa, a maioria se baseiam na experiência documentada e a investigação em computação distribuída.

História

Os esforços de investigação e experimentação começaram na década de 1970 e continuou até 1990, com um bico no interesse mostrado no tema no final de 1980. Um número de sistemas operativos distribuídos foram introduzidos durante este período, no entanto, muito poucas destas implementações conseguiu um sucesso comercial nem sequer modesto. Implementações fundamentais e pioneiras dos conceitos primitivos das componentes de sistemas operativos distribuídos datam de princípios de 1950. [12][13][14] Alguns destes passos individuais não se centraram directamente na computação distribuída, e nesse momento, muitos não notaram a importância de seu impacto. Estes esforços pioneiros estabeleceram bases importantes, e inspiraram a investigação em temas relacionados com a computação distribuída. [15] [16] [17] [18] [19] [20] Na década de 1970, produziram-se importantes avanços na computação distribuída. Estas descobertas proporcionaram uma base sólida e estável para os esforços que continuaram durante a década de 1990. A proliferação acelerada de sistemas multi-processador e de processadores multi-núcleos deu passo ao resurgir do conceito de sistema operativo distribuído.

O DYSEAC

Um dos primeiros esforços foi o DYSEAC, um computador sincrônico de propósito geral. Numa das primeiras publicações da Association for Computing Machinery, em abril de 1954, um pesquisador do Escritório Nacional de Normalização - agora o Instituto Nacional de Regulares e Tecnologia (NIST) - apresentou uma especificação detalhada da DYSEAC. A introdução centrou-se nos requisitos dos aplicativos previstos, incluídas as comunicações flexíveis, mas também mencionava outras equipas:

Finalmente, os dispositivos externos poderia inclusive incluir outros computadores a grande escala que empregam a mesma linguagem digital como a DYSEAC. Por exemplo, os computadores SEAC ou outras similares a ela poder-se-iam ligar à DYSEAC e mediante o uso de programas coordenados poderiam trabalhar juntas em cooperação mútua numa tarefa comum... Em consequência [,] a equipa pode-se utilizar para coordenar as diversas actividades de todos os dispositivos externos numa operação de conjunto eficaz. -ALAN L. LEINER, as especificações do sistema para o DYSEAC

A especificação discutiu a arquitectura de sistemas multi-computadores, preferindo peer-to-peer em lugar de amo-escravo.

A cada membro deste grupo interconectado de computadores separados é livre em qualquer momento para iniciar e despachar os pedidos especiais de controle para qualquer de seus colegas no sistema. Como consequência, o controle sobre a tarefa comum inicialmente pode ser livremente distribuído em todo o sistema e, depois temporariamente concentrada num computador, ou inclusive passar rapidamente de uma máquina à outra quando surja a necessidade... Há que assinalar que relações que se descreveram se baseiam na cooperação mútua entre o computador os dispositivos externos ao mesmo, e não refletem meramente um simples esquema mestre-escravo. -ALAN L. LEINER, as especificações do sistema para o DYSEAC

Este é um dos primeiros exemplos de uma equipa com controle distribuído. Reporte-los do Departamento do Exército [21]certificaram sua fiabilidade e que passou todas as provas de aceitação em abril de 1954. Isto era um "computador portátil", localizado num tractor com mola, com 2 veículos acompanhantes e 6 toneladas de capacidade de refrigeração.

Lincoln TX-2000

Descrito como um sistema experimental primeiramente saída, o Lincoln TX-2 fez finca-pé em dispositivos simultâneos de operações primeiramente saída flexíveis, isto é, multiprogramación. O desenho da TX-2 era modular, suportando um alto grau de modificação e expansão. [13] O sistema empregou a técnica de programa de sequência múltipla. Esta técnica permitiu múltiplos contadores de programa para a cada associado com uma de 32 possíveis sequências de código de programa. Estas sequências explicitamente priorizadas poderiam ser intercaladas e executas ao mesmo tempo, afectando não só o cálculo em processo, sina também o fluxo de controle das sequências e a conmutación de dispositivos. Ao igual que a DYSEAC os dispositivos TX-2 programados por separados podem funcionar simultaneamente, aumentando o rendimento. Todo o poder da unidade central estava disponível para qualquer dispositivo. O TX-2 é outro exemplo de um sistema de controle distribuído no qual sua unidade central não tem controle dedicado.

Celas intercomunicadas

Um primeiro esforço em conseguir uma abstracção ao acesso de cor foram as células intercomunicadas, onde uma célula estava composta de um conjunto de elementos de cor. Um elemento da memória era basicamente um relé. Dentro de uma célula tinha dois tipos de elementos, símbolo e cela. A cada estrutura de cela alojava os dados numa corrente de símbolos, que consistia num nome e um conjunto de parâmetros. A informação estava vinculada através de associações de celas. [14]

As celas intercomunicadas fundamentalmente romperam com a tradição em que não tinha contadores ou qualquer outro conceito de direccionamiento de cor. A informação era acedida de duas maneiras diferentes, directa e recuperação cruzada.

A memória celular teria muitas vantagens: • Uma parte importante da lógica do sistema está distribuída dentro das associações da informação alojada nas celas. • O fluxo de associação na informação é guiado de alguma forma por armazenamento e a recuperação. • O tempo requerido para o armazenamento e recuperação é em maior medida constante e completamente não relacionada com o tamanho e o factor de recheado da memória • As células são logicamente indistinguibles, o que os faz de uso flexível e relativamente simples estender seu tamanho.

Esta configuração é ideal para sistemas distribuídos. A projecção de tempo constante para o armazenamento e a recuperação era inerentemente atómico e exclusivo. Os autores estavam a considerar os sistemas distribuídos, declarando:

Temos querido apresentar aqui as ideias básicas de um sistema de lógica distribuída com... o conceito macroscópico de desenho lógico, longe da análise, de busca, de direccionamiento e de contar, é igualmente importante. Devemos, a toda a costa, libertar dos ónus dos detalhes e os problemas locais que só beneficia a uma equipa baixa na escala evolutiva das máquinas. —Chung-Yeol (C. E.) Lê, Intercommunicating Cells, Basis for a Distributed Logic Computer

Trabalho fundacional

Abstracção de cor coerente

Algoritmos para a sincronização escalable em multiprocesadores de cor compartilhada [22]

Abstracção do sistema de arquivos

As medidas de um sistema de arquivos distribuído [23] Memória coerente nos sistemas compartilhados de cor virtual [24]

Abstracção de transacções

Transaciones Sagas [25] Memória Transacional Operações componibles memória [26] Memória transacional: o apoio arquitectónico para o bloqueio livre de estruturas de dados [27] Memória de software transacional para estruturas de dados de tamanho dinâmico [28] Memória de software transacional [29]

Abstracção de persistência

Oceanstore: uma arquitectura para o armazenamento persistente a escala global [30]

Abstracção de fiabilidade

Verificações de previdência O Problema dos generais bizantinos [33] Processadores Fail-Stop: um enfoque para o desenho de sistemas tolerantes a falhas [34] Recuperabilidad Instantâneas distribuídas: determinar estados globais dos sistemas distribuídos [35] Recuperação optimista em sistemas distribuídos [36]

Modelos de computação distribuída

A natureza da distribuição

Os elementos de hardware de um sistema operativo distribuído repartidos em várias localizações dentro de um rack, ou ao redor do mundo. As configurações distribuídas permitem que as funções sejam distribuídas e descentralizada.

Três distribuições básicas

Para ilustrar melhor este ponto, examinaremos três arquitecturas de sistema; centralizado, descentralizado e distribuído. Neste exame, consideraremos três aspectos estruturais: organização, conexão e controle. A organização descreve as características físicas de um sistema. A conexão cobre as rotas de comunicação entre os nós. O controle gere o funcionamento das duas considerações anteriores.

Organização

Um sistema centralizado tem uma estrutura de um sozinho nível, onde todos os componentes dependem de um único elemento de controle. Um sistema descentralizado é hierárquico. Um sistema distribuído é uma colecção de elementos autónomos que não têm conceito de níveis.

Conexão

Os sistemas centralizados ligam a cada componente a um nó central. Um sistema descentralizado (também conhecido como sistema de rede) incorpora vias directas e indirectas entre os elementos constitutivos e da entidade central. Finalmente, o sistema operativo distribuído não requer nenhum padrão; conexões directas e indiretas são possíveis entre dois elementos.

Controle

Os sistemas centralizados e descentralizados dirigem os fluxos de conexão para e desde a entidade central, enquanto os sistemas distribuídos comunicam-se ao longo de caminhos arbitrários. Esta é a ideia central da terceira consideração. Controle implica equilibrar a atribuição de tarefas e dados aos elementos do sistema, bem como a capacidade de resposta e a complexidade.

Os sistemas centralizados e descentralizados oferecem um maior controle, facilitando a administração mediante a limitação das opções. Os sistemas distribuídos são mais difíceis de controlar de maneira explícita, mas são mais fáceis de escalar e têm um menor número de pontos de falha.

Considerações de desenho

Transparência

A transparência faz referência à habilidade que têm os aplicativos de tratar ao sistema no que operam sem importar se este é distribuído ou não e sem importar o hardware ou a implementação. Muitas áreas de um sistema pode beneficiar da transparência, incluindo o acesso, a localização, o funcionamento, a denominação, e a migração. A consideração da transparência afecta directamente a tomada de decisões na cada aspecto do desenho de um sistema operativo distribuído. A transparência pode impor certos requisitos e / ou restrições sobre as considerações de desenho. Os sistemas opcionalmente pode violar a transparência em diversos graus para satisfazer os requisitos de aplicativos específicos. Por exemplo, um sistema operativo distribuído pode apresentar uma unidade de disco duro num computador como "C" e uma unidade de disco em outra equipa como "G:". O utente não requer nenhum conhecimento dos controladores de dispositivo ou a localização da unidade, ambos dispositivos funcionam da mesma maneira, desde a perspectiva do aplicativo. Uma interface menos transparente pode requerer o aplicativo para saber que equipa aloja a unidade.

Domínios de Transparência:

• Transparência de locación: compreende dois aspectos diferentes da transparência, a transparência de nome e a mobilidade de utente. A transparência de nome exige que nenhuma das referências físicas ou lógicas a qualquer entidade do sistema deve expor nenhuma indicação da localização da entidade, ou de sua relação local ou remota para o utente ou o aplicativo. A transparência de mobilidade dos utentes requer a referência consistente de entidades do sistema, independentemente da localização do sistema desde o que se origina a referência. [8]

• Transparência de acesso: as entidades do sistema sejam locais ou remotas devem seguir sendo indistinguibles quando se vejam através da interface de utente. O sistema operativo distribuído

mantém esta percepção através da exposição de um mecanismo de acesso único para uma entidade do sistema, independentemente de que a entidade seja local ou remota para o utente. A transparência exige que as diferenças nos métodos de acesso a uma entidade de um sistema particular já seja local ou remoto deve ser ao mesmo tempo invisível a, e indetectable pelo utente. [3]

• Transparência de migração: Permite aos recursos migrar de um elemento a outro controlado unicamente pelo sistema e sem o conhecimento do utente ou aplicativo. [9]

• Transparência de replicação: O processo de replicação ou o facto de que um recurso se duplicou em outro elemento se produz baixo o controle do sistema e sem o conhecimento ou intervenção do utente ou aplicativo. [9]

• Transparência de participação: Os utentes ou os aplicativos não são conscientes da presença de outros utentes ou aplicativos. [9]

• Transparência de falha: o sistema é o responsável pela detecção e correcção de falhas. Não se requerem conhecimentos ou acção de utente / aplicativo excepto esperar a que o sistema resolva o problema. [10] • Transparência de rendimento: O sistema é o responsável pela detecção e a solução dos problemas de rendimento. Nenhuma acção do utente é necessária. [8]

• Transparência de escala: O sistema é o único responsável por seu alcance geográfico, quantidade de nós ou capacidade da cada nó sem o conhecimento ou intervenção do utente. [8] De forma similar também existem:

• Transparência de revisão

• Transparência de controle

• Transparência de dados

• Transparência de paralelismo

Comunicação entre processos

A comunicação entre processos (IPC) é a implementação da comunicação em general, a interacção de processos e fluxo de dados entre fios e / ou (1978)processos, tanto dentro de um nó, e entre os nós de um sistema operativo distribuído. Neste sentido, IPC é o maior conceito subjacente nas considerações de desenho de baixo nível de um sistema operativo distribuído.

Gestão de processos

A gestão de processos proporciona as políticas e mecanismos para o intercâmbio eficaz e eficiente dos recursos entre os processos distribuídos. Estas políticas e mecanismos de apoio às operações que implicam a atribuição de processadores e portos a processos, bem como os mecanismos para executar, suspender, emigrar, deter ou retomar a execução de um processo. Conquanto estes recursos e as operações podem ser locais ou remotas, o sistema operativo distribuído mantém o estado de sincronização através de todos os processos no sistema.

Gestão dos recursos

Os recursos tais como a memória, os arquivos, dispositivos, etc. distribuem-se por todo um sistema. #O ónus compartilhado e o equilíbrio de ónus requerem muitas decisões orientadas a dito fim, que vão desde encontrar uma CPU inactiva, quando mover, e que se move. Muitos algoritmos existem para ajudar nestas decisões, no entanto, isto requer um segundo nível da política de tomada de decisões na eleição do algoritmo mais adequado para o palco e as condições que rodeiam o palco.

Confiabilidade

Um sistema operativo distribuído pode proporcionar os recursos e serviços necessários para atingir altos níveis de confiabilidade, ou a capacidade para prevenir e / ou recuperar dos erros. As Falhas são defeitos físicos ou lógicos que podem causar erros no sistema. Para que um sistema seja fiável, de alguma maneira deve superar os efeitos adversos das falhas.

A tolerância a falhas é a capacidade de um sistema para continuar a operação em presença de uma falha. No caso, o sistema deve detectar e recuperar a funcionalidade completa. Em qualquer caso, todas as medidas adoptadas devem fazer todo o possível para preservar a imagem de sistema único.

Disponibilidade

Disponibilidade é a fracção de tempo durante o qual o sistema pode responder a petições.

Rendimento

O rendimento num sistema operativo distribuído geralmente traduz-se no balanço entre o paralelismo e a comunicação entre processos.

Sincronização

Os processos concorrentes cooperantes têm uma necessidade inerente de sincronização, o que garante que as mudanças ocorrem de uma maneira correcta e previsível. Há três situações básicas que definem o âmbito de aplicativo desta necessidade: • um ou mais processos devem sincronizar num ponto dado para um ou mais de outros processos a seguir, • um ou mais processos devem esperar uma condição assincrônica com o fim de continuar, • um processo deve estabelecer um acesso exclusivo a um recurso compartilhado.

A sincronização incorreta pode dar lugar a múltiplas formas de falha, incluindo a perda de atomicidad, coerência, isolamento e durabilidade, bloqueio, bloqueio activo e a perda de serialización.

Investigação

Replicated model estendam to a component object model

Architectural Design of E1 Distributed Operating System [38] The Cronus distributed operating system [39] Design and development of MINIX distributed operating system [40]

Complexity/Trust exposure through accepted responsibility

Scale and performance in the Denali isolation kernel. [41]

Multi/Many-core focused systems

The multikernel: a new VOS architecture for scalable multicore systems. [42] Corey: an Operating System for Many Cores. [43]

Distributed processing over extremes in heterogeneity

Helios: heterogeneous multiprocessing with satellite kernels. [44]

Effective and stable in multiple levels of complexity

Tessellation: Space-Time Partitioning in a Manycore Client VOS. [45]

Ver também

• Network operating system (NOS)

• Single system image (SSI)

• Operating System Projects

• List of operating systems

• Comparison of operating systems

• Computer systems architecture

• Multikernel

• MINIX

• Distributed computing

• Operating system

• List of important publications in concurrent, parallel, and distributed computing

• Edsger W. Dijkstra Prize in Distributed Computing

• List of distributed computing conferences

• List of distributed computing projects

Referências

1. ^ a b Tanenbaum, Andrew S (Septermber 1993). "Distributed operating systems anno 1992. What have we learned so far?". pg. 3-10. doi:10.1088/0967-1846/1/1/001.

2. ^ Nutt, Gary J. (1992). Centralized and Distributed Operating Systems. Prentice Hall. ISBN 978-0-13-122326-4.

3. ^ a b c d e f Gościński, Andrzej (1991). Distributed Operating Systems: The Logical Design. Addison-Wesley Pub. Co.. ISBN 978-0-201-41704-3.

4. ^ Fortier, Paul J. (1986). Design of Distributed Operating Systems: Concepts and Technolog. Intertext Publications.

5. ^ Hansen, Per Brinch, ed. (2001). Classic Operating Systems: From Batch Processing to Distributed Systems. Springer. ISBN 978-0-387-95113-3.

6. ^ Using LOTOS for specifying the CHORUS distributed operating system kernel Pecheur, C. 1992. Using LOTOS for specifying the CHORUS distributed operating system kernel. Comput. Commun. 15, 2 (Mar. 1992), 93-102.

7. ^ COOL: kernel support for object-oriented environments Habert, S. and Mosseri, L. 1990. COOL: kernel support for object-oriented environments. In Proceedings of the European Conference on Object-Oriented Programming on Object-Oriented Programming Systems, Languages, and Applications (Ottawa, Canada). OOPSLA/ECOOP '90. ACM, New York, NY, 269-275.

8. ^ a b c d e Sinha, Pradeep Kumar (1997). Distributed Operating Systems: Concepts and Design. IEEE Press. ISBN 978-0-7803-1119-0.

9. ^ a b c d Galli, Doreen L. (2000). Distributed Operating Systems: Concepts and Practice. Prentice Hall. ISBN 978-0-13-079843-5.

10. ^ a b c d Chow, Randy; Theodore Johnson (1997). Distributed Operating Systems and Algorithms. Addison Wesley. ISBN 978-0-201-49838-7.

11. ^ Surajbali, B., Coulson, G., Greenwood, P., and Grace, P. 2007. Augmenting reflective middleware with an aspect orientation support layer. In Proceedings of the 6th international Workshop on Adaptive and Reflective Middleware: Held At the ACM/IFIP/USENIX international Middleware Conference (Newport Beach, CA, November 26–30, 2007). ARM '07. ACM, New York, NY, 1-6.

12. ^ Leiner, A. L. 1954. System Specifications for the DYSEAC. J. ACM 1, 2 (Apr. 1954), 57-81.

13. ^ a b Forgie, J. W. 1957. The Lincoln TX-2 input-output system. In Papers Presented At the February 26–28, 1957, Western Joint Computer Conference: Techniques For Reliability (Los Angeles, Califórnia, February 26–28, 1957). IRE-AIEE-ACM '57 (Western). ACM, New York, NY, 156-160.

14. ^ a b Lê, C. E. 1962. Intercommunicating cells, basis for a distributed logic computer. In Proceedings of the December 4–6, 1962, Fall Joint Computer Conference (Philadelphia, Pennsylvania, December 04–06, 1962). AFIPS '62 (Fall).

15. ^ Dreyfuss, P. 1958. System design of the Gama 60. In Proceedings of the May 6–8, 1958, Western Joint Computer Conference: Contrasts in Computers (Los Angeles, Califórnia, May 06–08, 1958). IRE-ACM-AIEE '58 (Western). ACM, New York, NY, 130-133.

16. ^ Leiner, A. L., Notz, W. A., Smith, J. L., and Weinberger, A. 1958. Organizing a network of computers to meet deadlines. In Papers and Discussions Presented At the December 9–13, 1957, Eastern Joint Computer Conference: Computers with Deadlines To Meet (Washington, D.C., December 09–13, 1957). IRE-ACM-AIEE '57

17. ^ Leiner, A. L., Smith, J. L., Notz, W. A., and Weinberger, A. 1958. PILOT, the NBS multicomputer system. In Papers and Discussions Presented At the December 3–5, 1958, Eastern Joint Computer Conference: Modern Computers: Objectives, Designs, Applications (Philadelphia, Pennsylvania, December 03–05, 1958). AIEE-ACM-IRE '58 (Eastern). ACM, New York, NY, 71-75.

18. ^ Bauer, W. F. 1958. Computer design from the programmer's viewpoint. In Papers and Discussions Presented At the December 3–5, 1958, Eastern Joint Computer Conference: Modern Computers: Objectives, Designs, Applications (Philadelphia, Pennsylvania, December 03–05, 1958). AIEE-ACM-IRE '58 (Eastern). ACM, New York, NY, 46-51.

19. ^ Leiner, A. L., Notz, W. A., Smith, J. L., and Weinberger, A. 1959. PILOT—A New Multiple Computer System. J. ACM 6, 3 (Jul. 1959), 313-335.

20. ^ Estrin, G. 1960. Organization of computer systems: the fixed plus variável structure computer. In Papers Presented At the May 3–5, 1960, Western Joint IRE-AIEE-ACM Computer Conference (San Francisco, Califórnia, May 03–05, 1960). IRE-AIEE-ACM '60 (Western). ACM, New York, NY, 33-40.

21. ^ Martin H. Weik, "A Third Survey of Domestic Electronic Digital Computing Systems," Ballistic Research Laboratories Report Não. 1115, pg. 234-5, Aberdeen Proving Ground, Maryland, March 1961

22. ^ Mellor-Crummey, J. M. and Scott, M. L. 1991. Algorithms for scalable synchronization on shared-memory multiprocessors. ACM Trans. Comput. Syst. 9, 1 (Fev. 1991), 21-65.

23. ^ Baker, M. G., Hartman, J. H., Kupfer, M. D., Shirriff, K. W., and Ousterhout, J. K. 1991. Measurements of a distributed file system. In Proceedings of the Thirteenth ACM Symposium on Operating Systems Principles (Pacific Grove, Califórnia, United States, October 13–16, 1991). SOSP '91. ACM, New York, NY, 198-212.

24. ^ Li, K. and Hudak, P. 1989. Memory coherence in shared virtual memory systems. ACM Trans. Comput. Syst. 7, 4 (Nov. 1989), 321-359.

25. ^ Garcia-Molina, H. and Salem, K. 1987. Sagas. In Proceedings of the 1987 ACM SIGMOD international Conference on Management of Data (San Francisco, Califórnia, United States, May 27–29, 1987). Ou. Dayal, Ed. SIGMOD '87. ACM, New York, NY, 249-259.

26. ^ Harris, T., Marlow, S., Peyton-Jones, S., and Herlihy, M. 2005. Composable memory transactions. In Proceedings of the Tenth ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming (Chicago, IL, USA, June 15–17, 2005). PPoPP '05. ACM, New York, NY, 48-60.

27. ^ Herlihy, M. and Moss, J. E. 1993. Transactional memory: architectural support for lock-free data structures. In Proceedings of the 20th Annual international Symposium on Computer Architecture (San Diego, Califórnia, United States, May 16–19, 1993). ISCA '93. ACM, New York, NY, 289-300.

28. ^ Herlihy, M., Luchangco, V., Moir, M., and Scherer, W. N. 2003. Software transactional memory for dynamic-sized data structures. In Proceedings of the Twenty-Second Annual Symposium on Principles of Distributed Computing (Boston, Massachusetts, July 13–16, 2003). PODC '03. ACM, New York, NY, 92-101.

29. ^ Shavit, N. and Touitou, D. 1995. Software transactional memory. In Proceedings of the Fourteenth Annual ACM Symposium on Principles of Distributed Computing (Ottawa, Ontario, Canada, August 20–23, 1995). PODC '95. ACM, New York, NY, 204-213.

30. ^ Kubiatowicz, J., Bindel, D., Chen, E., Czerwinski, S., Eaton, P., Geels, D., Gummadi, R., Rhea, S., Weatherspoon, H., Wells, C., and Zhao, B. 2000. OceanStore: an architecture for global-scale persistent storage. In Proceedings of the Ninth international Conference on Architectural Support For Programming Languages and Operating Systems (Cambridge, Massachusetts, United States). ASPLOS-IX. ACM, New York, NY, 190-201.

31. ^ Gifford, D. K. 1979. Weighted voting for replicated data. In Proceedings of the Seventh ACM Symposium on Operating Systems Principles (Pacific Grove, Califórnia, United States, December 10–12, 1979). SOSP '79. ACM, New York, NY, 150-162

32. ^ Dwork, C., Lynch, N., and Stockmeyer, L. 1988. Consensus in the presence of partial synchrony. J. ACM 35, 2 (Apr. 1988), 288-323.

33. ^ Lamport, L., Shostak, R., and Pease, M. 1982. The Byzantine Generals Problem. ACM Trans. Program. Lang. Syst. 4, 3 (Jul. 1982), 382-401.

34. ^ Schlichting, R. D. and Schneider, F. B. 1983. Fail-stop processors: an approach to designing fault-tolerant computing systems. ACM Trans. Comput. Syst. 1, 3 (Aug. 1983), 222-238.

35. ^ Chandy, K. M. and Lamport, L. 1985. Distributed snapshots: determining global states of distributed systems. ACM Trans. Comput. Syst. 3, 1 (Fev. 1985), 63-75.

36. ^ Strom, R. and Yemini, S. 1985. Optimistic recovery in distributed systems. ACM Trans. Comput. Syst. 3, 3

37. ^ Tanenbaum, Andrew S. (1995). Distributed Operating Systems. Prentice Hall. ISBN 978-0-13-219908-7.

38. ^ L.B. Ryzhyk, A.E. Burtsev. Architectural design of E1 distributed operating system. System Research and Information Technologies international scientific and technical journal, October 2004, Kiev, Ukraine.

39. ^ Vinter, S. T. and Schantz, R. E. 1986. The Cronus distributed operating system. In Proceedings of the 2nd Workshop on Making Distributed Systems Work (Amsterdã, Netherlands, September 08–10, 1986). EW 2. ACM, New York, NY, 1-3.

40. ^ Ramesh, K. S. 1988. Design and development of MINIX distributed operating system. In Proceedings of the 1988 ACM Sixteenth Annual Conference on Computer Science (Atlanta, Georgia, United States). CSC '88. ACM, New York, NY, 685.

41. ^ Whitaker, A., Shaw, M., and Gribble, S. D. 2002. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation 42. ^ Baumann, A., Barham, P., Dagand, P., Harris, T., Isaacs, R., Peter, S., Roscoe, T., Schüpbach, A., and Singhania, A. 2009. In Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles (Big Sky, Montana, USA, October 11–14, 2009). SOSP '09.

43. ^ S. Boyd-Wickizer, H. Chen, R. Chen, E. Mao, F. Kashoek, R. Morris, A. Pesterev, L. Stein, M. Wu, E. Dai, E. Zhang, and Z. Zhang. Proceedings of the 2008 Symposium on Operating Systems Design and Implementation (OSDI), December 2008.

44. ^ Nightingale, E. B., Hodson, Ou., McIlroy, R., Hawblitzel, C., and Hunt, G. 2009. In Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles (Big Sky, Montana, USA, October 11–14, 2009). SOSP '09.

45. ^ Rose Liu, Kevin Klues, and Sarah Bird, University of Califórnia at Berkeley; Steven Hofmeyr, Lawrence Berkeley National Laboratory; Krste Asanović and John Kubiatowicz, University of Califórnia at Berkeley. HotPar09.

Ligações externas

• Distributed computing at the Open Directory Project

• Distributed computing journals at the Open Directory Project

• MIT Parallel and Distributed Operating System Laboratory

• UCB parallel computing laboratory

• Parallel Data laboratory

• E1 Distributed Operating System

• Amoeba DOIS Source

• Amoeba home page

• USENIX: Advanced Computing association

• How Stuff Works - Operating Systems