Sistema de multiprogramación RC 4000
 | Este artículo incluye una lista de referencias , lecturas relacionadas o enlaces externos , pero sus fuentes siguen sin estar claras porque carece de citas en línea . ( Enero de 2019 ) |
| Desarrollador | Regnecentralen |
|---|---|
| Estado de trabajo | Interrumpido |
| Versión inicial | 1969 |
| Plataformas | RC 4000 |
| Tipo de grano | Microkernel |
El sistema de multiprogramación RC 4000 es un sistema operativo descontinuado desarrollado para la minicomputadora RC 4000 en 1969.
Visión general
El sistema de multiprogramación RC 4000 es históricamente notable por ser el primer intento de dividir un sistema operativo en un grupo de programas interactivos que se comunican a través de un kernel de transmisión de mensajes . Aunque RC 4000 en sí no tuvo mucho éxito, sin embargo fue extremadamente influyente, lo que provocó el concepto de microkernel que dominó la investigación de sistemas operativos durante las décadas de 1970 y 1980. El sistema también se conoce como Monitor y, de manera algo confusa, simplemente RC 4000 dependiendo de la referencia. Para mayor claridad, este artículo utilizará el término Monitor.
Monitor fue creado en gran parte por un programador, Per Brinch Hansen , que trabajaba en Regnecentralen, donde se estaba diseñando el RC 4000. Leif Svalgaard participó en la implementación y prueba de Monitor. Brinch Hansen descubrió que ningún sistema operativo existente se adaptaba a la nueva máquina y estaba cansado de tener que adaptar los sistemas existentes. Sintió que una mejor solución era construir un kernel subyacente, al que se refirió como el núcleo , que podría usarse para construir un sistema operativo a partir de programas interactivos. Unix , por ejemplo, utiliza pequeños programas interactivos para muchas tareas, transfiriendo datos a través de un sistema conocido como canalizaciones.. Sin embargo, una gran cantidad de código fundamental está enterrada en el propio kernel, en particular cosas como sistemas de archivos y control de programas. Monitor también eliminaría este código, convirtiendo casi todo el sistema en un conjunto de programas interactivos, reduciendo el kernel (núcleo) a un sistema de comunicaciones y soporte únicamente.
Monitor utilizó un sistema similar a una tubería de memoria compartida como base de sus comunicaciones entre procesos . Los datos que se enviarían de un proceso a otro se copiaron en un búfer de memoria vacío y, cuando el programa receptor estaba listo, se volvieron a sacar. Luego, el tampón se devolvió al grupo. Los programas tenían una API muy simple para pasar datos, usando un conjunto asincrónico de cuatro métodos. Las aplicaciones cliente envían datos con send messagey, opcionalmente, pueden bloquear el uso wait answer. Los servidores utilizaron un conjunto de llamadas duplicadas wait messagey send answer. Tenga en cuenta que los mensajes tenían una "ruta de retorno" implícita para cada mensaje enviado, lo que hace que la semántica se parezca más a una llamada a procedimiento remoto que al sistema completamente basado en E / S de Mach .
Monitor dividió el espacio de la aplicación en dos; Los procesos internos eran la ejecución de programas tradicionales, iniciados a pedido, mientras que los procesos externos eran efectivamente controladores de dispositivos. Los procesos externos en realidad se manejaban fuera del espacio del usuario por el núcleo, aunque podían iniciarse y detenerse como cualquier otro programa. Los procesos internos se iniciaron en el contexto del "padre" que los lanzó, de modo que cada usuario pudiera construir efectivamente su propio sistema operativo iniciando y deteniendo programas en su propio contexto.
La programación se dejaba enteramente a los programas, si era necesario (en la década de 1960, la multitarea era una característica discutible). Un usuario podría iniciar una sesión en un entorno multitarea preventivo , mientras que otro podría iniciar en un modo de usuario único para ejecutar el procesamiento por lotes a mayor velocidad. La programación en tiempo real podría ser compatible enviando mensajes a un proceso de temporizador que solo regresaría en el momento apropiado.
Estas dos áreas han visto la gran mayoría del desarrollo desde el lanzamiento de Monitor, impulsando diseños más nuevos para usar hardware para admitir mensajes y admitiendo subprocesos dentro de las aplicaciones para reducir los tiempos de lanzamiento. Por ejemplo, Mach necesitaba una unidad de gestión de memoria para mejorar la mensajería mediante el uso del protocolo de copia en escritura y mapeo (en lugar de copiar) los datos de un proceso a otro. Mach también usó subprocesos ampliamente, lo que permitió que los programas externos, o servidores en términos más modernos, iniciaran fácilmente nuevos controladores para las solicitudes entrantes. Aún así, Mach IPC fue demasiado lento para hacer que el enfoque del microkernel fuera prácticamente útil. Esto solo cambió cuando el microkernel Liedtke L4 demostró una mejora de orden de magnitud en los gastos generales de IPC.
Ver también
Referencias
- Brinch Hansen, Per (1970). "El núcleo de un sistema operativo de multiprogramación" (PDF) . Comunicaciones de la ACM . 13 (4): 238–250. CiteSeerX 10.1.1.105.4204 . doi : 10.1145 / 362258.362278 .
- Software RC 4000: Sistema de multiprogramación
- Manual de referencia de RC 4000 en bitsavers.org
- Sistemas operativos basados en microkernel
- Microkernels
- Software de 1969
