| dbo:abstract
|
- El Sistema de multiprogramación RC 4000 fue un sistema operativo desarrollado para el minicomputador RC 4000 en 1969. Es históricamente notable por ser el primer intento de descomponer/derribar/romper un sistema operativo en un grupo de programas que interactúan comunicando a través de mensajes que pasan por el núcleo (kernel). Aunque el RC 4000 no fue muy exitoso, fue muy influyente provocando el concepto de microkernel (micro núcleo) que dominaba el estudio del sistema operativo sobre los años y . Este sistema es también conocido como Monitor y en este artículo usaremos este término. El Monitor fue creado, en gran parte, por Per Brinch Hansen, que trabajó en donde el RC 4000 acabó siendo diseñado. participó en la implementación y testeo del Monitor. encontró que no existía un sistema operativo adecuado para la nueva máquina y estaba cansado de tener que adaptar sistemas existentes en ella. En su opinión, la mejor solución era construir un kernel subyacente, que se refirió como el núcleo, que podrían ser utilizados para construir un sistema operativo de los programas de interacción. Unix, por ejemplo, utiliza pequeños programas que interactúan para muchas tareas, la transferencia de datos a través de un sistema conocido como tuberías “(pipes)”. Sin embargo, una gran cantidad de código fundamental es sepultado en el núcleo en sí, en particular cosas como sistemas de archivos y control del programa. El Monitor eliminaría este código haciendo que casi todo el sistema sea un conjunto de programas que interactúan, lo que reduce el núcleo (kernel) a un único sistema de comunicación y de soporte. El Monitor utiliza un sistema de tuberías de memoria compartida como base de su propia comunicación entre procesos. Los datos que se envían desde un proceso a otro se copian en un búfer de memoria vacía, y cuando el programa de recepción estaba listo, los mandaba de vuelta otra vez. El buffer fue devuelto a la piscina. Los programas tenían una API muy sencilla para pasar datos, utilizando un conjunto de cuatro métodos . Las aplicaciones cliente envían datos con send message y podrían opcionalmente bloquearlas usando el código wait answer. Los servidores usaban una serie de llamadas, wait message y send answer. Los mensajes tenían un implícito "return path" para cada mensaje enviado, haciendo la semántica más parecida a una llamada a procedimiento remoto que a un sistema Mach de entrada/salida. El Monitor dividió el espacio de aplicación en dos; los “procesos internos” que eran programas tradicionales que se iniciaban a petición, y los “programas externos” que eran controladores de dispositivos eficaces. Los procesos externos se manejaron realmente fuera del espacio de usuario por el núcleo, aunque podían haber empezado y parado como otro programa. Los programas internos se iniciaron con el contexto del “padre” que los lanzó, así que cada usuario podía crear su propio sistema operativo al iniciar y detener los programas en su propio contexto. La programación fue dejada enteramente para los programas si así lo requerían (en los años la multitarea era una característica discutible). Un usuario podía iniciar una sesión en un entorno multitarea preferente, mientras que otro podía empezar en un modo de usuario único para ejecutar el procesamiento por lotes a mayor velocidad. La programación en tiempo real podía ser apoyada por el envío de mensajes a un proceso temporizador que sólo volvería en el momento oportuno. El monitor demostró tener un rendimiento verdaderamente terrible. Mucho de esto fue debido al coste de la comunicación entre procesos (IPC), un problema que ha afectado a la mayoría de . Los datos del Monitor se han copiado dos veces para cada mensaje, y el manejo de memoria en el RC 4000 no era particularmente rápido. Una área de preocupación que se tuvo fue la de lanzar y matar programas para manejar las peticiones que se fueron sucediendo durante todo ese tiempo. Estas dos zonas han visto la gran mayoría del desarrollo desde el lanzamiento del monitor: manejar nuevos diseños para usar el hardware para el apoyo de la mensajería y el apoyo a los subprocesos dentro de las aplicaciones para reducir los tiempos de lanzamiento. Un ejemplo de ello, Mach requiere una unidad de gestión de memoria para mejorar la mensajería mediante el uso del protocolo y de asignación (en lugar de copiar datos) de un proceso a otro. Mach también se utiliza para enhebrar extensamente, permitiendo que los programas externos o los servidores en términos más modernos inicien nuevos controladores para la recepción de peticiones. Sin embargo, la IPC de Mach era demasiado lenta como para plantear la aproximación del y que esta pudiera considerarse prácticamente útil. Esto cambió cuando el de Liedtke demostró una orden de magnitud de mejora en los gastos generales de la comunicación entre procesos (IPC). (es)
- El Sistema de multiprogramación RC 4000 fue un sistema operativo desarrollado para el minicomputador RC 4000 en 1969. Es históricamente notable por ser el primer intento de descomponer/derribar/romper un sistema operativo en un grupo de programas que interactúan comunicando a través de mensajes que pasan por el núcleo (kernel). Aunque el RC 4000 no fue muy exitoso, fue muy influyente provocando el concepto de microkernel (micro núcleo) que dominaba el estudio del sistema operativo sobre los años y . Este sistema es también conocido como Monitor y en este artículo usaremos este término. El Monitor fue creado, en gran parte, por Per Brinch Hansen, que trabajó en donde el RC 4000 acabó siendo diseñado. participó en la implementación y testeo del Monitor. encontró que no existía un sistema operativo adecuado para la nueva máquina y estaba cansado de tener que adaptar sistemas existentes en ella. En su opinión, la mejor solución era construir un kernel subyacente, que se refirió como el núcleo, que podrían ser utilizados para construir un sistema operativo de los programas de interacción. Unix, por ejemplo, utiliza pequeños programas que interactúan para muchas tareas, la transferencia de datos a través de un sistema conocido como tuberías “(pipes)”. Sin embargo, una gran cantidad de código fundamental es sepultado en el núcleo en sí, en particular cosas como sistemas de archivos y control del programa. El Monitor eliminaría este código haciendo que casi todo el sistema sea un conjunto de programas que interactúan, lo que reduce el núcleo (kernel) a un único sistema de comunicación y de soporte. El Monitor utiliza un sistema de tuberías de memoria compartida como base de su propia comunicación entre procesos. Los datos que se envían desde un proceso a otro se copian en un búfer de memoria vacía, y cuando el programa de recepción estaba listo, los mandaba de vuelta otra vez. El buffer fue devuelto a la piscina. Los programas tenían una API muy sencilla para pasar datos, utilizando un conjunto de cuatro métodos . Las aplicaciones cliente envían datos con send message y podrían opcionalmente bloquearlas usando el código wait answer. Los servidores usaban una serie de llamadas, wait message y send answer. Los mensajes tenían un implícito "return path" para cada mensaje enviado, haciendo la semántica más parecida a una llamada a procedimiento remoto que a un sistema Mach de entrada/salida. El Monitor dividió el espacio de aplicación en dos; los “procesos internos” que eran programas tradicionales que se iniciaban a petición, y los “programas externos” que eran controladores de dispositivos eficaces. Los procesos externos se manejaron realmente fuera del espacio de usuario por el núcleo, aunque podían haber empezado y parado como otro programa. Los programas internos se iniciaron con el contexto del “padre” que los lanzó, así que cada usuario podía crear su propio sistema operativo al iniciar y detener los programas en su propio contexto. La programación fue dejada enteramente para los programas si así lo requerían (en los años la multitarea era una característica discutible). Un usuario podía iniciar una sesión en un entorno multitarea preferente, mientras que otro podía empezar en un modo de usuario único para ejecutar el procesamiento por lotes a mayor velocidad. La programación en tiempo real podía ser apoyada por el envío de mensajes a un proceso temporizador que sólo volvería en el momento oportuno. El monitor demostró tener un rendimiento verdaderamente terrible. Mucho de esto fue debido al coste de la comunicación entre procesos (IPC), un problema que ha afectado a la mayoría de . Los datos del Monitor se han copiado dos veces para cada mensaje, y el manejo de memoria en el RC 4000 no era particularmente rápido. Una área de preocupación que se tuvo fue la de lanzar y matar programas para manejar las peticiones que se fueron sucediendo durante todo ese tiempo. Estas dos zonas han visto la gran mayoría del desarrollo desde el lanzamiento del monitor: manejar nuevos diseños para usar el hardware para el apoyo de la mensajería y el apoyo a los subprocesos dentro de las aplicaciones para reducir los tiempos de lanzamiento. Un ejemplo de ello, Mach requiere una unidad de gestión de memoria para mejorar la mensajería mediante el uso del protocolo y de asignación (en lugar de copiar datos) de un proceso a otro. Mach también se utiliza para enhebrar extensamente, permitiendo que los programas externos o los servidores en términos más modernos inicien nuevos controladores para la recepción de peticiones. Sin embargo, la IPC de Mach era demasiado lenta como para plantear la aproximación del y que esta pudiera considerarse prácticamente útil. Esto cambió cuando el de Liedtke demostró una orden de magnitud de mejora en los gastos generales de la comunicación entre procesos (IPC). (es)
|
