Perspectiva Histrica

GNU LINUX Haga clic para modificar el estilo

de subttulo del patrn

4/7/12

Perspectiva histrica

Los primeros sistemas (1945 - 1950) eran grandes mquinas operadas desde la consola maestra por los programadores. Durante la dcada siguiente (1950 - 1960) se llevaron a cabo avances en el hardware: lectoras de tarjetas, impresoras, cintas magnticas, etc. Esto a su vez provoc un avance en el software: compiladores, ensambladores, cargadores, manejadores de dispositivos, etc.

4/7/12

Problemas de explotacin S.O. y soluciones iniciales

del

El problema principal de los primeros sistemas era la baja utilizacin de los mismos, la primera solucin fue poner un operador profesional que manejaba el sistema, con lo que se eliminaron las hojas de reserva, se ahorr tiempo y se aument la velocidad. Para ello, los trabajos se agrupaban de forma manual en lotes mediante lo que se conoce como procesamiento por lotes (batch) sin automatizar.

4/7/12

Monitores residentes

Fichas en lenguaje de procesamiento por lotes, con programa y datos, para ejecucin secuencial Segn fue avanzando la complejidad de los programas, fue necesario implementar soluciones que automatizaran la organizacin de tareas sin necesidad de un operador. Debido a ello se crearon los monitores residentes: programas que residan en memoria y que gestionaban la ejecucin de una cola de trabajos. Un monitor residente estaba compuesto por un cargador, un Intrprete de comandos y un Controlador (drivers) para el manejo de entrada/salida.

4/7/12

Sistemas con almacenamiento temporal de E/S

Se avanza en el hardware, creando el soporte de interrupciones. Luego se lleva a cabo un intento de solucin ms avanzado: solapar la E/S de un trabajo con sus propios clculos. Por ello se crea el sistema de buffers con el siguiente funcionamiento: Un programa escribe su salida en un rea de memoria (buffer 1). El monitor residente inicia la salida desde el buffer y el programa de aplicacin calcula depositando la salida en el buffer 2.

4/7/12

Sistemas con almacenamiento temporal de E/S

La salida desde el buffer 1 termina y el nuevo clculo tambin. Se inicia la salida desde el buffer 2 y otro nuevo clculo dirige su salida al buffer 1. El proceso se puede repetir de nuevo. Los problemas surgen si hay muchas ms operaciones de clculo que de E/S (limitado por la CPU) o si por el contrario hay muchas ms operaciones de E/S que clculo (limitado por la E/S).

4/7/12

Spoolers
Hace aparicin el disco magntico con lo que surgen nuevas soluciones a los problemas de rendimiento. Se eliminan las cintas magnticas para el volcado previo de los datos de dispositivos lentos y se sustituyen por discos (un disco puede simular varias cintas). Debido al solapamiento del clculo de un trabajo con la E/S de otro trabajo se crean tablas en el disco para diferentes tareas, lo que se conoce como Spool (Simultaneous Peripherial Operation On-Line).

4/7/12

Sistemas Operativos Multiprogramados

Surge un nuevo avance en el hardware: el hardware con proteccin de memoria. Lo que ofrece nuevas soluciones a los problemas de rendimiento:

Se solapa el clculo de unos trabajos con entrada/salida de otros trabajos. Se pueden mantener en memoria varios programas.

la

Se asigna el uso de la CPU a los diferentes programas en memoria.

4/7/12

Sistemas Operativos Multiprogramados

Debido a los cambios anteriores, se producen cambios en el monitor residente, con lo que ste debe abordar nuevas tareas, naciendo lo que se denomina como Sistemas Operativos multiprogramados, los cuales cumplen con las siguientes funciones:

Administrar la memoria. Gestionar el uso de la CPU (planificacin). Administrar el uso de los dispositivos de E/S. Cuando desempea esas tareas, el monitor residente se transforma en un sistema operativo multiprogramado.
4/7/12

Llamadas al Sistema Operativo llamadas que ejecutan los Definicin breve:

programas de aplicacin para pedir algn servicio al SO. Cada SO implementa un conjunto propio de llamadas al sistema. Ese conjunto de llamadas es el interfaz del SO frente a las aplicaciones.

4/7/12

Llamadas al Sistema Operativolenguaje que deben usar las Constituyen el

aplicaciones para comunicarse con el SO. Por ello si cambiamos de SO, y abrimos un programa diseado para trabajar sobre el anterior, en general el programa no funcionar, a no ser que el nuevo SO tenga el mismo interfaz.

4/7/12

Modos de ejecucin en un Las aplicaciones no deben poder usar todas las CPU instrucciones de la CPU.
No obstante el SO, tiene que poder utilizar todo el juego de instrucciones del CPU. Por ello, una CPU debe tener (al menos) dos modos de operacin diferentes:

Modo usuario: el CPU podr ejecutar slo las instrucciones del juego restringido de las aplicaciones. Modo supervisor: la CPU debe poder ejecutar el juego completo de instrucciones.
4/7/12

Una aplicacin, normalmente no sabe dnde est situada la rutina de servicio de la llamada. Por lo que si sta se codifica como una llamada de funcin, cualquier cambio en el SO hara que hubiera que reconstruir la aplicacin. Pero lo ms importante es que una llamada de funcin no cambia el modo de ejecucin de la CPU.

Llamadas al Sistema

4/7/12

Con lo que hay que conseguir llamar a la rutina de servicio, sin tener que conocer su ubicacin, y hacer que se fuerce un cambio de modo de operacin de la CPU en la llamada (y la recuperacin del modo anterior en el retorno). Esto se hace utilizando instrucciones mquina diseadas especficamente para este cometido, distintas de las que se usan para las llamadas de funcin.

Llamadas al Sistema

4/7/12

Bibliotecas de interfaz de llamadas al Las llamadas al sistema no siempre tienen una sistema

expresin sencilla en los lenguajes de alto nivel, por ello se crean las bibliotecas de interfaz, que son bibliotecas de funciones que pueden usarse para efectuar llamadas al sistema. Las hay para distintos lenguajes de programacin. La aplicacin llama a una funcin de la biblioteca de interfaz (mediante una llamada normal) y esa funcin es la que realmente hace la llamada al sistema.

4/7/12

El SO ocupa una posicin intermedia entre los programas de aplicacin y el hardware. No se limita a utilizar el hardware a peticin de las aplicaciones ya que hay situaciones en las que es el hardware el que necesita que se ejecute cdigo del SO. En tales situaciones el hardware debe poder llamar al sistema, pudiendo deberse estas llamadas a dos condiciones: Algn dispositivo de E/S necesita atencin. Se ha producido una situacin de error al intentar ejecutar una instruccin del programa (normalmente de la aplicacin).
4/7/12

Interrupciones y excepciones

En ambos casos, la accin realizada no est ordenada por el programa de aplicacin, es decir, no figura en el programa. Segn los dos casos anteriores tenemos: las interrupciones y la excepciones Interrupcin: seal que enva un dispositivo de E/S a la CPU para indicar que la operacin de la que se estaba ocupando, ya ha terminado. Excepcin: una situacin de error detectada por la CPU mientras ejecutaba una instruccin, que requiere tratamiento por parte del SO.
4/7/12

Interrupciones y excepciones

Importancia de las El mecanismo de tratamiento de las interrupciones SO utilizar la CPU en interrupciones permite al

servicio de una aplicacin, mientras otra permanece a la espera de que concluya una operacin en un dispositivo de E/S. El hardware se encarga de avisar al SO cuando el dispositivo de E/S ha terminado y el SO puede intervenir entonces, si es conveniente, para hacer que el programa que estaba esperando por el dispositivo, se contine ejecutando. En ciertos intervalos de tiempo puede convenir no aceptar seales de interrupcin. Por ello las interrupciones pueden

4/7/12

Cuando la CPU intenta ejecutar una instruccin incorrectamente construida, la unidad de control lanza una excepcin para permitir al SO ejecutar el tratamiento adecuado. Al contrario que en una interrupcin, la instruccin en curso es abortada. Las excepciones al igual que las interrupciones deben estar identificadas.

Excepciones

4/7/12

Las instrucciones de un programa pueden estar mal construidas por diversas razones: El cdigo de operacin puede ser incorrecto. Se intenta realizar alguna operacin no definida, como dividir por cero. La instruccin puede no estar permitida en el modo de ejecucin actual. La direccin de algn operando puede ser incorrecta o se intenta violar alguno de sus permisos de uso.

Clases de excepciones

4/7/12

Importancia delaslas El mecanismo de tratamiento de excepciones es esencial para impedir, junto a los modos de ejecucin de la CPU y los excepciones la memoria, que las aplicaciones mecanismos de proteccin de

realicen operaciones que no les estn permitidas. En cualquier caso, el tratamiento especfico de una excepcin lo realiza el SO.

Como en el caso de las interrupciones, el hardware se limita a dejar el control al SO, y ste es el que trata la situacin como convenga.

Es bastante frecuente que el tratamiento de una excepcin no retorne al programa que se estaba ejecutando cuando se produjo la excepcin, sino que el SO aborte la ejecucin de ese programa.

Este factor depende de la pericia del programador para 4/7/12 controlar la excepcin adecuadamente.