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 minicomputadora RC-4000 en 1969. [1] Para mayor claridad, este artículo utiliza principalmente el término Monitor.
El sistema de multiprogramación RC 4000 se destaca históricamente por ser el primer intento de dividir un sistema operativo en un grupo de programas interactivos que se comunican a través de un núcleo que pasa mensajes . RC 4000 no fue ampliamente utilizado, pero fue muy influyente, generando el 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 trabajó 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. Sintió que una mejor solución era construir un núcleo subyacente, al que llamó 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 llamado canalizaciones o canalizaciones . Sin embargo, una gran cantidad de código fundamental está integrado en el kernel, en particular aspectos 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 interactivos, reduciendo el kernel (núcleo) a un sistema de comunicaciones y soporte únicamente.
Monitor utilizó un sistema de memoria compartida similar a una tubería como base de su comunicación entre procesos (IPC). Los datos que se iban a enviar de un proceso a otro se copiaban en un buffer de datos de memoria vacío y, cuando el programa receptor estaba listo, se volvían a sacar. Luego, el búfer se devolvió 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 send messagey, opcionalmente, pueden bloquearlos usando wait answer. Los servidores utilizaron 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 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 pedido, mientras que los procesos externos eran efectivamente controladores de dispositivos. Los procesos externos los manejaba el núcleo fuera del espacio del usuario, aunque podían iniciarse y detenerse como cualquier otro programa. Los procesos internos se iniciaban en el contexto del padre que los iniciaba, de modo 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 la década de 1960, la multitarea informática era una característica de valor discutible). Un usuario podría iniciar una sesión en un entorno multitarea preventivo , mientras que otro podría iniciar una sesión en modo de usuario único para ejecutar el procesamiento por lotes a mayor velocidad. La programación en tiempo real podría respaldarse enviando mensajes a un proceso 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 admitir 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 el mapeo (en lugar de copiar) datos de un proceso a otro. Mach también utilizó ampliamente los subprocesos, 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 que el enfoque del microkernel fuera prácticamente útil. Esto sólo cambió cuando el micronúcleo L4 de Jochen Liedtke demostró que los gastos generales de IPC se redujeron en un orden de magnitud.