SISTEMAS MONOLITICOS

Esta organizacin, que con mucho es la ms comn, bien podra

subtitularse como El Gran Lo. La estructura consiste en que no hay estructura. El sistema operativo se escribe como una coleccin de procedimientos, cada uno de los cuales puede llamar a cualquiera de los otros siempre que lo necesite. Cuando se utiliza esta tcnica, cada procedimiento del sistema tiene una interfaz bien definida desde el punto de vista de los parmetros y resultados, y cada uno est en libertad de llamar a cualquier otro, si ese otro realiza alguna operacin til que el primero necesita. Cuando se adopta este enfoque, el programa objeto del sistema operativo se construye compilando primero todos los procedimientos individuales, o ficheros que contienen los procedimientos, para a continuacin enlazarlos todos en un nico fichero objeto, utilizando el enlazador del sistema. En cuanto a la ocultacin de la informacin, esencialmente no hay ninguna ya que cualquier procedimiento puede ver a cualquier otro (en contraposicin con una estructura que contiene mdulos o paquetes, en la que gran parte de la informacin queda oculta dentro de los mdulos, y desde afuera slo pueden invocarse los puntos de entrada oficialmente declarados).

SISTEMAS MONOLITICOS

SISTEMAS MONILITICOS
Es muy comn: no existe estructura propiamente dicha o es mnima. El S. O. es una coleccin de procedimientos que se pueden llamar entre s Cada procedimiento tiene una interfaz bien definida en trminos de parmetros y resultados. Para ejecutar los servicios del S. O. (llamadas al sistema): Se solicitan colocando los parmetros en lugares bien definidos (registros o pilas) Se ejecuta una instruccin especial de trampa: llamada al ncleo o llamada al supervisor. La instruccin cambia la mquina del modo usuario al modo ncleo (o modo supervisor). Se transfiere el control al S. O. El S. O. examina los parmetros de la llamada para determinar cul de ellas se desea realizar. El S. O. analiza una tabla que contiene en la entrada k un apuntador al procedimiento que realiza la k-sima llamada al sistema: Identifica al procedimiento de servicio llamado. La llamada al sistema termina y el control regresa al programa del usuario.

SISTEMAS ESTRUCTURADOS EN CAPAS

consiste en organizar el sistema operativo en una jerarqua de capas, cada una construida sobre la que est debajo. El primer sistema construido de esta manera fue el THE construido en la Technische Hogescholl Eindhoven en los Pases Bajos por E.W. Dijkstra (1968) y sus estudiantes. El sistema THE era un sencillo sistema por lotes para un ordenador holands, la Electrologica X8, que tena 32K palabras de 27 bits (los bits eran costosos en aquel entonces).
El sistema tena seis capas, como se muestra en la Figura 1-25. La capa 0 se ocupaba de la asignacin del procesador, conmutando entre procesos segn tenan lugar las interrupciones o expiraban los timers. Por encima de la capa 0, el sistema consista de procesos secuenciales, cada uno de los cuales poda programarse sin tener que preocuparse por el hecho de que varios procesos estuvieran ejecutndose en un nico procesador. En otras palabras, la capa 0 hac posible la multiprogramacin bsica de la CPU.

SISTEMAS ESTRUCTURADOS EN CAPAS

La capa 1 se encargaba de la administracin de la memoria. Asignaba memoria a los procesos en la memoria principal y sobre un tambor de 512K palabras en el que se guardaban las partes de los procesos (pginas) que no caban en la memoria principal. Por encima de la capa 1, los procesos no tenan que preocuparse de saber si estaban en la memoria o en el tambor; el software de la capa 1 se encargaba de que las pginas se transfirieran a la memoria cuando se necesitaban. La capa 2 manejaba la comunicacin entre cada proceso y la consola del operador. Por encima de esta capa cada proceso tena efectivamente su propia consola de operador. La capa 3 se encargaba de gestionar los dispositivos de E/S y de colocar bferes intermedios en los flujos de informacin hacia y desde los dispositivos de E/S. Encima de la capa 3 cada proceso poda tratar con dispositivos de E/S abstractos con bonitas propiedades, en lugar de dispositivos reales con muchas peculiaridades. En la capa 4 estaban los programas de usuario, que no tenan que preocuparse por la gestin de los procesos, la memoria, la consola o la E/S. El proceso del operador del sistema se localizaba en la capa 5.

SISTEMAS ESTRUCTURADOS EN CAPAS

Es una generalizacin del modelo de estructura simple para un sistema monoltico. Consiste en organizar el s. o. como una jerarqua de capas, cada una construida sobre la inmediata inferior. Capa 0:

Trabaja con la asignacin del procesador. Alterna entre los procesos cuando ocurren las interrupciones o expiran los cronmetros. Proporciona la multiprogramacin bsica. Administra la memoria. Asegura que las pginas (porciones de memoria) requeridas de los procesos lleguen a memoria cuando fueran necesarias. Administra la comunicacin entre cada proceso y la consola del operador. Por sobre esta capa, cada proceso tiene su propia consola de operador. Controla los dispositivos de e / s y almacena en buffers los flujos de informacin entre ellos. Por sobre la capa 3 cada proceso puede trabajar con dispositivos abstractos de e / s en vez de con dispositivos reales. Aloja los programas del usuario. Los programas. del usuario no tienen que preocuparse por el proceso, memoria, consola o control de e / s. Localiza el proceso operador del sistema.

Capa 1:

Capa 2:

Capa 3:

Capa 4:

Capa 5:

Una generalizacin mas avanzada del concepto de capas se presento con Multics (MIT, Bell Labs y General Electric): Multics: multiplexed information and computing service. Presenta una estructura en anillos concntricos, siendo los interiores los privilegiados. Un procedimiento de un anillo exterior, para llamar a un procedimiento de un anillo interior, debe hacer el equivalente a una llamada al sistema.

MAQUINAS VIRTUALES

Las primeras versiones de OS/360 fueron estrictamente sistemas por lotes. No obstante, muchos usuarios de las 360 deseaban disponer de tiempo compartido, por lo que diversos grupos, tanto dentro como fuera de IBM, decidieron escribir sistemas de tiempo compartido para esa mquina. El sistema de tiempo compartido oficial de IBM, el TSS/360, tard mucho en entregarse, y cuando por fin lleg era tan grande y lento que pocos sitios adoptaron el nuevo sistema. Eventualmente el sistema se abandon despus de que su desarrollo hubiera consumido alrededor de 50 millones de dlares (Graham, 1970). No obstante, un grupo del Centr Cientfico de IBM, en Cambridge, Massachussets, produjo un sistema radicalmente distinto, que IBM acept al final como producto, y que ahora se utiliza ampliamente en los mainframes que subsisten. Este sistema, denominado originalmente CP/CMS y rebautizado ms adelante como VM/370 (Seawright y MacKinnon, 1979), se basaba en una astuta observacin: un sistema de tiempo compartido proporciona: (1) multiprogramacin y (2) una mquina extendida con una interfaz ms conveniente que el hardware desnudo. La esencia del VM/370 consiste en separar por completo estas dos funciones. El corazn del sistema, conocido como monitor de mquina virtual, se ejecuta sobre el hardware desnudo y realiza la multiprogramacin, proporcionando no una, sino varias mquinas virtuales a la siguiente capa inmediatamente superior Sin embargo, a diferencia de todos los dems sistemas operativos, estas mquinas virtuales no son mquinas extendidas, con ficheros y otras caractersticas bonitas. En vez de eso, son copias exactas del hardware desnudo que incluyen el modo dual de ejecucin usuario/supervisor, E/S, interrupciones y todo lo dems que tiene la mquina real.

MAQUINAS VIRTUALES

Dado que cada mquina virtual es idntica al hardware verdadero, cada una puede ejecutar cualquier sistema operativo ejecutable directamente sobre el hardware desnudo. Diferentes mquinas virtuales pueden ejecutar sistemas operativos distintos, y a menudo lo hacen. Algunas ejecutan uno de los descendientes del OS/360 para el procesamiento por lotes o de transacciones, mientras que otras ejecutan un sistema interactivo monousuario llamado CMS (Conversational Monitor System; Sistema Monitor Conversacional) para usuarios interactivos de tiempo compartido. Cuando un programa CMS ejecuta una llamada al sistema, sta salta (mediante un TRAP) al sistema operativo en su propia mquina virtual, no al VM/370, como hara si se estuviera ejecutando sobre una mquina real, no virtual. Luego el CMS ejecuta las instrucciones de E/S normales para leer de su disco virtual, o lo que sea que se necesite para llevar a cabo la llamada. VM/370 atrapa estas instrucciones de E/S y luego las ejecuta como parte de su simulacin del hardware real. Al separar por completo las funciones de multiprogramacin y de proporcionar una mquina extendida, cada una de las partes puede ser mucho ms sencilla, ms flexible y ms fcil de mantener.

MAQUINAS VIRTUALES
Se separan totalmente las funciones de multiprogramacin y de mquina extendida. Existe un elemento central llamado monitor de la mquina virtual que: Se ejecuta en el hardware. Realiza la multiprogramacin. Proporciona varias mquinas virtuales a la capa superior. Las mquinas virtuales instrumentan copias exactas del hardware simple, con su modo ncleo / usuario, e / s, interrupciones y todo lo dems que posee una mquina real. Pueden ejecutar cualquier S. O. que se ejecute en forma directa sobre el hardware. Las distintas mquinas virtuales pueden ejecutar distintos S. O. y en general as lo hacen. Soportan perifricos virtuales. La llamada es atrapada por el S. O. en su propia m. v.; no pasa directamente al VM/370. CMS proporciona las instrucciones de e / s en hardware para la lectura del disco virtual o lo necesario para efectuar la llamada. VM/370 atrapa estas instrucciones de e / s y las ejecuta sobre el hardware verdadero.

MODELO CLIENTE-SERVIDOR
El VM/370 gana mucho en simplicidad al mover una gran parte del cdigo del sistema operativo tradicional (la implementacin de la mquina extendida) a una capa superior, CMS. No obstante, VM/370 sigue siendo l mismo un programa complejo porque la simulacin de varias 370 virtuales en su totalidad no es tan sencilla (sobre todo si se quiere hacer con una eficiencia razonable). Una tendencia en los sistemas operativos modernos consiste en llevar ms lejos an la idea de subir cdigo a las capas superiores y quitar tanto como sea posible del modo ncleo, dejando un microkernel mnimo. El enfoque usual es implementar la mayor parte del sistema operativo en procesos de usuario. Para solicitar un servicio, tal como la lectura de un bloque de un fichero, un proceso de usuario (que ahora se denomina proceso cliente) enva una solicitud a un proceso servidor, que realiza el trabajo y devuelve la repuesta.

MODELO CLIENTE-SERVIDOR

En este modelo, que se muestra en la Figura 1-27, lo nico que hace el ncleo es manejar la comunicacin entre clientes y servidores. Al dividir el sistema operativo en partes, cada una de las cuales slo se encarga de una faceta del sistema, tales como el servicio de ficheros, el servicio de procesos, el servicio de terminal o el servicio de memoria, cada parte se vuelve ms pequea y manejable. Adems, dado que todos los servidores se ejecutan como procesos en modo usuario, no en modo ncleo, no tienen acceso directo al hardware. En consecuencia, si se produce un error en el servidor de ficheros, podra fallar el servicio de ficheros, pero usualmente ese error no llega a provocar que se detenga toda la mquina. Otra ventaja del modelo cliente-servidor es su adaptabilidad para usarse en sistemas distribuidos (vea la Figura 1-28). Si un cliente se comunica con el servidor envindole mensajes, el cliente no necesita saber si el mensaje se maneja de forma local en su propia mquina, o si se envi a travs de la red a un servidor situado en una mquina remota. En lo que concierne al cliente, en ambos casos sucede lo mismo: se envi una solicitud y se recibi una respuesta.

MODELO CLIENTE-SERVIDOR
La descripcin presentada anteriormente de un ncleo que tan solo se encarga De transportar mensajes desde los clientes a los servidores y al revs, no es del todo realista. Algunas funciones del sistema operativo (como la carga de comandos en los registros de los dispositivos de E/S fsicos) son difciles, sino imposibles, de llevar a cabo desde programas en 61 el espacio del usuario. Hay dos formas de resolver este problema. Una es hacer que algunos procesos servidores cruciales (por ejemplo, los drivers de dispositivo) se ejecuten realmente en modo ncleo, con un acceso sin restricciones a todo el hardware, pero manteniendo todava su comunicacin con los otros procesos, empleando el mecanismo normal de mensajes.

MODELO CLIENTE-SERVIDOR
Una tendencia en los S. O. modernos es la de explotar la idea de mover el cdigo a capas superiores y mantener un ncleo mnimo, de manera similar al VM/370. Implantar la mayora de las funciones del S. O. en los procesos del usuario. El proceso del usuario (proceso cliente) enva la solicitud a un proceso servidor: Realiza el trabajo y regresa la respuesta. El ncleo controla la comunicacin entre los clientes y los servidores. Se fracciona el S. O. en partes, cada una controlando una faceta: Servicio a archivos, a procesos, a terminales, a memoria, etc., cada parte pequea y ms fcilmente controlable. Los servidores se ejecutan como procesos en modo usuario: No tienen acceso directo al hardware. Se aslan y acotan ms fcilmente los problemas. Si un cliente se comunica con un servidor mediante mensajes: No necesita saber si el mensaje se atiende localmente o mediante un servidor remoto, situado en otra mquina conectada. Enva una solicitud y obtiene una respuesta. Algunas funciones del S. O., por ej. el cargado de comandos en los registros fsicos del dispositivo de e / s, presentan problemas especiales y distintas soluciones: Ejecucin en modo ncleo, con acceso total al hardware y comunicacin con los dems procesos mediante el mecanismo normal de mensajes. Construccin de un mnimo de mecanismos dentro del ncleo manteniendo las decisiones de poltica relativas a los usuarios dentro del espacio del usuario.

BIBLIOGRAFIA
SISTEMAS OPERATIVOS MODENOS ANDREW S.

TANENBAUN http://exa.unne.edu.ar/depar/areas/informatica/Siste masOperativos/SO1.htm#ESO