Sistema multiprogramador RC 4000

El sistema de multiprogramación RC 4000 (también denominado Monitor o RC  4000 , según la referencia) es un sistema operativo descontinuado desarrollado para la computadora RC-4000 de tercera generación en 1969. ^{[ 1 ]} Para mayor claridad, este artículo utiliza principalmente el término Monitor.

El sistema de multiprogramación RC 4000 fue el primer intento de dividir un sistema operativo en un grupo de programas que interactuaban entre sí y se comunicaban mediante un núcleo de paso de mensajes . Si bien el RC 4000 no tuvo una amplia difusión, fue muy influyente, dando 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 principalmente por un programador, Per Brinch Hansen , quien trabajaba en Regnecentralen , donde se diseñaba el RC  4000. Leif Svalgaard participó en la implementación y las pruebas 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. Consideró que una mejor solución era construir un núcleo subyacente, al que denominó núcleo , que pudiera utilizarse para construir un sistema operativo a partir de programas que interactuaban entre sí. Unix , por ejemplo, utiliza pequeños programas que interactúan entre sí para muchas tareas, transfiriendo datos a través de un sistema llamado tuberías o canales . Sin embargo, una gran cantidad de código fundamental está integrado en el núcleo, como los sistemas de archivos y el control de programas. Monitor también reubicaría dicho código, convirtiendo casi todo el sistema en un conjunto de programas que interactúan entre sí, reduciendo el núcleo a un simple sistema de comunicación y soporte.

Monitor utilizaba un sistema de memoria compartida tipo tubería como base de su comunicación entre procesos (IPC). Los datos que se enviaban de un proceso a otro se copiaban en un búfer de datos de memoria vacío y, cuando el programa receptor estaba listo, se volvían a enviar. El búfer se devolvía entonces al pool. Los programas tenían una interfaz de programación de aplicaciones ( API ) muy simple para pasar datos, utilizando un conjunto asíncrono de cuatro métodos. Las aplicaciones cliente enviaban datos con send messagey podían bloquear opcionalmente usando wait answer. Los servidores utilizaban un conjunto de llamadas espejo wait messagey send answer. Cabe destacar que los mensajes tenían una "ruta de retorno" implícita para cada mensaje enviado, lo que hacía que la semántica se pareciera más a una llamada a procedimiento remoto que al sistema completamente basado en entrada/salida (E/S) de Mach .

Monitor dividía el espacio de la aplicación en dos: los procesos internos ejecutaban programas tradicionales, iniciados bajo demanda, mientras que los procesos externos funcionaban como controladores de dispositivos. El núcleo gestionaba los procesos externos fuera del espacio de usuario, aunque podían iniciarse y detenerse como cualquier otro programa. Los procesos internos se iniciaban en el contexto del proceso padre que los ejecutaba, de modo que cada usuario podía, en la práctica, configurar su propio sistema operativo iniciando y deteniendo programas en su propio contexto.

La planificación quedaba totalmente a cargo de los programas, si es que era necesaria (en la década de 1960, la multitarea informática era una característica de valor cuestionable). Un usuario podía iniciar una sesión en un entorno multitarea con prioridad , mientras que otro podía iniciarla en modo de usuario único para ejecutar el procesamiento por lotes a mayor velocidad. La planificación en tiempo real podía implementarse enviando mensajes a un proceso temporizador que solo respondía en el momento adecuado.

Estas dos áreas han experimentado la mayor parte del desarrollo desde el lanzamiento de Monitor, impulsando nuevos diseños que utilizan hardware para la mensajería y el soporte de subprocesos dentro de las aplicaciones para reducir los tiempos de inicio. Por ejemplo, Mach requería una unidad de gestión de memoria para mejorar la mensajería mediante el protocolo de copia en escritura y el mapeo (en lugar de la copia) de datos de un proceso a otro. Mach también utilizaba ampliamente los subprocesos, lo que permitía a los programas externos, o servidores en términos más modernos, iniciar fácilmente nuevos manejadores para las solicitudes entrantes. Aun así, la comunicación entre procesos (IPC) de Mach era demasiado lenta para que el enfoque de microkernel resultara práctico. Esto solo cambió cuando el microkernel L4 de Jochen Liedtke demostró una reducción de la sobrecarga de IPC en un orden de magnitud.

• El sistema de multiprogramación
• Cronología de los sistemas operativos

• Hansen, Per Brinch (1970). "El núcleo de un sistema operativo multiprogramación" (PDF) . Communications of the ACM . 13 (4). Association for Computing Machinery : 238–250 . CiteSeerX 10.1.1.105.4204 . doi : 10.1145/362258.362278 . S2CID 9414037 .  
• Software RC 4000: Sistema de multiprogramación
• Manual de referencia del RC 4000 en bitsavers.org