Un sistema operativo distribuido es la unión lógica de un grupo de sistemas operativos sobre una colección de nodos computacionales independientes, conectados en red, comunicándose y físicamente separados. [1] Cada nodo contiene de forma individual un subconjunto específico de los programas que componen el sistema operativo distribuido. Cada subconjunto es una combinación de dos proveedores de servicios distintos. [2] El primero es un núcleo ubicuo mínimo o micro núcleo, que controla el hardware del nodo. El segundo es una colección de componente de administración del sistema de alto nivel que coordinan las actividades individuales y colaborativas del nodo. Estos componentes son una abstracción de las funciones del micro núcleo y dan soporte a las aplicaciones de usuario. [3]
El micro núcleo y los componentes de administración trabajan en conjunto. Ambos dan soporte al objetivo del sistema el cual es integrar múltiples recursos y capacidad de procesamiento en un sistema eficiente y estable. [4] Esta integración sin fisuras de nodos individuales en un sistema global es conocido como transparencia, o sistema de imagen única; haciendo referencias a la ilusión que se le brinda a los usuarios de que el sistema global luce como una entidad computacional única.
Un sistema operativo distribuido provee las funcionalidades esenciales requeridas por un sistema distribuido, agregando atributos y configuraciones para dar soporte a los requerimientos adicionales, tales como aumento de escala y disponibilidad. Desde el punto de vista del usuario el SO funciona de forma similar a un Sistema Operativo monolítico de un solo nodo. O sea que, aunque está compuesto por múltiples nodos, para los usuarios y aplicaciones luce como un solo nodo.
Separando las funcionalidades mínimas a nivel de sistema de los servicios modulares adicionales a nivel de usuario provee “una separación de mecanismos y políticas”. Mecanismos y políticas pueden ser interpretados de la siguiente manera “cómo algo se hace” contra “por qué algo se hace” respectivamente. Esta separación incrementa la escalabilidad y la flexibilidad.
En cada unidad (típicamente un nodo), el núcleo provee un conjunto mínimo pero completo de utilidades necesarias para operar con los recurso y hardware subyacentes del nodo. Estos mecanismos incluyen la asignación, manejo y disposición de los recursos de un nodo, los procesos, la comunicación y las funciones de administración la entrada/salida.[5] Dentro del núcleo el subsistema de comunicación es de suma importancia para el sistema distribuido.[3]
En un sistema distribuido el núcleo comúnmente soporta un conjunto mínimo de funciones que incluyen administración de direcciones de bajo nivel, administración de hilos y comunicación entre procesos. Un núcleo con este diseño se conoce como micro-núcleo. [6][7] Su naturaleza modular mejora la seguridad y la fiabilidad, características fundamentales para un sistema distribuido. [8] Es común que todos los nodos en un sistema tengan réplicas de un mismo núcleo y por tanto que todos los nodos usen hardware similar. [9] La combinación de diseño minimalista y cobertura ubicua de los nodos mejora la extensibilidad del sistema global así como su habilidad de agregar nuevos nodos o servicios de manera dinámica. [10]
Las componentes de administración del sistema son procesos de software que definen las políticas del nodo. Estas componentes son la parte del SO fuera del núcleo. Proveen comunicación de alto nivel, administración de procesos y recursos, confiabilidad, rendimiento y seguridad. Estas componentes tienen las mismas funcionalidades de un sistema formado por una sola entidad, adicionando la transparencia requerida en un sistema operativo distribuido. [3]
La naturaleza distribuida del sistema distribuido requiere servicios adicionales para soportar las responsabilidades del nodo en el sistema global. Además las componentes de administración del sistema aceptan las responsabilidades “defensivas” de confiabilidad, disponibilidad y persistencia. Estas responsabilidades pueden entrar en conflicto una con otra. La separación de políticas y mecanismos pueden mitigar dichos conflictos. [10]
La arquitectura y diseño de un sistema operativo distribuido deben comprender tanto las metas del nodo individual, como las del sistema. El diseño y la arquitectura deben ser concebidos de forma que se mantengan separados las políticas y los mecanismos. De este modo, un sistema operativo distribuido intenta proporcionar un marco de computación distribuida eficiente y fiable que permita a los usuarios tener en cuenta lo menos posible los esfuerzos necesarios subyacentes para logarlo. [8] La colaboración multi-nivel entre el núcleo y los componentes del sistema de gestión, y a su vez entre los distintos nodos en un sistema operativo distribuido es el desafío funcional del mismo. Este es el punto en el sistema que debe mantener una perfecta armonía de propósito, y al mismo tiempo mantener una desconexión completa de la intención de la implementación. Este desafío es la oportunidad del sistema operativo distribuido para producir la base y el marco para un sistema fiable, eficiente, disponible, robusto, extensible y escalable. Sin embargo, esta posibilidad tiene un coste muy alto en complejidad.
En un sistema operativo distribuido, el excepcional grado de complejidad inherente fácilmente podría hacer de todo el sistema una maldición para cualquier usuario. Como tal, el precio lógico de realización de un sistema de operación distribuida se debe calcular en términos de superar grandes cantidades de complejidad en muchas áreas, y en muchos niveles. Este cálculo incluye la profundidad, la amplitud y el alcance de la inversión en diseño arquitectónico y la planificación necesaria para lograr incluso la aplicación más modesta. [11] Estas consideraciones de diseño y desarrollo son fundamentales e implacables. Por ejemplo, una comprensión profunda del diseño y detalles de la arquitectura de un sistema operativo distribuido es fundamental desde el inicio. [1] Una cantidad agotadora de consideraciones de diseño son inherentes al desarrollo de un sistema operativo distribuido. Cada una de estas consideraciones de diseño puede afectar potencialmente a muchas de las otras en un grado significativo. Esto conduce a un esfuerzo masivo en lograr un enfoque equilibrado, en términos de las consideraciones de diseño individuales, y muchos de sus permutaciones. Como apoyo para esta tarea, la mayoría se basan en la experiencia documentada y la investigación en computación distribuida.
Los esfuerzos de investigación y experimentación comenzaron en la década de 1970 y continuó hasta 1990, con un pico en el interés mostrado en el tema a finales de 1980. Un número de sistemas operativos distribuidos fueron introducidos durante este período, sin embargo, muy pocas de estas implementaciones logró un éxito comercial ni siquiera modesto. Implementaciones fundamentales y pioneras de los conceptos primitivos de las componentes de sistemas operativos distribuidos datan de principios de 1950. [12][13][14] Algunos de estos pasos individuales no se centraron directamente en la computación distribuida, y en ese momento, muchos no notaron la importancia de su impacto. Estos esfuerzos pioneros establecieron bases importantes, e inspiraron la investigación en temas relacionados con la computación distribuida. [15] [16] [17] [18] [19] [20] En la década de 1970, se produjeron importantes avances en la computación distribuida. Estos descubrimientos proporcionaron una base sólida y estable para los esfuerzos que continuaron durante la década de 1990. La proliferación acelerada de sistemas multi-procesador y de procesadores multi-núcleos dio paso al resurgir del concepto de sistema operativo distribuido.
Uno de los primeros esfuerzos fue el DYSEAC, un ordenador sincrónico de propósito general. En una de las primeras publicaciones de la Association for Computing Machinery, en abril de 1954, un investigador de la Oficina Nacional de Normalización - ahora el Instituto Nacional de Estándares y Tecnología (NIST) - presentó una especificación detallada de la DYSEAC. La introducción se centró en los requisitos de las aplicaciones previstas, incluidas las comunicaciones flexibles, pero también mencionaba otros equipos:
Finalmente, los dispositivos externos podría incluso incluir otros ordenadores a gran escala que emplean el mismo lenguaje digital como la DYSEAC. Por ejemplo, las computadoras SEAC u otras similares a ella se podrían conectar a la DYSEAC y mediante el uso de programas coordinados podrían trabajar juntas en cooperación mutua en una tarea común... En consecuencia [,] el equipo se puede utilizar para coordinar las diversas actividades de todos los dispositivos externos en una operación de conjunto eficaz. -ALAN L. LEINER, las especificaciones del sistema para el DYSEAC
La especificación discutió la arquitectura de sistemas multi-computadoras, prefiriendo peer-to-peer en lugar de amo-esclavo.
Cada miembro de este grupo interconectado de computadoras separadas es libre en cualquier momento para iniciar y despachar los pedidos especiales de control para cualquiera de sus compañeros en el sistema. Como consecuencia, el control sobre la tarea común inicialmente puede ser libremente distribuido en todo el sistema y, después temporalmente concentrada en un ordenador, o incluso pasar rápidamente de una máquina a la otra cuando surja la necesidad... Hay que señalar que relaciones que se han descrito se basan en la cooperación mutua entre el ordenador los dispositivos externos al mismo, y no reflejan meramente un simple esquema maestro-esclavo. -ALAN L. LEINER, las especificaciones del sistema para el DYSEAC
Este es uno de los primeros ejemplos de un equipo con control distribuido. Los reportes del Departamento del Ejército [21]certificaron su confiabilidad y que pasó todas las pruebas de aceptación en abril de 1954. Ubicado en un tractor con remolque, con 2 vehículos acompañantes y 6 toneladas de capacidad de refrigeración.
Descrito como un sistema experimental de entrada salida, el Lincoln TX-2 hizo hincapié en dispositivos simultáneos de operaciones de entrada salida flexibles, es decir, multiprogramación. El diseño de la TX-2 era modular, soportando un alto grado de modificación y expansión. [13] El sistema empleó la técnica de programa de secuencia múltiple. Esta técnica permitió múltiples contadores de programa para cada asociado con una de 32 posibles secuencias de código de programa. Estas secuencias explícitamente priorizadas podrían ser intercaladas y ejecutas al mismo tiempo, afectando no sólo el cálculo en proceso, sino también el flujo de control de las secuencias y la conmutación de dispositivos. Al igual que la DYSEAC los dispositivos TX-2 programados por separados pueden funcionar simultáneamente, aumentando el rendimiento. Todo el poder de la unidad central estaba disponible para cualquier dispositivo. El TX-2 es otro ejemplo de un sistema de control distribuido en el cual su unidad central no tiene control dedicado.
Un primer esfuerzo en lograr una abstracción al acceso de memoria fueron las células intercomunicadas, donde una célula estaba compuesta de un conjunto de elementos de memoria. Un elemento de la memoria era básicamente un relé. Dentro de una célula había dos tipos de elementos, símbolo y celda. Cada estructura de celda almacenaba los datos en una cadena de símbolos, que consistía en un nombre y un conjunto de parámetros. La información estaba vinculada a través de asociaciones de celdas. [14]
Las celdas intercomunicadas fundamentalmente rompieron con la tradición en que no tenía contadores o cualquier otro concepto de direccionamiento de memoria. La información era accedida de dos maneras diferentes, directa y recuperación cruzada.
La memoria celular tendría muchas ventajas: • Una parte importante de la lógica del sistema está distribuida dentro de las asociaciones de la información almacenada en las celdas. • El flujo de asociación en la información es guiado de alguna forma por almacenamiento y la recuperación. • El tiempo requerido para el almacenamiento y recuperación es mayormente constante y completamente no relacionada con el tamaño y el factor de relleno de la memoria • Las células son lógicamente indistinguibles, lo que los hace de uso flexible y relativamente simple extender su tamaño.
Esta configuración es ideal para sistemas distribuidos. La proyección de tiempo constante para el almacenamiento y la recuperación era inherentemente atómico y exclusivo. Los autores estaban considerando los sistemas distribuidos, declarando:
Hemos querido presentar aquí las ideas básicas de un sistema de lógica distribuida con... el concepto macroscópico de diseño lógico, lejos del análisis, de búsqueda, de direccionamiento y de contar, es igualmente importante. Debemos, a toda costa, liberarnos de las cargas de los detalles y los problemas locales que sólo beneficia a un equipo bajo en la escala evolutiva de las máquinas. —Chung-Yeol (C. Y.) Lee, Intercommunicating Cells, Basis for a Distributed Logic Computer
Algoritmos para la sincronización escalable en multiprocesadores de memoria compartida [22]
Las mediciones de un sistema de archivos distribuido [23] Memoria coherente en los sistemas compartidos de memoria virtual [24]
Transacciones Sagas [25] Memoria Transaccional Operaciones componibles memoria [26] Memoria transaccional: el apoyo arquitectónico para el bloqueo libre de estructuras de datos [27] Memoria de software transaccional para estructuras de datos de tamaño dinámico [28] Memoria de software transaccional [29]
Oceanstore: una arquitectura para el almacenamiento persistente a escala global [30]
Comprobaciones de sanidad El Problema de los generales bizantinos [33] Procesadores Fail-Stop: un enfoque para el diseño de sistemas tolerantes de fallos [34] Recuperabilidad Instantáneas distribuidas: determinar estados globales de los sistemas distribuidos [35] Recuperación optimista en sistemas distribuidos [36]
Los elementos de hardware de un sistema operativo distribuido repartidos en varias ubicaciones dentro de un rack, o alrededor del mundo. Las configuraciones distribuidas permiten que las funciones sean distribuidas y descentralizada.
Para ilustrar mejor este punto, examinaremos tres arquitecturas de sistema; centralizado, descentralizado y distribuido. En este examen, consideraremos tres aspectos estructurales: organización, conexión y control. La organización describe las características físicas de un sistema. La conexión cubre las rutas de comunicación entre los nodos. El control gestiona el funcionamiento de las dos consideraciones anteriores.
Un sistema centralizado tiene una estructura de un solo nivel, donde todos los componentes dependen de un único elemento de control. Un sistema descentralizado es jerárquico. Un sistema distribuido es una colección de elementos autónomos que no tienen concepto de niveles.
Los sistemas centralizados conectan cada componente a un nodo central. Un sistema descentralizado (también conocido como sistema de red) incorpora vías directas e indirectas entre los elementos constitutivos y de la entidad central. Finalmente, el sistema operativo distribuido no requiere ningún patrón; conexiones directas e indirectas son posibles entre dos elementos.
Los sistemas centralizados y descentralizados dirigen los flujos de conexión hacia y desde la entidad central, mientras que los sistemas distribuidos se comunican a lo largo de caminos arbitrarios. Esta es la idea central de la tercera consideración. Control implica equilibrar la asignación de tareas y datos a los elementos del sistema, así como la capacidad de respuesta y la complejidad.
Los sistemas centralizados y descentralizados ofrecen un mayor control, facilitando la administración mediante la limitación de las opciones. Los sistemas distribuidos son más difíciles de controlar de manera explícita, pero son más fáciles de escalar y tienen un menor número de puntos de fallo.
La transparencia hace referencia a la habilidad que tienen las aplicaciones de tratar al sistema en el que operan sin importar si este es distribuido o no y sin importar el hardware o la implementación. Muchas áreas de un sistema puede beneficiarse de la transparencia, incluyendo el acceso, la ubicación, el funcionamiento, la denominación, y la migración. La consideración de la transparencia afecta directamente la toma de decisiones en cada aspecto del diseño de un sistema operativo distribuido. La transparencia puede imponer ciertos requisitos y / o restricciones sobre las consideraciones de diseño. Los sistemas opcionalmente puede violar la transparencia en diversos grados para satisfacer los requisitos de aplicaciones específicas. Por ejemplo, un sistema operativo distribuido puede presentar una unidad de disco duro en un ordenador como "C" y una unidad de disco en otro equipo como "G:". El usuario no requiere ningún conocimiento de los controladores de dispositivo o la ubicación de la unidad, ambos dispositivos funcionan de la misma manera, desde la perspectiva de la aplicación. Una interfaz menos transparente puede requerir la aplicación para saber qué equipo aloja la unidad.
Dominios de Transparencia:
• Transparencia de locación: comprende dos aspectos distintos de la transparencia, la transparencia de nombre y la movilidad de usuario. La transparencia de nombre exige que ninguna de las referencias físicas o lógicas a cualquier entidad del sistema debe exponer ninguna indicación de la ubicación de la entidad, o de su relación local o remota para el usuario o la aplicación. La transparencia de movilidad de los usuarios requiere la referencia consistente de entidades del sistema, independientemente de la ubicación del sistema desde el que se origina la referencia. [8]
• Transparencia de acceso: las entidades del sistema sean locales o remotas deben seguir siendo indistinguibles cuando se vean a través de la interfaz de usuario. El sistema operativo distribuido
mantiene esta percepción a través de la exposición de un mecanismo de acceso único para una entidad del sistema, independientemente de que la entidad sea local o remota para el usuario. La transparencia exige que las diferencias en los métodos de acceso a una entidad de un sistema particular ya sea local o remoto debe ser a la vez invisible a, e indetectable por el usuario. [3]
• Transparencia de migración: Permite a los recursos migrar de un elemento a otro controlado únicamente por el sistema y sin el conocimiento del usuario o aplicación. [9]
• Transparencia de replicación: El proceso de replicación o el hecho de que un recurso se ha duplicado en otro elemento se produce bajo el control del sistema y sin el conocimiento o intervención del usuario o aplicación. [9]
• Transparencia de concurrencia: Los usuarios o las aplicaciones no son conscientes de la presencia de otros usuarios o aplicaciones. [9]
• Transparencia de fallo: el sistema es el responsable de la detección y corrección de fallos. No se requieren conocimientos o acción de usuario / aplicación excepto esperar a que el sistema resuelva el problema. [10] • Transparencia de rendimiento: El sistema es el responsable por la detección y la solución de los problemas de rendimiento. Ninguna acción del usuario es necesaria. [8]
• Transparencia de escala: El sistema es el único responsable de su alcance geográfico, cantidad de nodos o capacidad de cada nodo sin el conocimiento o intervención del usuario. [8] De forma similar también existen:
• Transparencia de revisión
• Transparencia de control
• Transparencia de datos
• Transparencia de paralelismo
La comunicación entre procesos (IPC) es la implementación de la comunicación en general, la interacción de procesos y flujo de datos entre hilos y / o (1978)procesos, tanto dentro de un nodo, y entre los nodos de un sistema operativo distribuido. En este sentido, IPC es el mayor concepto subyacente en las consideraciones de diseño de bajo nivel de un sistema operativo distribuido.
La gestión de procesos proporciona las políticas y mecanismos para el intercambio eficaz y eficiente de los recursos entre los procesos distribuidos. Estas políticas y mecanismos de apoyo a las operaciones que implican la asignación de procesadores y puertos a procesos, así como los mecanismos para ejecutar, suspender, emigrar, detener o reanudar la ejecución de un proceso. Si bien estos recursos y las operaciones pueden ser locales o remotas, el sistema operativo distribuido mantiene el estado de sincronización a través de todos los procesos en el sistema.
Los recursos tales como la memoria, los archivos, dispositivos, etc. se distribuyen por todo un sistema. La carga compartida y el equilibrio de carga requieren muchas decisiones orientadas a dicho fin, que van desde encontrar una CPU inactiva, cuando mover, y que se mueve. Muchos algoritmos existen para ayudar en estas decisiones, sin embargo, esto requiere un segundo nivel de la política de toma de decisiones en la elección del algoritmo más adecuado para el escenario y las condiciones que rodean el escenario.
Un sistema operativo distribuido puede proporcionar los recursos y servicios necesarios para alcanzar altos niveles de fiabilidad, o la capacidad para prevenir y / o recuperarse de los errores. Las Fallas son defectos físicos o lógicos que pueden causar errores en el sistema. Para que un sistema sea fiable, de alguna manera debe superar los efectos adversos de los fallos.
La tolerancia a fallos es la capacidad de un sistema para continuar la operación en presencia de un fallo. En el caso, el sistema debe detectar y recuperar la funcionalidad completa. En cualquier caso, todas las medidas adoptadas deben hacer todo lo posible para preservar la imagen de sistema único.
Disponibilidad es la fracción de tiempo durante el cual el sistema puede responder a peticiones.
El rendimiento en un sistema operativo distribuido generalmente se traduce en el balance entre el paralelismo y la comunicación entre procesos.
Los procesos concurrentes cooperantes tienen una necesidad inherente de sincronización, lo que garantiza que los cambios ocurren de una manera correcta y predecible. Hay tres situaciones básicas que definen el ámbito de aplicación de esta necesidad: • uno o más procesos deben sincronizar en un punto dado para uno o más de otros procesos a seguir, • uno o más procesos deben esperar una condición asincrónica con el fin de continuar, • un proceso debe establecer un acceso exclusivo a un recurso compartido.
La sincronización incorrecta puede dar lugar a múltiples formas de falla, incluyendo la pérdida de atomicidad, coherencia, aislamiento y durabilidad, bloqueo, bloqueo activo y la pérdida de serialización.
Architectural Design of E1 Distributed Operating System [38] The Cronus distributed operating system [39] Design and development of MINIX distributed operating system [40]
Scale and performance in the Denali isolation kernel. [41]
The multikernel: a new OS architecture for scalable multicore systems. [42] Corey: an Operating System for Many Cores. [43]
Helios: heterogeneous multiprocessing with satellite kernels. [44]
Tessellation: Space-Time Partitioning in a Manycore Client OS. [45]
• Network operating system (NOS)
• Comparison of operating systems
• Computer systems architecture
• MINIX
• 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
1. ^ a b Tanenbaum, Andrew S (Septermber 1993). "Distributed operating systems anno 1992. What have we learned so far?". pp. 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, California, February 26–28, 1957). IRE-AIEE-ACM '57 (Western). ACM, New York, NY, 156-160.
14. ^ a b Lee, C. Y. 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 Gamma 60. In Proceedings of the May 6–8, 1958, Western Joint Computer Conference: Contrasts in Computers (Los Angeles, California, 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 variable structure computer. In Papers Presented At the May 3–5, 1960, Western Joint IRE-AIEE-ACM Computer Conference (San Francisco, California, 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 No. 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 (Feb. 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, California, 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, California, United States, May 27–29, 1987). U. 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, California, 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, Y., 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, California, 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 (Feb. 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.Y. 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 (Ámsterdam, 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, Y. Mao, F. Kashoek, R. Morris, A. Pesterev, L. Stein, M. Wu, Y. Dai, Y. Zhang, and Z. Zhang. Proceedings of the 2008 Symposium on Operating Systems Design and Implementation (OSDI), December 2008.
44. ^ Nightingale, E. B., Hodson, O., 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 California at Berkeley; Steven Hofmeyr, Lawrence Berkeley National Laboratory; Krste Asanović and John Kubiatowicz, University of California at Berkeley. HotPar09.
• 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
• E1 Distributed Operating System
• USENIX: Advanced Computing association
• How Stuff Works - Operating Systems
• Algorithms for scalable synchronization
Escribe un comentario o lo que quieras sobre Sistema operativo distribuido (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)