Unix llegó relativamente tarde. Déjame darte un software (o una técnica de software) que es mucho más antiguo: interrupciones.
Regresemos a 1953 y al UNIVAC-1103-1103A. De la excelente historia y descripción general de las interrupciones y los sistemas de interrupción, Mark Smotherman:
Bell y Newell citaron el UNIVAC (o ERA para Engineering Research Associates) 1103 (1953) como el primer sistema informático en usar interrupciones. … Otros dan crédito al 1103A (1956) como el primero en usar interrupciones.
- ¿Cuál es la mejor herramienta / software de gestión de ventas?
- ¿Cuál es el mejor software de ingeniería inversa versátil para datos de escaneo láser y por qué?
- ¿Existe alguna herramienta o software que pueda convertir artículos de texto en video + audio? Si incluye personajes humanos en el video, sería bueno.
- ¿Cuáles son algunas de las cosas que los técnicos pueden decir sobre la durabilidad y confiabilidad de las computadoras portátiles y sus componentes?
- ¿Cuál es el costo del software mlm?
Smotherman también ofrece una cita deliciosa de un artículo de 1958 de Turner y Rawlings sobre las desventajas de esta técnica:
El corazón de estas dificultades es una sutil diferencia entre los modos de operación interrumpido y no interrumpido. En el modo convencional, el resultado del cálculo no solo depende solo del código almacenado inicialmente y de los datos, sino que también depende de cada estado intermedio de la computadora. Con interrupción, debido al tiempo aleatorio de interrupción, esto ya no es cierto; de hecho, incluso con un programa correcto, solo se espera que las respuestas sean predecibles. Uno de los efectos sorprendentes de esta variabilidad es que un error de programación o codificación, al producir un error variable o alguna vez ninguno, puede ser indistinguible de un mal funcionamiento aleatorio de la computadora. Se pasaron muchas horas descubriendo esta pecularidad [sic]. (énfasis añadido).
La historia de Smotherman pone el manejo de excepciones incluso antes (1951), pero eso podría ser un nivel demasiado bajo.
Ahora para una prueba pop: ¿Qué semidiós informático temprano comentó así:
A este respecto, la historia de la interrupción en tiempo real es esclarecedora. Este fue un invento de la segunda mitad de los años 50, que permitió completar una comunicación con el mundo externo para interrumpir la ejecución de un programa a favor de otro. Su ventaja es que permitió la implementación de una reacción rápida ante circunstancias externas cambiadas sin pagar el precio de una gran cantidad de tiempo de procesador perdido en espera improductiva. La desventaja era que el sistema operativo tenía que garantizar la ejecución correcta de los diversos cálculos a pesar de la imprevisibilidad de los momentos en los que tendrían lugar las interrupciones y el procesador central pasaría de un cálculo a otro; El no determinismo implicado por esta imprevisibilidad ha causado dolores de cabeza sin fin para aquellos diseñadores de sistemas operativos que no sabían cómo lidiar con eso. Hemos visto dos reacciones al desafío de esta complejidad adicional.
La única reacción fue mejorar las instalaciones de depuración, como lo hizo IBM para el diseño de OS / 360. (Este fue el sistema operativo que IBM trató de diseñar para sus máquinas de la serie 360, que se introdujeron en la primera mitad de los años 60; los problemas de IBM con este diseño facilitaron en 1968 el reconocimiento del fenómeno mundial que se conoció como ” la crisis del software “.) IBM construyó, de hecho, monitores especiales que registraron exactamente cuándo el procesador central cumplió con la interrupción; Cuando algo había salido mal, el monitor podía convertirse en un controlador, forzando así una repetición del historial del sospechoso y haciendo que el “experimento” fuera repetible.
La otra reacción se pudo observar en THE (Universidad Tecnológica de Eindhoven), a saber. determinar las condiciones bajo las cuales uno podría razonar de manera factible y segura sobre tales programas no deterministas y, posteriormente, asegurarse de que el hardware y el software cumplan estas condiciones.
La diferencia fue sorprendente, mostrando una vez más que la depuración no es una alternativa para el control intelectual. Si bien OS / 360 siguió siendo un desastre para siempre, el sistema de multiprogramación diseñado en THE era tan robusto que ningún mal funcionamiento del sistema dio lugar a una llamada espuria para el mantenimiento del hardware. No hace falta decir que todo el episodio me dejó una impresión duradera.
Una moraleja es que la interrupción en tiempo real fue solo la ola, mientras que la marea fue la introducción del no determinismo y el desarrollo de técnicas matemáticas para enfrentarlo. (énfasis añadido)
La respuesta se puede encontrar en el enlace Smotherman.
¡Disfrutar!
