El sistema multiprogramación RC 4000 (también denominado Monitor o RC 4000 según la referencia) es un sistema operativo discontinuado desarrollado para la minicomputadora RC-4000 en 1969. [1] Para mayor claridad, este artículo utiliza principalmente el término Monitor.
El sistema multiprogramación RC 4000 es históricamente conocido por ser el primer intento de dividir un sistema operativo en un grupo de programas que interactúan y se comunican a través de un núcleo de paso de mensajes . El RC 4000 no se utilizó ampliamente, pero fue muy influyente y dio origen al concepto de micronúcleo que dominó la investigación de sistemas operativos durante las décadas de 1970 y 1980.
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 era adecuado para la nueva máquina y estaba cansado de tener que adaptar los sistemas existentes. Pensó que una mejor solución era construir un núcleo subyacente, al que se refirió como el núcleo , que podría usarse para construir un sistema operativo a partir de programas que interactúan. Unix , por ejemplo, utiliza pequeños programas que interactúan para muchas tareas, transfiriendo datos a través de un sistema llamado tuberías o conductos . Sin embargo, una gran cantidad de código fundamental está integrado en el núcleo, en particular cosas como sistemas de archivos y control de programas. Monitor también reubicaría dicho código, convirtiendo casi todo el sistema en un conjunto de programas que interactúan, reduciendo el núcleo (núcleo) a un sistema de comunicaciones y soporte únicamente.
Monitor utilizó un sistema de memoria compartida en forma de tubería como base de su comunicación entre procesos (IPC). Los datos que se enviarían de un proceso a otro se copiaban en un búfer de datos de memoria vacío y, cuando el programa receptor estaba listo, volvía a salir. Luego, el búfer se devolvía al grupo. Los programas tenían una interfaz de programación de aplicaciones ( API ) muy simple para pasar datos, utilizando un conjunto asincrónico de cuatro métodos. Las aplicaciones cliente envían datos con send messagey pueden bloquear opcionalmente utilizando wait answer. Los servidores utilizan un conjunto de llamadas reflejadas 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 un procedimiento remoto que al sistema completamente basado en entrada/salida (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 petición, mientras que los procesos externos eran efectivamente controladores de dispositivos. Los procesos externos eran manejados fuera del espacio de usuario por el núcleo, aunque podían iniciarse y detenerse como cualquier otro programa. Los procesos internos se iniciaban en el contexto del padre que los lanzaba, por lo que cada usuario podía construir efectivamente su propio sistema operativo iniciando y deteniendo programas en su propio contexto.
La programación se dejaba enteramente en manos de los programas, si es que era necesaria (en los años 60, la multitarea de las computadoras era una característica de valor discutible). Un usuario podía iniciar una sesión en un entorno de multitarea preventiva , mientras que otro podía iniciarla en un modo de usuario único para ejecutar el procesamiento por lotes a mayor velocidad. La programación en tiempo real podía respaldarse enviando mensajes a un proceso temporizador que solo regresaría en el momento apropiado.
Estas dos áreas han sido testigo de la mayor parte del desarrollo desde el lanzamiento de Monitor, impulsando nuevos diseños para utilizar hardware para soportar mensajes y soportar subprocesos dentro de las aplicaciones para reducir los tiempos de lanzamiento. Por ejemplo, Mach requería una unidad de administración de memoria para mejorar la mensajería mediante el uso del protocolo de copia en escritura y mapeo (en lugar de copiar) datos de un proceso a otro. Mach también utilizó subprocesos de manera extensiva, 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 era demasiado lento para hacer que el enfoque del microkernel fuera prácticamente útil. Esto solo cambió cuando el microkernel L4 de Jochen Liedtke demostró que los costos generales de IPC se redujeron en un orden de magnitud.