Índice

• 1. Introducción

• 2. Necesidad de Sistema Operativo

• 2.1. Vista histórica

• 2.2. Definición

• 3. Tipos de gestión de procesos

• 3.1. Lotes

• 3.2. Multiprogramación

• 3.2.1. Tiempo compartido

• 3.2.2. Tiempo real

• 3.2.3. Combinados

• 3.3. Distribuidos

• 4. Arquitectura

• 4.1. Kernel monolítico

• 4.2. Microkernel

• 4.3. Máquinas virtuales

• 4.4. Cliente-servidor

• 5. Funciones

• 6. Otros aspectos

• 7. Un paseo por la historia

• Referencias

• Conclusiones

1. Introducción

Antaño, con las primeras máquinas, era algo muy complicado ser programador... y no sólo porque los lenguajes de programación no habían evolucionado, sino porque se debía manejar el ordenador desde la consola y la consola en aquellos tiempos significaba un puñado de interruptores. Afortunadamente, esto ha ido cambiando y se lo debemos, en parte, a que han nacido y evolucionado los sistemas operativos. Como también lo han hecho las máquinas, los lenguajes de programación e incluso las ideas.

2. Necesidad de Sistema Operativo

• 2.1. Vista histórica [Tanenbaum92]

En un principio solo existía el hardware del computador. Los primeros computadores eran (físicamente) grandes máquinas que se operaban desde una consola. El programador escribía un programa y luego lo controlaba directamente. En primer lugar, el programa se cargaba manualmente en la memoria, desde los interruptores del tablero frontal, desde una cinta de papel o desde tarjetas perforadas. Luego se pulsaban los botones adecuados para establecer la dirección de inicio y comenzar la ejecución del programa. Mientras este se ejecutaba, el programador-operador lo podía supervisar observando las luces en la consola. Si se descubrían errores, el programador podía detener el programa, examinar el contenido de la memoria y los registros y depurar el programa directamente desde la consola. La salida del programa se imprimía, o se perforaba en cintas de papel o tarjetas para su impresión posterior. Un aspecto importante de ese entorno era su naturaleza interactiva directa. El programador también era el operador del sistema de computación.

La mayoría de los sistemas utilizaban un esquema de reservas o de registro para asignar tiempo de máquina. Si alguien quería usar el computador, acudía a la hoja de registro, buscaba el siguiente tiempo libre de la máquina que fuera conveniente y se anotaba para usarla. Sin embargo, con este procedimiento se presentaban ciertos problemas. Si un programador se había registrado para usar una hora de tiempo del computador dedicada a ejecutar el programa que estaba desarrollando, pero se topaba con algún error difícil y no podía terminar en esa hora. Si alguien más había reservado el siguiente bloque de tiempo, el programador debía detenerse, rescatar lo que pudiera y volver mas tarde para continuar. Por otra parte, si el programa se ejecutaba sin problemas, podría terminar en 35 minutos; pero como pensó que necesitaría la máquina durante más tiempo, se registró para usarla un hora, y permanecería inactiva durante 25 minutos.

Conforme transcurrió el tiempo, se desarrollaron software y hardware adicionales; empezaron a popularizarse los lectores de tarjetas, impresoras de líneas y cintas magnéticas. Se diseñaron ensambladores, cargadores y ligadores para facilitar las tareas de programación, y se crearon bibliotecas de funciones comunes, de manera que éstas podían copiarse a un nuevo programa sin tener que escribirlas de nuevo.

Se podía necesitar un considerable tiempo de operación para realizar un trabajo. Cada trabajo consistía en varios pasos distintos: cargar la cinta del compilador de FORTRAN, ejecutar el compilador, descargar la cinta del compilador, cargar la cinta del ensamblador, ejecutar el ensamblador, descargar la cinta del ensamblador, cargar el programa objeto y ejecutarlo. Si ocurría un error en cualquiera de los pasos, probablemente habría que comenzar desde el principio. Cada paso del trabajo podía ocasionar la necesidad de cargar y descargar cintas magnéticas, cintas de papel o tarjetas perforadoras, por lo que al avanzar el tiempo aparecieron los primeros sistemas operativos.

Los computadores, sobretodo los centrales de gran tamaño, han sido siempre máquinas muy costosas. Por ello, los dueños han deseado que estas máquinas efectúen la mayor cantidad posible de cálculos. Hoy en día, esta situación también se aplica a los microprocesadores de menor coste, de los cuales, a pesar de no ser tan costosos, siempre se espera que logren el mayor número posible de cálculos. El cambio a los sistemas por lotes con secuenciación automática de trabajos se efectuó para mejorar el rendimiento. El problema es que las personas somos demasiado lentas. Por lo tanto, es deseable sustituir la intervención humana por el software del sistema operativo. Aún con esta secuenciación automática de trabajos, la UCP todavía tiene periodos de inactividad. El problema es la velocidad de los dispositivos mecánicos de E/S, los cuales son intrínsecamente más lentos que los dispositivos electrónicos. Una UCP lenta trabaja en el orden de los microsegundos, pues ejecuta millones de instrucciones por segundo. La solución que se encontró a esto fue el uso de buffers o tampones que se anticipaban al programa leyendo los datos y dejándolos en memoria antes de que se produjese la orden de leerlos, con lo que se acelera la ejecución total del programa.

• 2.2. Definición

Definamos ahora el concepto de Sistema Operativo: Es un programa que actúa como intermediario entre el usuario y el hardware de un computador y su propósito es proporcionar un entorno en el cual el usuario pueda ejecutar programas. El objetivo principal de un sistema operativo es lograr que el sistema de computación se use de manera cómoda y el objetivo secundario es que el hardware del computador se emplee de manera eficiente. Una definición más común es que el sistema operativo es el programa que se ejecuta todo el tiempo en el computador, siendo programas de aplicación todos los demás.

• Objetivo principal: los sistemas operativos existen porque se supone que es mas fácil trabajar con uno de ellos que sin él. Esta situación es particularmente clara cuando se observan los sistemas operativos para los pequeños computadores personales.

• Objetivo secundario: es la utilización eficiente del sistema de computación. Este propósito tiene una importancia especial en los grandes sistemas multiusuario compartidos. En el pasado, las consideraciones de eficiencia a menudo eran más importantes que la comodidad, por lo que gran parte de la teórica de sistemas operativos se concentra en el uso óptimo de los recursos de computación.

Los sistemas operativos y la arquitectura del computador tienen una gran influencia mutua. Los sistemas operativos se desarrollan para facilitar el uso del hardware. Al ir diseñando y utilizando los sistemas operativos, se hizo patente que podrían simplificarse con cambios en el diseño del hardware.

3. Tipos de gestión de procesos de un Sistema Operativo [Tanenbaum91]

En un principio, los computadores se utilizaban desde la consola central. El software mejoró la comodidad de programar, pero necesitaba un tiempo considerable de preparación. Para reducir este tiempo, se contrataron operadores y los trabajos semejantes se agruparon en lotes. El computador ya no tenía que esperar la intervención humana, aun así, la utilización de la UCP era muy lenta. Con el fin de mejorar el rendimiento global del sistema se introdujo el concepto de multiprogramación, gracias al cual se almacenan en la memoria varios trabajos al mismo tiempo, lo que aumenta el rendimiento de la UCP y reduce el tiempo de ejecución de los trabajos.

• 3.1. Sistemas por lotes.

Cuando se desarrollaron por primera vez, estaban caracterizados por la "agrupación en bloques" de trabajos similares. Los modernos sistemas utilizan otras características. El rasgo característico de un sistema por lotes es la ausencia de interacción entre el usuario y el trabajo mientras éste se ejecuta. El trabajo se prepara y se envía. Tiempo después aparece la salida.

• 3.2. Multiprogramación.

Un solo usuario no puede, en general, mantener todo el tiempo ocupado a la UCP o a los dispositivos de E/S. La multiprogramación aumenta la utilización de la UCP organizando los trabajos de manera que ésta siempre tenga algo que ejecutar. El S.O. escoge uno de los trabajos del depósito y comienza a ejecutarlo. En algún momento el trabajo tendrá que esperar, ya que el sistema ha pasado el control a otro programa y así sucesivamente. Mientras haya otro trabajo por ejecutar, la UCP nunca estará inactiva.

Dentro de los sistemas multiprogramados tenemos tres tipos:

• 3.2.1. Tiempo compartido.

Utiliza la planificación de la UCP y la multiprogramación para proporcionar a cada usuario, que tiene su propio programa en memoria, una pequeña porción de un computador de tiempo compartido. La E/S interactiva es demasiado lenta para un computador por lo que, para que la UCP no permanezca inactiva, el S.O. la cambiará al programa de otro usuario. Ésto ocurre tan rápidamente que cada usuario tiene la impresión de que cuenta con su propio computador, cuando en realidad todos lo comparten.

• 3.2.2 Tiempo real.

Suele usarse como dispositivo de control en una aplicación dedicada. Tiene restricciones temporales bien definidas, por lo que el procesamiento debe llevarse a cabo dentro de los límites definidos o el sistema fallará. Puede parecernos extraña la utilidad de este tipo de gestión, así que pondremos un ejemplo: una nave espacial se dispone a acoplarse a la estación espacial MIR, nos interesa conocer las coordenadas de la MIR en todo momento para compararlas con las nuestras y así actuar en consecuencia. De nada nos sirve que se resuelvan los cálculos una vez nos hemos estrellado porque un astronauta estaba jugando con el mismo ordenador al tetris y este consumía toda la potencia de cálculo del ordenador.

• 3.2.3 Combinados

Es una mezcla de los dos anteriores. Aunque se ha intentado combinar la funcionalidad del tiempo compartido y el tiempo real en un solo S.O., los resultados han sido pésimos debido a los obvios conflictos entre los requisitos de ambos tipos.

• 3.3. Sistemas distribuidos. [Goscinski91]

Es un sistema débilmente acoplado, es decir, los procesadores no comparten ni memoria ni reloj, cada uno cuenta con su propia memoria local y se comunican a través de distintas líneas de comunicación. Los procesadores pueden variar de tamaño y función. Las principales ventajas son:

• Compartición de recursos.

• Aceleración de los cálculos.

• Fiabilidad.

• Comunicación.

4. Arquitectura de un S.O. [Milenkovic94]

Para comenzar este apartado podemos plantear la siguiente pregunta: "¿Qué pasa si el propio sistema operativo necesita hacer algo que es capaz de hacer pero no se encuentra en el código que está ejecutando en ese momento?" Dicho de otra manera, vamos a ver dónde se encuentran las diferentes funciones de un S.O. y qué tiene que hacer para usarlas. Hasta ahora hemos visto parte del aspecto "exterior" del S.O., que es la organización que da a los programas a la hora de ejecutarlos. Pasemos a examinar las diferentes posibilidades de implementación de un S.O. "por dentro", es decir, no cómo organiza el sistema operativo al resto de programas, sino cómo se organiza respecto a sí mismo.

• 4.1. Kernel monolítico: La estructura de esta arquitectura es simplemente no tener ninguna. A nivel de núcleo no se produce ninguna abstracción, es decir, si un procedimiento necesita a otro es libre de hacerlo en cualquier momento. Fue el primer enfoque en la historia, el resto son evoluciones.

• 4.2. Microkernel o micronúcleo: En este caso, el S.O. se ocupa solo de unas pocas funciones, reduciendo el núcleo a su mínima expresión. El resto de funciones pasan a estar en el espacio de usuario.

• 4.3. Maquinas virtuales: El primer sistema con esta arquitectura nació con la idea de separar completamente las dos funciones características de un S.O. de tiempo compartido: multiprogramación y un interfaz mas apropiado que el del puro HW. El centro del sistema, también conocido como monitor de la máquina virtual, se ejecuta directamente sobre el propio HW, encargándose de la multiprogramación. De esta forma, ofrece al nivel superior varias máquinas virtuales, que son copias exactas del hardware, por lo que se puede dar el caso de ejecutar varios S.O. sobre cada una de ellas (de hecho, el caso mas usual).

• 4.4. Modelo cliente-servidor: Esta es la tendencia en cuanto a arquitectura de los S.O. hoy en día. Consiste en reducir al mínimo el kernel, al igual que en el caso de los microkernels, pero en este caso la única función del kernel es de servir de puente entre procesos: cuando una función necesita de otra es el kernel el que se encarga de mantener la comunicación entre ellas, pero nada más.

5. Diferentes funciones de un S.O. [Stallings97]

El sistema operativo crea un entorno para la ejecución de cada proceso, además de ofrecer ciertos servicios a los programas y a sus usuarios. Vamos a ver algunos de ellos.

Los servicios específicos que ofrece cada S.O. suelen ser diferentes, dependiendo del sector al que están destinados, aunque algunas clases de ellos son comunes: las operaciones de E/S, la manipulación del sistema de archivos, la detección de errores, etc. Estas funciones tienen el propósito, en su mayoría, de favorecer la tarea del programador, haciendo más fácil su trabajo. Lo que realmente nos está dando el S.O. es una capa de abstracción del hardware particular sobre el que corre. Por si no ha quedado claro el porqué de estas facilidades, pongamos un ejemplo: un programador de bases de datos que trabaje con dos máquinas distintas en HW se encontrará con el problema de que tiene que saber manipular los archivos tanto en una como en otra plataforma. Si el S.O. cumple bien el objetivo de abstracción, un mismo programa puede funcionar sobre dos máquinas de arquitectura diferente con el mismo sistema operativo, sin que haga falta modificar el código del programa.

Además de estas funciones, el S.O. tiene otro conjunto destinado al funcionamiento eficiente de la máquina: asignación de recursos, gestión de procesos, ...

Prácticamente, estos dos grandes grupos de funciones determinan todo lo que hace un S.O.: por un lado, las que facilitan la vida al programador y, por otro, las que hacen que éstas últimas se ejecuten en un medio con consistencia. De nada serviría que el sistema permitiese abrir 5 archivos simultáneamente si es incapaz de dejar algo de memoria para la ejecución del programa que los ha abierto.

Veamos ahora algunos de estos tipos de llamadas al sistema, o servicios que ofrece el sistema:

• Para la gestión de procesos: Dentro de este tipo nos encontramos todas aquellas llamadas necesarias para la ejecución de programas, así como la eficiente distribución de recursos entre éstos.

• Para el acceso a dispositivos de E/S: Como hemos dicho antes, el S.O. debe abstraer el funcionamiento del hardware al programador. Para ello, el sistema nos provee de ciertas funciones genéricas para su acceso.

• Para la detección de errores y respuesta: A pesar de ser máquinas, en los sistemas se pueden producir multitud de errores, tanto de SW como de HW, algunos de ellos pueden ser:

• Acceso a zonas prohibidas de memoria (SW)

• Imposibilidad de asignar los recursos solicitados por una aplicación (SW)

• Fallo de algún dispositivo de almacenamiento (HW)

En todos los casos el sistema ha de ser capaz de responder con éxito a estos sucesos, o en su defecto, evitar la pérdida de datos. Alguno de estos problemas, como la imposibilidad de asignar recursos solicitados por una aplicación han causado muchos quebraderos de cabeza a los programadores y se han llegado a escribir capítulos enteros sobre las posibles soluciones.

• Para la contabilidad del sistema: Si bien este tipo de funciones no las encontramos en todos los S.O., son bastante comunes en aquellos que tienen la particularidad de ser multiusuario.

6. Otros aspectos.

Hasta ahora nos hemos centrado en describir qué es lo que nos ofrecía un S.O. objetivamente. Es hora de ver cuál es el resultado de emplear un tipo determinado de estructura o de gestión de procesos.

Por norma, nos encontraremos generalmente con el dilema de que más comodidad significa automáticamente menos eficiencia y viceversa. Ocurre lo mismo con los lenguajes de programación: el ensamblador es tremendamente eficiente pero, sin embargo, es mucho más difícil de usar.

Otro aspecto importante a considerar es la facilidad que tiene el sistema operativo para adaptarse a los nuevos cambios, o sea, evolucionar. Un kernel monolítico será mucho mas difícil de mantener que un microkernel donde podríamos hacer los cambios simplemente en la capa de usuario.

Un paseo por la historia.

A continuación se presenta una tabla cronológica que nos va a ayudar a relacionar diferentes S.O.'s según sus características más notables.

The

Universidad de Eindhoven

Lotes

modular

no

RC4000

Brinch Hansen de Regenecentralen

S.O. Completo

modular

no

Solo

Brinch Hansen de Regenecentralen

multiprogramado

modular

no

CTSS

MIT

multiprogramado-tº compartido

monolítico

si

Multics

MIT

multiprogramado-tº compartido

modular

si

Unix

1969

Ritchie / Thompson

multiprogramado-tºcompartido

monolítico

si

Sprite

1984

multiprogramado

modular

si

Merlin

1984

Lotes

monolítico

no

Windows NT

1985

Microsoft

multiprogramado

modular

si

Mach

1986

Darpa

multiprogramado

monolítico

si

Amoeba

1994 (En desarrollo)

distribuido

microkernel

si

Windows 95/98

1995/98

Microsoft

multiprogramado

monolítico

no

Coyote

1996

Trinity College Dublín

distribuido

modular

si

Exokernel

En desarrollo

micro-kernel

monolítico

si

Referencias

Conclusiones

Como hemos visto, existen multitud de Sistemas Operativos, muchos de los cuales el público desconoce, pero que nosotros, como informáticos tenemos la 'obligación' de saber de ellos o incluso probarlos. Muchos de ellos son incluso de libre distribución.

De nada nos servirá que las tiendas ofrezcan ahora preinstalar Windows o Linux, habiendo una baraja entera de S.O.'s entre los que elegir. Estas iniciativas están lejos de complacer a todos aquellos que tratan de llegar más lejos, es decir, de abrir los ojos.