Logros Sistemas Operativos

LOGROS PRINCIPALES

Los sistemas operativos están entre los elementos de software más complejos que se han de-sarrollado. Esto refleja el reto de tratar de conjugar las dificultades y, en algunos casos, objetivos opuestos de comodidad, eficiencia y capacidad de evolución. Denning y sus colegas [DENN80a] proponen que, hasta la fecha, se han obtenido cuatro logros intelectuales significativos en el desarrollo de los sistemas operativos:

• Los procesos

• La gestión de memoria

• La seguridad y la protección de la información

• La planificación y la gestión de recursos

• La estructura del sistema

Cada logro viene caracterizado por unos principios o abstracciones que se han desarrollado para solucionar las dificultades de los problemas prácticos. En conjunto, estos cinco campos abarcan los puntos clave del diseño e implementación de los sistemas operativos modernos. La breve revisión que se hará de estos cinco campos en esta sección sirve como introducción a gran parte del texto restante.

Procesos

El concepto de proceso es fundamental en la estructura de los sistemas operativos. Este término fue acuñado por primera vez por los diseñadores de Multics en los años 60. Es un término algo más general que el de trabajo. Se han dado muchas definiciones para el término proceso, entre las que se incluyen las siguientes:

• Un programa en ejecución

• El "espíritu animado" de un programa

• La entidad que puede ser asignada al procesador y ejecutada por él.

El concepto de proceso debe quedar más claro a medida que se avance.

Tres líneas principales en el desarrollo de los sistemas informáticos crearon problemas de tiempos y de sincronización que contribuyeron al desarrollo del concepto de proceso: la operación por lotes con multiprogramación, el tiempo compartido y los sistemas de transac-ciones en tiempo real. Como se ha visto, la multiprogramación fue diseñada para mantener ocupados a la vez tanto procesador como los dispositivos de E/S, incluyendo los dispositivos de almacenamiento, de modo que se alcance la mayor eficiencia posible. La clave de este mecanismo es que, como respuesta a las señales que indiquen que ha terminado una transacción de E/S, el procesador cambia entre los diversos programas que residen en la memoria principal.

Una segunda línea de desarrollo fue la de los sistemas de tiempo compartido de propósito general. La justificación de tales sistemas es que los usuarios del computador son más pro-ductivos si pueden interactuar directamente con el computador desde algún tipo de terminal. En este caso, el objetivo clave del diseño es que el sistema sea sensible a las necesidades del usuario individual y que, además, por razones de coste, pueda dar soporte simultáneo a muchos usuarios. Estos objetivos son compatibles debido al tiempo de reacción relativamente lento que tienen los usuarios. Por ejemplo, si un usuario típico necesita, en promedio, 2 segundos de tiempo de procesamiento por minuto, entonces cerca de 30 usuarios deberían ser capaces de compartir el mismo sistema sin interferencias notables. Por supuesto, debe tenerse en cuenta la sobrecarga que impone el propio sistema operativo.

Otra línea importante de desarrollo la han constituido los sistemas de proceso de transacciones en tiempo real. En este caso, un cierto número de usuarios hacen consultas o actualizaciones sobre una base de datos. Un ejemplo clásico es un sistema de reservas de unas líneas aéreas. La diferencia clave entre un sistema de proceso de transacciones y un sistema de tiempo compartido es que el primero está limitado a una o pocas aplicaciones, mientras que los usuarios de un sistema de tiempo compartido pueden dedicarse al desarrollo de un programa, a la ejecución de trabajos y al uso de diferentes aplicaciones. En ambos casos, el tiempo de respuesta del sistema es primordial.

La herramienta principal disponible para los programadores de sistemas en el desarrollo de los primeros sistemas interactivos multiusuario y de multiprogramación fue la interrupción. La actividad de cualquier trabajo podía suspenderse por el acontecimiento de un suceso determinado, como la culminación de una E/S. El procesador debía entonces salvar algún tipo de contexto (por ejemplo, el contador de programa y otros registros) y desviarse hacia una rutina de tratamiento de la interrupción, que determinaba la naturaleza de la interrupción, la procesaba y luego reanudaba el proceso del usuario en el trabajo interrumpido o en algún otro trabajo.

El diseño del software del sistema para coordinar estas diversas actividades resultó extraordinariamente difícil. Con muchos trabajos en progreso al mismo tiempo, donde cada uno involucraba numerosos pasos que dar de una manera secuencial, resultaba imposible de analizar todas las combinaciones posibles de secuencias de sucesos. En ausencia de un medio sistemático de coordinación y cooperación entre las actividades, los programadores recurrían a métodos ad hoc basados en su comprensión del entorno que el sistema operativo tenía que controlar. Estos esfuerzos estaban expuestos a errores sutiles de programación cuyos efectos podría ser que sólo se manifestasen si se producían ciertas secuencias de acciones relativamente raras. Estos errores eran muy difíciles de diagnosticar, porque era necesario poder distinguirlos de los errores del software de aplicación y de los del hardware. Aún cuando se detectase el error, resultaba muy difícil determinar las causas, porque las condiciones precisas bajo las que aparecían los errores resultaban muy difíciles de reproducir. En líneas generales, había cuatro causas principales de error [DENN80a]:

• Sincronización incorrecta: Es frecuente el caso en el que una rutina debe ser suspendida a la espera de un suceso en cualquier lugar del sistema. Por ejemplo, un programa inicia una lectura de E/S y debe esperar hasta que los datos estén disponibles en un buffer antes de continuar. En tales casos se requiere alguna señal proveniente de alguna otra rutina. Un diseño incorrecto del mecanismo de señalización puede dar como resultado la pérdida de señales o la recepción de señales duplicadas.

• Fallos de exclusión mutua: Es habitual el caso en que más de un usuario o programa in-tentan a la vez hacer uso de un recurso compartido. Por ejemplo, en un sistema de reservas de líneas aéreas, dos usuarios pueden intentar leer de la base de datos y, si hay un asiento disponible, actualizar la base de datos para hacer una reserva. Si no se controlan estos accesos, puede producirse un error. Debe existir algún tipo de mecanismo de exclusión mutua que permita que sólo una rutina a la vez pueda realizar una transacción

...