Sistema operativo distribuido
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. Estas 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 las 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 referencia a la ilusión que se le brinda a los usuarios de que el sistema global luce como una entidad computacional única.
Descripción
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.
El núcleo
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]
Componentes de administración del sistema
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]
Trabajando juntos como un sistema operativo
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 las 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.
El precio de la 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.
Historia
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.
El DYSEAC
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. Esto era un "ordenador portátil", ubicado en un tractor con remolque, con 2 vehículos acompañantes y 6 toneladas de capacidad de refrigeración.
Lincoln TX-2
Celdas intercomunicadas
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
Trabajo fundacional
Abstracción de memoria coherente
Algoritmos para la sincronización escalable en multiprocesadores de memoria compartida [22]
Abstracción del sistema de archivos
Las mediciones de un sistema de archivos distribuido [23] Memoria coherente en los sistemas compartidos de memoria virtual [24]
Abstracción de transacciones
Abstracción de persistencia
Oceanstore: una arquitectura para el almacenamiento persistente a escala global [30]
Abstracción del coordinador
Votación ponderada para los datos replicados [31] Consenso en presencia de sincronía parcial [32]
Abstracción de confiabilidad
Comprobaciones de sanidad El Problema de los generales bizantinos [33] Procesadores Fail-Stop: un enfoque para el diseño de sistemas tolerantes a fallos [34] Recuperabilidad Instantáneas distribuidas: determinar estados globales de los sistemas distribuidos [35] Recuperación optimista en sistemas distribuidos [36]
Modelos de computación distribuida
La naturaleza de la distribución
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.
Tres distribuciones básicas
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.
Organización
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.
Conexión
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.
Control
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.
Consideraciones de diseño
Transparencia
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] •
Comunicación entre procesos
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.
Gestión de procesos
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.
Gestión de los recursos
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.
Fiabilidad
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
Disponibilidad es la fracción de tiempo durante el cual el sistema puede responder a peticiones.
Rendimiento
El rendimiento en un sistema operativo distribuido generalmente se traduce en el balance entre el paralelismo y la comunicación entre procesos.
Sincronización
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.
Investigación
Replicated model extended 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 OS 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 OS. [45]
Referencias
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.
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.
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 (Amsterdam, 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.
HotPar09.
Enlaces externos
• Distributed computing [1] at the Open Directory Project
• Distributed computing journals at the Open Directory Project [2]
• MIT Parallel and Distributed Operating System Laboratory [3]
• UCB parallel computing laboratory [4]
• Parallel Data laboratory [5]
• E1 Distributed Operating System [6]
• Amoeba DOS Source [7]
• Amoeba home page [8]
• USENIX: Advanced Computing association [9]
• How Stuff Works - Operating Systems [10]
• Algorithms for scalable synchronization [11]
Referencias
[1] http://www.dmoz.org/Computers/Computer_Science/Distributed_Computing/
[2] http://www.dmoz.org/Computers/Computer_Science/Distributed_Computing/Publications/ [3] http://pdos.csail.mit.edu/
[4] http://parlab.eecs.berkeley.edu/ [5] http://www.pdl.cmu.edu/index.shtml [6] http://www.e1os.org/eng/index.html [7] http://fsd-amoeba.sourceforge.net/ [8] http://www.cs.vu.nl/pub/amoeba/ [9] http://www.usenix.org/
[10] http://computer.howstuffworks.com/operating-system.htm
Fuentes y contribuyentes del artículo
Sistema operativo distribuido Fuente: http://es.wikipedia.org/w/index.php?oldid=65533837 Contribuyentes: 5truenos, Fle3tw00d, NaBUru38, Osnel.rabelo88
