sistemas operativos mod8

El estado del artede los sistemasoperativos actualesTeodor Jov Lagunas

P05/75097/00811Mdulo 8

FUOC P05/75097/00811 Mdulo 8 2 El estado del arte de los sistemas operativos actuales

FUOC P05/75097/00811 Mdulo 8 El estado del arte de los sistemas operativos actuales

ndice

Introduccin............................................................................................. 5

Objetivos .................................................................................................... 6

1. Conceptos generales........................................................................... 7

1.1. El modelo cliente/servidor............................................................... 7

1.2. Los procesos multiflujo (multi-thread) ............................................. 9

2. Los sistemas operativos de tiempo real ........................................ 11

3. Los sistemas operativos multiprocesador .................................... 14

3.1. Las arquitecturas multiprocesador .................................................. 14

3.2. Las ventajas de los sistemas multiprocesador ................................. 15

3.3. Tipos de sistemas operativos multiprocesador................................ 16

4. Los sistemas operativos en red y los sistemas

operativos distribuidos..................................................................... 19

4.1. El entorno distribuido ..................................................................... 19

4.2. Definicin y evolucin de los sistemas operativos en red .............. 20

4.3. Tipos de sistemas operativos distribuidos ....................................... 24

Resumen..................................................................................................... 27

Actividades................................................................................................ 29

Glosario ...................................................................................................... 29

Bibliografa............................................................................................... 30


Introduccin

En este mdulo didctico trataremos diferentes aspectos relacionados con los

sistemas operativos actuales.

Comenzaremos haciendo una breve introduccin a los siguientes conceptos:

El modelo cliente/servidor como paradigma que permite construir y or-

ganizar, entre otros, los servicios del sistema operativo (SO).

El flujo de ejecucin como evolucin lgica del concepto de proceso.

A continuacin analizaremos las caractersticas ms importantes de tres tipos

de sistemas operativos:

a) Los sistemas operativos de tiempo real, que se centran en las aplicaciones

que presentan fuertes restricciones temporales.

b) Los sistemas operativos multiporcesador y los sistemas operativos dis-

tribuidos, que se orientan ms hacia el hardware que tienen que administrar

y a las posibilidades y condicionamientos que ste comporta que hacia el tipo

de servicio que tienen que ofrecer.


Objetivos

En los materiales didcticos que contiene el presente mdulo encontraris las

herramientas necesarias para alcanzar estos objetivos:

1. Conocer el modelo cliente/servidor.

2. Entender el concepto de flujo de ejecucin.

3. Conocer las principales caractersticas de los sistemas operativos de tiempo

real.

4. Identificar las particularidades de las arquitecturas multiprocesador y de

sus sistemas operativos.

5. Reconocer las caractersticas de los sistemas operativos en red y de los sis-

temas operativos distribuidos.


1. Conceptos generales

En este apartado nos disponemos a introducir dos conceptos que han influido

de manera decisiva en la evolucin de los sistemas operativos: el modelo clien-

te/servidor y los procesos multiflujo (multi-thread). Ambos se pueden aplicar a

cualquier tipo de SO, tanto si ste es de propsito general, como los que vere-

mos en este mdulo didctico, como si se orientase a objetivos ms especfi-

cos. Ahora bien, estos conceptos han incidido de una forma especial en los

sistemas distribuidos y en los sistemas multiprocesador.

1.1. El modelo cliente/servidor

La invocacin de un procedimiento, las llamadas al sistema y la solicitud de

ejecucin de una orden se pueden considerar como la peticin de un servicio

por parte de un cliente. Desde este punto de vista, en esta relacin podemos

distinguir los siguientes elementos:

El cliente, que es el ente que realiza la peticin del servicio.

El servidor, que es el ente que ofrece el servicio.

El servicio, que es la accin solicitada.

Clientes y servidores pueden ser de manera indistinta procesos o sistemas ope-

rativos directamente, y pueden estar ubicados dentro de la misma mquina o

en mquinas diferentes interconectadas mediante una red de transmisin de

datos. La figura 1 muestra la relacin que se establece entre cliente y servidor

en tres situaciones diferentes:

a) El cliente es un proceso y el servidor es su sistema operativo. Este primer

caso representa la ejecucin de una llamada al sistema.

b) El cliente y el servidor son procesos del SO. Este segundo caso utiliza las lla-

madas al sistema para poner en contacto al cliente y al servidor.

c) El cliente y el servidor son procesos de sistemas operativos diferentes. Este

ltimo caso utiliza las llamadas al sistema de acceso a la red para comunicar

procesos de mquinas diferentes.

El ltimo caso es el ms importante al permitir que los servicios se puedan

ofrecer desde cualquier punto de una red. Esta idea es la base de los sistemas

abiertos, que permiten ofrecer servicios a procesos remotos y/o acceder a ser-


vicios externos a la mquina local. Adems de las tres situaciones menciona-

das, se pueden considerar casos particulares a partir de uno ms general. A

partir de ahora nos centraremos en esta posibilidad.

Los mecanismos de comunicacin utilizan las herramientas ms elementales

como base para construir las ms complejas. Estos mecanismos, que se utilizan

para poner en contacto a un cliente y a un servidor, se pueden clasificar en

funcin de su nivel semntico. As, tenemos los siguientes tipos:

1) El paso de mensajes. El caso ms elemental de comunicacin entre cliente

y servidor se basa en el uso de las operaciones de paso de mensajes. En este

caso, cliente y servidor tienen que ser conscientes de la ubicacin de cada uno

de ellos, y tienen que transferir y presentar de manera explcita los parmetros

y la respuesta de la solicitud.

2) Los procedimientos remotos (RPC*). Aqu el cliente considera el servicio

como un procedimiento ms de la librera. La librera y el SO son los encargados

de esconder al usuario las particularidades del mecanismo de comunicacin.

3) Los objetos distribuidos. Otro paso consiste en adoptar la semntica de la

programacin orientada a objetos. En este caso, el usuario ve el servicio como la

llamada de un mtodo del objeto al que quiere acceder. Igual que antes, la libre-

ra y el sistema operativo se encargan de esconder al cliente y el servidor las par-

ticularidades del mecanismo de comunicacin.

Figura1

Podis ver el paso de mensajes en el apartado 7 del mdulo didctico La concurrencia y la comunicacin.

* RPC es la sigla del trmino ingls Remote Procedure Call.


En torno a la relacin cliente/servidor surge un gran nmero de cuestiones,

problemas y posibilidades que no existan o son triviales en el entorno de un

proceso o de un SO aislados como los que hemos estudiado. Por ejemplo, uno

de estos problemas es la localizacin del servidor o servidores de un servicio

concreto; otro es la recuperacin de errores en caso de que falle algn elemen-

to de los que intervienen*. Para solucionarlos, podemos optar por alguna de

las siguientes posibilidades:

a) Una posibilidad consiste en tener ms de un servidor repartido en mqui-

nas diferentes para implementar polticas tolerantes a fallos, o bien para ser

ms eficientes.

b) Otras posibilidades se centran en la estructura del propio servidor, como si

por ejemplo el servidor puede servir a ms de un cliente a la vez o no, o si el

servicio se tiene que realizar de manera sncrona con la ejecucin del cliente

(como haramos con la ejecucin de un procedimiento) o de manera asncro-

na, dejando que el cliente contine su ejecucin en paralelo con la realizacin

del servicio.

1.2. Los procesos multiflujo (multi-thread)

Un proceso es un entorno de ejecucin. Otra manera de considerar un proceso

es como una mquina virtual completa: con memoria, dispositivos de entra-

da/salida y un procesador asociado. Hasta ahora hemos supuesto que esta m-

quina virtual que configuran los procesos tena que ser monoprocesador, es

decir, que en cada momento slo poda alojar la ejecucin de una secuencia

de instrucciones (thread). Esta restriccin es puramente lgica y se ha hecho

por analoga con la mquina real sobre la cual se han construido los primeros

sistemas operativos.

La posibilidad de multiplexar el procesador y la existencia de mquinas mul-

tiprocesador ha planteado la necesidad de tener ms de un flujo de ejecucin

por proceso. En otras palabras, se ha pasado de mquina virtual monoproce-

sada a una multiprocesada (multi-thread).

Si analizamos las necesidades actuales de las aplicaciones, vemos que el hecho

de tener ms de un flujo por proceso es una evolucin natural del concepto de

proceso. Podemos darnos cuenta de esta necesidad simplemente mediante el

anlisis de las rutinas de servicio de las seales de software. En este caso pode-

mos ver el proceso como un entorno multiflujo: nos encontramos con un flu-

jo para la ejecucin normal, y otro para atender de manera asncrona las

seales que puedan llegar.

Un paso ms es la necesidad de ejecutar aplicaciones paralelas. Lo ms natural

es que esta aplicacin utilice el paradigma de la memoria compartida para co-

* Los elementos que intervienen en la invocacin de un proceso son

el cliente, el servidor y la red.

Podis ver el concepto de mquina virtual en el apartado 1 del mdulo didctico El sistema operativo:una mquina virtual.

Podis ver las rutinas de servicio de las seales de software en el apartado 3 del mdulo didcticoLa concurrencia y la comunicacin.


municar y sincronizar las diferentes secuencias paralelas. Con el concepto tra-

dicional de proceso deberamos tener tantos procesos como secuencias, y se

tendran que reservar recursos para cada proceso. En cada cambio de contexto,

el sistema debera guardar todo el proceso y activar el nuevo. En definitiva, el

uso de procesos con un solo flujo provoca un aumento del uso de recursos y

tiempo de gestin del sistema.

Un ejemplo de aplicacin paralela son los servidores que debern tener la po-

sibilidad de atender a ms de un cliente al mismo tiempo. En un sistema mul-

tiflujo podramos contar con un flujo que atendiese la llegada de nuevas

peticiones. Para cada nueva peticin tendra que crear un nuevo flujo que

atendiese a la peticin, y que se destruira al finalizar el servicio. El coste de

este servidor es menor que el de un servicio construido de acuerdo con proce-

sos. ste es el caso de UNIX, en el que un proceso atendera las peticiones de

servicio, y para cada nueva peticin creara, mediante la llamada fork, un

nuevo proceso para atenderla.

Para que el sistema pueda gestionar ms de un flujo por proceso slo tenemos

que aumentar los elementos que lo configuran, los cuales estn apuntados en

el bloque de control de procesos (PCB). En concreto, para cada flujo de ejecu-

cin el sistema tiene que proporcionar los siguientes elementos: un conjunto

de registros, una pila y un contador de programa.

Estos elementos, agrupados en un identificador de flujo, reflejarn en cada

instante el estado en que se encuentra la ejecucin del proceso.

Podis ver el PCB en el subapartado 1.1. del mdulo didcticoLa gestin de procesos.


2. Los sistemas operativos de tiempo real

Las aplicaciones que se gestionan con sistemas operativos de tiempo real tie-

nen que dar respuesta a acontecimientos externos, en general asociados a in-

terrupciones. Si la respuesta no se da en un tiempo concreto, la ejecucin de

la aplicacin carece de sentido.

Gestin de una presa hidrulica

En una presa hidrulica, desde el momento en que se detecta una riada hasta que se abrenlas compuertas para dejar salir el sobrante de agua, no puede pasar ms de un tiempo de-terminado. Si no se acta dentro de este margen de tiempo, la presa revienta y ya no tienesentido dar la orden de abrir. En este ejemplo interviene, adems, el tiempo del procesode apertura de las compuertas, que tendr que ser concreto y conocido. A la hora de ini-ciar la apertura de las compuertas no slo se tiene que garantizar que todava no ha re-ventado la presa, sino que estamos a tiempo de evitarlo. Si no pudiese hacerlo, el sistematendra que dedicar sus recursos a una accin ms prioritaria: avisar a la poblacin y eva-cuar al personal.

En general, los sistemas de tiempo real tienen que garantizar que la ejecucin

de las aplicaciones se inicie antes de un cierto intervalo de tiempo, y que debe

haber finalizado antes de que la accin que llevan a cabo deje de tener sentido.

As pues, un sistema de tiempo real, a diferencia de los sistemas interactivos o

de los de procesamientos por lotes, no slo tiene el objetivo de finalizar los tra-

bajos en un tiempo ms o menos razonable, sino que lo tiene que hacer con

unas restricciones temporales. Para conseguirlo, la gestin que realizan tanto

el sistema como la mquina virtual que presenta los procesos tiene que ser, en

este caso concreto, diferente de la que hemos visto en los mdulos anteriores,

y prever los siguientes puntos:

Hay que evitar, en la medida de lo posible, los mecanismos de gestin que

no pueden ofrecer servicio en un intervalo de tiempo conocido o que lo ha-

cen con un coste de tiempo excesivo.

Hay que proporcionar herramientas que permitan ordenar los procesos en

funcin de su urgencia.

Hay que facilitar mecanismos de comunicacin rpidos y flexibles que per-

mitan cubrir todas las necesidades de las aplicaciones.

Los sistemas operativos de tiempo real son sistemas que tienen que ofre-

cer servicio con unas restricciones temporales bien definidas: tienen

que dar una respuesta a determinados acontecimientos en un tiempo li-

mitado y dentro de un periodo de tiempo concreto.

Como ejemplos de entornos de trabajo...

... que utilizan sistemas operati-vos de tiempo real podemos en-contrar: el control de procesos industriales, los simuladores de tiempo real, los equipos de tele-fona, el control de electrodo-msticos, sistemas dedicados a aplicaciones militares, etc.


As pues, los principales puntos de accin de los sistemas operativos de tiempo

real son:

1) Gestin de procesos. La planificacin del procesador es expropiativa y se

basa en la determinacin de prioridades para los diferentes procesos. En este

modelo de planificacin del procesador, a cada proceso se le asocia una prio-

ridad. El procesador se asigna siempre al proceso ms prioritario de todos los

que se encuentran preparados, y el sistema proporciona mecanismos para de-

finir y modificar la prioridad de los procesos.

2) Gestin de la memoria. En la ejecucin de procesos crticos puede resultar

necesario prever con exactitud el tiempo de ejecucin y, en caso de no poder cal-

cularlo de manera exacta, se tiene que poder determinar cul puede ser el tiempo

mximo de ejecucin. El uso de mecanismos como la memoria virtual, que per-

miten que un proceso, en un instante concreto, pueda no residir totalmente en la

memoria, no son deseables, ya que introducen un grado tan elevado de variabili-

dad que impiden efectuar a priori el clculo de tiempo de ejecucin. Por este mo-

tivo, los sistemas de tiempo real permiten definir qu procesos tienen que estar de

forma permanente residentes en la memoria y cules no.

3) Gestin de las entradas/salidas. El sistema proporciona herramientas

para que los usuarios puedan definir directamente los tratamientos de las in-

terrupciones de determinados dispositivos de entrada/salida y evitar, as, la

ejecucin de cdigo genrico del sistema.

4) Comunicacin entre procesos. En este punto incluimos tanto la comuni-

cacin entre procesos propiamente dicha, como la comunicacin con aconte-

cimientos asncronos producidos por los procesos o por los dispositivos de

entrada/salida:

a) Los mecanismos de seales, adems de permitir controlar ciertos mecanis-

mos de entrada/salida, tienen que ser lo bastante sensibles como para propor-

cionar un mecanismo de seales de software, tambin lo bastante amplio como

para ofrecer servicio a diferentes situaciones: con seales de prioridad definible

por el usuario, con la posibilidad de inhibir o permitir la recepcin de seales

de cierta prioridad, etc.

b) La comunicacin entre procesos mediante dispositivos provoca un incre-

mento variable del tiempo de ejecucin a causa de la gestin del sistema y del

uso del mismo dispositivo. Para evitarlo, los sistemas de tiempo real permiten

definir regiones de memoria compartidas con el fin de que los procesos las uti-

licen para comunicarse sin costes de tiempo. Este mecanismo tiene que ir acom-

paado de herramientas de sincronizacin como pueden ser semforos que

permitan acceder a stas, en caso de que sea necesario, en exclusin mutua.

5) Gestin del sistema de ficheros. Como ya hemos visto, para evitar la variabi-

lidad del tiempo de acceso a los dispositivos, los procesos crticos utilizan mayo-

ritariamente la memoria compartida en tanto que mecanismo de comunicacin.

Podis ver los mecanismos de seales en el apartado 3 del mdulo didctico La gestin de procesos.

Podis ver los semforos en el apartado 4 del mdulo didcticoLa concurrencia y la comunicacin.


Por el mismo motivo, se podra utilizar la memoria como dispositivo de almace-

namiento, pero puede ser necesario un dispositivo de mayor capacidad y no tan

voltil como la memoria principal. Para que esto resulte viable, los sistemas de

tiempo real ofrecen un sistema de ficheros que suele sacrificar la optimizacin del

espacio para hacer el tiempo de acceso ms ajustado y regulado.

En la actualidad encontramos los sistemas de tiempo real como sistemas con un

objetivo especfico orientados a tareas muy concretas. A pesar de todo, tambin

hay sistemas de propsito general con extensiones de tiempo real. Por ejemplo,

el sistema VMS de la marca Digital es de este tipo.

Ejemplo de aplicacin de tiempo real

Supongamos un sistema de radar de un aeropuerto que capta seales de varios radares,realiza una composicin y, en caso de detectar una posible colisin, avisa a los aparatosimplicados y a la torre de control. Si se produce la colisin, el sistema tiene que ofrecerla posibilidad de proporcionar todos los datos que ha reunido para facilitar las investiga-ciones. As pues, el sistema podra estar formado por los siguientes procesos:

Los procesos que captan las seales de los radares. El proceso que analiza las seales para determinar las posibles colisiones. Los procesos que avisan del peligro. El proceso que almacena la informacin.

Figura 2

La figura...

... muestra los procesos posi-bles y sus prioridades relativas, as como los mecanismos de comunicacin y sincronizacin que podran utilizar.


3. Los sistemas operativos multiprocesador

Cada vez son necesarios sistemas ms rpidos para soportar un volumen de

trabajo mayor o para abordar problemas ms costosos en tiempo de clculo.

La forma de conseguirlo se basa en la mejora del hardware mediante las si-

guientes posibilidades:

1) Soluciones tecnolgicas que permiten ir cada vez ms rpido.

2) Soluciones arquitectnicas que permiten llevar a cabo ejecuciones concurren-

tes o en paralelo. Dentro de dichas soluciones nos encontramos con estas dos:

a) Mejorar el diseo del procesador.

b) Combinar procesadores que ya se encuentran en un sistema multiprocesador.

La ltima opcin suele ser la ms econmica y permite construir sistemas con

un crecimiento escalado en funcin de las necesidades.

3.1. Las arquitecturas multiprocesador

Podemos clasificar las arquitecturas multiprocesador teniendo en cuenta la re-

lacin que se establece entre procesadores y memoria:

Figura 3


a) Multiprocesadores acoplados fuertemente, tambin conocidos como sis-

temas de memoria compartida. En este caso, cada procesador ve y, por lo tanto,

puede acceder de manera directa a la totalidad de la memoria.

b) Multiprocesadores acoplados dbilmente, tambin denominados sistemas

de memoria distribuida. Cada procesador slo puede acceder a una memoria priva-

da. Los procesadores se comunican entre s por medio de mecanismos de paso de

mensajes.

Los multiprocesadores tambin se pueden clasificar segn la tipologa y las ca-

ractersticas de acceso de la red de interconexin que une los procesadores y

los mdulos de memoria, o los procesadores entre s. Sin embargo, vamos a

dejar este anlisis para un estudio arquitectnico de los multiprocesadores,

tema que, por otra parte, no es el objeto de esta asignatura.

3.2. Las ventajas de los sistemas multiprocesador

Las principales ventajas de los sistemas multiprocesador con respecto a los

monoprocesador se pueden resumir en las siguientes:

1) La tolerancia a fallos: los sistemas multiprocesador se pueden haber dise-

ado para trabajar aunque slo funcionen algunos de los procesadores que los

integran. Esta caracterstica hace que, en caso de fallo de algn componente

del sistema, el usuario, a pesar de que aprecia la prdida lgica de rendimiento,

pueda continuar trabajando. Cada vez es ms habitual que ni siquiera se tenga

que detener el sistema para reemplazar alguno de los componentes, ya sea por-

que se han estropeado o porque se tienen que actualizar.

2) El rendimiento y la potencia de clculo: el hecho de disponer de varios

procesadores permite abordar en paralelo ms de una aplicacin o bien partir

las aplicaciones en tareas que se ejecutan en paralelo. De este modo, en un sis-

tema multiprocesador podemos abordar los dos tipos de problemas que pre-

sentamos a continuacin:

El aumento de la productividad del sistema, entendiendo por productivi-

dad el nmero de procesos ejecutados por unidad de tiempo.

El aumento de la velocidad con que se ejecutan las aplicaciones.

Este abanico de posibilidades nos permitir obtener un alto rendimiento del

sistema.

3) El crecimiento modular: cada sistema multiprocesador est diseado para

interconectar un nmero mximo de procesadores. Ahora bien, el sistema

tambin puede funcionar, tal y como hemos comentado con anterioridad,

con un nmero menor de procesadores. Esta circunstancia permite que cada


instalacin se dimensione en funcin del trabajo que tenga que soportar, y

que pueda crecer, con la incorporacin de nuevos procesadores, si las necesi-

dades lo requieren. De esta manera se evita la renovacin de todo el sistema,

que es lo que ocurrira con el sistema monoprocesador.

4) La especializacin funcional: los sistemas multiprocesador pueden ser he-

terogneos, es decir, los procesadores que los integran pueden ser diferentes

en funcin de las necesidades de cada instalacin.

5) La flexibilidad: todas las caractersticas anteriores hacen que estos sis-

temas presenten un grado de flexibilidad superior al de los sistemas monopro-

cesador.

3.3. Tipos de sistemas operativos multiprocesador

Los sistemas operativos multiprocesador, en funcin de los objetivos de rendi-

miento que se hayan fijado, pueden tener bsicamente dos apariencias externas:

En los sistemas orientados a aumentar la productividad, el usuario tiene

una visin idntica a la que tendra, por ejemplo, en un sistema monopro-

cesador de propsito general.

En los sistemas orientados a aumentar la velocidad, el usuario trabaja de

manera diferida. En este caso, el desarrollo de las aplicaciones y el trabajo in-

teractivo en general se efectan en un sistema previo al multiprocesador de-

nominado front-end, que se encarga de enviar a las colas de trabajo diferido los

procesos que se tienen que llevar a cabo, as como de recoger sus resultados.

Los sistemas operativos multiprocesador pueden clasificarse en funcin de su

estructura interna en los tres modelos bsicos siguientes:

1) El modelo de supervisores separados

Como todos los modelos de sistemas operativos multiprocesador que veremos,

este modelo se puede aplicar a cualquier tipo de multiprocesador y a cualquier

objetivo, aunque se suele encontrar en multiprocesadores de memoria distribui-

da. Su objetivo bsico suele ser aumentar la velocidad de ciertas aplicaciones,

para cuya consecucin se dividen las aplicaciones en tareas que se ejecutan en

En el modelo de supervisores separados cada procesador tiene un sistema

operativo independiente que funciona como un sistema casi aislado.

Para aprovechar la arquitectura multiprocesador, cada sistema operativo

(supervisor) dispone de algunos servicios como el de comunicacin entre

procesos de diferentes procesadores. No obstante, no suelen tener herra-

mientas eficientes para repartir la carga entre los diferentes procesadores.


paralelo en diferentes procesadores. Suelen trabajar en ejecucin diferida y de-

jan el trabajo interactivo para un sistema monoprocesador con menos presta-

ciones.

Los sistemas hipercubo constituyen un caso comn de sistemas supervisores.

Cada nodo de la red tiene un ncleo de SO que lleva a cabo la gestin de pro-

cesos y de la memoria e implementa los mecanismos de comunicacin me-

diante el paso de mensajes. La asignacin de procesadores a programas que se

tienen que ejecutar se suele hacer estrictamente a mano o con utilidades ex-

ternas al SO; despus, un cargador distribuye las diferentes tareas a cada pro-

cesador en funcin de la asignacin preestablecida.

2) El modelo maestro/esclavo

Este modelo permite gestionar mejor la asignacin de procesos a procesadores

que el modelo anterior. Su diseo es muy similar al de los sistemas monoprocesa-

dor, pero se diferencian bsicamente por el modelo de planificacin de los proce-

sadores, motivo por el cual su aplicacin resulta poco costosa. La ejecucin del

sistema se lleva a cabo, tal y como hemos dicho, sobre un nico procesador, de

manera que este modelo no es vlido para multiprocesadores con muchos proce-

sadores, ya que el acceso al maestro se puede convertir en un cuello de botella.

Este modelo, a pesar de que puede funcionar bien en cualquier caso, en gene-

ral gestiona multiprocesadores de memoria compartida con un nmero pe-

queo de procesadores. Su objetivo bsico es el aumento de la productividad

del sistema, y ofrece a sus usuarios una visin muy similar a la que proporcio-

nan los sistemas interactivos monoprocesador, con la ventaja aadida de que

permite ejecutar aplicaciones en paralelo

3) El modelo simtrico

En este modelo, un procesador, el maestro, se encarga de ejecutar el sis-

tema operativo mientras que el resto de los procesadores, los esclavos,

se dedican a ejecutar los procesos que el maestro les encarga. Los proce-

sadores esclavos tienen capacidad para ejecutar llamadas elementales al

sistema; a pesar de todo, la mayor parte de los servicios los realiza el

maestro directamente.

En un esquema simtrico, todos los procesadores tienen las mismas

competencias*. Lo ms usual es que los recursos de todo el sistema se

encuentren a disposicin de todos los procesos. En tal caso, a diferencia

de los dos casos anteriores, el sistema se ejecuta en paralelo, de modo

que constituye en s mismo una aplicacin concurrente y, como tal, ne-

cesita utilizar de manera interna herramientas de sincronizacin y ex-

clusin mutua para gestionar sus recursos sin conflictos.

Sistemas hipercubo

Los sistemas hipercubo son sis-temas de memoria distribuida con una topologa de red de interconexin en forma de hi-percubo.

* Todos los procesadores pueden ejecutar el sistema.


La forma ms simple de implementar un sistema de estas caractersticas es lo

que se conoce como maestro flotante. En este caso, el sistema constituye una

gran exclusin mutua, y slo un procesador puede ejecutar al mismo tiempo

el SO. Con esta idea, convertir en portable un sistema monoprocesador es re-

lativamente fcil.

Este modelo est especialmente indicado para sistemas de memoria comparti-

da, en los que el objetivo es la productividad.


4. Los sistemas operativos en red y los sistemasoperativos distribuidos

La aparicin de las redes de computadores es uno de los elementos que ms ha

transformado el mundo de los sistemas operativos. En poco tiempo se ha pasa-

do de los sistemas cerrados, sistemas aislados sin red, a los sistemas abiertos,

sistemas interconectados mediante una red. Hoy da, la evolucin de esta situa-

cin nos ha llevado hasta los sistemas distribuidos. En el transcurso de este apar-

tado analizaremos dicha evolucin y algunas de las ideas en que se basa.

4.1. El entorno distribuido

La comunicacin y la sincronizacin en este modelo se basan en el paso de

mensajes. Las caractersticas propias de la red, como pueden ser los retrasos en-

tre el momento en que se produce un mensaje y el momento de su recepcin,

hacen imposible que un nodo del sistema distribuido conozca, en un instante

concreto, el estado global del sistema. Por otra parte, la propia estructura abier-

ta de las redes de comunicaciones configura un entorno fcilmente vulnera-

ble. Todo esto hace que las tcnicas que se aplican habitualmente a sistemas

cerrados, sin red de interconexin, se tengan que revisar y/o redefinir.

Las principales ventajas de los entornos distribuidos son las siguientes:

1) La comparticin de recursos: la aparicin de las redes ha permitido renta-

bilizar los recursos mediante la comparticin. La existencia de la red hace que

todos sus usuarios puedan acceder a recursos caros*, independientemente de

su ubicacin.

2) La comunicacin y la comparticin de informacin: la red permite que pro-

cesos y usuarios intercambien y compartan informacin. Este hecho hace posible:

a) La cooperacin tanto de personas como de aplicaciones mediante herra-

mientas como, por ejemplo, la mensajera electrnica. Es muy probable que

Podramos definir el entorno distribuido como varios sistemas interco-

nectados con una red que tienen la capacidad de cooperar y comunicarse

gracias a esta red y al software que la gestiona. Estos sistemas presentan las

siguientes caractersticas:

No disponen de memoria compartida.

Tienen el estado del sistema repartido entre los diferentes componentes.

Tienen los condicionamientos propios de redes de interconexin:

retrasos y fragilidad en la seguridad.

* Recursos como algunos perifricos, procesadores especializados,

sistemas de ficheros, aplicaciones, etc.


este hecho sea el que mayor impacto y repercusin ha tenido entre los usua-

rios de las redes.

b) La ejecucin de aplicaciones en paralelo.

3) La fiabilidad, la disponibilidad y la tolerancia a fallos: la interconexin

de muchos equipos informticos mediante una red abre las puertas a una serie

de tcnicas que hasta ahora se haban estado reservando a equipos muy espe-

cializados y caros.

La coexistencia de diferentes equipos hace posible la implementacin de tc-

nicas que aumenten la fiabilidad, como la duplicacin de clculos en ms de

un equipo y por mtodos diferentes, entre otros. La disponibilidad de equipos

independientes hace que la cada de uno no paralice la totalidad del sistema,

como ocurrira con un gran sistema aislado. En este caso, los usuarios aprecian

una disminucin del rendimiento, pero pueden continuar trabajando.

Otro aspecto de este mismo punto es la posibilidad de duplicar las funciones

y servicios, puesto que, de esta manera, se puede garantizar el funcionamiento

del sistema aunque una parte de ste haya fallado.

4) El crecimiento progresivo: la flexibilidad con que la red permite conectar

de manera gradual nuevos elementos hace posible llevar a cabo una poltica

de actualizacin y adaptacin a las circunstancias que no es viable en un sis-

tema cerrado.

El crecimiento progresivo permite que, a medida que es necesario tener ms

potencia de clculo o una mayor capacidad de disco, se pueden ir incorporan-

do al sistema sin tener que desecharlo y comprarlo de nuevo.

5) El rendimiento: para finalizar, el conjunto de ventajas anteriores hace que

el rendimiento global del sistema pueda ser elevado, e incluso superior en al-

gunos puntos al que se obtendra con un sistema centralizado.

4.2. Definicin y evolucin de los sistemas operativos en red

As pues, un sistema operativo distribuido integra el conjunto de elementos

que contiene la red en un nico sistema y ofrece al usuario una mquina de

nivel ms alto que esconde las particularidades de su gestin. Cada usuario tie-

ne que ser nico para todo el sistema, debe tener los mismos derechos en cual-

quier punto de la red, no debe saber en qu nodo se ejecutan sus programas,

dnde residen sus ficheros, etc.

Denominamos sistema operativo distribuido el sistema operativo que

engloba y gestiona un entorno distribuido de manera transparente para

el usuario.


Figura 4

Ms adelante tendremos ocasin de ver que se produce una gradacin en el

nivel de transparencia e integracin que va desde sistemas independientes con

servicios sobre el entorno distribuido totalmente visibles para el usuario los

sistemas en red, hasta los sistemas propiamente distribuidos.

A continuacin veremos ejemplos de esta gradacin en los campos de los pro-

cesos, los sistemas de ficheros y la proteccin:


1) La ejecucin de procesos

Cuando se quiere ejecutar una aplicacin en un sistema cerrado no nos preocupa

desde dnde se ejecutar, ni cul o cmo ser el entorno de ejecucin. Esta situa-

cin que parece obvia no lo es tanto cuando en nuestro sistema tenemos una red.

Acto seguido veremos diferentes situaciones que podemos encontrar en funcin

del grado de distribucin que posea el sistema que utilicemos:

a) Desde el sistema local, para ejecutar una aplicacin sobre una mquina

concreta del sistema nos tenemos que conectar mediante una operacin del

tipo telnet que nos abre una sesin completa sobre la mquina remota. Esta

sesin comporta un cambio completo de entorno: desde el punto de vista del

usuario, la mquina local desaparece para ser sustituida por la remota.

b) Desde el sistema local se puede dar la orden de ejecutar una aplicacin con-

creta sobre una mquina remota, por ejemplo mediante la operacin de UNIX

rsh (remote shell). El entorno del usuario contina siendo el de la mquina lo-

cal, mientras que la mquina remota abre una sesin para ejecutar la aplica-

cin. La mquina remota tiene que poder acceder al ejecutable de la aplicacin

desde este nuevo entorno que configura la sesin. Ambos entornos, el de la

aplicacin y el del usuario, son diferentes y disyuntos.

c) Un paso ms en direccin a la distribucin lo constituye el hecho de que

el mismo sistema local tuviese una llamada al sistema crear_ proceso con un pa-

rmetro con el que poder especificar la mquina donde se quiere ejecutar la

aplicacin. Se podra suponer que esta llamada permite la transferencia de par-

te del entorno de ejecucin del usuario local a la mquina remota, como m-

nimo el ejecutable de la aplicacin. La diferencia principal con respecto de la

situacin anterior es que la distribucin la realiza directamente el SO, mientras

que en el caso anterior se haca mediante una aplicacin externa al SO.

d) Finalmente, en el sistema local nos encontramos la llamada al sistema

crear_ proceso, que localiza automticamente la mquina del sistema ms ade-

cuada para realizar la ejecucin y crea un proceso. El entorno de ejecucin es

el mismo que tendra si la ejecucin fuese local y el usuario desconoce qu m-

quina ha ejecutado finalmente la aplicacin.

2) El sistema de ficheros

Cuando se accede a un fichero no se piensa en qu disco est, si est en un

disco o en la memoria, etc. El sistema nos gestiona los ficheros y los discos para

ofrecernos, as, las mejores prestaciones. El hecho de tener la red nos permite

compartir ficheros entre los usuarios de la misma. Cuando trabajamos en red

no sabemos exactamente dnde est el fichero, si lo tenemos que copiar, si se

encuentra en el formato adecuado para poder ser ejecutado, etc.

Veamos qu niveles de servicio nos puede ofrecer el sistema:

a) Si se quiere compartir un fichero remoto del sistema, el usuario tiene que co-

piarlo de manera explcita dentro del sistema local de ficheros y, para hacerlo, se


utiliza una aplicacin especfica como puede ser ftp. En tal caso, los sistemas de

ficheros local y remoto son totalmente disyuntos. La responsabilidad de saber

dnde se encuentran los ficheros, mantener la coherencia entre las copias que se

realicen, hacer conversiones de tipos de datos, etc. pertenece al usuario.

b) El sistema operativo tiene un espacio de nombres que incluye el nmero

de la mquina remota. En este caso, el usuario contina teniendo las mismas

responsabilidades que en el caso anterior, pero no es necesario que ejecute una

aplicacin externa para llevar a cabo la transferencia de ficheros, ya que el SO

se encarga de esto desde las llamadas al sistema.

c) Otra posibilidad nos la ofrecen entornos como el del sistema de ficheros

NFS (Network File System) de UNIX. Ahora el sistema ofrecer al usuario un ni-

co espacio de nombres que integra los sistemas de ficheros de las mquinas de

la red. En este caso, el acceso a ficheros se realiza de manera remota, sin nece-

sidad de transferir una copia de los ficheros al sistema local. El usuario no sabe

dnde se ubican los ficheros y la reparticin de los ficheros entre las mquinas

se efecta en funcin del directorio en el que se crea cada fichero.

d) En un sistema distribuido, el usuario tiene la misma visin que en un sis-

tema aislado. Aqu el sistema se encarga de distribuir los ficheros entre los dis-

cos de la red, replicarlos o moverlos si conviene por motivos de seguridad o de

eficiencia en el acceso.

3) La proteccin

En un sistema cerrado, cada usuario tiene asociado un dominio de proteccin

que se activa cuando se inicia una sesin de trabajo y que le da los derechos

necesarios para llevar a cabo la tarea que tenga asignada. Una vez dentro del

sistema, ya no se tiene que preocupar del domino donde est trabajando y de

si tiene que cambiar o no de dominio.

El hecho de saber en qu dominio nos encontramos depender, como en los

casos que hemos visto hasta ahora, del grado de distribucin del sistema.

a) Una primera opcin es que las mquinas de un entorno distribuido tengan

dominios de proteccin totalmente separados. De este modo, cada mquina

tiene sus usuarios con sus derechos independientes de los del resto. Por ejem-

plo, en UNIX tendramos que hacer un telnet o un rlogin (remote login)para acceder a una mquina remota. En cada mquina podramos tener un

nombre de usuario, una contrasea, un UID y un GID diferentes.

Este hecho tiene una importancia especial si se consideran sistemas con un

cierto grado de distribucin, como un sistema de ficheros con NFS. En estos

tipos de entornos el administrador del sistema ser el encargado de mantener

coherentes los dominios en todas las mquinas del sistema.

b) Una opcin ms avanzada es que los sistemas posean tablas de conversin en-

tre dominios de mquinas diferentes. Cuando un usuario accede a un sistema

remoto no es necesario que se autentifique de nuevo, ya que el sistema local in-

Podis ver los dominios de proteccin en el subapartado 4.1. del mdulo didctico El sistema de ficheros.

Podis ver el UID y el GID en el apartado 4 del mdulo didcticoLa gestin de procesos.

Por ejemplo...

... los ficheros creados por un usuario en una mquina, con un UID y GID propietarios con-cretos, no los reconocera como suyos si accediese desde otra mquina. En el peor de los casos, podran acceder otros usuarios que tuviesen el mismo UID en otra mquina de la red.


forma al sistema remoto de qu usuario se trata y ste lo convierte automtica-

mente en un usuario reconocido por l. UNIX ofrece esta posibilidad mediante

los ficheros denominados hosts.equiv, que contienen las tablas de conversin.

c) Por ltimo, en un sistema distribuido los usuarios tienen un nico domi-

nio, independientemente de la mquina del sistema con que trabajen. UNIX,

mediante los paquetes YP (yellow pages), permite tener un UID y un GID ni-

cos asociados a un nombre de usuario y a una contrasea para todas las m-

quinas del sistema.

4.3. Tipos de sistemas operativos distribuidos

Desde el punto de vista externo, los sistemas operativos distribuidos pueden

ofrecer los mismos servicios que un sistema de propsito general, se pueden

orientar hacia el trabajo interactivo, la mejora de la productividad, la accesibi-

lidad y la tolerancia de fallos, etc.

Desde el punto de vista interno, su estructura se basa en el modelo cliente/servidor,

y utilizan paradigmas de comunicacin que van desde el paso de mensajes hasta

los objetos distribuidos, pasando por las llamadas a procedimientos remotos.

La forma como los sistemas agrupan y gestionan los diferentes servicios nos

permite establecer una clasificacin en los dos tipos siguientes:

1) El modelo monoltico

Podis ver el modelo cliente/servidor en el subapartado 1.1.de este mdulo didctico.

Figura 5


La principal ventaja del sistema monoltico es la integracin en un nico

espacio de todos los servicios, circunstancia que nos permitir llevarlos a cabo

con un coste reducido con respecto a los microncleos, ya que la mayora de

los servidores se encuentran en el mismo espacio que el ncleo, por lo que no

es necesario que se produzcan cambios de espacios de direcciones ni transfe-

rencias de informacin entre procesos.

2) Los modelos microncleo (-kernel)

En este modelo el SO se reduce a un ncleo que proporciona y gestiona los ob-

jetos ms bsicos: los procesos, la memoria y la comunicacin entre procesos.

El resto de los servicios viene proporcionado por servidores externos que se

Este modelo es el que han utilizado los sistemas operativos tradicional-

mente. Un sistema monoltico es un sistema en el que los servicios que

ofrece son gestionados por servidores que en su mayora forman parte

del ncleo del propio sistema y, por tanto, se encuentran dentro de su

espacio protegido. En cada nodo de la red se ejecuta el sistema comple-

to, e internamente los diferentes ncleos se coordinan para llevar a cabo

la gestin de los diferentes recursos.

Lecturas complementarias

Algunos sistemas monolticos son UNIX, Amoeba, Sprite, V kernel, etc. Encontraris ms informacin sobre estos sistemas en la bibliografa:

Milenkovic, M. (1994). Sistemas operativos, conceptos y diseo (2. ed.; trad. de A. Bautista). Madrid: McGraw-Hill.

Tanenbaum, A. (1993). Sistemas operativos modernos (trad. de O. Palmas). Mxico: Prentice Hall Hispanoamericana.

Figura 6


pueden crear y destruir de manera dinmica y que se pueden situar en cual-

quier nodo de la red. Para gestionar las entradas/salidas y proporcionar un me-

canismo de control de los traps y las llamadas al sistema, los microncleos

permiten, bajo el control del sistema de proteccin, que los servidores puedan

utilizar el espacio protegido del sistema. El usuario, en funcin del servidor

que utilice, puede ver diferentes interfaces o, lo que es los mismo, puede tener

la sensacin de trabajar con sistemas operativos diferentes o con subsistemas.

Las principales ventajas de los microncleos son las siguientes:

Son sistemas extraordinariamente abiertos que permiten al usuario adap-

tarse y evolucionar muy bien en entornos distribuidos.

Utilizan servidores externos, y esto les permite adaptarse con facilidad o

emular modelos de sistema para los que hay aplicaciones probadas; en con-

secuencia, permiten volver a aprovecharlas.

Tienen una dimensin reducida que hace posible desarrollarlos y depurar-

los con una mayor facilidad con respecto a los sistemas monolticos. Al

mismo tiempo, esto permite transportarlos a plataformas diferentes con

una mayor facilidad.

As pues, el microncleo es una capa de software que se encuentra en

todas las mquinas del sistema y que cubre el hardware y proporciona

un entorno bsico donde se ejecutan los servidores que configuran los

mencionados subsistemas.

Lectura complementaria

Los microncleos actuales ms conocidos son Mach y Chorus. Encontraris ms informacin sobre estos sistemas en la bibliografa:

Milenkovic, M. (1994). Sistemas operativos, conceptos y diseo (2. ed.; trad.de A. Bautista). Madrid: McGraw-Hill.


Resumen

A lo largo de este mdulo didctico hemos visto diferentes aspectos de los SO

actuales.

En primer lugar hemos introducido dos de los principales conceptos relacio-

nados con los sistemas operativos modernos:

a) El modelo cliente/servidor: este modelo es la base de los sistemas abiertos.

Como mecanismo de comunicacin entre cliente/servidor puede utilizar he-

rramientas de diferente nivel semntico: paso de mensajes, llamadas a proce-

dimientos remotos y objetos distribuidos.

b) Los procesos multiflujo.

En segundo lugar, hemos estudiado las principales caractersticas de los siste-

mas operativos que ahora mencionamos:

a) Los sistemas operativos de tiempo real, que son sistemas orientados a eje-

cutar aplicaciones con fuertes restricciones temporales. Su principal caracters-

tica es que pueden ofrecer mecanismos que permiten realizar una planificacin

en tiempo de las siguientes aplicaciones:

Los procesos con prioridad y residentes en la memoria fsica.

El acceso directo a los drivers de los dispositivos.

La comunicacin mediante memoria compartida.

La comunicacin y la sincronizacin con acontecimientos externos me-

diante mecanismos de seales.

El acceso a un sistema de ficheros optimizado en funcin del tiempo de ac-

ceso.

b) Los sistemas operativos multiprocesador, que son sistemas orientados a

conseguir los objetivos que presentamos a continuacin:

El aumento de la productividad del sistema, entendiendo por productivi-

dad el nmero de procesos ejecutados por unidad de tiempo.

El aumento de la velocidad con que se ejecutan las aplicaciones.


Dentro de estos sistemas podemos encontrar diferentes modelos:

El modelo de supervisores separados.

El modelo maestro/esclavo.

El modelo simtrico.

c) Los sistemas operativos distribuidos, que son una evolucin de los sis-

temas abiertos o sistemas en red. Como hemos visto, son sistemas que gestionan

de manera independiente todos los recursos de una red. Su flexibilidad y capa-

cidad de reconfiguracin y crecimiento escalonado, as como la facilidad para

aplicar tcnicas que permiten la tolerancia a fallos, los convierten en sistemas

muy atractivos. Por otra parte, sus principales inconvenientes son la dificultad

que presentan para gestionar el estado global del sistema y el hecho de que hay

que prever el proceso de recuperacin de las posibles cadas de la red.

Los principales modelos de sistema distribuido son los dos siguientes:

El modelo monoltico.

El modelo microncleo.


Actividades

1. Analizad las caractersticas de Windows 95 y de UNIX relacionadas con los tipos de siste-mas operativos que hemos estudiado.

2. Analizad qu servidores tiene en marcha la versin de UNIX que utilizis para las prcticas.

3. Observad las seales (signals) que ofrece UNIX y analizad si son adecuadas para un sistemaoperativo de tiempo real.

Glosario

entorno distribuidoConjunto de sistemas interconectados con una red que son capaces de cooperar y comuni-carse gracias a esta red y al software que la gestiona.

maestro/esclavoModelo de SO multiprocesador en el que un procesador, el maestro, se encarga de ejecutar elsistema operativo y el resto de los procesadores, los esclavos, se dedica a ejecutar los procesosque el maestro le encarga.

microncleoModelo de SO utilizado principalmente por sistemas operativos distribuidos. En este modelo,el SO se reduce a un ncleo que proporciona y gestiona los objetos ms bsicos: procesos,gestin de memoria y comunicacin entre procesos. El resto de los servicios los proporcionanservidores externos que se pueden crear y destruir de manera dinmica y que pueden estarsituados en cualquier nodo de la red.

modelo cliente/servidorParadigma de programacin en el que intervienen un cliente que solicita un servicio y el ser-vidor que lo proporciona. La comunicacin entre cliente y servidor se efecta mediante me-canismos basados en el paso de mensajes. Este modelo es la base de los sistemas abiertos ydistribuidos.

modelo simtricoModelo de SO multiprocesador en el que todos los procesadores tienen las mismas compe-tencias, todos pueden ejecutar el sistema.

procesos multiflujoProcesos con ms de una secuencia de ejecucin en los que cada flujo se caracteriza por unapila, unos registros del procesador y un contador de programa. El resto de los elementosque configuran el entorno de ejecucin son compartidos con el resto de los flujos del pro-pio proceso.

SO abiertoCaso contrario a un SO cerrado, es decir, en red. Ved SO en red.

SO cerradoEn el marco de este mdulo, sistema aislado sin red. En un sentido ms amplio de la palabraaislado, se podra decir que es un sistema que no utiliza aplicaciones, protocolos, etc., es de-cir, estndar y, por tanto, slo puede utilizar aplicaciones nativas de su sistema.

SO de tiempo realSistema que se orienta a ejecutar aplicaciones con fuertes restricciones temporales que puedeofrecer mecanismos que permitan realizar una planificacin en tiempo de las aplicaciones.

SO distribuidoSistema operativo que engloba y gestiona un entorno distribuido de manera transparentepara el usuario.

SO en redSistema operativo independiente con servicios sobre el entorno distribuido visibles para elusuario.

SO monolticoSistema operativo en el que los servicios que ofrece estn gestionados por servidores que ma-yoritariamente forman parte del ncleo del propio sistema y, en consecuencia, se encuentrandentro de su espacio protegido.


SO multiprocesadorSistema operativo que gestiona una arquitectura multiprocesador.

supervisores separadosModelo de SO multiprocesador en el que cada procesador tiene su sistema operativo inde-pendiente que funciona como un sistema casi aislado.

Bibliografa

Bibliografa bsica

Milenkovic, M. (1994). Sistemas operativos, conceptos y diseo (2. ed.; trad. de A. Bautista).Madrid: McGraw-Hill.

Silberschatz, A.; Peterson, J.; Galvin, P. (1994). Sistemas operativos, conceptos fundamen-tales (3. ed.; trad. de E. Morales). Wilmington: Addison-Wesley Iberoamericana.

Tanenbaum, A. (1993). Sistemas operativos modernos (trad. de O. Palmas). Mxico: PrenticeHall Hispanoamericana.

Bibliografa complementaria

Singhal, M.; Shivaratri, N. (1994). Advanced Concepts in Operating Systems, Distributed, Da-tabase and Multiprocessors Operating Systems. Nueva York: McGraw-Hill.

Couloris, G.; Dollimore, J.; Kindberg, T. (1995). Distributed Systems, Concepts and Design(2. ed.). Wokingham: Addison-Wesley.

sistemas operativos mod8

Documents