Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Stallings W. Sist Op

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 110

nidad .

istemas
operativos.

Stallings William. Introducción a los Sistemas Operativos. pp. 47 - 155. En: Sistemas
Operativos. Prentice Hall. 2da Edición. España. 1997.
,.

CAPITU LO 2

• I ntroducci6n a
los Sistemas Operativos

EI estudio. de lo.S sistemas o.perativo.s va a co.menzar co.n una breve histo.ria. Esta histo.ria es
interesante en sf misma, a la 'vez que o.frece una panonimica de los principio.s en que se ba- .
san los sistemas operativos.
EI capitulo co.mienza con una ojeada a las funciones y objetivo.s de los sistemas o.pera­
tivos, 10 que servini para definir los requisitos que debe satisfacer el disefio de un sistema
,~ operativo. Luego se vera como han evolucionado los sistemas o.perativos, desde los pri­
mitivos sistemas de proceso. por lotes hasta los sofisticados sistemas multimodo y mul­
tiusuario. En el resto del capitulo se analiza la historia y las caracteristicas generales de
tres sistemas operativo.s que servinin de ejemplo a 10 largo dellibro. Es una feliz coinci­
dencia que estos no solo sean quiza los tres mejores ejemplos que podrlan usarse en este
libro, sino que ademas recogen Io.S Io.gros mas importantes en la historia de los sistemas
operativos.

2.1
• FUNCIONESY OBJETIVOS DE LOS SISTEMAS OPERATIVOS •

Un sistema operativo. es un programa que controla la ejecucion de los programas de aplica­


cion y que actua como interfaz entre el usuario de un computador y el hardware de la
misma. Puede considerarse que un sistema operativo tiene tres objetivos 0 lleva a cabo tres
funciones:
• Comodidad: Un sistema operativo hace que un computador sea mas comoda de utilizar.
• £ficiencia: Un sistema operativo permite que los recursos de un sistema informatico~se
apro~echen de una manera mas eficiente. .
• Capacid04 de evoluci6n: Un sistema operativo debe construirse de modo qilepermita el
desarrollo efectivo, la verificadoll Y la introduccion de nuevas funciones en e1 sistema.y,

-
a la vez, no interferir en lo.S servicio.s "ue brinda....
A continuacion se van a tratar estos tres aspectos de los sistemas operativos.

47


\ f "
48 Introducci6n a los sistemas operativos

EI Sistema Operativo como Interfaz Usuario/Computadora


El hardware y el software que se utilizan para proveer de aplicaciones a los usuarios pueden
contemplarse de forma estratificada 0 jenirquica, como se muestra en la figura 2.1. Al usuario de
estas aplicaciones se Ie llama usuario final y, generalrnente, no tiene que ocuparse de la arquitec­
tura del computador. POI tanto, .el usuario final ve a1 sistema informatico en terminos de aplicacio­
nes. Las aplicaciones pueden construirse con un lenguaje de programacion y son desarrolladas por
programadores de aplicaciones. Si se tuviera que desarrollar un programa de aplicacion como un
conjunto de instrucciones maquina que sean del todo responsables del control del hardware, se
. teniJria una tarea abrumadora y compleja Para facilitar esta tarea, se ofrecen una serle de progra­
mas de sistemas. Algunos de estos programas se denominan utilidades e implementan funciones
muy utilizadas que ayudan a la creacion de los programas, la gestion de los archivos y el control
de los dispositivos de EIS. Los programadores hacen uso de estos servicios en el desarrollo de una
aplicacion y esta, mientras se esta ejecutando, invoca a estas utilidades para llevar a cabo ciertas
acciones. EI programa de sistemas mas importante es el sistema operativo. El sistema operativo
oculta al programador los detalles del hardware y Ie proporciona una !nt~rfaz cOmod,wara utilizar
el sistema. Acrua como mediador, facilitandole a1 programador y a los programas de aplicacion el
acceso y uso de todas esas caracterfsticas y servicios.
De forma resumida, un sistema operativo ofrece servicios en las areas siguientes:
• CreaciOn de programas: El sistema operativo ofrece una variedad de caracterfsticas y servicios,
tales como los ~res V los depuradt1res...(debugw.,v, para ayudar al programador en la crea­
cion de programas. Normalmente, estos servicios estan en forma de programas de utilidad que
no formah realmente parte del sistema operativo, pero que son accesibles a traves del mismo.
• FJecuci6n de programas: Para ejecutar un programa se necesita un cierto numero de ta­
teas. L& mstrucciones y los datos se deben cargar en la memoria principal, los archivos y
los dispositivos de E/S se deben inicializar y se deben preparar otros recursos. EI sistema
operativo administra todas estas tareas para el usuario.

Final

Programador •
Programas de
Aplicad6n

Utilidades

Sistema Operativ~

Hardware de 1a computadora

FIGURA 2.1 Niveles y vistas de un sistema informatico .

>
It....

Funciones y objetivos de los sistemas operativos 49

• Acceso a los disposirivos de EIS: Cada dispositivo de E/S requiere un conjunto propio y
peculiar de instrucciones 0 de senales de control para su funcionamiento. El sistema ope­
rativo tiene en cuenta estos detalles de modo que el programador pueda pensar en forma
de lecturas y escrituras simples.
• Acceso controlado a los archivos: En el caso de los archivos, el control debe incluir una
comprension, no solo de la naturaleza del dispositivo de E/S (controlador de disco, con­
trolador de cinta) sino del fonnato de los archivos y del medio de almacenamiento. Una
vez mas, es el sistema operativo el que se encarga de los detalles. Es mas, en el,caso de sis­
.It
temas con varios usuarios trabajando simulU'ineamente, es el sistema operativo el que
brinda los mecanismos de control para controlar el acceso a los archivos.
• Acceso 01 sisrema: En el caso de un sistema compartido 0 publico, el sistema operativo
control a el acceso al sistema como un todo y a los ,ecursos especfficos del sistema. Las
funciones de acceso pueden brindar proteccion, a los recursos y a los datos, ante usuarios
no autorizados y debe resolver los contlictos en la propiedad de los recursos.
• Detecci6n y respuesta a errores: Cuando un sistema informatico esta en funcionamiento
pueden producirse varios elTores, Entre estos se incluyen los errores intemos y externos
del hardware, tales como los elTorcs de memoria, fallos 0 mal funcionamiento de disposi­
tivos y distintos tipos de elTores de software, como el desbordamiento aritmetico, el in­
tento de acceder a una posicion prohibida de memoria y la incapacidad del sistema opera­
tivo para satisfacer la solicitud de una aplicacion. En cada caso, el sistema operativo debe
dar una respUesta que elimine la condicion de error con el menor impacto posible sobre las
<I
aplicaciones que estan en ejecucion. La respuesta puede ser desde terminar el programa
que produjo el en'or, hasta reintentar la operacion 0, simplemente, informar del error a la
aplicacion.
• Contabilidod: Un buen sistema operativo debe recoger estadlsticas deutilizacion de los
diversos recursos y supervisar los parametros de rendimiento tales como el tiempo de res­
puesta, Para cualquier sistema, esta informacion es util para anticiparse a la necesidad de
mejoras futuras y para ajustar el sistema y aSI mejorar su rendimiento. En un sistema mul­
tiusuario, la informacion puede ser utilizada con propos ito de cargar en cuenta.
EI sistema operativo como administrador de recursos
~, Un computador es un conjunto de recursos para el traslado, almacenamiento y proceso de
datos y para el control de estas funciones. EI sistema operativo es el responsable de la ges­
tion de estos recursos.
i,Se puede afirmar que es el sistema operativo el que control a el traslado, almacenamiento
yproceso de los datos? Desde un punto de vista, la respuesta es afirmativa: Administrando
los recursos del computador, el sistema operativo tiene el control sobre las funciones basicas
de la misma. Pero este control se ejerce de una manera curiosa. Normalmente, se piensa en
un mecanismo de control como algo extemo a 10 control ado 0, al menos, como algo distinto
y una parte separada de 10 controlado. (Por ejemplo, un sistema de calefaccion de una estan­
cia es controlado por un tem10stato, que es algo completamente diferente de los aparatos de
generaci6n de calor y de distribucion del calor). Este no es el caso de un sistema operativo,
que no es habitual como mecanismo de control en dos aspectos:
,.. • El sistema operativo funciona de la misma manera que el software nOlmal de un compu­
tador, es decir, es un programa ejecutado por el procesador.
r

50 Introducci6n a los sistemas operativos

• EI sistema operativo abandona con frecuencia el control y debe depender del procesador
para recuperarlo.
EI sistema operativo es, de hecho, nada mas que un prograrna del computador l . Como
otros prograrnas de computador, da instrucciones al procesador. La diferencia clave esta en
el prop6sito del prograrna. EI sistema operativo . dir!~ al procesador en el empleo.de otros
recurs os del sistemay en e1c:o.!ltr9LdeltiempQde ejecudon de, QU;oS PFogrf!.lll;\S. Pero para
. que el procesador pueda hacer estas cosas, debe cesar la ejecuci6n del prograrna del sistema
operativo y ejecutar otros prograrnas. As! pues, el sistema operativo cede el control al pro­
cesador para hacer alglln trabajo "l1til" y luego 10 retoma durante el tiempo suficiente para
preparar el procesador para llevar a cabo la siguiente parte del trabajo. Los mecanismos in­
volucrados se iran esclareciendo a medida que se avance en el capftulo.
La figura 2.2 propone los recurs os principales que son administrados por el sistema ope­
rativo. Una parte del sistema operativo esta en la memoria principaL En esta parte esta el nll­
cleo (kernel), que incluye las funciones utilizadas con mas frecuencia en el sistema opera­
tivo y, en un momento dado, puede incluir otras partes del sistema operativo que esten en
uso. EI resto de la memoria principal contiene datos y otros prograrnas de usuario. Como se

Dispositivos de E/S

FIGURA 2.2 EI sistema op~rativo como administrador de recursos

I Una cantidad creciente de sistemas operativos toma partido cada vez mas por el firmware en vez de por el software. Esto
no altera los argumentos de modo sensible.
Evolud6n de los sistemas operativos 51

vera, la asignacion de este recurso (la memoria principal) es controlada conjuntamente por
el sistema operativo y por el hardware de gestion de memoria en el procesador. El sistema
operativo decide cuando puede utilizarse un dispositivo de E/S por parte de un programa en
ejecucion y controla el acceso y la utilizacion de los archivos. El procesador es, en sf mismo,
un recurso y es el si~teril<:i operativo el que debe determinar cuanto tiempo del procesador
debe dedicarse a la ejecucion de un programa de usuario en particular. En el caso de siste­
mas multiprocesador, la decision debe distribuirse entre todos los procesadores.

Facilidad de evolucion de un sistema operativo


Un sistema operativo importante evolucionara en el tiempo por una serie de razones:
• Actualizaciones del hardware y nuevos tipos.de hardware: Por ejemplo, las primeras ver­
siones de UNIX y OS/2 no empleaban mecanismos de paginacion, porque funcionaban en
maquinas sin hardware de paginacion2• Las versiones mas recientes se han modificado
. para aprovechar las capacidades de paginacion. Ademas, el empleo de terminales graficos
y terminaies de pantalla completa, en Iugar de los terminales de lineas, pueden influir en
el disefio de los sistemas operativos. Por ejemplo, un terminal de estos puede permitirle al
usuario ver diferentes aplicaciones al mismo tiempo, a traves de '.'ventanas" en la pantalla.
Esto necesita un soport{( mas sofisticado en el sistema operativo .
• Nuevos servicios: Como respuesta a las demandas del usuario 0 a las. necesidades de los ad­
ministradores del sistema, el sistema operativoampliara su oferta de servicios. Por ejemplo,
si se determina que es difkil de mantener un buen rendimiento para los usuarios con las he­
rramientas existentes, se deben afiadir nuevas medidas y herramientas de control al sistema
operativo. Otro ejemplo es el de las nuevas aplicaciones que exigen el uso de ventanas en la
pantalla. Esta caracteristica requiere actualizaciones mayores en el sistema operativo.
• Correcciones: Desafortunadamente, el sistema operativo tiene fallos que se descubriran
con el curso del tiempo y que es necesario corregir. Por supuesto, estas correciones pue­
den introducir nuevos fallos a su vez y asf sucesivamente.
La necesidad de hacer cambios en un sistema operativo de forma regular introduce ciertos
requisitos en el disefio. Una afirmacion obvia es que el sistema debe tener una construccion
modular, con interfaces bien definidas entre los modulos y debe estar bien documentado.
Para programas grandes, como normalmente son los sistemas operativos actuales, no es ade­
cuado 10 que podria denominarse modularizacion elemental [DENN80a]. Es decir, debe ha!
cerse mucho mas que dividir simplemente un programa en subrutinas. Se vol vera a este
tema mas adelante en el capitulo.

2.2
EVOLUCION DE LOS SISTEMAS OPERATIVOS
Para intentar comprender los requisitos basic os de un sistema operativo y el significado de
las caracteristicas principales de un sistema operativo contemporaneo, resulta util considerar
como han evolucion~do los sistemas operativos a 10 largo de los afios.

2 La paginacion se introducira de fonna breve mas adelante en este mismo capitulo y se discutini en detalle en los capitulos 6 y 7.
,.......

52 Introducci6n a los sistemas operativos

Proceso en serie
En los primeros computadores, de finales de los 40 hasta mediados de los 50, el programa­
dor interactuaba directamente con el hardware; no habia sistema operativo. La operaci6n
con estas maquinas se efectuaba desde una con sola consistente en unos indicadores lumino­
sos, unos conmutadores, algun tipo de dispositivo de entrada y una impresora. Los progra­
mas en c6digo maquina se cargaban a traves del dispositivo de entrada (un lector de tarjetas,
por ejemplo). Si se detenia el programa por un error, la condici6n de error se indicaba me­
diante los indicadores luminosos. EI programador podia examinar los registros y la memo­
ria principal para determinar la causa del error. Si el programa continuaba hasta su culmina­
ci6n normal, la salida apareceria en la impresora.
Estos primeros sistemas presentaban dos px:oblemas principales:
• Planificacion: La mayoria de las instalaciones empleaban un formulario de reserva de
tiempo de maquina. Normalmente, un usuario podia reservar bloqlies de tiempo en multi­
plos de media hora 0 algo por el estilo. Un usuario podia reservar una hora y terminar a los
45 minutos; esto daba como resultado un desperdido del tiempo del computador. Por el
contrario, el usuario podia tener dificultades, no terminar en el tiempo asignado y verse
forzado a parar sin haber sol.ucionado el problema. .
• Tiempo de preparacion: Un programa sencillo, llamado trabajo, cargaba un compilador y
un programa en lenguaje de alto nivel (programa fuente) en la memoria, salvaba el pro­
grama compilado (program a objeto) y luego montaba y cargaba el progf<m1a objeto junto
con las fllndones comunes. Cada uno de estos pasos podia implicar fl10ntarY desmontar
cintas 0 preparar paquetes de tarjetas. Si Se producia un error, el infortunado usuario tenia
que volver a1 inici() de este proceso de preparaci6n. De este modo, se perdia un tiempo
considerable en preparar un programa para su ejecuci6n.
Este modo de operad6n podria denominarse proceso en serie porque refleja el hecho de
que los usuarios tenian que acceder al computador en serie. Con el paso del tiempo se desa­
. rrollaron varias herramientas de software de sistemas para intentar hacer mas eficiente este
proceso en serie. Entre estas se incluian bibliotecas de fundones comunes, montadores, car­
gadores, depuradores y rutinas de manejo de E/S que estaban disponibles como un software
comun para todos los usuarios.
.
Sistemas sencillos de proceso por lotes
Las primeras maquinas eran muy caras y, por tanto, era importante maximizar la utilizaci6n de
las mismas. EI tiempo desperdiciado por la planificaci6n y la preparaci6n era inaceptable.
Para mejorar el uso, se desarroll6 el concepto de sistema operativo por lotes
(batch). EI primer sistema operativo por lotes fue desarrollado a mediados de los 50
por la General Motors para usar en un IBM 701 [WEIZ81]. Este concepto fue refinado
posteriormente e implementado en un IBM 704 por una serie de clientes de IBM. A
principios de los 60, un conjunto de constructores ya hablan desarrollado sistemas
operativos por lotes para sus computadores. IBSYS, el sistema operativo de IBM para
las computadores 7099/7094, es particularmente notable por su amplia influencia en
otros sistemas.
La idea central que esta detras del esquema sencillo de proceso por lotes es el usn de un
elemento de softwaTp,.~onocido como monitor. Con el uso de esta clase de-sistema opera­
Evoluci6n de los sistemas operativos 53

tivo, los usuarios ya no tenian acceso directo ala maquina. En su lugar, <=1 usuario debfa en­
tregar los trabajos en tarjetas 0 en cinta al operador del computador, quien agrupaba secuen­
cialmente los trabajos por Iotes y ubicaba los lotes enteros en un dispositivo de entrada para
su empleo por parte del monitor. Cada programa se construia de modo tal que volviera al
monitor al terminar suprocesamiento y, en ese momento, el monitor comenzaba a cargar au­
tomaticamente el siguiente programa.
Para entender como funciona este esquema, se va aver desde dos puntos de vista: el del
monitor y el del procesador. Desde el punto de vista del monitor, el es quien control a la se­
cuencia de sucesos. Para que esto sea posible, gran parte del monitor debe estar siempre en
memoria principal y disponible para su ejecucion (figura 2.3). Esta parte del monitor se co­
noce como monitor residente. El resto del monitor consta de utilidades y funciones comu­
nes que se cargan como subrutinas en los programas de los usuarios al comienzo de cual­
quier trabajo que las necesite. ~l monitor lee los trabajos uno a uno del dispositivo de
entrada (normalmente, un lector de tarjetas 0 una unidad de cintamagnetica). A medida que
10 lee, el trabajo actual se ubica en la zona del programa de usuario y el control pasa al tra­
bajo. C}lando el trabajo termina, ~e devuelve el control al monitor, quien lee inmediatamente
un nuevo trabajo. Los re~ultados de cada trabajo se imprimen y entregan al usuario.
Considerese ahora esta secuencia desde el punto de vista del procesador. En un cierto mo­
mento, el procesador estara ejecutando instrucciones de la zona de memoria principal que
contiene al monitor. Estas instrucciones hacen que el trabajo siguiente sea lefdo en otra zona
de la m~moria principal. Una vez que el trabajo se ha lefdo, el procesador encuentra en el
monitor una instrucci6n de desvfo que ordena al procesador continuar la ejecucion en el ini­
cio del programa de usuario. EI procesador ejecuta entonces las instrucciones del programa
de usuario hasta que encuentre una condicion de finalizaci6n 0 de error. Cualquiera de estos

Tratainiento de
Interrupciones

Controlador.es de
Dispositivos
Monitor
Secuenciamiento
de Trabajos
Interprete del

Lenguaje de

Control

-Umite

Zona del
Programa de
Usuario

FIGURA 2.3 Di!!posid6n de la memoria con un monitor residente [SllB94]



54 Introducci6n a los sistemas operativos

dos sucesos provocan que el procesador vaya a por la instruccion siguiente del programa
monitor. De este modo, la frase "el control se Ie pasa al trabajo" quiere decir simplemente
que el procesador pasa a leer y ejecutar instrucciones del programa de usuario, mientras que
la frase "el control vuelve al monitor" quiere decir que el procesador pasa ahora a leer y eje­
cutar las instrucciones del programa monitor.
Debe quedar claro quees el monitor el que gestiona el problema de la planificacion. Se
pone en cola un lote de trabajos y estos son ejecutados tan nipido como es posible, sin que
haya tiempo alguno de desocupacion.
l,Que ocurre con la preparacion de los trabajos? EI monitor tambien se encarga de esto.
Con cada trabajo, se incluyen instrucciones de una forma primitiva de lenguaje de control
de trabajos (JCL, Job Control Language), que es un tipo especial de lenguaje de program a­
don empleado para dar instrucciones al monitor. La figura 2.4 muestra un ejemplo sencillo
con entrada de trabajos des de tarjetas. En este ejemplo, el usuario envia un programa escrito
en FORTRAN junto a unos datos que se utilizaran en el programa. Ademas de las tarjetas de
FORTRAN y de datos, el paquete incluye instrucdones de control de trabajos, que se deno­
tan mediante un signo dolar ($) al comienzo.
Para ejecutar el trabajo, el monitor lee la tarjeta $FfN y carga el compilador adecuado
desde el dispositivo de 'almacenamiento masivo (generalmente una dnta). EI compilador
traduce el programa de usuario en codigo objeto, que se almacena en memoria 0 en el dis­
positivo de almacenamiento. Si se carga en memoria, la operacion es conodda como "com­
pilar, cargar y arrancar" (compile, load, and go). Si se almacena en cinta, entonces se re­
quiere la tarjeta $LOAD. Esta tarjeta es leida por el monitor, quien retoma el control despues
de la operacion de compilacion. El monitor llama al cargador, que carga el program a objeto
en memoria en ellugar del compilador y Ie transfiere el control. De esta manera, un seg­
men to grande de memoria se puede compartir entre diferentes subsistemas, aunque en cada
momento solo uno de ellos tiene que estar presente y ejecutandose.

Datos para el Programa

Programa a Compilar ~

FIGURA 2.4 Paquete de tarjetas para un sistema sencillo por lotes


Evolucion de los sistemas operativos 55

Durante la ejecucion del programa de usuario, cada instruccion de entrada origina la lec­
tura de una tarjeta de datos. La instruccion de entrada en el programa del usuario hace que se
invoque una rutina de entrada, que forma parte del sistema operativo. La rutina de entrada se
asegura de que el programa de usuario no ha lefdo accidental mente una tarjeta JCL. Si esto
sucede, se produce un error y el control se transfiere al monitor. Al terminar un trabajo, con
o sin exito, el monitor recorre las tarjetas de entrada hasta encontrar la proxima tarjeta JCL.
De este modo, el sistema se protege contra un programa que tenga tarjetas de datos de mas
ode menos.
Se comprobara que el monitor 0 el sistema de proceso por lotes es simplemente un pro­
grama de computador. Se basa en la capacidad del procesador para traer y ejecutar instruc­
ciones desde varias zonas de la memoria principal y asf apoderarse y ceder el control de
forma altema. Para esto serfan convenientes algunas otras caracterfsticas del hardware, entre
las que se encuentran las siguientes:
• Proteccion de memoria: Mientras el program a de usuario este ejecutandose, no debe mo­
dificar la zona de memoria en la que esta el monitor. Si se hace un intento tal, el hardware
del procesador debenl detectar el error y transferir el control al monitor. El monitor abor­
tara entonces el trabajo, imprirninl el mensaje de error y cargara el siguiente trabajo.
• Temporizador: Se utiliza un temporizador para impedir que un solo trabajo monopolice el
sistema. El temporizador se lanza al comenzar cada trabajo. Si expira el tiempo, se produ­
cira una interrupcion y el control volveni al monitor.
• Instrucciones Privilegiadas: Ciertas instrucciones son designadas como privilegiadas y
pueden ser ejecutadas solo por el monitor. Si el procesador encuentra una instruccion tal,
cuando esta ejecutando el programa del usuario, se producira una interrupcion de error.
Entre las instrucciones privilegiadas se encuentran las instrucciones de ElS, de forma que
el monitor retenga el control de todos los dispositivos de E/S. Esto impide, por ejemplo,
que un programa de usuario lea accidentalmente instrucciones de control que son del tra­
bajo siguiente. Si un programa de usuario desea realizar una E/S, debe solicitarle al moni­
tor; que haga la operacion por 61. Si el procesador encuentra una instruccion privilegiada
cuando esta ejecutando un programa de usuario, el hardware del procesador la considera
como un error y transfiere el control al monitor.
• Interrupciones: Los primeros modelos de computadores no tenian esta capacidad. Esta ca­
racterfstica aporta al sistema operativo mas flexibilidad para ceder y retomar el control de '
los programas usuarios.
Naturalmente, se puede construir un sistema operativo sin estas caracterfsticas, pero los
fabric antes de computadores comprobaron rapidamente que los resultados eran caoticos y,
por tanto, inc1uso los sistemas operativos por lotes mas primitivos ya disponian de estas ca­
racterfsticas en e] hardware. Por otro lado, hay que decir que el sistema operativo mas utili­
zado del mundo, el PC-DOS/MS-DOS, no dispone de proteccion de memoria ni de instruc­
ciones privilegiadas de E/S. Sin embargo, como este sistema esta destinado a computadores
personales de un solo usuario, los problemas que se pueden originar son menos graves.
En un sistema operativo por lotes, el tiempo de maquina se reparte entre la ejecucion de
programas de usuario >' la ejecucion del monitor. Asi se tienen dos p6rdidas: se entrega al
monitor cierta cantidad de memoria principal y este consume cierto tiempo de la maquina.
Ambas p6rdidas son una forma de sobrecarga. Aun con esta sobrecarga, los sistemas opera­
tivos sencillos por lotes mejoran el uso del computador.

56 Introduccion a los sistemas operativos

Sistemas por lotes con multiprogramacion


Aun con el secuenciamiento automatico de los trabajos ofrecido por un sistema operativo
sencillo por lotes, el procesador esta desocupado a menudo. El problema es que los disposi­
tivos de E/S son lentos comparados con el procesador. La figura 2.5 detalla un calculo re­
presentativo. Los numeros corresponden a un programa que procesa un archivo de registros
y ejecuta, en promedio, 100 instrucciones de maquina por cada registro. En este ejemplo, el
computador gasta mas del 96% del tiempo esperando a que los dispositivos de E/S terminen
de transferir sus datos. La figura 2.6a ilustra esta situacion. El procesador gasta parte del
tiempo ejecutando hasta que encuentra una instruccion de E/S. Entonces debe esperar a que
conc1uya la instrucci6n de E/S antes de continuar.
Esta ineficiencia no es necesaria. Se sabe que hay memoria suficiente para almacenar el
sistema operativo (el monitor residente) y un programa de usuario. Supongase que hay es­
pacio suficiente para el sistema operativo y dos programas usuarios. Ahora, cuando un tra­
bajo necesite esperar una E/S, el procesador puede cambiar al otro trabajo, que probable­
mente no estara esperando a la E/S (figura 2.6b). Ademas, se podria ampliar la memoria para
almacenar tres, cuatro 0 mas program as y conmutar entre todos ellos (figura 2.6c). Este pro­
ceso es conocido como multiprogramacion 0 multitarea. Este es el punto central de los
sistemas operativos modernos. .
Para ilustrar el beneficio de la multiprogramacion, considerese un ejemplo basado en uno
de Turner [,I:URN86]. Sea un computador con 256K palabras de memoria disponible (no
utilizadas por el sistema operativo), un disco, una terminal y una impresora. Tres programas,
TRABAJOl, TRABAJ02 YTRABAJ03, son enviados para su ejecucion al mismo tiempo,
con los atributos que se enumeran en la tabla 2.1. Se suponen unos requisitos minimos de
procesador para el TRABAJ02 y el TRABAJ03 y un uso continuado del disco y de la im­
presora por parte del TRABAJ03. En un sistema sencillO por lotes, estos trabajos serian eje­
cutados en secuencia. As! pues, el TRABAJOI tetmina en 5 minutos. El TRABAJ02 debe
esperar a que transcurran esos 5 minutos y terminar 15 minutos despues. El TRABAJ03 co­
mienza'despues de los 20 minutos para terminar 30 minutos despues del momento en que
fue lanzado. La utilizacion media de los recursos, la productividad y los tiempos de res­
puesta se ilustran en la columna de monoprogramacion de la tabla 2.2. El uso de dispositi­
vos queda ilustrado en la figura 2.7. Es evidente que hay una infrautilizaci6n neta de todos
los recursos cuando se promedian los tiempos de uso en el periodo exigido de 30 minutos. ~

Supongase ahora que los trabajos se ejecutan concurrentemente en un sistema operativo


con monoprogramacion. Como hay poca contenci6n de recursos entre los trabajos, cada uno
de los tres puede ejecutarse en un tiempo cercano al minima mientras coexiste con los otros
en el computador (suponiendo que a TRABAJ02 y TRABAJ03 se les adjudica tiempo su-

Leer un registro 0,0015 segundos


Ejecutar 100 instrucciones 0,000 I segundos
Escribir un registro 0,0015 segundos
TOTAL 0,0031 segundos
Porcentaje de Utilizaci6n de la CPU 0,0001/0,0031 =0,032 =3,2%
FIGURA 2.5 Ejemplo de u.tilizadon del sistema
Evolud6n de los sistemas operativos 57

Prograrna A ~
·s Jecu-
Esperar
(a) Monoprograrnaci6n

~
Ejecu-
tar Esperar

Esperar Esperar

Esperar Esperar
Tiernpo •

(b) Multiprograrnaci6n con dos prograrnas

Prograrna A I tar Esperar I tar I E_s-"-p_er_a_r_ _ __

Esperar Esperar

PrograrnaC ____L -__~____~_____=~==~_________L_=~L___~~~___

Esperar Esperar
Tiernpo ..

(C) Multiprograrnaci6n can tres prograrnas


FIGURA 2.6 Multiprogramad6n

TABLA 2.1 Atributos de Ejemplo de la Ejecucion de un Programa


TRABAjOl TRABAj02 TRABAj03
Tipo de trabajo Calculo intensivo E/S intensiva E/S intensiva
Duraci6n 5 min 15 min 10 min
Memoria exigida 50 K lOOK 80 K
iNecesita diSCO? No No Sf
lNecesita terminal? No Sf No
,;Necesita impresora? No No Sf
,...

58 Introducci6n a los sistemas operativos

TABLA 2.2 Efectos de la Multiprogramaci6n sobre la Utilizaci6n de Recursos


Monoprogramacion Multiprogramacion
Uso del procesador 17% 33%
Uso de la memoria 30% 67%
Uso del disco 33% 67%
Uso de la impresora 33% 67%
Tiempo transcurrido 30 min 15 min
Tasa de productividad 6 trabajos/hora 12 trabajoslhora
Tiempo medio de respuesta 18 min 10 min

100

CPU

o
100

Memoria

a
100

Disco

a
100

Terminal

a
100

Impresora

o
Historia del ITRABAJO 1
• •
TRABAJO 2 TRABAJO 3
Trabajo
o 5 10 15 20 25 30
FIGURA 2.7 Histograma de utilizaci6n con monoprogramaci6n [TURN861
Evoluci6n de los sistemas operativos 59

ficiente de procesador para mantener activas sus operaciones de E/S). EI TRABAJOI re­
querin'i 5 minutos para terminar, pero al finalizar este tiempo, el TRABAJ02 estara termi­
nado en una tercera parte y el TRABAJ03 estara ala mitad. Los tres trabajos habran termi­
nado dentro de 15 minutos. La mejora es evidente cuando se examina la columna de
multiprogramaci6n de la tabla 2.2, obtenida del histograma que se muestra en la figura 2.8.
Al igual que un sistema sencillo por lotes, un sistema por lotes con multiprogramaci6n tiene
que depender de ciertas caracteristicas del hardware del computador. La caracteristica adicio­
nal mas notable y uti! para la multiprogramaci6n es que el hardware respalde las interrupcio­
nes de E/S y el DMA. Con E/S dirigida por interrupciones y con DMA, el procesador puede
enviar una orden de E/S para un trabajo y continuar con la ejecuci6n de otro, mientras la E/S
~~. efectuada por el controlador del dispositivo. Cuando termina la operaci6n de E/S, el proce­

100

CPU

a
100

Memoria

a
100

Disco

a
100

Terminal

a
100

Impresora

a
TRABAJO 1
Historia del I TRABAJO 2
Trabajo • TRABAJO 3 •

a 5 10 15

FIGURA 2.6 Histogramade utilizaci6n con multiprogramaci6n [TURN66]


60 Introduccion a los sistemas operativos

sador es interrumpido y el control pasa a un programa de tratamiento de interrupdones del sis­


tema operativo. El sistema operativo Ie pasa entonces el control a otro trabajo.
Los sistemas operativos con multiprogramacion son bastante mas sofisticados en compa­
racion con los sistemas de monopro'gramacion 0 de un solo programa. Para tener varios tra­
bajos listos para ejecutar, estos deben mantenerse en la memoria principal, 10 aIle requiere
cierto tipo de gestion de memoria. Ademas, si hay varios trabajos listos para ejecutarse, el
procesador debe decidir cual de ellos va a ejecutar, 10 que reQuiere un algoritmo de planifi­
cacion. Estos conceptos seran discutidos mas adelante en este capitulo.

Sistemas de tiempo compartido


Con el uso de la multiprogramacion, el tratamiento por lotes puede llegar a ser bastante efi­
ciente. Sin embargo, para muchas tareas, es conveniente suministrar un modo en que. el
usuario interactue directamente con el computador. De hecho, para algunos trabajos, tales
como el proceso de transacciones, este modo interactivo es fundamental.
Hoy en dfa, los requisitos de un servicio de computacion interactiva pueden y suelen lle­
varse a cabo con el empleo de un computador dedicada. Esta opcion no estaba disponible en
los afios 60, cuando la mayorfa d~ los computadores eran grandes y costosas. En su lugar, se
desarrollaron las tecnicas de tiempo compartido.
Al igual que la mUltiprogramacion pennite al procesador manejar varias tareas por lotes al
mismo tiempo, la multiprogramacion puede tambien utilizarse para manejar varias tareas in­
teractivas. En este ultimo caso, la tecnica se conoce como tiempo compartido, porque refleja
el hecho de que el tiempo del procesador es compartido entre los diversos usuarios. La tec­
nica Msica de un sistema de tiempo compartido es tener a varios usuarios utilizando simul­
taneamente el sistema mediante tenninales, mientras que el sistema operativo intercala la
ejecucion de cada programa de usuario en rafagas cortas de computo 0 cuantos (quantum).
De esta manera, si hay n usuarios que solicitan servicio ala vez, cada usuario solo dispon­
dra, en promedio, de 1In de la atencion efectiva del computador, sin contar con la sobrecarga
del sistema operativo. Sin embargo, dado el tiempo de reaccion relativamente lento que
tiene el ser humano, el tiempo de respuesta en un sistema correctamente disefiado deberfa
ser comparable al de un computador dedicada.
Tanto la multiprogramacion por Iotes como el tiempo compartido utilizan multiprograma­
cion. Las diferencias Msicas se enumeran en la tabla 2.3.
Uno de los primeros sistemas de tiempo compartido que se desarrollaron fue el Sistema
Compatible de Tiempo Compartido (CTSS, Compatible Time-Sharing System) [CORB62,
CORB63], desarrollado en el MIT por un grupo conocido como Proyecto MAC (Machine­
Aided Cognition, Multiple-Access Computers)3. El sistema fue desarrollado primero para
una IBM 709 en 1961 y luego pas ado a una IBM 7094.
Comparado con sistemas posteriores, el CTSS era bastante primitivo y su funcionamiento
Msico faci} de explicar.IEl sistema se ejecutaba en una maquina con una memoria de 32K
palabras de 36 bits, con un monitorresidente que consumfa 5K del total. Cuando habfa que
asignar el control a un u~uario interactivo, el programa del usuario y los datos eran cargados
en las restantes 27K de la memoria principal. Un reloj del sistema generaba interrupciones a

3 Conocimiento Asistido por Computadora, Computadoras de Acceso Multiple (N. del'C,)


Evolucion de los sistemas operativos 61

TABLA 2:3 Mulliprogramaci6n por loles frente a Tiempo Com partido .


Multiprogramacion por lotes Tiempo Compartido
Objetivo principal Maximizar la utilizaci6n del procesador Minimizar el tiempo de
respuesta
Origen de las instrucciones Instrucciones de un lenguaje de control
al sistema operativo de trabajos incluidas junto con el trab~jo Ordenes dadas en el terminal

razon de aproximadamente una cada 0,2 segundos (sg). En cada interrupcion de reloj, el sis­
tema operativo se aduefiaba del control y Ie podIa asignar el procesador a otro usuario~ De
esta manera, a intervalos regulares, el usuario en curso era expulsado y se cargaba otto Usua­
rio en su lugar. Para conservar e1 estado del usuario anterior, para su reanudacion posterior,
los programas del usuario anterior y sus datos eran escritos en el disco antes de leer los pro­
gramas del nuevo usuario y sus datos. En consecuencia, el espacio de memoria del usuario
anterior debia ser restaurado cuando Ie Uegara de nuevo su tumo.
Para mini mizar el tnlfico en el disco, la memoria del usuario se escribia a disco solo cuando
el nuevo program a a cargar podia sobreescribirla. Este principio se ilustra en la figura 2.9. Su­
pongase que hay cuatro usuarios interactivos con los siguientes requisitos de memoria:
• TRABAJOI: 15K
• TRABAJ02: 20K
• TRABAJ03: 5K
• TRABAJ04: 10K
Al principio, el monitor carga el TRABAJOI y Ie transfiere el control (figura 2.9a). Pos­
teriormente, el monitor decide transferir el control al TRABAJ02. Puesto que el TRA­
BAJ02 requiere mas memoria que el TRABAJ01, este debe sacarse primero, para luego
cargar el TRABAJ02 (figura 2.9b). A continuacion, se carga el TRABAJ03 para ser ejecu­
tado. Sin embargo, como el TRABAJ03 es mas pequefio que el TRABAJ02, entonces una
parte del TRABAJ02 puede quedarse en la memoria, 10 que reduce el tiempo de escritura en
eldisco (figura 2.9c). Mas tarde, el monitor decide transferir de nuevo el control al TRA­
BAJOl. Una parte adicional del TRABAJ02 debe sacarse cuando el TRABAJOI se cargue
de nuevo a memoda (figura 2.9d). Cuando se cargue el TRABAJ04, parte del TRABAJOI •
Yde la parte remanente del TRABAJ02 se retienen en memoria (figura 2.ge). En este punto,
tanto si el TRABAJOI como el TRABAJ02 son activados, solo se necesita una carga par­
cial. En este ejemplo es el TRABAJ02 el que se ejecuta a continuacion. Esto exige que se
saquen el TRABAJ04 y la parte remanente que estaba residente del TRABAJO I, para que
se pueda leer la parte que falta del TRABAJ02.
EI enfoque del CTSS era muy primitivo, si se compara con los sistemas actuales de tiempo
compartido, pero funcionaba. Era extremadamente simple, 10 que minimizaba el tamafio del
monitor. Como un trabajo siempre se cargaba en las mismas posiciones de memoria, no habfa
necesidad de utilizar tecnicas de reubicacion durante la carga (que se discutiran masade­
lante). La tecnica de escribir en el disco solo cuando era necesario minimizaba la actividad
con el disco. Ejectitado sobre una 7094, el CTSS daba soporte a un maximo de 32 usuarios.
EI tiempo compartido y la multiprogramacion plantean una multitud de problemas nuevos
para el sistema operativo. Si hay varios trabajos en memoria, entonces deben protegerse de
62 Introducci6n a los sistemas operativos "

32K rei ~~--.~~ 32K,. ."

TRABAJO~
TRABAJ02
TRABAJ02

5K' 5K
10K
5K
I TRABAJO 3
Monitor
Monitor I Monitor
01 0' 0
(a) (b) (c)

32K 32K

25K
(TRABAJ02)
20K: 20K
15K TRABAJ02
TRABAJ01

5K 5K
5Kf-----~·
Monitor
0 0
0'----'-----'
(d) (e) (f)
FIGURA 2.9 Funcionamiento del CTSS

..,
injerencias unos de otros, como, por ejemplo, que uno modifique los datos de otro. Con va­
rios usuarios interactivos, el sistema de archivos debe protegerse de forma que solo los
usuarios autorizados puedan tener acceso a un archivo en particular. La contenci6n de recur­
sos tales como la impresora y los dispositivos de almacenamiento masivo debe estar contro­
lada. Este y otros problemas, con sus posibles soluciones, se encontraran a 10 largo del texto.

2.3
LOGROS PRINCIPALES

Los sistemas operativos estan entre los elementos de software mas complejos que se han de­
sarrollado. Esto refleja el reto de tratar de conjugar las dificultades y, en algunos casos, ob­
jetivos opuestos de comodidad, eficiencia y capacidad de evoluci6n. Denning y sus cole gas
[DENN80al proponen que, hasta la fecha, se han obtenido cuatro logros intelectuales sign i­
ficativos en el desarrollo de los sistemas operativos:
• Los procesos
• La gesti6n de memoria
• La seguridad y la protecci6n de la informaci6n
• La planificacion y la gesti6n de recursos
• La estructura del sistema
Cada logro viene caracterizado por unos principios 0 abstracciones que se han de sarro­
llado para solucionar las dificultades de los problemas practicos. En conjunto, estos cinco
logros principales 63

campos abarcan los puntas clave del diseno e implementacion de los sistemas operativos
modernos. La breve revision que se hara de estos cinco campos en esta seccion sirve como
introduccion a gran parte del texto restante.

Procesos
El concepto de proceso es fundamental en la estructura de los sistemas operativos. Este ter­
mino fue acunado por primera vez por los disenadores de Multics en los afios 60. Es un ter­
mino algo mas general que el de trabajo. Se han dado muchas definiciones para el termino
proceso, entre las que se incluyen las siguientes:
• Un programa en ejecucion
• El "esplritu animado" de un program a
• La entidad que puede ser asignada al procesador y ejecutada por 61.
El concepto de proceso debe quedar mas claro a medida que se avance.
Tres llneas principales en el desarrollo de los sistemas informaticos crearon problemas de
tiempos y de sincronizacion que contribuyeron al desarrollo del concepto de proceso: la
operacion por lotes con multiprogramacion, el tiempo compartido y los sistemas de transac­
ciones en tiempo real. Como.se ha visto, la multiprogramacion fue disenada para mantener
ocupados ala vez tanto procesador como los dispositivos de E/S, incluyendo los dispositi­
vos de almacenamiento, de modo que se alcance la mayor eficiencia posible. La clave de
este mecanismo es que, como respuesta a las senales que indiquen que ha terminado una
transaccion de E/S, el procesador cambia entre los diversos programas que residen en la me­
moria principal.
Una segunda linea de desarrollo fue la de los sistemas de tiempo compartido de propos ito
general. La justificacion de tales sistemas es que los usuarios del computador son mas pro­
ductivos si pueden interactuar directamente con el computador desde algun tipo de terminal.
En este caso, el objetivo clave del diseno es que el sistema sea sensible a las necesidades del
usuario individual y que, ademas, por razones de coste, pueda dar soporte simultaneo a mu­
chos usuarios. Estos objetivos son compatibles debido al tiempo de reaccion relativamente
lento que tienen los usuarios. Por ejemplo, si un usuario upico necesita, en promedio, 2 se­
gundos de tiempo de procesamiento por minuto, entonces cerca de 30 usuarios deberian ser
capaces de compartir el rnismo sistema sin interferencias notables. Por supuesto, debe te- •
nerse en cuenta la sobrecarga que impone el propio sistema operativo.
Otra llnea importante de desarrollo la han constituido los sistemas de proceso de transac­
ciones en tiempo reaL En este caso, un cierto numero de usuarios hacen consultas 0 actuali­
zaciones sobre una base de datos. Un ejemplo clasico es un sistema de reservas de unas 11­
neas aereas. La diferencia clave entre un sistema de proceso de transacciones y un sistema
de tiempo compartido es que el primero esta limitado a una 0 pocas aplicaciones, mientras
que los usuarios de un sistema de tiempo compartido pueden dedicarse al desarrollo de un
programa, a la ejecucion de trabajos y al uso de diferentes aplicaciones. En ambos casos, el
tiempo 4e respuesta del sistema es primordiaL
La herramienta principal disponible para los programadores de sistemas en el desarrollo
de los primeros sistemas interactivos multiusuario y de multiprogramacion fue la interrup­
cion. La actividad de' cualquier trabajo podia suspenderse por el acontecimiento de un su­
ceso determinado, como la culminacion de una E/S. El procesador debia entonces salvar al­

~
64 Introducci6n a los sistemas operativos

gun tipo de contexto (por ejemplo, el contador de programa y otros registros) y desviarse ha­
cia una rutina de tratamiento de la interrupci6n, que determinaba la naturaleza de la inte­
rrupci6n, la procesaba y luego reanudaba el proceso del usuario en el trabajo interrumpido 0
en algun otro trabajo.
El diseno del software del sistema para coordinar estas diversas actividades result6
extraordinariamente dificil. Con muchos trabajos en progreso al mismo tiempo, donde
cada uno involucraba numerosos pasos que dar de una manera secuencial, resultaba im­
posible de analizar todas las combinaciones posibles de secuencias de sucesos. En au­
1r
sencia de un medio sistematico de coordinaci6n y cooperaci6n entre las actividades, los
program adores recurrian a metodos ad hoc basados en su comprension del entorno que
el sistema operativo tenia que controlar. Estos esfuerzos estaban expuestos a errores su­
tiles de programaci6n cuyos efectos podria ser que solo se manifestasen si se producian
ciertas secuencias de acciones relativamente raras. Estos errores eran muy diffciles de
diagnosticar, porque era necesario poder distinguirlos de los errores del software de
aplicacion y de los del hardware. Aun cuando se detectase el error, resultaba muy diffcil
determinar las causas, porque las condiciones precisas bajo las que aparecian los errores
resultaban muy dificiles de reproducir. En lfneas generales, habia cuatro causas princi­
pales de error [DENN80a]:
• Sincronizacion incorrecta: Es frecuente el caso en el que una rutina debe ser suspendida a
la espera de un suceso en cualquier lugar del sistema. Por ejemplo, un programa inicia una
. lectura de E/S y debe esperar hasta que los datos esten disponibles en un buffer antes de
continuar. En tales casos se requiere alguna senal proveniente de alguna otra rutina. Un di­
seno incorrecto del mecanismo de senalizacion puede dar como resultado la perdida de se­
nales 0 la recepcion de senales duplicadas.
• F alios de exclusion mutua: Es habitual el caso en que mas de un usuario 0 programa in­
tentan a la vez hacer uso de un recurso compartido. Por ejemplo, en un sistema de reser­
vas de lfneas aereas, dos usuarios pueden intentar leer de la base de datos y, si hay un
asiento disponible, actualizar la base de datos para hacer una reserva. Si no se controlan
estos accesos, puede producirse un error. Debe exisJir algun tipo de mecanismo de exclu­
si6n mutua que permita que s610 una rutina a la vez pueda realizar una transaccion sobre
una determinada parte de los datos. Verificar la correcci6n de la implementaci6n de dicha
exclusi6n mutua bajo todas las secuencias posibles de sucesos es diffcil.
• Funcionamiento no determinista del programa: Los resultados de un programa en parti­
cular deben depender normalmente solo de la entrada del programa y no de las actividades
de otros programas en un sistema compartido. Pero cuando los programas comparten me­
moria y sus ejecuciones son intercaladas por el procesador, entonces pueden interferir con
otros, sobreescribiendo zonas comunes de memoria de forma incierta. Asf pues, el orden
en que se organiza la ejecuci6n de varios programas puede inftuir en los resultados de un
programa en particular.
• lnterb(oqueos: Es posible que dos 0 mas programas esten suspendidos a la espera uno del
otro. Por ejemplo, dos programas pueden requerir dos dispositivos de E/S para llevar a
cabo cierta operaci6n (por ejemplo, copiar de disco a cinta). Uno de los programas ha to­
rnado el control de uno de los dispositivos y el otro programa tiene el control del otro dis­
positivo. Cada uno esta esperando que el otro libere el recurso deseado. Dicho interblo­
queo puede depender del ritmo imprevisto de la asignacion y la liberaci6n de recursos.
.
logros principales 65

Lo que se necesita para enfrentarse a estos problemas es una forma sistematica de super­
visar y controlar los distintos programas que pueden estar ejecutandose en el procesador. El
concepto de proceso pone las bases. Se puede considerar que un proceso esta formado por
las tres componentes siguientes:
• Un programa ejecutable
• Los datos asociados necesarios para el programa (variables, espacio de trabajo, buffers, etc.)
• El contexto de ejecucion del programa
" Este ultimo elemento es esenciaL El contexto de ejecucion inc1uye toda la informacion
que el sistema operativo necesita para administrar el proceso y que el procesador nece­
sita para ejecutar correctamente el proceso. Asi pues, el contexto inc1uye los contenidos
. de varios registros del procesador, tales como e1 contador de programa y los registros de
datos. Tambien inc1uye informacion de utilidad para el sistema operativo, tal como la
prioridad del proceso y si el proceso esta esperando la terminacion de un suceso particu­
lar de E/S.
La figura 2.10 indica una forma en la que pueden implementarse los procesos. Hay dos
procesos, A y B, en secciones de la memoria principaL Esto es, a cada proceso se Ie debe
asignar un bloque de memoria que contiene los programas, los datos y la informacion del
contexto. Cada proceso es registrado en una lista de procesos construida y guardada por el
sistema operativo. La !ista de procesos contiene una entrada para cada proceso, la cual dis­
pone de un puntero a la posicion del bloque de memoria que contiene al proceso. Esta en­
~
trada tambien puede incluir parte 0 todo el contexto de ejecucion del proceso. El resto del
contexto de ejecucion del proceso es almacenado en el mismo proceso. EI registro de indice
del proceso contiene el indice, dentro de la lista de procesos, del proceso que esta actual­
mente controlando al procesador. El contador de programa apunta a la proxima instruccion
del proceso que se ejecutara. Los registros de base y de limite definen la region de memoria
ocupada por el proceso. EI contador de programa y todas las referencias a datos se interpre­
tan como relativas al registro de base y no deben exceder el valor del registro de limite. Esto
impide las interferencias entre procesos.
En la figura 2.10, e1 registro de fndice del proceso indica que el proceso B esta ejecutan­
dose. EI proceso A estaba ejecutandose con anterioridad, pero ha sido interrumpido tempo­
110
ralmente. EI contenido de todos los registros en el momento de la interrupcion de A fue re­
gistrado en su contexto de ejecucion. Mas tarde, el procesador podra llevar a cabo un
cambio de contexto y reanudar la ejecucion del proceso A. Cuando el contador de programa
se cargue con un valor que apunte a la zona de program a de A, el proceso A reanudara auto­
maticamente su ejecucion.
De esta manera, el proceso es tratado como una estructura de datos. Un proceso puede
estar ejecutandose 0 esperando su ejecucion. EI "estado" entero del proceso esta conte­
nido en su contexto. Esta estructura permite el desarrollo de tecnicas potentes que asegu­
ran la coordinacion y la cooperacion entre procesos. Se pueden disefiar e incorporar nue­
vas caracterfsticas al sistema operativo (por ejemplo, prioridades) mediante la ampliacion
del contexto para incluir cualquier nueva informacion que sea necesaria para dar soporte
al nuevo atributo. A 10 largo de este libro se veran varios ejemplos en los que se emplea
.. esta estructura de proceso para resolver los problemas planteados por la multiprograma­
cion y la comparticionde recursos.
66 Introduccion a los sistemas operativos

Memoria Registros del


Principal Procesador
Indice de I L - _ - : : '_ _....J

Proceso
PC ~_---!..=::t---,

Base
Lista de Limite
Procesos

~:;t""j,--___-,
Proceso
A

Proceso Datos
h
B

Programa

FIGURA 2.10 Implementacion tfpica de los procesos


-,

Gestion de memoria

Los usuarios necesitan un entorno infonmitico que de soporte a la program adon modular y

la utilizacion flexible de los datos. Los administradores de sistemas necesitan un control efi­

dente y ordenado de la asignacion del almacenamiento. Para satisfacer estos requisitos, el

sistema operativo tiene cinco responsabilidades principales en la gestion del almacena­

miento'[DENN71], que son:

• Aislamiento del proceso: El sistema operativo debe procurar que cada proceso indepen­
diente no interfiera con los datos y la memoria de ningun otro.
• Asignacion y gestion automaticas: A los program as se les debe asignar memoria dimimi­
camente en la jerarqufa de memoria, segun la vayan necesitando. Este proceso debe ser
'.
Logros principales 67

transparente para el programador. De este modo, el programador se libera de todo 10 con­


cemiente a las limitaciones de memoria y el sistema operativo puede lograr eficiencia
asignando memoria a los trabajos seglin la vayan necesitando.
• Soporte para la programilcion modular: Los programadores deben ser capaces de definir
modulos de programa y de crear, destruir y alterar el tamafio de los modulos dimimicamente.
• Proteccion y control de acceso: Compartir la memoria en algun nivel de la jerarquia de me­
.moria origina la posibilidad de que un program a pueda direccionar el espacio de memoria
;y de otro programa. Algunas veces, esto es conveniente, sobre todo cuando se necesita com­
particion en una aplicacion en particular. En otros casos, esto amenaza la integridad de los
program as y del mismo sistema operativo. El sistema operativo debe permitir que las sec­
ciones de memoria esten accesibles de varias maneras para los diversos usuarios.
• Almacenamiento a largo plazo: Muchos usuarios y aplicaciones necesitan medios para al­
macenar informacion por largos periodos de tiempo.
Normalmente, los sistemas operativos satisfacen estos requisitos .mediante la memoria
virtual y los servicios del sistema de archivos. La memoria virtual es un servicio que permite
a los program as direccionar la memoria desde un punto de vista logico, sin depender del ta­
mafio de la memoria principal fisica disponible. Cuando se esta ejecutando, solo una parte
del program a y de los datos pueden estar real mente en memoria principal. Las partes restan­
tes del programa y de los datos se mantienen en bloques en el disco. Se vera en capitulos
posteriores como esta separacion de la memoria en vistas logicas y fisicas ofrece al sistema
. .., operativo una potente herramienta para lograr sus objetivos .
EI sistema de archivos da cuenta del almacenamiento a largo plazo, almacenandose la in­
formacion en unos objetos con nombre denominados archivos. El archivo es un concepto
pnktico para el programador y es una unidad litil de control de acceso y de proteccion en el
sistema operativo.
La figura 2.11 ofrece un esquema general de un sistema de almacenamiento administrado
por un sistema operativo. El hardware del procesador, junto con el sistema operativo, dotan al
usuario de un "procesador virtual" que tiene acceso a la memoria virtual. Este almacen puede
ser un espacio lineal de direcciones de memoria 0 una coleccion de segmentos, que son blo­
..
ques de direcciones contiguas con longitud variable. En cualquier caso, las instrucciones del
lenguaje de programacion pueden hacer referencia a los programas y las posiciones de los da­
tos en la memoria virtual. EI aislamiento de los procesos se puede lograr dandole a cada pro­
ceso una linica memoria virtual que no se solape con otra. La comparticion entre los procesos
se puede lograr solapando secciones de dos espacios de memoria virtual. Los archivos se
mantienen en un almacen permanente. Los archivos 0 una parte de los mismos pueden co­
piarse en la memoria virtual para su manipulacion por parte de los programas.
EI punto de vista que el disefiador tiene del aImacenamiento tambien se ilustra en la figura
2.11. El almacenani.iento consta de una memoria principal directamente direccionable (me­
diante instrucciones de la maquina) y una memoria auxiliar de velocidad inferior a la que se
accede in'directamente, cargando los bloques en la memoria principal. Se coloca un hardware
de traduccion de direcciones (mapper) entre el procesador y la memoria. Los program as hacen
referencia a las posiciones utilizando direcciones virtuaies, que son traducidas' a direcciones
reales de la memoria principal. Si se hace una referencia a una direccion virtual que no esta en
"
la memoria real, entonces una parte del contenido de la memoria,-eal se expulsa hacia la me­
68 Introduccion a los sistemas operativos

DO
Leer, Escribir COfliar o
Memoria
Almacen a largo plazo
Virtual

(a) Vista del Usuario

----------------------~----------:

Procesador
Real
I

IDirecci6n de
i
Traductor I
I "
Direcciones Di r~~C1on
Memoria
Principal Inter-
i M'~Orl' I
Auxiliar
Virtual cambio
Memoria
(b) Vista del disefiador del sistema operativo
FIGURA 2.11 Dos puntos de vista de un sistema de almacenamiento [DENN80aj

1
moria auxiliar, intercambiandose con el bloque de memoria deseado. Durante esta actividad,
debe suspenderse el proceso que genero la referencia a la direcdon. Es tarea del disefiador
construir un mecanismo de traduccion de direcciones que genere poca sobrecarga y una poli­
tica de asignacion del almacenamiento que minimice el trMico entre los niveles de memoria.

Seguridad y proteccion de la informacion


El crecimiento de la utilizaci6n de los sistemas de tiempo compartido y, mas recientemente,
las redes de computadores, ha traido consigo un aumento de las preocupaciones por la pro­
tecci6n de la informacion.
Una pubUcacion de la Oficina Nacional de Estandares 4 identifica algunas de las amenazas. ..
a las que es necesario atender en el campo de la seguridad [BRAN78]:
1. Intentos organizados y deliberados de obtener informaci6n econ6mica y mercantil de las
organizaciones competitivas del sector privado
2. Intentos organizados y deliberados de obtener informacion econ6mica de las oficinas del
gobierno
3. Adquisici6n inadvertida de informaci6n econ6mica 0 mercantil
4. Adquisicion inadvertida de informaci6n sobre las personas
5. Fraude intencional a traves del acceso ilegal a bancos de datos en computadores, con en­
fasis, en orden decreciente de importancia, en la adquisicion de datos financieros, econo­
micos, de aplicacion de leyes y personales

4 National Bureau o/Staildards (N, del T)


logros principales 69

6. Intromision del gobiemo en los derechos individuales


7. Atropello de los derechos individuales por la comunidad
Estos son ejemplos de amenazas especfficas que una organizacion 0 un individuo (0 una
organizacion en nombre de sus empleados) puede sentir la necesidad de contrarrestar. La na­
turaleza de las amenazas que conciemen a una organizacion pueden variar enormemente de
un conjunto de circunstancias a otro. Sin embargo, pueden construirse algunas herramientas
de proposito general dentro de los computadores y de los sistemas operativos para dar so­
porte a varios mecanismos de proteccion y seguridad. En general, interesan los problemas
de control de acceso a los sistemas informaticos y a la informacion almacenada en ellos. Se
han identificado cuatro clases de polfticas generales de proteccion, en orden creciente de di­
ficultad [DENN80a]:
• No comparticion: En este caso, los procesos estan completamenteaislados uno del otro y
cada proceso tiene control exclusivo sobre los recursos que Ie fueron asignados estatica 0
dinamicamente. Con esta politica, los procesos suelen compartir los programa 0 archivos
de datos haciendo copias y pasandolas a su propia memoria virtuaL
• Compartiendo los originales de los programas 0 archivos de datos: Con el uso de codigo
reentrante (ver Apendice lB), una unica copia fisica de un program a puede aparecer en
varios espacios de memoria virtual como archivos de solo lectura. Se requieren mecanis­
mos especiales de bloqueo para compartir archivos de datos en los que se puede escribir e
impedir que usuarios simultaneos interfieran unos con otros.
Subsistemas corif'inados 0 sin memoria: En este caso, los procesos se agrupan en subsiste­
mas para cumplir una politic a de proteccion en particular. Por ejemplo, un proceso
"cliente" llama a un proceso "servidor" para llevar a cabo cierta tare a con los datos. El ser­
vidor se protegera de que el cliente descubra el algoritmo con el cuailleva a cabo su tra­
bajo y el cliente se protegera de que el servidor retenga alguna informacion sobre el tra­
bajo que esta llevando a cabo.
• Diseminacion controlada de fa informacion: En algunos sistemas se definen clases de se­
guridad para cumplir una determinada politic a de diseminacion de la informacion. A los
usuarios y a las aplicaciones se les dan credenciales de seguridad de un cierto nivel, mien­
tras que a los datos y a otros recursos (por ejemplo, los dispositivos de E/S) se les dota de
clasificaciones de seguridad. La politic a de seguridad hace cumplir las restricciones rei a­
tivas a que usuarios tienen acceso a que clasificaciones. Este modelo es uti! no solo en
contextos militares, sino tarnbien en aplicaciones comerciales.
Gran parte del trabajo que se ha realizado en la seguridad y protecci6n de los sistemas
operativos puede agruparse, en grandes Hneas, en las tres categonas siguientes.
• Control de acceso: Tiene que ver con la regulacion del acceso del usuario al sistema com­
pleto, a los subsistemas y a los datos, as! como a regular el acceso de los procesos a los re­
cursos y objetos del sistema.
• Control del flujo de informacion: Regula el flujo de datos dentro del sistema y su distribu­
ci6n a los usuarios.
• Certificacion: Es relativa a la demostraci6n de que el acceso y los mecanismos de control
del flujo se Bevan a cabo de acuerdo a las especificaciones y a que estas cumplen las poH­
ticas de protecci6n y seguridad deseadas.
70 Introducci6n a los sistemas operativos

Planificacion y gestion de recursos


Una tarea clave del sistema operativo es administrar los recursos que tiene disponibles (es­
pacio de memoria, dispositivos de E/S, procesadores) y planificar su utilizaci6n por parte de
los diferentes procesos en ~ctivo. Cualquier polftica de asignacion de recursos y de planifi­
caci6n debe tener en cuenta los tres factores siguientes:
• Equidad: Normalmente, sena conveniente que a todos los procesos que compiten por el
uso de un determinado recurso le~ sea otorgado un acceso al recurso que sea aproximada­
, mente igualitario y equitativo. Esto es especialmente as! para los trabajos de una misma ...
clase, es decir, trabajos con demand as similares, que'son cargados con la misma tasa.
• Sensibilidades diferenciales: Por otro lado, el sistema operativ~ puede tener que discrimi­
nar entre las diferentes clases de tiabajos con diferentes requisitos de servicio. El sistema
operativo debe intentar tomar decisiones de asignaciop y planificacion que satisfagan la
totalidad de los requisitos. El sistema operativo debe contemplar estas decisiones dimimi­
camente. Por ejemplo, si un proceso esta esperando por el uso de un dispositivo de E/S, el
sistema operativo puede querer planificar la ejecucion de dicho proceso tan pronto como
sea posible y as! tener disponible al dispositivo para las demandas de otros procesos.
• Eficiencia: Dentro de las restricciones de equidad y eficiencia, el sistema operativo debe
intentar maximizar la productividad, minimizar el tiempo de respuesta y, en el caso de
tiempo compartido, alojar a tantos usuarios como sea posible.
La tarea de planificacion y gestion de recursos es basicamente un problema de investiga­
cion operativa, as! que se pueden aplicar los resultados matematicos de esta disciplina. Ade­
mas, la medicion de la actividad del sistema es importante para poder controlar el rendi­
miento y poder hacer ajustes.
La figura 2.12 propone los elementos principales del sistema operativo que estan in­
volucrados en la planificacion de procesos y en la asignacion de recursos para un en­
tomo de multiprogramacion. El sistema operativo mantiene una serie de colas, cada una
de las cuales no es mas que una lista de procesos esperando a algun recurso. La cola a
corto plazo esta form ada por procesos que estan en memoria principal (0 que, por 10 me-
nos, una parte minima basica esta en memoria principal) y estan listos para ejecutar. AI­
guno de estos procesos podrfa ser el siguiente en usar el procesador. Depende del plani­
ficador a corto plazo 0 distribuidor (dispatcher) el escoger a uno. Una estrategia ' .
habitual es asignar por tumos. una cierta cantidad de tiempo a cada proceso de la cola;
esta tecnica es conocida como tumo rotatorio 0 round-robin. Tambien se pueden utilizar
niveles de prioridad.
La cola a largo plazo es una lista de nuevos trabajos que esperan para usar el sistema. EI
sistema operativo aiiade los trabajos al sistema transfiriendo un proceso desde la cola a largo
plazo hacia la cola a corto plazo. En ese momento, al proceso que se trae se Ie debe asignar
una parte de la memoria principal. De este modo, el sistema operativo debe estar seguro de
que no sobrecarga la memoria 0 el tiempo de procesamiento por admitir demasiados proce­
sos en el sistema. Hay una cola de E/S para cada dispositivo de E/S. Mas de un proceso pue­
den solicitar el uso de un mismo dispositivo de E/S. Todos los procesos esperando por el uso
de un determinado dispositivo estan alineados en la cola de dicho dispositivo. Una vez mas,
es el sistema operativo el que debe determinar a que proceso se Ie debe asignar un disposi­
tivo de E/S cuando este disponible.
logros principales 71

Sistema Operativo

Gestor de
Petici6n de
Peticiones
Servicio de un
Proceso
de Servicio
D
Cola a Cola a
D
Colas de
Interrupci6n Largo Corto E/S
de un Proceso Gestor de Plazo Plazo
Interrupci6n • I Interrupciones
deE/S Planificador
a Corto
Plazo

Pasar el Control al
Proceso
. FIGURA 2.12 Elementos dave de un sistema operativo para la multiprogramaci6n

Si se produce una interrupcion, el sistema operativo toma el control del procesador me­
diante la rutina de tratamiento de interrupciones. Un proceso puede invocar especialmente
algun servicio del sistema operativo, como un manejador de dispositivos de E/S, por medio
de peticiones de servicio. En este caso, el manejador de peticiones de servicio es el punto de
entrada al sistema operativo. En cualquier caso, una vez que la interrupcion 0 la peticion de
servicio es atendida, se invoca al planificador a corto plazo para que seleccione un proceso
para su ejecucion.
Esta descripcion es solamente funcional; los detalles y el disefio modular de esta parte del
sistema operativo difieren en los diversos sistemas. En cualquier caso, deben llevarse a cabo
estas funciones generales. Gran parte del esfuerzo de investigacion y desarrollo en sistemas
operativos se ha dedicado a los algoritmos de selecci6n y a las estructuras de datos para que
estas funciones brinden equidad, sensibilidades diferenciales y eficiencia.

Estructura del sistema


En la medida en que se afiaden mas caracteristicas a los sistemas operativos y en que el
hardware se hace mas complejo y versatil, el tamafio y la complejidad de los sistemas ope­
rativos ha ido creciendo (figura 2.13). El sistema CTSS (Compatible Time-Sharing System),
puestoeri funcionamiento en el MIT en 1963, constaba, como maximo, de aproximada­
mente 32.000 palabras de.36 bits. El OS/360, presentado posteriormente por IBM, tenia mas
de un milIon de instrucciones de maquina. Hacia 1973, el sistema Multics, desarrollado por
el MIT y los Laboratorios Bell, habia crecido a mas de 20 millones de instrucciones. Es
cierto que, mas recient~mente, se han desarrollado sistemas Opt rativos mas simples, para
72 Introducd6n a los sistemas operativos

• Multics

10.000.000 : (NUCLEO + lITILlDADES)

OS/360 (21) :

I .MVS

."
".
...... I
/' • VMS
1.000.000 Multics
. •
OS/360 (1)
(NUCLEO) •
Unix (BSD 4.2)
~
U)

:::l

SCOPE
VSOS 205

~ 100.000 (7.5)
~
~
o
,t:;

J 10.000

1.000

EDSAC
100
1940
---..l..---~:::----:=--~;;---l9'9c
L,
1950 1960 1970 1980 1990 ..
FIGURA 2.13 EI tamano de algunos sistemas operativos (en palabras)

sistemas mas pequefios, pero estos han ido creciendo inevitablemente en la medida en que el
hardware y los requisitos de los usuarios han crecido. Asi pues, UNIX es hoy mucho mas
complejo que el sistema casi de juguete puesto en marcha por unos pocos programadores
con talento en los primeros afios de los 70 y el simple PC-DOS ha cedido el paso a la rica y
compleja potencia de OS/2.
E1 tamafio de un sistema operativo completo y la dificultad de las tareas que lleva a cabo
plantean tres problemas desafortunados pero demasiado habituales. Primero, los sistemas
operativos, cuando se entregan, ya estan cronol6gicamente retrasados. Esto conduce a nue­
vos sistemas operativos y a actualizaciones de los anteriores. Segundo, los sistemas tienen
fallos latentes que se manifiestan en el terreno y que deben ser detectados y corregidos. Y,
por ultimo, su rendimiento no es a menudo el que se esperaba.
Para gestionar la complejidad de los sistemas operativos y solucionar estos proble­
mas, se ha prestado mucha atencion durante los ultimos aiios ala estructura del software
de los sistemas operativos. Ciertos puntos parecen obvios. El software debe ser modu­
lar. Esto ayuda a organizar el proceso de desarrollo de software y reduce las tareas de
diagn6s~ico y detecci6n de errores. Los m6dulos tienen que tener interfaces bien defini­
das entre sf y estas interfaces deben ser tan simples como sea posible. Esto facilita la la­
bor de programaci6n y·tambien hace mas facil la evoluci6n del sistema. Con interfaces
clar.a.s y minimas entre los m6dulos, se puede cambiar un m6dulo y que el imp acto so­
bre los otros sea mini mo.
.
Logros principales 73

Para grandes sistemas operativos, que van desde cientos de miles a millones de line as de
codigo, la programacion modular por sf sola no es suficiente. En su lugar, ha ido creciendo
el uso de conceptos como los de niveles jerarquicos y abstraccion de la informacion. La es­
tructura jerarquica de un sis.tema operativo modemo separa sus funciones de acuerdo a su
complejidad, su escala caracteristica de tiempo y su nivel de abstraccion. Se puede contem­
plar al sistema como una serie de niveles. Cada niveilleva a cabo un determinado subcon­
junto de funciones requeridas por el sistema operativo. Este se basa en el nivel inferior para
, llevar a cabo funciones mas primitivas y ocultar los detalles de dichas funciones. A su vez,
cada nivel ofrece servicios al nivel superior. En el mejor de los casos, los niveles deben es­
tar. definidos de forma que los cambios en un nivel no requieran cambios en otros niveles.
De este modo, se descompone un problema en un numero de subproblemas mas manejables.
En general, las capas mas bajas trabajan con esc alas de tiempo mas cortas. Algunas partes
del sistema operativo deben interactuar directamente con el hardware del computador,
donde los sucesos pueden tener una escala de tiempo tan breve como unas pocas billonesi­
mas de segundo. En el otro extremo del abanico, las partes del sistema operativo que se co­
munican con el usuario, que envia las ordenes con un ritmo mas tranquilo, pueden trabajar
en una escala de tiempo de unos pocos segundos. El uso de un conjunto de niveles se adapta
bien a este entorno.
La forma en que se aplican estos principios varia enormemente entre los distintos siste­
mas operativos actuales. Sin embargo, es util en este punto, con el fin de obtener una vision
general ddos sistemas operativos, presentar un modelo de sistema operativo jerarquico. Es
fI
util tomar un sistema propuesto por Brown y sus colegas [BROW84] y por Denning y
Brown [DENN84], aunque no corresponde a ningdn sistema operativo en particular. EI mo­
delo esta definido en la tabla 2.4 y consta de los siguientes niveles:
• Nivell; Consta decircuitos electronicos, donde los objetos que se tratan son registros, cel­
das de memoria y puertas logieas. Las operaciones definidas sobre estos objetos son ac­
ciones tales como borrar un registro 0 leer una posicion de memoria.
• Nivel 2: Es el conjunto de instrucciones del procesador. Las operaciones a este nivel son
aquellas permitidas por el conjunto de instrucciones del lenguaje de la maquina, tales
como SUMAR, RESTAR, CARGAR Y DEPOSITAR .
, • Nivel3: Afiade el concepto de procedimiento 0 subrutina, as! como las operaciones de Ua­
mada y retorno.
• Nivel4: Introduce las interrupciones, las cuales hacen que el procesador salve el contexto
actual e invoque a una rutina de tratamiento de la interrupcion.
Estos primeros cuatro niveles no forman parte del sistema operativo, sino que constituyen
el hardware del procesador. Sin embargo, algunos de los elementos de los sistemas operati­
vos comienzan a aparecer en estos niveles, tales como las rutinas de tratamiento de interrup­
cion. Es en el nivel 5 en el que comienza a alcanzarse el sistema operativo propiamente di­
cho y en el que comienzan a aparecer los conceptos asociados con la multiprogramaci6n.
• Nivel5: En este nivel se introduce la noci6n de proceso como un programa en ejecucion. Entre
los requisitos fuildarnentales de un sistema operativo que ofrezca soporte para multiples proce­
sos se incluye la capacidad de suspender y reanudar los prbcesos. Esto exige salvaguardar los
registros del hardware, de modo que la ejecucion pueda cambiar de un proceso a otro. Ademas,
" si los procesos necesitan cooperar, hace falta algun metodo de sincronizacion. Una de las tecni­
74 Introducd6n a los sistemas operativos

TABLA 2.4 Jerarqula de Disefio de un Sistema Operativo


Nivel Nombre Objetos Ejemplos de Operaciones
13 Shell Entorno de programaci6n Sentencias de un lenguaje de
del· usuario
12 Procesos de usuario Procesos de usuario Salir, eliminar, suspender, reanudar
11 Directorios Directorios Crear, destruir, conectar, desconec­
tar, buscar, listar
10 Dispositivos Dispositivos externos tales Crear, destruir, abrir, cerrar, leer,
como impresoras, pantallas escribir
y teclados
9 Sistema de archivos Archivos Crear, destruir, abrir, cerrar, leer,
escribir
8 Comunicaciones Tubos (pipes) Crear, destruir, abrir, cerrar, leer,
escribir
7 Memoria Virtual Segmentos, paginas Leer, escribir, traer (fetch)
6 Almacenamiento Bloques de datos, canales Leer, escribir, asignar, liberar
secu ndario local de dispositivos
5 Procesos Primitivos Procesos primitivos, semafo- Suspender, reanudar, esperar,
ros, colas de listos sefializar
4 Interrupciones Programas de tratamiento Invocar, enmascarar, desenmas­
de interrupciones carar, reintentar
3 Procedimientos Procedimientos, pila de Marcar la pila, lIamar, retornar
lIamadas, visualizacion
2 Conjunto de Evaluacion de la pila,
instrucciones interprete de microprogra-, Cargar, almacenar, sumar, restar,
mas, vectores de datos bifurcar
yescalares
Ci rcuitos electronicos Registros, puertas, buses, etc Borrar, transferir, activar,

cas mas simples, pero un concepto importante en el disefio de sistemas operativos, es el sema­

foro. El semaforo es una t:ecnica sencilla de sefializaci6n que se examinara en el capitulo 4.

• Nivel6: Tiene que ver con los dispositivos de almacenamiento secundario del computador. En f

este nivel se sit11an las funciones de ubicaci6n de las cabezas de lectura y escritura, y se pro­
ducen las transferencias reales de bloques. El mvel6 se apoya en el nivel5 para planificar las
operaciones y notificar al proceso que hizo la solicitud que la operaci6n ha culminado. Los ni­
veles mas altos se ocupan de las direcciones de los datos pedidos del disco y son los que pre­
sentan la solicitud de los bloques apropiados al manejador del dispositivo del mvel5.
• Nivel7: Crea un espacio de direcciones 16gicas para los procesos. Este mvel organiza el espacio
de direcciones virtuales en bloques que se pueden mover entre la memoria principal y la me­
moria secundaria Tres son los esquemas de uso mas habitual: los que utilizan pagioas de longi­
tud fija, los que usan segmentos de longitud variable y los que utilizan los dos. Cuando el blo­
que necesario no esta en memoria, la 16gica de este mvelle solicita una transferencia al mvel 6.
Hasta este punto, efsistema operativo se ocupa de los recursos de un solo procesador. Em­
pezando por el nivel 8, el sistema operativo trata con objetos extemos, tales como dispositi­ fc

vos perifericos y, posiblemente, redes y computadores conectadas. Los objetos de estos ni­
Sistemas de ejemplo 75

veles superiores son logicos, objetos con nombre que pueden ser compartidos por varios
procesos en un mismo computador 0 en varios computadores.
• Nivel 8: Se dedica a la comunicacion de iflformacion y mensajes entre los procesos. Mien­
tras que el nivel5 proporciona el mecanismo de sefializacion primitivo que permite la sin­
cronizacion entre procesos, este nive1 trata con una forma inas completa de compartir in­
formacion. Una de his herramientas mas potentes en este niveles el tubo (pipe), que es un
canallogico para el flujo de datos entre los procesos. Un tubo se define con su salida en un
. proceso y su entrada en otro proceso. Tambien se pueden usar para enlazar dispositivos
extemos 0 archivos con los procesos. EI concepto se discute en el capitulo 4.
• Nivel9: Da soporte al almacenamiento a largo plazo de los archivos con nombre. En este
nivel, los datos del almacenamiento secundario se contemplan en terminos de entidades
abstractas de longitud variable, en contraste con el enfoque orientado al hardware del ni­
vel 6, en terminos de pistas, sectores y bloques de tamano fijo.
• NivellO: Es el que proporciona acceso a los dispositivos extemos mediante interfaces es­
tandarizadas .
• Nivelll: Es responsable de mantener la asociacion entre los identificadores extemos e in­
temos de los recursos y objetos del sistema. El identificador extemo es un nombre que.
puede ser empleado por una aplicacion 0 un usuario. El identificador intemo es una direc­
cion que es utilizada en los niveles inferiores del sistema operativo para ubicar y controlar
un objeto. Estas asociaciones se mantienen en un directorio. Las entradas incluyen no solo
.las asociaciones extemo/intemo, sino otras caracteristicas, como los derechos de acceso.
• Nivel12: Proporciona servicioscompletos de soporte a los procesos. Esto va mucho mas
alIa que 10 que se ofrece en el nivel 5. En el nivel 5, solo se mantienen los contenidos de
los registros del procesador asociados con un proceso, junto a la logica para expedir a los
procesos. En el nivel 12, se da soporte a toda la informacion necesaria para la gestion or­
denada de los procesos. Esto incluye el espacio de direcciones virtuales del proceso, una
lista de objetos y procesos con lo~ que puede interactuar y las limitaciones de dicha inte­
raccion, los parametros pas ados all proceso en su creacion y cualesquiera otras caracteris­
ticas del proceso que pudieran set utilizadas por el sistema operativo para su control.
• Nivel 13: Ofrece al usuario una il1:~erfaz con el sistema operativo. Se denomina caparazon
oshell porque separa al usuario de los detalles y Ie presenta el sistema operativo como un
simple conjunto de servicios. El shell acepta las 6rdenes del usuario 0 las sentencias de
control de trabajos, las interpreta,crea y control a los procesos segun sea necesario.
Este modelo hipotetico de un sistema operativo proporciona una descripci6n 6tH de la es­
tructura, a la vez que sirve como gufa de implementaci6n. Se puede volver a esta estructura
en el transcurso de este libro para observar el contexto de cualquier aspecto particular de di­
sefio que este en discusion.

2.4
SISTEMAS DE EJEMPtO
Este texto esta concebido para dar a conocer los principios de disefio y los aspectos de im­
plementacion de los sistemas operativos contemporaneos. De acuerdo con esto, un trata­
76 Introducci6n a los sistemas operativos

miento puramente teorico 0 conceptual no serfa adecuado. Para ilustrar los conceptos y aso­
ciarlos con las decisiones reales de disefio que se deben tomar, se han seleccionado tres sis­
temas operativos actuales:
• Windows NT: Un sistema operativo monousuario y multitarea disefiado para que pueda
ejecutar sobre una amplia variedad de PC y estaciones de trabajo. Este es, en realidad, uno
de los pocos sistemas operativos que han sido disefiados basicamente desde cero. Como
tal, esta en posicion de incorporar de una forma clara los ultimos desarrollos en la tecno­
logla de los sistemas operativos.
• UNIX: Un sistema operativo multiusuario dirigido originalmente a minicomputadores
pero implementado en un amplio rango de maquinas, desde potentes minicomputadores
hasta supercomputadores.
• MVS (Multiple Virtual Storage): Es e1 sistema operativo situado en la cima de la linea de
grandes sistemas de IBM y uno de los sistemas operativos mas complejos que se han desa­
rrollado. Brinda tanto capacidades para el tratamiento por lotes como de tiempo compartido.
Se han escogido estos tres sistemas debido a su relevancia y a su representatitividad. La
mayorfa de los sistemas operativos de los computadores personalesson sistemas monousua­
rio y multitarea, y Windows NT da un buen ejemplo de liderazgo. UNIX ha llegado a ser el
sistema operativo dominante en una gran variedad de estaciones de trabajo y sistemas mul­
tiusuario. MVS es el sistema operativo de computadores centrales mas ampliamente utili­
zado. Por tanto, la mayorla de los lectores se enfrentaran con alguno de estos sistemas ope­
rativos durante el tiempo que empleen este libro 0 dentro de pocos aftos.
En esta seccion se dara una breve descripcion e historia de cada uno de estos sistemas
operativos.

WINDOWS NT
Historia
EI antepasado mas distante de Windows NT es un sistema operativo desarrollado por Mi­
crosoft para los primeros computadores personales de IBM y conocido como MS-DOS 0
PC-DOS. La version inicial, el DOS 1.0, fue lanzada en Agosto de 1981. Esta constaba de
4000 lfneas de codigo fuente en lenguaje de ensamblador y ejecutaba en 8K de memoria uti­
lizando el microprocesador Intel 8086.
Cuando IBM desarrollo su computador personal basada en disco duro, el PC XT, Micro­
soft desarrollo el DOS 2.0, lanzado en 1983. Este tenia so porte para un disco duro y ofre­
cia directorios jerarquicos. Hasta ese momento, un disco podia contener solo un directorio
de archivos y dar soporte a un maximo de 64 archivos. Aunque esto era adecuado en la era
de los discos flexibles, era demasiado limitado para un disco duro y la restriccion de un
unico directorio era demasiado molesta. La nueva version permitla que los directorios pu­
dieran tener subdirectorios, asi como archivos. Tambien contenia un conjunto mas com­
pleto de ordenes incluidas en el sistema operativo, que brindaban funciones que en la ver­
sion -l tenian que llevarse a cabo con programas extemos. Entre las capacidades que se Ie
afiadieron estaban algunas caracterfsticas del tipo de las de UNIX, tales como el redirec­
cionamiento de E/S, que es la capacidad de cambiar la identidad de la entrada 0 la salida de
una aplicacion y la impresion de fondo (background). La parte residente en memoria credo 1
hasta 24KB.
Sistemas de ejemplo 77

Cuando IBM anuneio el PC AT en 1984, Microsoft introdujo el DOS 3.0. EI AT incorpo­


raba el procesador Intel 80286, que estaba provisto con un direccionamiento ampliado y con
recursos de protecci6n de memoria. Estos no fueron utilizados por el DOS. Para mantenerse
compatible con las versiones anteriores, el sistema operativo utilizaba el80286 simplemente
o

como un "8086 nipido'~. El sistema operativo no ofrecfa ningiin soporte para los nuevos te­
clados y discos duros. Aiin asi, los requisitos de memoria aumentaron a 36KB. Hubo varias
actualizaciones notables en la version 3.0. El DOS 3.1, lanzado en 1984, tenia ya soporte
para redes de PC. EI tamafio de la parte residente no cambio; esto se consiguio aumentando
el volumen del sistema operativo que podia intercambiarse. EI DOS 3.3, lanzado en 1987,
ya daba soporte para la nueva linea de maquinas IBM, los PS/2. Una vez mas, esta version
no sacaba ventajas de las capacidades del procesador del PS/2, provisto con el 80286 y el
80386, de 32 bits. La parte residente del sistema habfa creeido hasta un minimo de 46KB,
necesitando mas cantidad si se seleccionaban ciertas opciones adici9nales.
En este tiempo, el DOS estaba siendo utilizado en un entomo que iba mas alla de sus ca­
pacidades. La introduccion del 80486 y del Pentium de Intel introdujeron potencia y carac­
terfsticas que no pueden ser explotadas por el ingenuo DOS. Mientras tanto, a comienzos de
los 80, Microsoft habia comenzado a desarrollar una interfaz gnifica de usuario (GUI, Grap­
hical User Interface) que podia colocarse entre el usuario y el DOS. La intencion de Micro­
soft era competir con los Macintosh, cuyo sistema operativo era insuperable en su facilidad
de uso. Hacia 1990, Microsoft tenia una version de GUI, conocida como Windows 3.0, que
se parecf~ a la interfaz de usuario del Macintosh. Sin embargo, este continuaba maniatado
por la necesidad de ejecutar encima del DOS.
Despues de una tentativa frustrada por parte de Microsoft de desarrollar conjuntamente
con IBM un sistema operativo de nueva generacion5 , que aprovecharia la potencia de los
nuevos microprocesadores y que incorporaria las caracterfsticas de facilidad de usa de Win­
dows, Microsoft continuo por su cuenta y desarrollo Windows NT. Windows NT puede apa­
recer ante los usuarios como si fuera Windows 3.1, pero esta basado en un concepto radical­
mente diferente. Windows NT aprovecha la potencia de los microprocesadores actuales y
ofrece una multitarea completa en un entomo monousuario.

Multitarea monousuario
Windows NT es, quiza, el ejemplo mas importante de 10 que se ha convertido en la nueva •
ola de los sistemas operativos de computadores personales (otros ejemplos son OS/2 y el
Sistema 7 de Macintosh). Windows NT se guio por la necesidad de aprovechar la tremenda
potencia de los microprocesadores de 32 bits de hoy en dia, los cuales rivalizan con las gran­
des computadores y las minicomputadores de hace unos pocos afios, tanto en velocidad
como en sofisticacion del hardware y en capacidad de la memoria.
Una de las caracterfsticas mas significativas de estos nuevos sistemas operativos es que,
aunque siguen estando orientados a dar soporte a un solo usuario interactivo, son sistemas
operativos multitarea. Dos desarrollos principales han disparado la necesidad de la multita­
rea en los computadores personales. Primero, con el aumento de la veloeidad y de la capaci­
dad de memoria de los microprocesadores, junto con el apoyo de la memoria virtual, las

IBM continu6 desarrollando el sistema OS/2 por su cuenla. Al igual que Windows l\'T, OS/2 es un sislema operalivo mo­
nousuario, multitarea y multihiioo
78 Introducci6n a los sistemas operativos

aplicaciones se han hech:otIDa$ co,n}p]ejas e.intelTelacionadas. Un usuario puede querer utili­


zar un procesador de textos, un programa de dibujo y una hoja de calcu\o simultaneamente
en una misma aplicacion para generar un documento. Sin la muititarea, si el usuario desea
crear un dibujo e incluir este dentro de un documento creado con un procesador de textos,
deberfa seguir los pasos siguientes:
1. Abrir el programa de dibujo
2. Crear el dibujo y salvar este temporalmente en un archivo 0 en un portapapeles temporaL
3. Cerrar el programa de dibujo.
4. Abrir el programa de proceso de textos.
5. Insertar el dibujo en ellugar adecuado.
Si se de sean hacer cambios, el usuario debe cerrar el procesador de textos, abrir el pro­
grama de dibujo, editar la imagen grMica, salvarla, cerrar el programa de dibujo, abrir de
nuevo el procesador de textos e insertar la imagen actualizada. Esto se convierte en algo te­
dioso de inmediato. En la medida en que los servicios y las capacidades disponibles para los
usuarios se hacen mas potentes y variadas, el entomo monotarea se hace rmls molesto y poco
amistoso. En un entomo de muititarea, el usuario abre cada aplicacion segun 10 necesita y la
deja ahierta. La infom1aci6n se puede mover con facilidad entre las distintas aplicaciones.
Cada aplicacion tiene una 0 mas ventanas abiertas y una interfaz grMica con un dispositivo
que sirve de apuntador, como puede ser un raton, que permite al usuario navegar con facili­
dad en este entomo.
Una segunda l11otivaci6n para la multitarea es el crecimiento del proceso cliente/servidor.
Con el proceso cliente/servidor, un computador personal 0 una estaci6n de trabajo (eJ
cliente) y un sistema anfitri6n 0 host (el servidor) se unen para llevar a cabo una aplicaci6n
particular. Las dos estan conectadas entre sf y a cada una se Ie asigna Ia parte del trabajo que
este acorde con sus capacidades. EI cliente/servidor se puede lograr en un red local de com­
putadores personales y servidores, 0 por mediaci6n de un enlace entre un sistema de usuario
y un host grande, como puede ser un computador central. En una aplicaci6n pueden entrar
en juego uno 0 mas computadores person ales y uno mas dispositivos servidores. Para brin­
dar el nivel de respuesta requerido, el sistema operativo tiene que dar soporte a un hardware
sofisticado de comunicaciones en tiempo real y a los protocolos asociados de comunicaci6n
y arquitecturas de transferencia de datos, mientras que, a Ia vez, da soporte a la interacci6n
con el usuario.

Descripcion
Muchos elementos influyeron en el disefio de Windows NT. Este ofrece el mismo tipo de
GUI que los productos anteriores de Windows, incluyendo el uso de ventanas, menus y la
interacci6n "sefialar y seleccionar" (point and dick). Su estructura intema esta inspirada en
el sistema operativo Mach, el cual esta basado, a su vez, en UNIX.
La figura 2.14 ilustra la estructura global de Windows NT. Esta estructura tan modular Ie da
a Windows NI una flexibilidad impresionante. NT puede ejecutar sobre varias plataformas de
hardware y dar soporte a las aplicaciones escritas para otras sistemas operativos distintos.
Como casi todos los sistemas operativos, NT diferencia el software de aplicaci6n del soft­
ware del sisteqla onerativ,Q. B.sle..UItimo ejecuta en 10 que se denomina modo privilegiado 0
modo mkleo.E\~&r~are bIt thoa6 hucleo tiene acceso a los datos del sistema y al hardware.
Cliente
Aplicaciones POSIX

Subsistema
I
Protegidos I

~ YlHJ""
~/
(Servidores) I
I
I
I"
Modo
II II I Usuano
I
r
I Modo
I
I Nlicleo
Servicios del Sistema

...
~I
?t-n
I
Ejecutor de NT 1 dor de

I
Objetos
I
Referencia
de
Seguridad
IServicio de
dor de I Procedi-
Administra- Monitor de Administra- Llamadas a

I
Procesos mientos
Locales
Administra-!
dor de I
Memoria
Virtual
i
Administrador de E/S
Sistema de Archiv~
Administrador de
Cache
Manejadores de
Dispositivos
-
~
o
Ci.:I
,..lII>
~g Paso de
Mensajes
I
l Nud,o
I

I J'Manejadores de
R,d ~/
~

I
V'l
1,;;'
Cepo del Capa de Abstraccion del Hardware (HAL)
Sistema
........ - ......
~
Il:
ManiRula­
cion ael
......................

.,
Q.

Hardware .,
~.
3
FIGURA 2.14 Estructura de Windows NT 12.
o

"

<.C
80 Introduccion a los sistemas operativos

EI software restante, que ejecuta en modo usuario, tiene acceso limitado a los datos del sis­
tema. EI software en este modo nucleo se denomina ejecutor de NT.
Tanto si esta ejecutando sobre un monoprocesador como sobre un multiprocesador, sobre
un sistema CISC 0 uno RISC, la mayor parte de NT tiene la misma vision del hardware sub­
yacente. Para alcanzar es.ta independencia, el sistema operativo consta de cuatro niveles:
• Capa de Abstraccion de hardware (HAL, Hardware Abstraction Layer): Establece una co­
rrespondencia entre las ordenes y respuestas genericas del hardware y aquellas que son pro­
pias de una platafonna especifica, como un Intel 486 0 un Pentium, un Power PC de Moto­
rola 0 un procesador Alpha de Digital Equipment Corporation (DEC). La HAL hace que el
bus del sistema de cada maquina, el controlador de DMA, el controlador de interrupciones,
los relojes de sistema y el mOdulo de memoria parezcan los mismos para el nucleo. Tambien
ofrece el soporte necesario para el multiproceso simetrico, que se explicara mas adelante.
• Nucleo: Consta de las componentes mas usadas y fundamentales del sistema operativo. EI
nucleo administra la planificacion y el cambio de contexto, la gestion de excepciones e in­
terrupciones y la sincronizacion de multiprocesadores.
• Subsistemas: Incluyen varios modulos con funciones especificas que hacen uso de los ser­
vicios basicos proporcionados por el nucleo.
• Servicios del sistema: Ofrece una interfaz al software en modo usuario.
Un subsistema concreto, el administrador de E/S, se salta la HAL para interactuar directa­
mente con .el hardware. Esto es necesario para lograr la eficiencia y la productividad reque­
ridas por las operaciones de E/S.
La potencia de Windows NT proviene de su habilidad para dar soporte a aplicaciones es­
critas para otros sistemas operativos. La fonna en que Windows NT da este soporte con un
ejecutor unico y compacto es a traves de los subsistemas protegidos. Los subsistemas prote­
gidos son aqueUas partes de NT que interactuan con el usuario final. Los subsistemas prote­
gidos ofrecen al usuario una interfaz grafica 0 de line as de ordenes que definen la apariencia
del sistema operativo para un usuario. Ademas, cada subsistema protegido proporciona la
interfaz para los programas de aplicacion (API, Application Programming lnteiface) del en­
torno particular de operacion. Esto significa que las aplicaciones creadas para un entorno
particular de operacion pueden ejecutarse sin modificaciones sobre NT, porque la interfaz
del sistema operativo que yen es la misma que para la que fueron escritas. De modo que, por
ejemplo, las aplicaciones basadas en OS/2 pueden ejecutarse en NT sin modificaciones. Mas
aun, puesto que el sistema NT esta en si mismo disenado para que sea independiente de la
platafonna, a traves del uso de la HAL, tanto los subsistemas protegidos como las aplica­
ciones que les dan soporte deben ser relativamente faciles de transportar desde una plata­
fonna de hardware a otra. En much os casos, todo 10 que se necesita es una recompilacion.
La fonna en que el ejecutor, los susbsistemas protegidos y las aplicaciones se estructuran en
NTes por medio del modelo cliente/servidor. La arquitectura cliente/servidor es un modelo de
computaci6n para sistemas distribuidos que se discutira en el capitulo 12. Esta misma arqui­
tectura puede adoptarse para su uso interno en un rnismo sistema, como es el caso de NT.
Cada servidor se implementa con uno 0 mas procesos. Cada proceso espera de un cliente
la solicitud de un servicio, como por ejemplo, servicios de memoria, de creaci6n de proce­
sos 0 de planificaci6n del procesador. Un cliente, que puede ser un programa de aplicaci6n
u otro modu10 del sistema operativo, solicita un servicio enviando un mensaje. EI mensaje
Sistemas de ejemplo 81

es encaminado a traves del ejecutor hasta el servidor apropiado. EI servidor lleva a cabo las
operaciones solicitadas y. devuelve los resultados 0 la informacion de estado por medio de
otro mensaje, que es encaminado a traves del ejecutor de regreso al cliente.
[CUST93) senala las ventajas siguientes en una arquitectura cliente/servidor:
• Simplifica el sistema operativo de base, el ejecutor de NT. Puesto que el ejecutor no
ofrece una API, es posible construir varias API sin ningun conflicto 0 duplicacion en el
ejecutor. Se pueden afiadir facilmente nuevas API.
• 'Mejora la fiabilidad. Cada servidor ejecuta un proceso independiente, con su propia parti­
cion de memoria, protegido de otros servidores. Mas aun, los servidores no pueden acce­
der directamente al hardware 0 modificar la memoria en la que se almacena el ejecutor.
Un servidor puede fallar sin que se hunda 0 corrompa el resto del sistema operativo.
• Proporciona una base natural para el proceso distribuido. Normalmente, el proceso distribuido
hace uso del modelo cliente/servidor, con llamadas a procedimientos temotos u ordenes remo­
tas que se implementan mediante mOdulos clientes y servidores distribuidos, y el intercambio
de mensajes entre clientes y servidores. En NT, un servidor local puedepasar un mensaje a otro
remoto para su procesarniento en nombre de las aplicaciones locales clientes, Los clientes no
necesitan saber si una solicitud es atendida por un servidor local 0 remoto. El hecho de que una
solicitud sea atendida de forma local 0 remota puede cambiar dinamicamente, en funcion de
.las condiciones actuales de carga y en los cambios dinamicos de configuracion.

Hilos6
Un aspecto importante de Windows NT es su soporte de hilos dentro de los procesos. Los hi­
los incorporan algunas de las funciones asociadas tradicionalmente con los procesos. Se
puede hacer la siguiente distincion:
• Hila: Una unidad de trabajo que se puede expedir para ejecucion. Es 10 que se ejecuta se­
cuencialmente y es interrumpible para que el procesador puede pasar a otro hilo. Desde el
punto de vista de la planificacion y la expedicion, este concepto es equivalente al de pro­
ceso en la mayoria de los demas sistemas operativos.
• Procesa: Una coleccion de uno 0 mas hilos y recurs os del sistema asociados (tales como
memoria, archivos abiertos y dispositivos). Esto se acerca mucho al concepto de pro­
grama en ejecucion. Dividiendo una aplicacion sencilla en varios hilos, el programador
tiene un gran control sobre la modularidad de la aplicacion y la temporizacion de los su­
cesos relativos a la aplicacion. Desde el punto de vista del trabajo 0 la aplicacion, este
concepto es equivalente al de proceso en la mayoria de los sistemas operativos.
Los hilos y los procesos se examinaran en detalle en el capitulo 3.

Multiproceso simetrico
Hasta hace poco, casi todos los computadores personales y las estaciones de trabajo tenfan
un nnico microprocesador de proposito generaL A medida que las demandas de rendimiento
aumentan y el coste de los microprocesadores continua bajando, esta imagen cambia. Los
fabric antes estan introduciendo sistemas con varios microprocesadores. Para alcanzar una

I Threads, en el original (N. del T.)


82 Introducci6n a los sistemas operativos

maxima eficiencia y fiabilidad, es conveniente un modo de operacion conocido como multi­


proceso simetrico (SMP, Symmetric MultiProcessing). Basicarnente, con SMP, cualquier
hilo 0 proceso puede ser asignado a cualquier procesador. Esto incluye a los procesos e hilos
del sistema operativo.
Uno de los requisitos clave en el diseiio de los sistemas operativos contemponineos es la
capacidad de explotar el SMP. [CUT93] enumera las siguientes caracterfsticas de Windows
NT que dan soporte aluso de SMP:
• Las rutinas del sistema operativo se pueden ejecutar en cualquier procesador disponible y
rutinas diferentes pueden ejecutarse simultanearnente en diferentes procesadores.
• NT permite el uso de varios hilos de ejecucion dentro de un solo proceso. En un mismo
proceso pueden ejecutarse varios hilos en diferentes procesadores simultanearnente.
• Los procesos servidores pueden utilizar varios hilos para procesar solicitudes de mas de
un cliente simultanearnente.
• NT brinda los mecanismos oportunos para compartir datos y recursos entre los procesos,
as! como capacidades flexibles de comunicacion entre procesos.

Objetos de -Windows NT
Windows NT se sustenta fuertemente en los conceptos del disefio orienta do a objetos. Este
enfoque facilita la comparticion de recursos y datos entre los procesos y la protecci6n de los
recursos ante usuarios no autorizados. Entre los conceptos clave empleados por NT estan los
siguientes:
• Encapsulamiento: Un objeto consta de uno 0 mas elementos de datos, Barnados atributos y
uno 0 mas procedimientos que pueden actuar sobre los datos, llarnados servicios. La unica
manera de acceder a los datos de un objeto es invocando a uno de los servicios del objeto.
As! pues, los datos en el objeto pueden ser protegidos faciImente ante usos no autorizados
e incorrectos (por ejemplo, tratar de ejecutar un elemento de datos no ejecutable).
• Clases e instancias: Una clase de objeto es una plantilla que enumera los atributos y los
servidos de un objeto y define ciertas caracterfsticas del objeto. EI sistema operativo
puede crear instancias especfficas de· una clase de objeto cada vez que 10 necesite. Por
ejemplo, hay una clase de objeto para procesos simples y un objeto proceso para cada pro­
ceso en activo. Este enfoque simplifica la creacion y gestion de objetos. •
EI lector no farniliarizado con los conceptos de orientaci6n a objetos deberfa revisar el
Apendice B al final del Iibro.
No todas las entidades de Windows NT son objetos. Los objetos se usan en los casos en
que los datos se abren para su acceso en modo usuario 0 cuando el acceso a los datos es
compartido 0 restringido. Entre las entidades representadas por objetos se encuentran los ar­
chivos, los procesos, los hilos, los semaforos, los temporizadores y las ventanas. NT crea y
administra todos los tipos de objetos de una manera uniforme, a traves de un volumen de co­
digo del nucleo, conocido como el administrador de objetos. EI administrador de objetos es
responsable de la creacion y destruccion de los objetos a peticion de las aplicaciones, as!
como de conceder ela<:ceso a los servicios y datos de un objeto. .
Un objeto ~por ejemplo, un proceso) puede hacer referenda a otro (por ejemplo, un ar­
chivo) abriendo un descriptor (handle) del mismo. Basicamentt', un descriptor es un puntero
Sistemas de ejemplo 83

al objeto referido. En NT, los objetos pueden tener nombre 0 no. Cuando un proceso crea un
objeto sin nombre, el administrador de objetos devuelve un descriptor del objeto, que es la
unica forma de hacer referencia al objeto. Los objetos con nombre disponen de un nombre
que pueden usar otros procesos para obtener un descriptor del objeto. Por ejemplo, si el pro­
ceso A desea sincronizarse con el proceso B, podua crear un objeto suceso con nombre y pa­
sarle aBel nombre del suceso. El proceso B podria abrir y usar este objeto suceso. Sin em­
bargo, si A solo desea utilizar el suceso para sincronizar dos hilos dentro de sf mismo,
entonces podrfa crear un objeto suceso sin nombre, porque no hay necesidad de poder usar
el suceso para otros procesos.
Una distincion importante entre los objetos con nombre y sin nombre es que los prime­
ros siempre tienen informacion de seguridad asociada a elIos, en forma de una senal de ac­
ceso (access token). Puede emplearse la informacion de seguridad para restringir el acceso
al objeto. Por ejemplo, un proceso puede crear un semaforo con nombre con la intencion de
que solo los procesos que conozcan su nombre sean capaces de abrir y usar el semaforo. La
senal de acceso asociada con el objeto semaforo enumerara aquellos procesos (en realidad,
los identificadores de los usuarios que son propietarios de los procesos) que pueden acce­
der al semaforo.
Windows NT no es un sisrema operativo completamente orientado a objetos. No esta im­
plementado en un lenguaje orientado a objetos. Las estructuras de datos que residen por
completo dentro de un mismo componente del ejecutor no se representan como objetos.
Ademas, NT no ofrece soporte para algunas capacidades habituales de los sistemas orienta­
dos a objetos, tales como la herencia y el polimorfismo. No obstante, NT ilustra la potencia
de la tecnologia orientada a objetos y representa la tendenda creciente a usar esta tecnologia
en el diseno de sistemas operativos.

SISTEMA UNIX, VERSION V


Historia
La historia de UNIX es una historia muchas veces contada que no se va a repetir aquf con
mucho detalle. En su lugar, se ofrecen'i. un breve resumen.
UNIX fue desarrollado inidalmente en los Laboratorios Bell y llego a ser operativo en
una PDP-7 en 1970. Algunas personas involucradas de los Laboratorios Bell tambien habfan
participado en el trabajo sobre tiempo compartido que se llevaba a cabo en el proyecto MAC
del MIT7. Aquel proyecto llev6 primero al desarrollo del CTSS y luego al de Multics. Aun­
que es habitual decir que UNIX es una versi6n a pequena escala de Multics, los desarrolla­
dores de UNIX dicen estar mas influenciados en realidad por CTSS [RITC78b], Sin em­
bargo, UNIX incorpor6 muchas ideas de Multics.
Merece la pena comentar algo sobre Multics. Multics estuvo no s610 anos sino decadas
adelantado a su tiempo. lnduso a mediados de los 80, casi 20 anos despues de que llegara a
ser operativo, Multics disponfa de caracterfsticas de seguridad superiores y una mayor sofis­
ticaci6n.en la interfaz de usuario yen otros campos que los sistemas operativos contempo­
raneosde los grandes computadores que puedan compararse. Aunque los desarrolladores de

7 SigJas de Massachusetts Institute a/Technology (N. del T.)


,..­

84 Introducci6n a los sistemas operativos

UNIX abandonaron el proyecto de Multics porque, segun su opinion, este fue un fracaso,
Multics fue cedido despues·a Honeywell y llego a disfrutar de un. modesto exito comercial.
Lo que tuvo Honeywell no 10 tuvieron los otros dos sistemas operativos de grandes compu­
tadores, uno de los cuales fue comercializado de forma muy agresiva. Multics pudo haber
tenido un gran exito. Sin. embargo, Multics permanecio como un producto de Honeywell
con una pequena, pero fiel, base de clientes, hasta que Honeywell abandono el negocio de la
informatica a finales de los 80.
Mientras tanto, el trabajo sobre UNIX en los Laboratorios Bell y, despues, en otros luga­
res, produjo una serie de versiones de UNIX. El primer hito notable fue llevar el sistema
UNIX de la PDP-7 a una PDP-II. Esta fue la primera senal de que UNIX seria un sistema
operativo para todos los computadores. El siguiente hito importante fue la reescritura de
.UNIX en el lenguaje de programacion C. Esta fue una estrategia inaudita en aquel tiempo.
Era de consenso general que algo tan complejo como un sistema operativo, que tenia que
tratar con sucesos de tiempo cntico, tenia que ser escrito exclusivainente en lenguaje en­
samblador. La implementacion en C demostro las ventajas de usar un lenguaje de alto nivel
para la mayor parte del codigo del sistema, si no todo. Hoy en dfa, casi todas las implemen­
taciones de UNIX estan escritas en C.
Estas primer as versiones de UNIX fueron muy populares en los Laboratorios Bell. En
1974, el sistema UNIX fue descrito por primera vez en una revista tecnica [RITC74). Esto
desperto gran interes en el sistema. Se otorgaron licencias de UNIX a instituciones comer­
ciales y universidades. La primera version ampliamente disponible fuera de los Laboratorios
Bell fue la Version 6, en 1976. La siguiente, la version 7, lanzada en 1978, es el antepasado
de la mayona de los sistemas UNIX modernos. EI mas importante de los sistemas no desa­
rrollados por AT&T8 fue el realizado en la Universidad de California en Berkeley. Se Ie
llamo UNIX BSD y ejecutaba primero en una PDP y, mas tarde, en maquinas VAX. AT&T
continuo desarrollando y refinando el sistema. Hacia 1982, los Laboratorios Bell habian
combinado varias variantes del UNIX de AT&T en un unico sistema, que fue comerciali­
zado como Sistema UNIX, version III. Posteriormente se Ie anadio un cierto numero de ele­
mentos hasta llegar al Sistema UNIX, version V.
Este libro utiliza el Sistema UNIX, version V como ejemplo de UNIX. En el momento
de escribir este libro, parece que esta llegara a ser la version comercial dominante de
UNIX. Ademas, incorpora la mayoria de las caracteristicas importantes desarrolladas en
cualquier sistema UNIX y 10 hace de forma integrada y factible comercialmente. El Sis- ~
tern a V funciona actualmente en maquinas que van desde microprocesadores de 32 bits
hasta supercomputadores yes, sin duda, uno de los sistemas operativos mas importantes
que se han desarrollado.

Descripcion
La figura 2.15 Ofrece una descripcion general de la arquitectura de UNIX. El hardware ba­
sico ~sta rodeado por el software del sistema operativo. El sistema operativo se llama a me­
nudo nucleo del sistema 0, simplemente, micleo (kernel), para realzar su aislamiento de las
aplicaciones y de los.usuarios. Esta parte de UNIX sera de interes para su utilizacion como

• Siglas de American Telegraph and Telephone (N. del T.)


Sistemas de ejemplo 85

ejemplo en este libro. Sin embargo, UNIX viene equipado con una serie de servicios de
usuario e interfaces que se consideran parte del sistema. Estos pueden agruparse en un shell,
algun otro software de interfaz y las componentes del compilador de C (compilador, ens am­
blador, cargador). La c;apa exterior esta formada por las aplicaciones de los usuarios y una
interfaz de usuariocon el compilador C.
En la figura 2.16 se ofrece una mirada de cerca al nucleo. Los programas de usuario pue­
den invocar a los servicios del sistema operativo directamente 0 a traves de programas de bi­
blioteca. La interfaz de llamadas al sistema es la frontera con el usuario y Ie permite al soft­
ware de alto nivel el acceso a las funciones especfficas del nucleo. En el otro extremo, el
sistema operativo contiene rutinas primitivas que interacttian directamente con el hardware.
Entre estas dos interfaces, el sistema esti dividido en dos partes fundamentales, una ocupada
del control de los procesos y la otra relacionada con la gestion de archivos y la E/S. EI sub­
sistema de control de procesos es el responsable de la gestionde memoria, la planificacion
y expedicion de los procesos y la sincronizacion y comunicacion entre procesos. El sistema
de archivos intercambia los datos entre la memoria y los dispositivos extemos, tanto en flu­
jos de caracteres como en bloques. Para lograr esto, se utilizan varios manejadores de dis­
positivo. Para las transferencias de bloques se utiliza un metodode cache de disco: Se co­
loca un buffer del sistema en la memoria principal entre el espacio de direcciones. del
usuario y el dispositivo extemo.

Programas de Aplicaci611

Editores de Shell y

Programas Privados de

Usuarios

Nucleo
!5

8
."
..!!l
's..
§
u

FIGURA 2.15 Arquitectura global de UNIX


- 86 Introducci6n a los sistemas operativos

MVS
Historia
Hacia 1964, IBM estaba finnemente establecida en el mere ado de computadores con sus
maquinas de la serie 7000. En aquel ano, IBM anuncio el Sistema/360, una nueva familia de
productos de computadores. Aunque el anuncio en sf no fue una sorpresa, venia con algunas
noticias poco agradables para los clientes de IBM: la linea de productos 360 era incompati­
ble con las viejas maquinas de IBM. Por tanto, la transicion al 360 serfa dificil para la base
de usuarios. Esto fue un paso audaz de IBM pero que se crefa necesario para romper con al­
gunas de las limitaciones de la arquitectura 7000 y fabricar un sistema capaz de evolucionar
con la nueva tecnologia de circuitos integrados. La estrategia sali6 bien tantofinanciera
como tecnicamente. El 360 fue el exito de la decada y asent6 IBM como el irresistible ven-

Cepo __
Nivel de Usuario .
'Ni~~l'd~i'N6'~I~~''''''''''''''''''''''''''''''''''''''''''''''''''''''~
----1
~<:':::r........................................................................................

Interfaz de Llamadas a1 Sistema

Comunicaci6n
entre Procesos
Subsistemas de Archivos

Subsistemas
de Control de Planificador
Procesos

Gesti6n de
Memoria

Nucleo
·Ni~~l·d~i·H~;~-:~~~ ..·..···········..·····.. ···..··········....................................................................................................

FIGURA 2.16 Diagrama de bloques del nucleo de un sistema UNIX [BACH861



Sistemas de ejemplo 87

dedor de computadores con una cuota de mercado superior al 70%. Con algunas modifiea­
ciones y ampliaciones, laarquitectura del 360 se ha mantenido hasta el dia de hoy, mas de un
cuarto de siglo despues, como la arquitectura de los grandes computadores IBM.
Aunque el software del sistema operativo de los computadores centrales de IBM ha cam­
biado mas alla de 10 que se reconoce como la oferta inicial del 360, sus origenes se remon­
tan a aquellos primeros tiempos. El Sistema/360 fue la primera familia de computadores
planificada por la industria. La familia cubria un amplio rango de rendimiento y coste. Los
,.
diferentes modelos eran compatibles en el sentido de que un programa escrito para un mo­
delo era capaz de ejecutarse en otro modelo de la misma familia con diferencias s610 en el
tiempo necesario para ejecutar. Por esto, el primer sistema operativo que fue anunciado para
las nuevas maquinas, el OS/360, intentaba ser un sistema operativo tinieo que pudiera ope­
rar con todas las maquinas de la familia. Sin embargo, el amplio abanico de la familia 360 y
la diversidad de las necesidades del usuario obligaron a IBM a introducir varios sistemas
operativos. Se centrara la atenci6n en la linea de desarrollo que origin6 el MVS.
EI OS/360 original fue un sistema por lotes con multiprogramaci6n y permaneci6 asf por un
cierto tiempo. Su versi6n mas completa, el MVT (Multiprogramaci6n con un ntimero Variable
de Tareas), fue lanzado en 1969 y fue la mas flexible de las variantes del OS/360. La asigna­
ci6n de memoria para un trabajo era variable y no tenia que decidirse hasta la ejecuci6n. LIeg6.
a ser el sistema operativo mas popular de las grandes IBM/360 y en las primeras IBM/370.
MVT omiti6 algunas de las caracteristieas presentes en las ofertas de sus competidores mas
avanzados, como la capacidad para dar soporte a multiprocesadores, el almacenamiento vir­

-
tual y depuraci6n a nivel de fuente, pero brind6 un conjunto de servicios y utilidades de apoyo
mas completo que cualquiera de los sistemas operativos contemponineos. En campos tales
como la planificaci6n de trabajos, el soporte de perifericos, la cantidad de sistemas diferentes
y la conversion desde los sistemas anteriores, el OS/360 fue inigualab1e {WEIZ81].
MVT permitia que solo ejecutaran 15 trabajos concurrentemente. OS/SVS (Single Virtual
Storage, Almacenamiento Virtual Simple) fue introducido en el ano 1972 como un sistema
operativo provisional para sacar partido de la arquitectura IBM/370. El afiadido mas notable
fue dar soporte a la memoria virtuaL En el SVS se estableda un espacio de direcciones vir­
tual de 16MB. Sin embargo, este espacio de direcciones tenia que ser compartido entre el
sistema operativo y todos los trabajos activos. Muy pronto, incluso esta cantidad de memo­
~ ria se·haria inadecuada.
Como respuesta al crecimiento de las necesidades de memoria de los programas de apli­
caci6n, IBM introdujo el MVS. Al igual que en el SVS Y como dictaba la arquitectura 370,
las direcciones virtuales estaban limitadas a 24 bits (de ahi los 16 MB). Sin embargo, con el
MVS, ellfmite es de 16 MB par trabajo. Es decir, cada trabajo tiene su propia memoria vir­
tual dedicada de 16 MB. El sistema operativo traduce los bloques de memoria virtual a la
memoria real y es capaz de seguir la pista de las memorias virtuales separadas para cada tra­
bajo. En realidad, cada trabajo normalmente dispone de algo menos de la mitad de la me­
moria virtual asignada; el resto esta disponible para el sistema operativo.
El espacio de direcciones de 24 bits, con memoria virtual separada para cada trabajo, en breve
lleg6 a ser poco aprQpia~o para algunos usuarios. IBM amplio su procesador basico para que ma­
nejase direcciones de 3 I bits, una caracteristica conocida como direcciones ampliadas (XA, ex­
lit tended addressing). Para sacar partido de este nuevo hardware, en 1983 se introdujo una nueva
version de MVS, conocida como MVS/XA. Con el MVS/XA, el espacio de direcciones por ta­
88 Introduccion a los sistemas operativos

rea crecio a un maximo de 2GB (gigabytes). Esto, se crea 0 no, atill se considera inapropiado para
algunos entornos y aplicaciones. Por consiguiente, en 10 que puede representar la ultima mayor
ampliacion de la arquitectura 370 (de la 360, en realidad), IDM desarrollolaArquitectura de Sis­
temas Empresariales (ESA, Enterprise System Architecture) y un sistema operativo mejorado, el
MVS/ESA El mismo espacio de direcciones de 2GB por trabajo que estaba disponible en el
MVS/XA esrn tambien disponible para programas y datos. Lo nuevo es que hay hasta 15 espa­
cios de direcciones adicionales de 2GB de datos disponibles solo para un trabajo especifico. Por
tanto, el espacio maximo direccionable de memoria virtual por trabajo es de 32GB.

Descripcion
MVS es, probablemente, el sistema operativo mas grande y complejo desarrollado jamas.
Requiere un minima de 2MB de almacenamiento residente. Una configuraci6n mas realista
requiere 6MB para el sistema operativo. Los cuatro factores mas importantes que han deter­
minado el disefio de MVS son los siguientes: .
• Soporte para trabajos interactivos y por Iotes
• Almacenamiento virtual de hasta 32GB por trabajo 0 usuario
• Multiproceso fuertemente acoplado; esta arquitectura, que se examinara en el capitulo 9,
consiste en una serie de procesadores que comparten la misma memoria principal.
• Asignaci6n sofisticada de recursos y servicios de supervision para lograr un uso eficiente de
la gran memoria del sistema, multiples procesadores y estructura compleja de canales de E/S.
La necesidad de tratar con varios procesadores es un requisito que no se plantearon OS/2
ni el Sistema UNIX, version V. Cuando hay varios procesadores, donde cada uno de los cua­
les puede ejecutar cualquiera de los procesos y cuando se da soporte a la comunicacion en­
tre procesos que ejecutan en diferentes procesadores, la complejidad del sistema operativo
puede ser significativamente mayor que en una maquina con un monoprocesador.
La figura 2.17da una vision simplificada de los bloques principales constituyentes. Un
shell extemo contiene los servicios y las interfaces visibles para los usuarios y los operado­
res del sistema responsables de su mantenimiento y ajuste. Ademas de una coleccion de pro­
gramas necesarios para la creaci6n y compilacion de programas, hay un subsistema de ges­
tion de trabajos con las siguientes funciones:
• Interpreta las ordenes del operador (desde la consola del operador) y encamina los mensa-'
jes adecuados.
• Lee los datos de entrada del trabajo y escribe los datos de salida del trabajo en los disposi­
tivos perifericos.
• Asigna los dispositivos de E/S a un trabajo y notifica al operador de cualquier unidad fisica
de datos (rollo de cinta, paquete de discos) que debe montarse antes de ejecutar el trabajo.
• Convierte cada trabajo en tareas que pueden ser procesadas por el administrador de tareas.
Por ultimo, el shell extemo incluye un elaborado subsistema de gestion para la recupera­
cion de errores, que asegura que los fallos del trabajo quedan aislados de modo que no difi­
culten el resto del funcionamiento y que puedan diagnosticarse. Si es posible, se permitini a
los trabajos afectados por el error que contimien su ejecucion.
El nucleo del sistema operativo consta de un conjunto de modulos principales 0 subsiste­
mas que interacUian uno con otro, el hardware y el shell externo, Estos incluyen 10 siguiente:

Sistemas de ejemplo 89

• Distribuidor: El distribuidor puede verse como el administrador de los procesadores. Su


funcion es recorrer la cola de tareas listas y planificar la ejecucion de una.
• Tratamiento de interrupciones: La arquitectura del Sistema/370 da soporte a una amplia
variedad de interrupciones. Cualquier interrupcion hace que se suspenda el proceso en
curso y se pase el control a la rutina de tratamiento apropiada.
• Gestion de tareas: Una tarea es, basicamente, un proceso, en el sentido en que se ha usado
este termino. La gestion de tareas es la responsable de la creacion y eliminacion de las ta­
.;II.
· reas, el control de sus prioridades, la gestion de las colas de tareas de los recursos reutili­
zables en serie (por ejemplo, los dispositivos de E/S) y la sincronizacion de los sucesos.
• Gestion de programas: Este modulo es responsable de enlazar los pasos necesarios involu­
crados en la ejecucion de un programa. Este modulo puede ser controlado por ordenes del
JCL 0 en respuesta a las solicitudes de los usuarios para compilar y ejecutar un programa.
• Gestion del almacenamiento: Este modulo es el responsable de administrar la memoria
real y virtual.
• Gestion de recursos del sistema: Este modulo es el responsable dy la asignacion de los re­
cursos a los espacios de direcciones (procesos).
• Metodos de acceso: Un programa de aplicacion suele emplear un metoda de acceso para
llevar a cabo una operaci6n de E/S. Un metodo de acceso es una interfaz entre el programa
de aplicacion y el supervisor de E/S. Los metodos de acceso liberan al programa de apli­
cacion de la carga de escribir program as para los canales, construyendo los bloques de

.
control requeridos por el supervisor de E/S y manejando las condiciones de terminacion .
• Supervisor de EIS: El supervisor de E/S lleva a cabo la inicializacion y terminacion de las
operaciones de E/S a nivel del hardware. Genera la instruccion de Inicio de E/S, que pro­
voca que el procesador de un canal de E/S ejecute un programa de E/S en la memoria prin­
cipal y tambien trata la interrupcion que se origina al completarse la operacion de E/S.
Merece la pena comentar unas palabras sobre el gestor de recursos del sistema (SRM, Sys­
tem Resource Manager). El SRM dota al MVS de un grado de sofisticacion unico entre los
sistemas operativos. Ningun otro sistema operativo de computadores centrales e, incluso,
ningl1n otro sistema operativo, puede igualar las funciones que lleva a cabo el SRM.
El concepto de recurso incluye al procesador, la memoria real y los canales de E/S. Para llevar
... a cabo la tarea de asignacion de recursos, el SRM acurnula estadisticas relativas al uso del proce- •
sador, los canales y varias estructuras de datos clave. Su propos ito es el de ofrecer un rendimiento
optimo, basandose en el anruisis y supervision del rendirniento. Durante la instalacion se estable­
cen varios objetivos de rendirniento y estos sirven de guia al SRM, que modifica dimimicamente
las caracteristicas de la instalacion y del rendirniento de los trabajos en funcion de la utilizacion
del sistema. Sucesivamente, el SRM ofrece los informes que capacitan al operador formado para
refmar la configuracion y los valores de los panimetros y asf mejorar el servicio al usuario.
Un ejemplo puede mostrar el sabor de las actividades del SRM. La memoria real se di­
vide en bloques de igual tamano, denominados marcos (encuadres), de los que puede haber
varios millares. Cada marco puede albergar un bloque de memoria virtual, que se conoce
como pagina. EI SRM recibe el control aproximadamente 20 veces por segundo e inspec­
ciona cada uno de los marcos de pagina. Si la pagina no ha sido referenciada 0 cambiada,
se incrementa en 1 un contador. Despues de un cierto periodo, el SRM promedia estos nu­
'.
meros para determinar el numero medio de segundos que una pagina permanece sin tocar.
90 Introducci6n a los sistemas operativos

Gestion de Trabajos

Gestion
de
Distribuidor

Metodos de ~IdldUl1~I~lU ~] Gestion de


Acceso InterrupClones Tareas

Gestion de Gestion de
Programas I Gesti6n del I Recursos del
Almacenamiento
Sistema

Compiladores, Montadores,
Editores, Cargadores

FIGURA 2.17 Vision simplificada de los bloques constituyentes del sistema operativo MVS [PRAS81]

El operador del sistema puede revisar esta cantidad para determinar el nive! de "tensi6n"
del sistema. Reduciendo el numero de trabajos activos permitidos en el sistema, este pro­
medio puede mantenerse alto. Una guia util es que la media debe mantenerse por encima de
los 2 minutos para evitar problemas serios de rendimiento [JOHN89]. Esto puede parecer
demasiado, pero no 10 es.

2.5
VISION GENERAL DEl RESTO DEL lIBRO

Los dos primeros capitulos han aportado una panonimica de la arquitectura de los computa­
dores y los sistemas operativos y una introducci6n al resto dellibro. Esta secci6n ofrece una
breve sinopsis de los capftulos restantes.
. Vision general del resto del Iibro 91

Descripcion y Control de Procesos


El concepto de proceso es central para el estudio de los sistemas operativos y se exa­
mina en detalle en el Capitulo 3. Se definen los descriptores de procesos y los de scrip­
tores de recursos logico$. Un examen de los elementos tfpicos de estos descriptores
sienta las bases para una discusion de las funciones relativas a los procesos llevadas a
cabo por el sistema operativo. Se describen las primitivas de control de procesos. Tam­
bien se presenta una descripcion del estado de los procesos (listo, ejecutando, blo­
queado, etc.). El nuevo e importante concepto de hilo tambien se examina con cierto de­
'" taUe en este capitulo.

Concurrencia
Los dos temas centrales de los sistemas operativos modernos son la multiprogramacion y el
proceso distribuido. La concurrencia es fundamental para ambos temas y fundamental para
el disefio de la tecnologia de los sistemas operativos. Cuando se ejecutan varios procesos
concurrentemente, bien sea en el caso real de un sistema multiprocesador 0 en el caso virtual
de un sistema monoprocesador multiprogramado, aparecen cuestiones de resolucion de con­
flictos y de cooperacion. El capitulo 4 examina los mecanismos de resolucion de conflictos
en el contexto de las secciones crfticas que deben controlarse en la ejecucion de los proce­
sos. Los sematoros y los mensajes son dos tecnicas clave empleadas en e] control de las sec­
ciones crfticas, aplicando una disciplina de exclusion mutua. Por ello, eJ capitulo 5 analiza
dos problemas que atormentan todos los esfuerzos de realizar proceso concurrente: el inter­
bloqueo y la inanicion.
41

Gestion de memoria
Los capitulos 6 y 7 tratan de la gestion de Ja memoria principal. EJ capitulo 6 brinda
una descripcion de los objetivos de la gestion de memoria en terminos del problema de
la superposicion y de la necesidad de proteccion y comparticion. EJ capitulo continua
con una discusion de la carga de programas y del concepto de reubicacion. Esto con­
duce a una discus ion sobre la paginacion y la segmentacion. Se discuten los mecanis­
mos de direccionamiento necesarios para dar soporte a la paginacion y la segmenta­
cion. Despues, el capitulo 7 trata sobre el uso de la paginacion 0 de la paginacion y la
segmentacion, para disponer de memoria virtual. En el capitulo se incluye una discu­
'" sian sobre la interaccion entre el hardware y el software, la memoria principal, la me­
f

moria secundaria, la cache, la segmentacion y la paginacion. El objetivo es mostrar


como todos estos objetos y mecanismos pueden integrarse en un esquema global de
gestion de memoria.

Planificacion
El capitulo 8 comienza con un examen de los tres tipos de planificacion del procesador: a
largo plazo, a medio plazo y a corto plazo. Las cuestiones de la planificaci6n a largo y me­
dio plazo tambien se examinan en los capitulos 3 y 5, por 10 que el grueso del capitulo se
centra en los aspectos de la planificaci6n a corto plazo. Se examinan y comparan los dife­
rentes algoritmos que se han probado. EI capitulo 9 trata de los aspectos de planificaci6n re­
lativos especificamente a las configuraciones con multiprocesadores. Por ultimo, el capitulo
.. atiende a las consideraciones de disefio de la planificaei6n en tiempo real.
.,.
92 Introducci6n a los sistemas operativos

Gestion de la E/S y planificadon de discos

El capitulo 10 comienza con un resumen de los aspectos de E/S de la arquitectura del com­

putador y luego pasa a los requisitos que la E/S impone sobre el sistema operativo. Se anali­

zan y comparan diversas estrategias de amortiguamiento (buffering). Despues se exploran

algunos aspectos relativos a laE/S con el disco, inc1uyendo la planificacion de discos yel

uso de caches de disco.

Gestion de archivos
El capitulo 11 discute laorganizacion fisica y logica de los datos. Examina los servicios re­
..
lativos a la gestion de archivos que un sistema operativo tipico proporciona a los usuarios.
Desp1,les se observan los mecanismos y las estructuras de datos especificas que forman parte
de un sistema de gestion de archivos.

Redes y proceso distribuido


Los computadores operan cada vez mas no de forma aislada, sino formando parte de una red
de computadores y terminales. El capitulo 12 comienza con una revision dei concepto de ar­
quitectura de comunicaciones, poniendo un enfasis especial en el Modelo de Interconexion
de Sistemas Abiertos (OSI, Open Systems lnterconection) yen el TCP/IP. El capitulo estudia
el concepto cada vez mas importante de proceso cliente/servidor y los requisitos que esta ar­
quitectura impope a los sistemas operativos. El resto el capitulo analiza dos tecnicas de co­
municaci6n entre procesos que son c1aves para el proceso distribuido: el paso distribuido de
mensajes y las llamadas a procedimientos remotos. Despues, el capitulo 13 examina los ele­
mentos clave de los sistemas operativos distribuidos, inc1uyendo la migracion de procesos, '"
la determinacion de estados globales distribuidos y los mecanismos de exclusion mutua y de
deteccion y prevenci6n del interbloqueo.

Seguridad
El capitulo 14 comienza examinando los tipos de amenaza a los -que se enfrentan los com­
putadores y las comunicaciones. EI grueso del capitulo trata de las herramientas especificas
que pueden usarse para aumentar la seguridad. Lo primero en examinarse son los enfoques
tradicionales de la seguridad de los computadores, que se basan en la protecci6n de los dis­
tintos recursos del computador y, entre ellos, la memoria y los datos. Se sigue con una dis- f

cusion de un reciente tipo de amenaza, cada vez mas preocupante: el planteado por los virus
y mecanismos similares. A continuaci6n, se examina un enfoque relativamente nuevo de la
seguridad, los sistemas de confianza. La parte principal del capitulo termina con una mirada
a la ,seguridad en redes. Por ultimo, en un ap6ndice de este capitulo se presenta el cifrado,
que es una herramienta basica empleada en much as aplicaciones de seguridad .

. Analisis de colas -
Una herr~ienta importante que debe estar al alcance de cualquier interesado en la informa­
tica es elanruisis de colas . Muchas problemas del diseiio de los sistemas operativos y del pro­
ceso distribuido, asf como en muchos otros campos de la informatica, pueden representar-se
por un modelo de colas. EI analisis de colas posibilita al analista el rapido desarrollo de una
caracterizaci6n aproximada del comportamiento de un sistema bajo un regimen de carga. El
Ap6ndice A ofrece una introducci6n practica sobre como realizar un amilisis de colas.
leduras recomendadas 93

Diseiio orientado a objetos


Los conceptos de orientacion a objetos estan teniendo una importancia creciente en el di­
sefio de los sistemas operativos. Uno de los sistemas de ejemplo de este libro, Windows NT,
hace un amplio uso de las tecnicas de orientacion a objetos. El Apendice B ofrece una pano­
nunica de los principios esenciales del disefio orientado a objetos.

Orden de los temas


Es nonnal que ellector se pregunte sobre el orden particular que siguen los temas de este li­
bro. Por ejemplo, el tema de planificacion (capitulos 8 y 9) esta estrechamente relacionado
con los de concurrencia (capitulos 5 y 6) Y con el tema general sobre procesos (capitulo 3) y
podria abordarse de fonna razonable inmediatamente despues de dichos temas.
La dificultad estriba en que los distintos temas estan muy. interrelacionados. Por
ejemplo, en la discusion de la memoria virtual, es utiI poder hacer referencia a los as­
pectos de la planificadon relativos a los fallos de pagina. Por supuesto, tambien es
util poder hacer referenda a los aspectos de gesti6n de memoria cuando se discuten
las decisiones de planificacion. Este tipo de ejemplo puede repetirse indefinida­
mente: Una discusion de la.planificacion necesita derta comprension de la gestion de
la E/S y viceversa. .
La figura 2.18 propone algunas de las interrelaciones mas importantes entre los temas.
Las lineas.gruesas sefialan las relaciones mas fuertes, desde el punto de vista de las ded­
siones de disefio e implementadon. Basandose en este diagrama, parece tener senti do em­
pezar con un examen basico de los procesos, que se reaIizara, de hecho, en el capitulo 3.
Despues de esto, el orden es, en cierto modo, arbitrario. Muchos estudios de los sistemas
operativos cargan todas las tintas al principio sobre los procesos, para luego ocuparse de
otros temas. Esto es valido, desde luego. Sin embargo, la significacion central de la ges­
tion de memoria, que yo considero de igual importancia que la gestion de procesos, ha lIe­
vado hacia la conclusion de presentar este tema antes de abordar una vision en profundi­
dad de la planificacion.
La solucion ideal para e1 estudiante es, despues de completar sucesivamente los capitulos
. dell al 3, leer y asimilar los siguientes capitulos en paralelo: el4 seguido (opcionaImente)
por el 5; el6 seguido (opcionaImente) por 7; el8 seguido (opcionaImente) por eI 9; yel lO.
Por ultimo, se pueden estudiar los restantes capitulos en cualquier orden: el 11; el 12 se­
guido por el13; y el14. Sin embargo, aunque el cerebro humano puede dedicarse al proceso
paraleIo; el estudiante puede encontrar imposible (y costoso) trabajar de manera fructifera
con cuatro copias de un mismo Iibro abiertas simultaneamente por cuatro capftulos diferen­
tes. Dada la necesidad de una ordenadon lineal, creo que el orden empleado en este libro es
el mas efectivo.

2.6
LECTURAS RECOMENDADAS
Al igual que en el campo de Ia arquitectura de los computadores, hay muchos Iibros sobre los siste­
mas operativos. [SILB94], [TANE92], [MILE92] y [DEIT90] cubren los principios basicos usando
94 Introducci6n a los sistemas operativos

Planificacion
Gesti6n de
Concurrencia •

Gesti6n de
la E/S

FIGURA 2.18 Temas sobre un Sistema Operativo

un mlmero importante de sistemas operativos como casos de estudio. [SING94a], [NUTT92] y


[MAEK97] tratan los temas de los sistemas operativos a un nivel mas avanzado.
Ahora se consideran los libros dedicados a los sistemas operativos de ejemplo tornados en esta obra. "
En el caso de UNIX, a v.eces parece que hay tantos libros como computadores funcionando con dicho
sistema. En el ultimo recuento, s610 Prentice Hall tenia mas de 100 libros de UNIX en lista. Sin em­
bargo, casi todos estos libros tratan sobre el uso de UNIX mas que sobre sus mecanismos internos y ar­
quitectura. Para el Sistema UNIX, version V, [BACH96] ofrece un tratamiento defmitivo, con amplios
detalles tecnicos. Una referencia menos detallada y mas asequible es [SHAW87]. El estudiante que in­
tente hacer una investigacion minuciosa del Sistema V haria bien en leer primero esta ultima referen­
cia y despues atacar la de Bach. Otro libro que cubre las interioridades de UNIX es [ANDL90]; este
proporciona un tratamiento conciso, pero sistematico y exhaustivo, de las caracteristicas de UNIX y de
sus mecanismos. Para el UNIX 4.3BSD de Berkeley, tan popular en la ensefianza, [LEFF88] e8ta muy
recomendado. En el numero de julio-agosto de 1978 del Bell System Technical Journal yen el numero
de octubre de 1984 delRell Laboratories Technical Journal de AT&T se publicaron colecciones im­
portantes de artfculos sobre UNIX. Est08 se volvieron a editar como [ATT87a y b].
Hasta ahora, no se ha escrito mucho sobre las interioridades de Windows NT. [CUST93] propor­
ciona un tratamiento excelente.
..
lecturas recomendadas 95

Tambien hay pocos Iibros sobre las interioridades de MVS. Una excepcion destacable es
[JOHN89]. Este lib£O esta dirigido principalmente a los administradores de sistemas y a los operado­
res de los centros de dIculo, explicando MVS desde esta perspectiva. Sin embargo, al hacerlo, aporta
una cantidad razonable de detalles tecnicos del MVS. Ellogro principal de esta obra es que realiza un
estudio claro y exhaustivo del MVS en un solo !ibro. Los ot£Os libros tratan el MVS desde el punto de
vista del rendimiento: [PAAN86] y (SAMS90].
Ellector tambien puede desear investigar sobre el sistema operativo VMS, que ejecuta en las ma­
quinas VAX de DEC. Este es uno de los sistemas operativos mejor disenados, documentados y mas
~
estudiados. El tratamiento definitivo es el de [KENA91]. Es un modelo de como documentar un sis­
tema operativo.
ANDL90 ANDLEIGH, P. UNIX System Architecture. Prentice Hall, Englewood Cliffs, NI, 1990.
ATT87a AT&T UNIX Sytem V Readings and Examples, Volume I. Prentice Hall, Englewood Cliffs,
NI,1987.
ATI87b AT&T UNIX System Reading and Examples, Volume II. PrentiCe Hall, Englewood Cliffs,
NI,1987.
BACH86 BACH, M. The Design of the UNIX Operating System. Prentice Hall, Englewood Cliffs,
NI,1986.
CUST93 CUSTER H.Inside ~indows NT. Microsoft Press, Redmont, WA, 1993.
DEIT90 DEITEL. H. An Introduction to Operating System. Reading, MA: Addison-Wesley, 1990.
JOHN89 JOHNSON, R. MVS Concepts and Facilities. McGraw-Hill, Nueva York, 1989.
KENA91 ·KENAH, L., GOLDENBERG. R. Y BATE, S. VAXIMVS Internal and Data Structures.
Digital Press, Bedford. MA, 1991 .

LEFF88 LEFLER, S., MCKUSICK, M., KARELS. M., QUANTERMAIN, I., Y STETTNER, A.
The Design and Implementation of the 4.3BSD UNIX Operating System. Addison-Wesley, Rea­
ding, MA, 1988.
MAEK87 MAEKAWA, M., OLDEHOEFT, A., y OLDEHOEFT, R. Operating Systems: Advanced
Concepts. Benjamin Cummings, Menlo Park, CA, 1987.
MILE92 MILENKOVIC, M. Operating Systems: Concepts and Design. McGraw-Hill, Nueva
York,1992.
NUTI92 NUTI, G. Centralized and Distributed Operating System. Prentice Hall, Englewood
Cliffs, NI, 1992.
1. PAAN86 PAANS, R. A Close Look at MVS Systems: Mechanisms, Pefiormance, and Security. El­
sevier, Nueva York, 1986.
SAMS90 SAMSON, S. MVS Performance Management. McGraw-Hill, Nueva York, 1990.
SHAW87 SHAW, M. y SHAW, S. UNIX Internals: A System Operations Handbook. Tab Books,
Blue Ridge Summit, PA, 1987.
SILB94 SILBERSCHATZ, A. Y GALVIN, P. Operating System Concepts. Addison-Wesley, Rea­
ding, MA, 1994.
SING94a SINGHAL, M. Y SHIVARATRI, N. Advanced Concepts in Operating Systems. McGraw­
Hill, Nueva York, 1994.
TANE92' TANENBAUM, A. Modern Operating Systems. Prentice Hall, Englewood Cliffs, NI, 1992.

..

--
96 Introducci6n a los sistemas operativos

2.7
PROBLEMAS
2.1 Supongase que se tiene un computador multi­ 2.3 Un program a con carga de E/S es aquel que, si
programada en la que cada trabajo' iiene ca­ ejecuta en solitario, gastaria mas tiempo espe­
racterfsticas identicas. En un perfodo de com­ rando en E/S que usando el procesador. Un
puto T, la mitad del tiempo de un trabajo se programa con carga de procesador es el con­
pasa en E/S y la otra mitad en actividad del trario. Supongase que un algoritmo de planifi­
procesador. Cada trabajo se ejecuta durante cacion a corto plazo favorece a aquellos pro­
un total de N periodos. Se definen las canti­ gramas que han empleado poco tiempo del
dades siguientes: procesador en el pas ado reciente. Explicar por
• Tiempo de retorno tiempo real de termina­ que este algoritmo favorece a los programas
cion de un trabajo con carga de E/S pero sin denegarle permanen­
temente tiempo del procesador a los progra­
Productividad = numero medio de tareas ter­
mas con carga de procesador.
minadas por periodo de tiempo T
2.4 Un computador tiene una cache, una memoria
• Utilizaci6n del procesador == porcentaje de
principal y un disco u~ilizado como memoria
tiempo en el que el procesador esta activo (no
virtual. Si una palabra esta en la cache se re­
esperando)
quieren A ns para acceder a ella. Si esta en la
Calcular estas cantidades para uno, dos y cuatro memoria principal pero no en el cache, se re­
trabajos simultaneamente, suponiendo que el quieren B ns para cargarla en la cache y luego la .
perfodo T se distribuye de cada una de las for­ referencia empieza de nuevo. Si la palabra no
mas siguientes: esm en memoria principal, se requieren C ns
a) E/S durante la primera mitad, procesador du­ para traerla del disco, seguidos de B ns para tra­
rante la segunda mitad erla a la cache. Si la tasa de aciertos de la cache
es (n-l )/n y la tasa de aciertos de la memoria
b) E/S durante el primer y cuarto cuartos, proce­ principal es (m-l)/m, lcual es el tiempo medio
sador durante el segundo y el tercer cuartos. de acceso?
2.2 Si Se define el tiempo de espera como el tiempo 2.5 Comparar las politicas de planificaci6n que se
que un trabajo pasa esperando en la cola a corto podrian usar cuando se intenta optimizar un sis­
plazo (figura 2.12), obtener una ecuacion que re­ tema de tiempo com partido con las mismas poH­
lacione el tiempo de retorno, el tiempo que el ticas que se utilizarian para optimizar un sistema
procesador esm ocupado y el tiempo de espera. multiprogramado por lotes.
..

CAPITULO 3.

~ Descripci6n
y control de procesos
El disefio de un sistema operativo debe reflejar con seguridad los requisitos que se pretende
que este cumpla. Todos los sistemas operativos de multiprogramaci6n, desde los sistemas
monousuario, como Windo~s NT, hasta los sistemas de grandes computadores, como MVS,
que puede dar soporte a miles de usuarios, estan construidos en tomo ai concepto de pro­
ceso. Por tanto, los requisitos principales que debe satisfacer un sistema operativo estan ex­
presados haciendo referencia a los procesos:
• El sistema operativo debe intercalar la ejecuci6n de un conjunto de procesos para maxi­
'It
. mizar la utilizaci6n del procesador ofreciendo a la vez un tiempo de respuesta razonable.
• El sistema operativo debe asignar los recurs os a los procesos en conformidad con una
politica especifica (por ejemplo, ciertas funciones 0 aplicaciones son de prioridad mas
alta), evitando, al mismo tiempo, el interbloqueo. 1
• El sistema operativo podria tener que dar soporte ala comunicaci6n entre procesos y la
creaci6n de procesos por parte del usuario, labores que pueden ser de ayuda en la es­
tructuraci6n de las aplicaciones.
Puesto que el proceso es fundamental en todos los requisitos clave de los sistemas operativos,
se comenzara el estudio detallado de los sistemas operativos con un examen a la forma en que se •
... representan y controlan los procesos en los sistemas operativos. El capitulo se abre con una discu­
si6n sobre los estados del proceso, que caracterizan el comportamiento de los mismos. Despues, se
veran las estructuras de datos que hacen falta para que los sistemas operativos representen el es­
tado de cada proceso, asf como otras caracteristicas de los procesos que son necesarias para que el
sistema operativo alcance sus objetivos. A continuaci6n, se descubrira que el concepto de proceso
es mas complejo y sutil que el presentado al principio y que, de hecho, incorpora dos conceptos se­
parados independientes en potencia: el relativo ala propiedad de los recurs os y el relativo a la eje­
cuci6n. Esta distinci6n ha llevado al desarrollo, en algunos sistemas operativos, de una estructura
conocida como hilo (thread). Por ultimo, se veran las formas en que los sistemas operativos torna­
dos como ejemplo manejan los conceptos expuestos en este capitulo.

I El interbloqueo se examina en el capitulo 5. Basicamente, se produce un interbloqueo si hay dos procesos que necesitan los

mismos dos recursos.para continuar y cada uno de ellos se ha apropiado de uno de los recursos. Cada proceso espera indefini·
'" damente al recurso que Ie falta.

97
'"
98 Descripcion y control de procesos

3.1
ESTADOS DE UN PROCESO
La misi6n principal del procesador es ejecutar las instrucciones de la maquina que residen
en la memoria principal; Estas instrucciones se dan en forma de programas que contienen
secuencias de instrucciones. Como se discutio en el capitulo anterior, por razones de efi­
ciencia y de facilidad de programaci6n, un procesador puede intercalar la ejecuci6n de un
conjunto de programas en el tiempo.
De este modo, desde el punto de vista del procesador, este ejecutara instrucciones de en­
tre un repertorio en una secuencia dictada por los valores cambiante de un registro conocido
como el contador de programa (PC, Program Counter) 0 puntero a las instrucciones. A 10
. largo del tiempo, este contador puede apuntar a c6digo de programas diferentes que son
parte de diferentes aplicaciones. Desde el punto de vista de un programa individual, su eje­
cucion involucra una secuencia de instrucciones del programa. La ejecucion de un programa
individual se conoce como proceso 0 tarea.
El comportamiento de un proceso individual puede caracterizarse por ellistado de la se­
cuencia de instrucciones que se ejecutan para dicho proceso. Dicho listado se llama traza del
proceso. Vease, por ejemplo, eI tratamiento riguroso que da Hoare a las trazas [HOAR85]. EI
comportamiento del procesador puede caracterizarse mostrando la forma en que se intercalan
las trazas de varios procesos.
Considerese un ejemplo muy simple. La figura 3.1 muestra la disposici6n en la memoria
de tres procesos. Para simplificar la discusi6n, se supondra que no se emplea memoria vir­
tual; de esta manera, los tres procesos estan representados por programas que estan cargados
por completo en la memoria principal. Ademas, hay un pequeno programa distribuidor que

Memoria Principal Contador de Programa


OK
20K
35K ~~~=",,~"7'l

50K~=~~~
f.

Proceso B

140K ----~
1-1

Proceso C

FICURA 3.1 Instantanea de un ejemplo de ejecucion en el momento 18 (ver figura 3.3)


...
Estados de un proceso 99

asigna el procesador de un proceso a otro. La figura 3.2 muestra las trazas de los tres proce­
sos individuales durante la primera parte de la ejecuci6n. Se muestran las 12 primeras ins­
trucciones ejecutas en los procesos A y C. El proceso B ejecuta 4 instrucciones y se supone
que la cuarta instrucci6n invoca una operaci6n de E/S por la que el proceso debe esperar.
Van a considerarse ahora estas trazas desde el punto de vista del procesador. La figura 3.3
muestra las trazas intercaladas resultantes de los primeros 52 ciclos de instruccion. Se supone
que el sistema operativo permite a un proceso continuar su ejecuci6n s610 por un maximo de
.. seis ciclos de instrucci6n, despues de los cuales es interrumpido; esto imp ide que un solo pro­
ceso monopolice el tiempo del procesador. Como se ilustra en la figura, se ejecutan las pri­
meras seis instrucciones del proceso A, seguidas del fin del plazo (time-out) asignado y la eje­
cucion de cierto codigo del distribuidor, que devuelve el control al proceso B2. Despues de
ejecutar cuatro instrucciones de este proceso, este solicita una acci6n de E/S por la que debe
esperar. Por tanto, el procesador detiene la ejecuci6n del proceso B y avanza, por via del dis­
tribuidor, hasta el proceso C. Despues de vencer el tiempo, el procesador pasa de nuevo al
proceso A. Cuando este proceso consume su tiempo, el proceso B todavfa esta esperando que
termine la operacion de E/S, asf que el distribuidor avanza de nuevo hasta el proceso C.

Un modelo de procesos con dos estados


La responsabilidad principal del sistema operativo es el control de la ejecucion de los pro­
cesos; esto incluye la determinacion de las pautas de intercalado que se van a seguir y la
asignacion de recursos a los procesos. Para poder diseiiar el sistema operativo de una forma
efectiva, se necesita tener un modelo claro del comportamiento de un proceso. EI primer
~
paso para diseiiar un programa que controle los procesos es describir el comportamiento que
se querrfa que presentaran los procesos.

0.+0 ~+O y+O


0.+1 ~+ 1 y+1
0.+2 P+2 y+2
0.+3 P+3 y+3
a. + 4 (b) Traza del y+4
a. + 5 Proceso B y+5
. 0.+6
a. + 7
y+6
y+7
0.+8 y+8
0.+9 y+9
a. + 10 y+ 10
0.+11 y + 11
(a) Traza del (c) Traza del
ProcesoA ProcesoC
a. = Direcci6n inicial del programa del proceso A
p = Direcci6n inicial del program a del proceso B
y Direcci6n inicial del programa del proceso C
FIGURA 3.2 Trazas de los procesos de la figura 3.1

2 El pequeno numero de instrucciones ejecutadas por cada proceso y por el distribuido:- son ilusoriamente bajas.; se haee as!
para simplificar eJ ejemplo y acl~ar la diseusi6n.
100 Descripci6n y control de procesos

1 u+o 28 ,),+5

2 0:+1 ------------------- fin de plazo

3 0:+2 29 8+0

4 0:+3 30 8+1

5 0:+4 31 8+2

6 0:+5 32 8+3

------------------- fin de p lazo 33 8+4

7 8+0 34 8+5

8 8+1 35 0:+6

9 8+2 36 0:+7

10 8+3 37 0:+8

11 8+4 38 0:+9

12 8+5 39 0: + 10

13 13+0 40 0:+11

14 13+1 ------------------- fin de plazo

15 13+2 41 8+0

16 13+3 42 8+1

------------------- Solicitud de E/S 43 8+2

17 8+0 44 8+3

18 8+1 45 8+4

19 8+2 46 8+5

20 8+3 47 ,),+6

21 8+4 48 ,),+7

22 8+5 49 ,),+8

23 ,),+0 50 ,),+9

24 ')'+1 51 ')' + 10

25 ,),+2 52 ')' + 11

26 ')' + 3 ------------------- fin de plazo

27 ')'+4

8 = Direccion de comienzo del programa distribuidor


FIGURA 3.3 Traza combinada de los procesos de la figura 3.1

EI modelo mas sencillo que puede construirse tiene en cuenta que, en un momento dado, ~

un proceso puede estar ejecut<indose en el procesador 0 no. ASI pues, un proceso puede estar
en uno de dos estados: Ejecucion 0 No Ejecucion. Esto queda ilustrado en la figura 3.4a.
Cuando el sistema operativo crea un nuevo proceso, este entra en el sistema en estado de No
Ejecucion. De este modo, el proceso existe, es conocido por el sistema operativo y esta es­
perando la oportunidad de ejecutarse. De cuando en cuando, el proceso que esta ejecutando
sera interrumpido y el programa distribuidor del sistema operativo seleccionara un nuevo
proceso para que se ejecute. EI proceso anterior pasa del estado de Ejecucion al estado de
No Ejecucion y uno de los demas procesos pasara al estado de Ejecucion.
lnduso en este modelo tan simple ya se comienzan a apreciar algunos de los elementos de
disefio del sistema operativo. Cada proceso debe representarse de forma que el sistema ope­
rativo pueda seguirle la pista. Esto es, debe haber informacion relativa a cada proceso, in­
cluyendo su estado actual y su posicion en memoria. Aquellos procesos que no estan ejecu­ ~

tandose tienen que guardarse en algun tipo de cola, para que esperen su turno de ejecucion.
"11
> Estados de un proceso 101

Expedir

Entrar Salir

Interrumpir

;.. (a) Diagrama de transici6n de estados

Cola
Entrar
----r

Interrumpir

(b) Diagrama de colas

FIGURA 3.4 Modelo de Proceso de dos estados

La figura 3.4b propone una e~tructura. Hay una cola sencilla de procesos. Cada entrada de la
cola es un puntero a un proceso en particular. Por otra parte, la cola consiste en una lista en­
lazada de bloques de datos en la que cada bloque representa a un proceso; en la proxima sec­
cion se tratani esta ultima implementacion.
. EI comportamiento del distribuidor se puede describir en terminos de un diagrama de co­
las. Cuando un proceso se interrumpe, se Ie pasa a la cola de procesos en espera. Por otra
parte, si un proceso termina 0 se abandona, se Ie descarta del sistema (sale del sistema). En
cualquier caso, el distribuidor selecciona entonces un proceso de la cola para ejecutarlo.

Creaci6n y terminaci6n de procesos


Antes de intentar refinar el simple modelo de dos estados, sent de utilidad discutir sobre la
creacion y la terminacion de los procesos; en definitiva, independientemente del modelo que
se emplee para el comportamiento de los procesos, la vida de un proceso esta limitada por su
creacion y su terminacion
,.
Creacion de procesos
Cuando se afiade un proceso a los que ya esm administrando el sistema operativo, hay que
construir las estructuras de datos que se utilizan para administrar el proceso (como se des­
cribe en la seccion 3.2) y asignar el espacio de direcciones que va a utilizar el proceso. Estas
acciones constituyen la creacion de un nuevo proceso.
S,uatro sucesos comunes llevan a la creacion de un proceso, como se indica en la tabla 3.1.
Primero, en un entorno de trabajo por lotes, un proceso Se crea como respuesta a la remisi6n
de un trabajo. En un entorno interactivo, se crea un proceso cu;mdoun nuevo usuario intenta
conectarse. En ambos casos, el sistema operativo es el responsable de la creacion del nuevo
proceso. Un tercer caso en el que el sistema operativo crea un proceso es de ~wte de una apli­
.le<tc1Qn, Por ejemplo, si un usuario solicita la impresion de un archivo, el sistema operativo
creara un proceso que gestionara dicha impresion. Esto Ie permitira al proceso demandante
continuar independientemente del tiempo que tarde en terminar la tarea de impresion.
102 Descripci6n y control de procesos

TABLA 3.1 Razones la Creacion de Procesos


Nuevo trabajo por lotes EI sistema operativo esta provisto de un flujo de control de
trabajos por lotes, generalmente para cinta 0 disco.
Cuando el sistema operativo se prepara para tomar un
nuevo trabajo, leera la pr6xima secuencia de 6rdenes de
control de trabajos.
Conexi6n interactiva Un usuario entra en el sistema desde un terminal.
Cr~ado por el SO para dar un servicio EI sistema operativo puede crear un proceso para lIevar a
cabo una funci6n de parte de un programa usuario, sin que
el usuario tenga que esperar (por ejemplo, imprimir).
Generado por un proceso existente Con afan de modularidad 0 para aprovechar el parale­
lismo, un programa de usuario puede ordenar la creaci6n
de una serie de orocPsos

Tradicionalmente, todos los procesos eran creados por el sistema operativo de una forma
transparente para el usuario 0 el programa de aplicaci6n y eS as! como todavia se mantiene
en la mayorfa de los sistemas operativos actuales. Sin embargo, puede ser util permitir que
!!!l1!.~Qce~pueda originar la-creaci6n de otro proceso. Por ejemplo, el proceso de una apli­
caci6n puede~crear otro proceso para recibir los datos que la aplicaci6n este generando e ir
organizando estos datos de una forma conveniente para el anaUsis posterior. EI nuevo pro­
ceso ejecuta en paralelo con la aplicaci6n y es activado de cuando en cuando, cada vez que
haya nuevos datos disponibles. Este plan puede ser muy util para estructurar la aplicaci6n.
Con otro ejemplo, un proceso servidor (por ejemplo, un servidor de impresi6n 0 un servidor
de archivos) puede crear un nuevo proceso por cada solicitud que reciba. Cuando un proceso
es creado por el sistema operativo tras la solicitud explicita de otro proceso, la acci6n se co­
noce como generacion de procesos (process spawning).
Cuando un proceso genera otro, el proceso generador se conoce como proceso padre y el
proceso generado es el proceso hijo. Normalmente, estos proeesos "emparentados" necesi­
taran comunicarse y cooperar entre sf. Lograr esta cooperaci6n es una tarea diffcil para el
programador; este tema es discutido en el capitUlo 4.

Tenninaci6n de procesos
La tabla 3.2, basada en el trabajo de Pinkert y Wear [PINK89], resume las causas tipicas de
terminaci6n de un proceso.
En eualquier sistema informatico, debe haber alguna forma de que un proceso pueda in­
diear que ha terminado. Un trabajo por lotes debe incluir una instrueci6n de detenci6n (Halt)
o una Hamada explfcita a un servicio del sistema operativo para la terminaci6n. En el primer
caso, la instrucci6n Halt generara una interrupci6n para avisar al sistema operativo que el
proceso ha conc1uido. En una aplicaci6n interaetiva, es la acci6n del usuario la que indica
cuando termina el proceso. Por ejemplo, en un sistema de tiempo compartido, el proceso de
un usuario particular terminara cuando este se desconecte del sistema 0 apague el terminal.
En un computador personal 0 una estaci6n de trabajo, el usuario puede abandonar una apli­
caci6n (por ejemplo, un procesador de textos 0 una hoja de caIculo). Todas estas acciones
provocan al final una petici6n de servicio al sistema operativo para terminar con el proceso
demandante.
Estados de un proceso 103

TABLA 3.2 Razones para la Terminacion de un Proceso [PINK89]


Terminaci6n normal ~ EI proceso ejecuta una Ilamada a un servicio del 50 que indica
que ha terminado de ejecutar.
Tiempo limite excedido EI proceso ha ejecutado por mas del tiempo limite total especffi­
cado. Hay varias posibilidades para la clase de tiempo que se
mide. Entre estas se incluyen iii tiempo total transcurrido ("tiempo
de relon, el tiempo que ha estado ejecutando y ,en el caso de un
proceso interactivo, el tiempo transcurrido desde que el usuario
realiz6 su ultima entrada de datos.
No hay memoria disponible EI proceso necesita mas memoria de la que el sistema Ie puede
proporcionar
Violacion de Ifmites EI proceso trata de acceder a una posicion de memoria a la que
no Ie esta permitido acceder.
Error de proteccion EI proceso intenta utilizar un recurso 0 un archivo que no Ie esta
permitido utilizar, 0 trata de utilizarlo de forma incorrecta,
como escribir en un archivo que es solo de lectura.
Error aritmetico EI proceso intenta hacer un calculo prohibido, como una divi­
sion por cero, 0 trata de almacenar un numero mayor del que
el hardware acepta.
Tiempo maximo de espera rebasado EI proceso ha esperado mas alia del tiempo maximo especifi- .
cado para que se produzca cierto suceso.
Fallo de E/5 5e produce un error en la entrada 0 la salida, tal como la inca­
pacidad de encontrar un archivo, un fallo de lectura 0 escritura
despues de un numero maximo de intentos (cuando, por
ejemplo, hay un region defectuosa en una cinta), 0 una opera­
cion ilegal (como intentar leer de una impresora)
Instruccion invalida EI proceso intenta ejecutar una instruccion inexistente (a me­
nudo como resultado de un saito a una zona de datos para in­
tentar ejecutar los datos).
Instruccion privilegiada EI proceso intenta usar una instruccion reservada para el sistema
operativo.
Mal uso de los datos Un elemento de dato es de un tipo equivocado 0 no esta inicia­
lizado.
Intervencion del operador 0 del 50 Por alguna razon el operador 0 el sistema operativo termina con
el proceso (por ejemplo, si existe un interbloqueo),
Terminacion del padre Cuando un proceso padre finaliza, el sistema operativo puede
disenarse para terminar automaticamente con todos sus des­
cendientes.
50licitud del padre Un proceso padre tiene normal mente la autoridad de terminar
con cualquiera de sus descendientes.

Ademas, una serie de errores y condiciones de fallo pueden llevamos a la terminacion de


un proceso. La tabla 3.2 enumera algunas de las condiciones mas habituales. 3
Por ultimo, en algunos sistemas operativos, un proceso puede ser eliminado por el pro­
ceso que 10 creo 0 al terminar el proceso padre .

.1 Un sistema operativo misericordioso puede, en algunos casos, permitir que un usuario se recupere de un fallo sin tener que
~ terminar con el proceso. Por ejemplo, 5i un usuario solicita el acceso a un archivo y se Ie niega, el sistema operativo puede in­
formarle simplemente al usuario que el acceso Ie ha sido denegado y pennitir al proceso que continue.
104 Descripci6n y control de procesos

Un modelo de cinco estados


Si todos los procesos estuvieran siempre listos para ejecutar, entonces la disciplina de cola
propuesta en la figura 3.4b seria eficaz. La cola es una lista "primero en entrar, primero en
salir" (FIFO, First-In, First-Out) y el procesador opera segtin un turno rotatorio (round-ro­
bin) con todos los procesos disponibles (a cada proceso de la cola se Ie otorga una cierta can­
tidad de tiempo para ejecutar y luego vuelve a la cola, a menos que se bloquee). Sin em­
bargo, atin en el simple ejemplo que se ha descrito, esta implementacion no es adecuada:
Algunos procesos en el estado de No Ejecucion estan listos para ejecutar, mientras que otros
est an bloqueados, esperando a que termine una operacion de E/S. Asi pues, utilizando una
cola sencilla, el distribuidor podria no seleccionar exactamente el proceso que esta en el ex­
tremo mas antiguo de la cola. Mas bien, el distribuidor tendria que recorrer la lista buscando
el proceso que no este "no bloqueado" y que lleve mas tiempo en Ia cola.
Una forma mas natural de afrontar esta situacion es dividir el estado de No Ejecuci6n en
dos estados: Listo y Bloqueado. Esto se muestra en la figura 3.5. Por afiadidura, se han in­
corporado dos estados mas que se mostraran de utilidad. Los cinco estados de este nuevo
diagrama son los siguientes:
• Ejecucion: El proceso que esta actualmente en ejecuci6n. En este capitulo se suponen
computadores con un tinicoprocesador, de forma que solo un proceso,.a 10 sumo, puede
estar en este estado en un instante dado.
• Listo: Proceso que esui preparado para ejecutar, en cuanto se Ie de la oportunidad.
• Bloqueados: Proceso que no puede ejecutar hasta que se produzca cierto suceso, como
la terminacion de una operaci6n de E/S.
• Nuevo: Proceso que se acaba de crear, pero que min no ha sido admitido por el sistema
operativo en el grupo de procesos ejecutables.
• Terminado: Un proceso que ha sido excluido por el sistema operativo del grupo de pro­
cesos ejecutables, bien porque se detuvo 0 porque fue abandon ado por alguna razon.
Los estados Nuevo y Terminado son construcciones titHes para la gestion de procesos. EI
estado Nuevo corresponde a los procesos que acaban de ser definidos. Por ejemplo, si un
nuevo usuario intenta conectarse a un sistema de tiempo compartido 0 si un nuevo trabajo
por lotes es remitido para su ejecucion, el sistema operativo puede definir un nuevo proceso
en dos pasos. Primero, el sistema operativo lleva a cabo algunas tare as necesarias de gestion

Pasar a Ejecucion
"\ II
Listo

Bloqueado

FIGURA 3.5 Modelo de procesos de cinco estados


Estados de un proceso 105

intema. Se Ie asocia un ideritificador al proceso y se construyen y asigmin algunas tablas ne­


cesarias para gestionar el proceso. En este punto, el proceso estara en el estado Nuevo. Esto
significa que el sistema operativo ha llevado a cabo las acciones necesarias para crear el pro­
ceso pero no se ha comprometido aun a su ejecucion. Por ejemplo, un sistema operativo
puede limitar la cantidad de ·procesos que pueden estar en el sistema por razones de rendi­
miento 0 de limitacion de memoria. .
Asimismo, un proceso sale de Ufl sistema en dos pasos. Primero, el proceso termina
cuando llega al punto normal de tertninaei6n, cuando se abandona debido a un error irre­
cuperable 0 cuando otro proceso con la debida autoridad hace que el proceso abandone.
La terminaci6n pasa el'proceso al estado Terminado. En este punto, el proceso ya no se
elige mas para la ejecucion. Sin embargo, las tablas y otra informaci6n asociada con el
trabajo son conservadas temporalmente por el sistema operativo. Esto Ie da tiempo a olros
. programas auxiliares 0 de soporte para extraer la informaci6n ne.cesaria. Por ejemplo,
puede ser que un programa de contabilidad necesite registrar el tiempo de procesador y
otros recursos usados por el proceso con fines de facturacion. Un program a de utilidades
puede tener que extraer informacion sobre la historia del proceso con fines relativos a un
analisis de uso 0 de rendimiento. Una vez que estos programas han extrafdo la informa­
cion necesaria, el sistema op~rativo ya no necesita mantener mas datos relativos al pro­
ceso y estos se borran del sistema. La tabla 3.3 ofrece mas detalles. Se veran cada una de
las posibilidades por tumos:
• Nulo -:" Nuevo: Se crea un nuevo proceso para ejecutar un programa. Este suceso se
produce por algunas de las razones enumeradas en la tabla 3.1.
• Nuevo - Listo: El sistema operativo pasara un proceso del estado Nuevo al estado
Listo cuando este preparado para aceptar un proceso mas. La mayorfa de los sistemas
ponen un limite en funci6n del numero de procesos existente 0 en la cantidad de me­
moria virtual dedicada a los procesos existentes. EI motivo de este limite es asegurar
que no haya tantos procesos activos como para degradar el rendimiento.
• Listo - Ejecucion: Cuando es hora de seleccionar un nuevo proceso para ejecutar, el
sistema operativo elige a uno de los procesos del estado Listo. La cuesti6n de que pro­
ceso se escoge es estudiada en el capitulo 8.
• Ejecucion - Terminado: EI proceso que se esta ejecutando es finalizado por el sistema
operativo si indica que termino 0 si se abandona. .
• Ejecucion - Listo: La razon mas comnn de esta transici6n es que el proceso que esta en
ejecuci6n ha alcanzado el tiempo maximo permitido de ejecucion ininterrumpida; casi
todos los sistemas operativos con multiprogramacion imponen este tipo de norma de
tiempo. Hay otras causas altemativas para esta transicion que no estan implementadas
en todos los sistemas operativos. Por ejemplo, si el sistema operativo asigna diferentes
niveles de prioridad a los diferentes procesos. Sup6ngase que un proceso A esta ejecu­
tandose con un cierto nivel de prioridad y que el proceso B, con un nivel de prioridad
mayor, esta bloqueado. Si el sistema operativo se entera de que el suceso que B estaba
esperando se ha producido, pasandoasi B al estado Listo, entonces puede interrumpir al
proceso A y expedir a B. Por ultimo, otro caso es que un proceso ceda voluntariamente
el control del procesador.
• Ejecucion - Bloqueado: Un proceso se pone en el estado Bloqueado si solicita algo por 10
que debe esperar. Las solicitudes al sistema operativo suelen ser en forma de llamadas a ser­
....
<=
="

o
~:!.
"Cl
Q.
Q,
:::I
"'<
TABLA 3.3 Transicionesde Estado de un Proceso 8
....
:::I
DE5DE
Nuevo Ejecuci6n
HAClA
Listo Bloqueado Terminado
e.
Q.
Il>
EI SO responde a una X X X x "Cl
o
solicitud de control
de trabajos; se
conecta un usuario ~
de tiempo compartido;
un proceso crea
un hijo.
Nuevo X x EI SO esta preparado para X X
aceptar un proceso mas.
Ejecucion X x 5e acab6 el plazo de tiempo; Petici6n de servicio al SO; El proceso termina;
petici6n de servicio al SO; peticion de recurso; el proceso cancela.
el SO 10 expulsa a causa petici6n de suceso.
de otro de mayor
prioridad; el proceso
cede el control.
Listo X 5eleccionado por X x Proceso finalizado
el distribuidor por el padre.
como el pr6ximo
proceso a ejecutar.
Bloqueado X X 5e produce el suceso. X Proceso finalizado
por el padre.

"

Estados de un proceso 107

vicios del sistema, es rlecir, llamadas desde el programa que esm ejecutindose a un procedi­
mlento que fonna parte del c6digo del sistema operativo. Por ejemplo, un proceso puede so­
licitar un servicio que el sistema operativo no esta preparado para llevar a cabo de inmediato.
Puede pedir un recurso, tal y como un archivo 0 una secci6n compartida de memoria virtual,
que no este inmediat:;.unente disponible. 0 bien el proceso puede iniciar una acci6n, como una
operaci6n de E/S, que debe tenrtitlarse antes de que el proceso pueda continuar. Al comuni­
carse los procesos unos con olnls, uno se puede quedar bloqueado cuando espera a que otro
proceso le proporcione una ciena entrada 0 cuando espera un mensaje del otro proceso.
• Bloqueado ~ Listo: Un proceso que esta en el estado Bloqueado pasara al estado Listo
cuando se produzca el suceso que estaba esperando.
• Lislo ~ Terminado: Por razones de claridad, esta transici6n no se muestra en el dia­
grama de estados de la figura 3.5. En algunos sistemas, un padre puede tenninar con un
proceso hijo en cualquier momento. Ademas, si el padre tennina, todos los procesos hi­
jos asociados con el pueden ser finalizados .
• Bloqueado ~ Terminado: Se aplica el mismo comentario que en el caso anterior.
Volviendo al ejemplo planteado, la tabla 3.4 muestra el movimiento de cada proceso entre
los cinco estados. La figura 3.6a sugiere la fonna en la que podria implementarse una disci­
plina de colas. Ahora hay dos colas: Una cola de Listos y una cola de Bloqueados. A medida
que se admiten procesos en el sistema, se situan en la cola de Listo. Cuando llega la hora de
que el sistema operativo escoja otro proceso para ejecutar, selecciona uno de la cola de Lis­
tos. En ausencia de un esquema de prioridades, esta puede ser una simple cola FIFO.
Cuando un proceso que se esta ejecutando es apartado de la ejecuci6n, 0 bien se Ie finaliza 0
bien se pone enla cola de Listos 0 de Bloqueados, dependiendo de las circunstancias.
Por ultimo, cuando se produce un suceso, todos los procesos de la cola de Bloqueados que
estan esperando a dicho suceso se pasan a la cola de Listos.
Esta ultima medida significa que, cuando se produce un suceso, el sistema operativo debe
recorrer toda la cola de Bloqueados, buscando aquellos procesos que esperan al suceso. En
un sistema operativo grande, puede haber cientos 0 incluso miles de procesos en dicha cola.
Por tanto, seria mas eficiente tener una serie de colas, una para cada suceso. En tal caso,
cuando se produzca un suceso, la lista entera de procesos de la cola correspondieme al su­
ceso puede pasarse al estado Listo (figura 3.6b).

TABLA 3.4 Estados de los procesos para la traza de la figura 3.3


Tiempo Proceso A Proceso B Proceso C
1-6 Ejecucion Listo Listo
7-12 Listo Listo Listo
13-18 Listo Ejecucion Listo
19-24 Listo Bloqueado Listo
25-28 Listo Bloqueado Ejecuci6n
29-34 Listo Bloqueado Listo
35·-40 E;ecuci6n Bloqueado Listo
41·-46 Listo Bloqueado Listo
47-52 Listo Bloqueado Ejecuci6n
.~-.-.----~~~~--~.~--~
1 08 Descripci6n y control de procesos

Admitir

Fin de plazo (time-out)

Ocurre
suceso Cola de Bloqueados
(a) Una sola cola de bloqueados

Cola de Listos Pasar


_A_dm_it.....~_. , I : I I I Ia ejecuci6t;!

Fin de plazo (time-out)

Ocurre

suceso 1

Ocurre
erar suceso 2
suceso 2

Cola de suceso 2

erar suceso n
Ocurre

suceso n
Cola de suceso n
(b) Varias colas de bloqueados
FIGURA 3.6 Modelo de Colas de la figura 3.5

Un retoque final: Si la expedicion de procesos esta dictada por un esquema de priorida­


des, entonces es conveniente tener un cierto numero de colas de Listos, una para cada nivel
de prioridad. El sistema operativo podni determinar facilmente emU es el proceso de priori­
dad mas alta que lleva mas tiempo esperando.

Procesos suspendidos
Necesidad del intercambio
Los tres estados principales que se han descrito (Listo, Ejeeueion, Bloqueado) ofrecen una
forma sistematica de modelar el eomportamiento de los proeesos y de guiar la implementa­
cion del sistema operativo. Se han eonstruido muchos sistemas operativos empleando sola­
mente estos tres estados.
Estados de un proceso 109

Sin embargo, hay una buena justificacion para anadir mas estados al modelo. Para ver los
beneficios de estos nuevos estados, considerese un sistema que no utiliza memoria virtual.
Cada proceso que va a ejecutarse debe ser cargado por completo en la memoria principal.
De esta manera, en la figura 3.6b, todos los procesos de todas las colas deben estar residen­
tes en la memoria principal.
Recuerdese que la razon de todo este complicado mecanisrno es que las actividades de E/S
son mucho mas lentas que las de calculo y, por tanto, el procesador en un sistema de mono­
programacion esta parado la mayor parte del tiempo. Pero la disposicion de la figura3.6b no
resuelve por completo el problema. Es verdad que, en este caso, la memoria contiene varios
procesos y que el procesador puede dedicarse a otro proceso cuando uno este esperando. Pero
el procesador es tan rapido comparado con la E/S que suele ser habitual que lodos los proce­
sos de memoria esten esperando por E/S. Asf pues, incluso con multiprogramacion, el proce­
sador podrfa estar desocupado la mayor parte del tiempo.
i.QUe hay que hacer? La memoria principal podrfa ampjiarse para alojar mas procesos.
pero habrfa dos defectos en ('ste enfoque. Primero, se tiene un coste asociado con la memo­
ria principal, que, aunque es pequeno cuando se trata de hits, comienza a acumularse cuando
se trata de megabytes y gigabytes de almacenamiento. Segundo, el apetito de los programas
por la memoria ha crecido tan rapidamente como el coste de la memoria ha disminuido. Por
tanto, una memoria mayor significa procesos mayores. pero no milS procesos.
Otra solucion es el intercambio. 10 que significa mover una parte del proceso 0 lOdo el
proceso de la memoria principal a disco. Cuando ninguno de los procesos en memoria prin­
cipal esta en estado LiSIO, el sistema operativo expulsa a disco a uno de los proccsos que este
Bloqueado y 10 pasa a una cola de Suspendidos. Esta es una cob de I'WCl'SOS cxistenles que
han sido sacados lemporalmente de la memoria principal 0 sll'ipendidos. EI sistema opera­
tiyo trae entonccs otro proceso de la cola de Suspendilios 0 atiende la demanda de crear un
nuevo proceso. La ejecucion continua entonces con el nuevo proceso que ha lIegado.
EI inlercambio, no obstante, es una operacion de E/S y, por lanto, hay una posibilidad de
que eI problema empeore en vez de mejorar. Pero COIlIO la E/S con eI disco es, en general. la
mas rapida de un sistema (en comparacion, por ejemplo. con lIna cinla 0 una impresora),
el inkrcamhio suelc l1lcjorar el rendimienlo.
Ai emplc~\r cl inlcrcambio. tal y como se acaba de describir, se debe afiadir un nuevo es­
[ado ,d mo(k!o del comporlamiento de los procesos (figura 3.7a), el estado Suspendido.
ClIall:k, todos los procesos de la memoria principal estan en cl estado Bloqueado, el sistema
opcrativo pllccle sllspender un proceso ponicndolo en estado Suspendido y transferirlo a
disco. Ei cspacio que se libera de la memoria principal puede util izarse entonees para traer
ntro proc('~("
Cuando d sistema operativo haya realizado una operaeion de intereambio de un proceso
a disco. tendra dos opeiones para seleceionar el proceso que se va a traer a memoria: Puede
admitir un proecso [ecien creado 0 puede traer un proceso suspendido previamente. Puede
parecer que la preferencia debe ser traer un proeeso suspendido previamente para darle ser­
vicio, en lugar de haeer creeer la carga total de procesos en el sistema.
Pero esta lfnea de razonamiento presenta una dificultad. Todos los procesos que fueron
suspendidos estaban en el estado Bloqueado en el momenta de la suspension. Realmente no
haria ningun bien traer de nuevo a memoria principal un proceso Bloqueado porque no esta
110 Descripcion y control de procesos

(a) Con un estado Suspendido

,,
,Admitir
'I.,

\ Suspender
--- - -.­ ......~ -­ - -- - -­ - - .... -­ ...............
Expedir

Ocurre
suceso suceso

(b) Con dos estados Suspendido


FIGURA 3.7 Diagrama de transicion de estados de un proceso con estados de suspenion

todavia listo para ejecutarse. Debe reconocerse, sin embargo, que cada proceso en estado
Suspendido fue bloqueado originalmente por un suceso concreto. Cuando se produzca tal
suceso, el proceso se desbloqueara y, posiblemente, estara disponible para su ejecucion.
Por tanto, no se necesita volver a pensar sobre este aspecto del diseiio. Aqui se tienen dos
conceptos independientes: si un proceso esta esperando un suceso (bloqueado 0 no), y si un
proceso ha sido expulsado de la memoria principal (suspendido 0 no). Para ordenar estas
combinaciones, hacen falta los cuatro estados siguientes:
• Lis~o: El proceso esta en memoria principal y listo para la ejecucion .
• Bloqueado: El proceso esta en memoria principal esperando un suceso .
• Bloqueado y suspehdido: El proceso esta en memoria secundaria esperando un suceso.
• Listo y suspendido: EI proceso esta en memoria secundaria pero esta disponible para su
ejecucion tan pronto como se cargue en la memoria principal.
I!J
Estados de un proceso 111

Antes de observar el diagrama de transicion de estados que engloba a los dos nuevos es­
tados de suspension, debe hacerse menc~'6 a otro punto. En la discusion se ha supuesto
hasta ahora que no se utiliza memoria virt al y que un proceso estara bien en memoria prin­
cipal 0 bien fuera de ella po~ completo. C n un esquema de memoria virtual, es posible eje­
cutar un proceso que esre solo parcialmente en memoria prindpal. Si se hace una referencia
a una direccion del proceso que no esta en memoria principal, entonces la parte apropiada
del proceso debe traerse a memoria. E1 uso de la memoria virtual parece eliminar la necesi­
..
dad del intercambio explicito, ya que cualquier direccion deseada de cualquier proceso
puede ser tras1adada dentro 0 fuera de la memoria principal por el hardware de gestion de
memoria del procesador. Sin embargo, como se vera en el capitulo 7, el rendimiento del sis­
tema de memoria virtual puede desplomarse si hay un numero suficientemente grande de
procesos activos, todos los cuales estan en parte en la memoria principal. Por tanto, inc1uso
en un sistema de memoria virtual, el sistema operativo siempre tendra que expulsar de
cuando en cuando algunos procesos, de fonna completa y explfcita,en aras del rendimiento.
Va a observarse ahora, con la figura 3.7b y la tabla 3.5, el modelo de transicion de estados
que se ha desarrollado. (Las lineas discontinuas en la figura indican transiciones posibles
pero no necesarias). Las nuevas e importantes transiciones son las siguientes: .
• Bloqueado - Bloqueado y suspendido: Si no hay procesos Listos, entonees al menos
un proceso Bloqueado se expulsa para dar cabida a otro proceso que no este bloqueado.
Esta transicion puede haeerse aun cuando hay procesos listos disponibles, cuando el
sistema operativo detennina que el proceso que esta actual mente en Ejecucion 0 un pro­
.,
ceso Listo que serfa conveniente expedir requiere mas memoria principal para mante­
ner un rendimiento adecuado.
• Bloqueado y suspendido - Listo y suspendido: Un proceso en estado Bloqueado y sus­
pendido se pasa al estado Listo y suspendido cuando ocurre el suceso que estaba espe­
rando. Notese queesto requiere que este accesible para el sistema operativo la infonna­
cion relativa a los procesos Suspendidos.
• Usto y suspendido - Listo: Cuando no hay procesos Listos en la memoria principal, el
sistema operativo tendra que traer uno para continuar la ejecucion. Ademas, puede
darse el easo de que un proceso en estado Listo y suspendido tenga una prioridad mayor
que la de un proceso en estado Listo. En tal caso, el disefiador del sistema operativo
>Ii puede decidir que es mas importante tomar el proceso de mayor prioridad que minimi­
zar el intercambio.
• Listo - Usta y suspendido: Generalmente, el sistema operativo prefiere suspender a un
proceso Bloqueado en vez de a uno Listo, ya que el proceso Listo podria ejecutarse de
inmediato, mientras que el proceso Bloqueado estara ocupando espacio en la memoria
principal sin poder ejecutarse. Sin embargo, puede ser necesario suspender un proceso
Listo si esta es la unica fonna de liberar un bloque 10 suficientemente grande de memo­
ria principal. Por ultimo el sistema operativo puede escoger suspender un proceso Listo
de mas baja prioridad en lugar de uno Bloqueado que sea de priori dad mas alta si el cree
que.el proceso Bloqueado pronto estara listo.
Otras transiciones son tambien dignas de consideracion:

;I • Nuevo - Listo, Suspendido y Nuevo - Usto: Cuando se crea un nuevo proceso, se Ie


puede afiadir a la cola de Listos 0 a la de Listos y suspendirlos. En ambos casos, el sis­
....
....
h)

c
~...
TABLA 3.5 Transiciones de Estados de los Procesos con Estados·de Suspension -6'
!"\

DESDE HACIA s:
:I
'<
Listo y Bloqueado y aa
Nuevo Ejecucion Listo Bloqueado Suspendido Suspendido Terminado
~
EI SO responde X X X X X X c.
III
a una solicitud
de control de
...o
"l:I

!"\
trabajos; se
conecta un ~
'"
usuario de
tiempo
compartido;
un proceso
crea un hijo.
Nuevo X X EI SO esta X EI SO esta X X
preparado preparado
para aceptar para aceptar
un proceso un proceso ~
mas. mas.
Ejecuci6n X X Termin6 Petici6n de EI usuario X EI proceso
su tiempo; pe­ servicio al SO; solicita la termina;
tici6n de ser­ petici6n de suspensi6n del el proceso
vicio al SO; el recurso; proceso; el SO cancela.
SO 10 expulsa petici6n de solicita la
a causa de otro suceso. suspensi6n
proceso de del proceso.
mayor priori-
dad; el proce­
so cedeel
control.

".
... .. ~ . ~

Listo x 5elecdonado x X EI SO expulsa X Proceso


por el algun proceso finalizado
distribuidor para liberar porel
comoel memoria.
proximo
proceso
a ejecutar.
Bloqueado x X Ocurre x x EI SO expulsa Proceso
un suceso algun proceso finalizado
hacia fuera . por el padre.
para liberar
memoria;
el SO u otro
proceso
la
suspension

,
del proceso.

Listo y X X EI SO intercam­ X X X
Proceso
5uspendido bia un proceso finalizado
en memoria por el
Bloqueado y X X X EI SO intercam­ 5e produce X Proceso
5uspendido bia un proceso un suceso. finalizado
en memoria. por el padre.

~
Q.

~
Q.
~
C
::s
..,
"l:I
o
~
.....
.....
w
114 Descripcion y control de procesos

tema operativo necesita construir unas tab las para poder administrar el proceso y
narle un espacio de direcciones. Podrfa ser preferible que el sistema operativo lIevara a
cabo estas labores en un primer momento, de modo que se mantuviera una reserva
grande de procesos que no estan bJoqueados. Con esta estrategia serfa frecuente el caso
de que hubiese poco espacio en memoria principal para un nuevo proceso; de ahf el uso
de la nueva transicion Nuevo ---->- Listo y suspendido. Por otro lado, puede argumentarse
que una filosofia de creacion de los procesos "justo a tiempo", retrasando la creacion
todo 10 que se pueda, reducir!a la sobrecarga del sistema operativo y Ie permitirfa lIevar
a cabo las tareas de creacion de procesos en el momento en el que el sistema este atas­
cado de todas maneras con procesos Bloqueados .
• Bloqueado y suspendido ---->- Bloqueado: La inclusion de esta transicion puede parecer
resultado de un mal diseflo. Despues de todo, si un proceso no esta !isto para ejecutarse
ya1m no esta en memoria principal, lcwll es el imeres por traerlo a memoria? Pero la si­
guiente situacion es posible: Un proceso termina, liberando memoria principal. Hay un
proceso en la cola de Bloqueados y suspendidos que tiene una prioridad mayor que la
de cualquier proceso de la cola de Listos y suspendidos, as! que el sistema operativo
tiene razones para suponer que pronto ocurrira el suceso por el que el proceso esta blo­
queado. En estas circunstancias, podrfa parecer razonable traer un proceso Bloqueado a
memoria antes que un proceso Listo.
• Ejecuci/jn LiSlO y suspendido: Generalmente, un proceso en Ejecucion pasa at estado
Listo cuando expira su fraccion de tiempo asignado. Sin embargo, si se esta expulsando
al proceso porque hay un proceso de prioridad mayor en la lista de Bloqueados y sus­
pen didos que se acaba de desbloquear, entonces el sistema operativo podrfa pasar el
proceso en Ejecucion directamente a la cola de Listos y suspendidos, Iiberando espacio
en la memoria principal.
• Varios ---->- Terminado: Normalmente, los proeesos terminan mientras estan ejecutan­
dose, bien porque se completaron 0 bien por causa de alguna condicion dnistica de
error. Sin embargo, en algunos sistemas operativos, un proceso puede ser finalizado por
eI proceso que 10 creo 0 bien finalizar cuando termina el proceso padre. Si se permite
esto, un proceso situado en cualquier estado podni pasar al estado Terminado.

Otros usos de la suspensi6n


Hasta ahora, se ha identificado el concerto de proceso Suspendido con el hecho de que el
proceso no eSla en memoria principal. Un proceso que no <:-.:Ic ("11 t1lt:lllOi'i,i no r'Stan~
nible de inmediato para su ejecuci6n, cstc 0 no esperando lin suc\:,:-,o,
Se puede generalizar este concepto de proceso Suspendido. Se define proceso Suspendido
',( lmo aquel que tiene las caracterfsticas siguientes:
I. Un proceso que esta suspendido no esta disponible de inmediato para ejecuci6n.
2. EI proceso puede estar esperando 0 no un suceso. Si 10 esta, la condicion de Bloqueado
es independiente de la condicion de Suspendido y el acontecimiento del suceso blo­
queante no 10 habilita para la ejecucion.
3. EI proceso fue situado en el estado suspendido por un agente (por sf mismo, por el pro­
ceso padre 0 por el sistema operativo) con el fin de impedir su ejecucion.
4. El proceso no puede apartarse de este estado hasta que el agente 10 ordene explfcitamente.
IJ
Estados de un proceso 115

La tabla 3.6 enumera algunas razones para la suspension de un proceso. Una razon que ya
se ha discutido es la necesidad de expulsar un proceso a disco para dar cabida a un proceso
Listo 0, simple~e te, para aliviar la presi6n sobre el sistema de memoria virtual de forma
que los proceso estantes tengan disponible mas memoria principal. El sistema operativo
puede tener otr motivos para suspender un proceso. Por ejemplo, puede emplearse un pro­
ceso de auditorfa 0 de seguimiento para supervisar la actividad del sistema; el proceso puede
emplearse para registrar el nivel de utilizaci6n de diversos recursos (procesador, memoria,
canales) y la velocidad de avance de los procesos de usuario en el sistema. El sistema ope­
... rativo, bajo el control del operador, puede conectar 0 desconectar este proceso de cuando en
cuando. Si el sistema operativo detecta 0 sospecha un problema, puede suspender un pro­
ceso. Un ejemplo de esto es el interbloqueo, que se discutira en el capitulo 5. Otro ejemplo:
. Se detecta un problema en una linea de comunicaciones y el operador tiene que hacer que el
sistema operativosuspenda al proceso que este usando la linea mientras que se ejecutan al­
gunas pruebas.
Otra serie de razones tienen que ver con las acciones de los usuarios interactivos. Por
ejemplo, si un usuario sospecha un defecto en el programa, puede depurarlo suspendiendo la
ejecuci6n del programa, examinando y modificando el programa 0 los datos y reanudando la
ejecuci6n. Tambien puede haber un proceso de fondo que recoja estadisticas de contabilidad
o seguimiento y que el usuario puede querer activar y desactivar.
Las consideraciones de tiempos pueden conducirnos tambien a un intercambio. Por ejem­
plo, si un proceso se va a activar peri6dicamente, pero esta libre Ia mayor parte del tiempo,
.
entonces deberia ser expulsado entre cada uso. Un ejemplo es el de un programa que super­
vise la utilizaci6n 0 la actividad de los usuarios.
Por ultimo, un proceso padre puede querer suspender a un proceso descendiente. Por
ejemplo, el proceso A puede generar un proceso B para llevar a cabo Ia lectura de un ar­
chivo. Posteriormente, el proceso B encuentra un error en el procedimiento de lectura del ar­
chivo e informa al proceso A. El proceso A suspende al proceso B para investigar la causa
del error.
En todos estos casos, la activaci6n de un proceso Suspendido es solicitada por el agente
que solicit6 al principio la suspension.
tri'

TABLA 3.6 Razones para la Suspension de procesos


Intercambio EI sistema operativo necesita liberar suficiente memoria principal
para cargar un proceso que esta listo para ejecutarse.
Otra raz6n del 50 EI sistema operativo puede suspender un proceso de fondo, de
utilidad 0 cualquier proceso que se sospecha sea el causante de
un problema.
50licitud de un usuario Un usuario puede querer suspender la ejecuci6n de un programa
con fines de depuraci6n 0 en conexi6n con el uso de un recurso.
Por tiemr:o Un proceso puede ejecutarse peri6dicamente (por ejemplo, un
proceso de contabilidad 0 de supervisi6n del sistema) y puede
ser suspendido mientras espera el siguiente intervalo de tiempo.
50licitud del Un proceso padre puede querer suspender la ejecuci6n de un
It. proceso padre descendiente para examinar 0 modificar el proceso suspendido
o para coordinar la actividad de varios descendientes.
116 Descripci6n y control de procesos

3.2
DESCRIPCION DE PROCESOS
El sistema operativd es el controlador de los sucesos que se producen en un sistema infor­
matico. Es el sistema operativo el que planifica y expide a los procesos para su ejecucion en
el procesador, el que asigna los recursos a los procesos y el que responde a las solicitudes de
sen:icios basicos realizadas por los programas de usuario. Esencialmente, se puede imaginar
al sistema operativo como una entidad que administra el uso que hacen los procesos de los
recursos del sistema.
Este concepto queda ilustrado en la figura 3.8. En un entomo de multiprogramacion, habra
un cierto numero de procesos (PI' ... , PN ) que se han creado y que existen en la memoria vir­
tual. Durante el curso de su ejecuci6n, cada proceso necesita tener acceso a ciertos recursos
del sistema, entre los que se incluyen el procesador, los dispositivos de E/S y la memoria
principal. En la figura, el proceso PI esta ejecutfindose; al menos una parte del proceso esm en
memoria principal y tiene el control de dos dispositivos de E/S. EI proceso P2 tambien esta en
memoria principal, pero esta bloqueado esperando a un dispositivo de E/S que esm asignado
a Pl' EI proceso PN ha sido descargado al disco y, por tanto, esta suspendido.
Los detalles de la gestion d~ estos recursos por el sistema operativo para los procesos sera
explorado en capitulos posteriores. Aqui se esm abordando una cuestion mas basica: l Que
necesita el .sistema operativo para ser capaz de controlar los procesos y administrar los re­
cursos para ellos?

Estruduras de control del sistema operativo


Si el sistema operativo va a administrar los procesos y los recursos, entonces tiene que dis­
poner de informacion sobre el estado actual de cada proceso y de cada recurso. El metodo
universal para obtener esta informacion es sencillo: El sistema operativo construye y man­
tiene tablas de informacion sobre cada entidad que este administrando. En la figura 3.9 se
ofrece una idea general del alcance de este procedimiento, que muestra cuatro tipos de ta­
bias diferentes mantenidas por el sistema operativo: de memoria, de E/S, de archivos y de
procesos. Aunque los detalles pueden diferir de un sistema operativo a otro, en 10 funda­
mental todos los sistemas operativos organizan la informacion en estas cuatro categorias.
Las Tablas de memoria se utilizan para seguir la pista de la memoria principal (real) y
secundaria (virtual). Parte de la memoria principal esm reservada para el uso del sistema

oV Memoria
: Virtual
I
···.. ·····················!·················R~~~~~~~·de la
I

~
Computadora

.~
FIGURA 3.8 Procesos y recursos
...
Descripci6n de procesos 117

operativo; el resto esta disponible para el uso de los procesos. Los procesos se mantienen en
memoria secundaria mediante alguna forma de memoria virtual 0 por un simple mecanismo
de intercambio. Las tablas de memoria deben incluir la informacion siguiente:
• La asignacion de memoria principal a los procesos
• La asignacion de memoria secundaria a los procesos
• Cualesquiera atributos de proteccion de segmentos de memoria principal 0 virtual, tales

.
como que procesos pueden acceder a ciertas regiones compartidas de memoria
• Cualquier informacion necesaria para gestionar la memoria virtual
En los ~los 6 y 7 se estudiaran en detalle las estructuras de datos para la gestion de
memoria.
Las Tablas de E/S son utilizadas por el sistema operativo para administrar los dispositi­
vos y los canales de E/S del sistema informatico. En un momentodado, un dispositivo de
E/S puede estar disponible 0 estar asignado a un proceso en particular. Si hay una operacion
de E/S en marcha, el sistema operativo necesita conocer el estado de la operacion de E/S y
la posicion de memoria principal que se esta utilizando como origeno destino de la transfe­
rencia de E/S. La gestion de la E/S se examinara en el capitulo 10.
EI sistema operativo tambit~n puede mantener tablas de archivos, las cuales ofrecen in-.
formacion sobre la existencia de los archivos, su posicion en la memoria secundaria, su es­
tado actual y otros atributos. Gran parte de esta informacion, si no toda, puede ser mantenida

Imagen
'"
del proceso
.....- - -.....,..jl Tablas de memoria Proceso
Memoria 1

VOS Tablas de E/S

' - - - -......,1 Tablas de archivos


~

Tabla de Procesos

Imagen

del proceso

..,------,
Proceso
n

Proceso n


FIGURA 3.9 Estructura general de las tablas de control del sistema operativo
118 Descripci6n y control de procesos

y utilizada por un sistema de gesti6n de archivos, en cuyo caso el sistema operativo tendni
poco 0 ningun conocimiento de los archivos. En otros sistemas operativos, gran parte de los
detalles de la gesti6n de archivos son gestionados por el propio sistema operativo. Este tema
se explora en el capitulo 11.
Finalmente, el sistema'operativo debe mantener tablas de procesos para administrar­
los. EI resto de esta secci6n se dedica a un examen de las tab las de procesos requeri­
das. Antes de continuar con esta discusi6n, se deben sefialar dos puntos. En primer lu­
gar, aunque la figura 3.9 muesJ:ra cuatro conjuntos de tablas distintos, debe quedar
claro que estas tablas debeJt estar enlazadas 0 disponer de referencias cruzadas de al­
guna manera. La memoria, la E/S y los archivos son administrados en nombre de los
procesos, por 10 que debe haber alguna referenda directa 0 indirecta a estos recursos
en las tablas de procesos. Los archivos que son referidos en las tab las de archivos son
accesibles a traves de un dispositivo de E/S y, algunas veces, estanin en memoria prin­
cipal 0 en memoria virtual. As! pues, hacen falta referencias cruzadas. Las tablas en sf
mismas deben ser accesibles por medio del sistema operativo y, por tanto, estan sujetas
a la gesti6n de memoria.
El segundo punto tiene que ver con la afmnaci6n anterior de que el sistema operativo crea
y mantiene estas tablas. Surge entonces la pregunta sobre la procedencia. l,C6mo crea el sis­
tema operativo las tablas por primera vez? Desde luego, e1 sistema operativo debe tener al~
gun conocimiento sobre el entorno basico, tal y como cUlinta memoria principal hay, cmiles
son los dispositivos de E/S y sus identificadores, etc. Este es un asunto de configuraci6n, es
decir, cuando se inidaliza el sistema operativo, este debe tener acceso a algunos datos de
configuraci6n que definan el entorno basico y estos datos deben crearse fuera del sistema
operativo, con la asistencia humana.

Estruduras de c::ontrol de procesos

Considerese 10 que debe conocer un sistema operativo si tiene que administrar y controlar a

los procesos. En primer lugar, debe saber d6nde esta ubicado el proceso y, en segundo lugar,

debe conocer los atributos del proceso que son necesarios para su administraci6n.

Ubicaci6n de los procesos


Antes de tratar las cuestiones sobre d6nde se ubican los procesos 0 sobre cuales son sus atri- •
butos, se tiene que abordar una cuesti6n mas fundamental aun: l,Cual es la manifestaci6n ff­
sica de un proceso? Como minimo, un proceso debe incluir un programa 0 un conjunto de
program as que sean ejecutados. Asociados a estos programas hay un conjunto de ubicacio­
nes de datos para las variables locales y globales, y las constantes definidas. As! pues, un
proceso constara, al menos, de la memoria suficiente para albergar los programas y los da­
tos del proceso. Ademas de esto, en la ejecuci6n de un program a entra en juego normal­
mente una pila (ver Apendice IB), que se utiliza para llevar la cuenta de las llamadas a pro­
cedimientos y de los parametros que se pasan entre los procedimientos. Por ultimo, asociado
a cada proceso hay una serie de atributos utilizados por el sistema operativo para el control
del proceso. Estos atributos se conocen como el bloque de control del proceso. 4 Esta co­
lecci6n de programa, datos, pila y atributos puede llamarse imagen del proceso (tabla 3.7).
4 Olros nombres habituales utilizados para esta estrucrura de datos son bloque de control de tarea, descriptor del proceso y des­
criptor de tarea,
~
Descripci6n de procesos 119

La ubicaci6n de la imagen de un proceso depende del esquema de gesti6n de memoria


utilizado. En el caso mas sencillo posible, la imagen del proceso sec guarda como un blo­
que contiguo de memoria. Este bloque se mantiene en memoria secundaria, normalmente
en el disco. Para que el sistema operativo pueda administrar el proceso, al menos una pe­
quena parte de su imagen, que contiene la informaci6n a usar por el sistema operativo,
debe mantenerse en memoria principal. Para ejecutar el proceso, la imagen completa debe
cargarse en la memoria principal. Por tanto, el sistema operativo necesita conocer la ubi­
cad6n de cada proceso en el disco y tambien la ubicaci6n de los procesos que esten en
<. memoria principal. En el capitulo 2 se vio una variacion ligeramente mas compleja de este
esquema. (el sistema operativo CTSS). Cuando un proceso se descarga al disco en el
CTSs., parte de su imagen permanece en memoria principal. De esta forma, el sistema
operativo puede seguir la pista de las partes de la imagen de cada proceso que se quedan
en memoria principal.
La mayoria de los sistemas operativos modemos utilizan algoo tipo de esquema de ges­
ti6n de memoria en el que la imagen de un proceso consiste en un conjunto de bloques que
no tienen por que estar almacenados consecutivamente. Dependiendo del tipo de esquema
utilizado, estos bloques pueden ser de longitud variable (llamados segmentos) 0 de longitud
fija (llamadas paginas) 0 una combinaci6n de ambos. En cualquier caso, tales esquemas per­
miten al sistema operativo tener que traer s610 una parte de un proceso en particular. De este
modo, en un momenta dado, una parte de la imagen de un proceso puede estar en la memo­
ria principal y e1 resto en la memoria secundaria. 5 Por tanto, las tablas de procesos deben
mostrar la ubicacion de cada segmento y/o pagina de cada imagen de proceso.
t.
La figura 3.9 representa la estructura de la informaci6n de ubicaci6n de lei manera si­
guiente. Hay una tabla principal de procesos con una entrada para cada proceso. Cada en­
trada conti ene, al menos,un puntero a la imagen de un proceso. Si la imagen del proceso
contiene varios bloques, entonces esta informacion estara guardad;:l directamente en la tabla
principal 0 con referencias cruzadas a entradas de las tablas de memoria. Desde luego, esta

TABLA 3.7 Elementos Tipicos de una Imagen de Proceso


Datos de Usuario
...
La parte modificable del espacio de usuario. Puede guardar datos del programa, una zona para una
pila del usuario y programas que pueden modificarse.
Programa de Usuario
EI programa a ejecutar.
Pila del Sistema
Cada proceso tiene una 0 mas pilas (el ultimo que entra es el primero en salir) asociadas a el. Una pila
se utiliza para almacenarlos parametros y las direcciones de retorno,
Bloque de Control de Proceso
Informacion necesaria para que el sistema operativo controle al proceso (ver tabla 3.8)

, Esta breve discusi6n omite algunos delalles, En particular, toda imagen de un proceso activo est<l siempre en memoria se­
cundaria, Cuando una parte. de la imagen se carga en la memoria principal, esta se copia en vez de moverse. De este modo, la

..
memoria secundaria conserva unacopia de todos los segmentos y/o paginas. Sin embargo, si la parte de la imagen que esta en
memoria principal se modifica, la copia respectiva de la memoria secundaria quedani desactualizada hasta que la parte en me­
moria principal se vuelva a copiar aJ disco.
120 Descripci6n y control de procesos

representacion es generica; cada sistema operativo tiene su propia forina de organizar la in­
formacion de ubicacion.

Atributos del proceso .


En un sistema de multiprogramacion sofisticado, se req~iere una gran cantidad de in­
formacion de cada proceso para su administracion. Como ya se dijo, puede conside­
rarse que esta informacion reside en un bloque de control del proceso. Diferentes siste­
'mas organizanin esta informacion de modo diferente. Se venin varios ejemplos de esto
en la seccion 3.5. Por ahora, se intentani simplemente explorar el tipo de informacion
que podrfa J\sarse en un sistema operativo, sin detallar la forma en que se organiza esta
informacion.
La tabla 3.8 enumera las categonas tfpicas de la informacion que requiere el sistema ope­
rativo para cada proceso. Uno se puede sorprender al principio por la cantidad de informa­
cion necesaria. Al avanzar en ellibro y adquirir una mejor apreciacion de las responsabili­
dades del sistema operativo, estalista parecera mas razonable.
Se puede agrupar la informacion de los bloques de control del proceso en las tres catego­
nas generales siguientes:
• Identificacion del proceso
• Informacion del estado del procesador
• Informacion de control del proceso
Con respecto a la identiticacion del proceso, en casi todos los sistemas operativos
se Ie asigna a cada proceso un identificador numerico unico. El identificador puede
ser tan simple como un fndice en la tabla principal del proceso (vease la figura 3.9). Si
no hay identificadores numericos, entonces debe haber una correspondencia que per­
mita al sistema operativo ubicar las tablas apropiadas a partir del identificador de pro­
ceso. Este identificador es utH en varios sentidos. Muchas de las otras tablas controla­
das por el sistema operativo pueden usar identificadores de procesos como referencias
cruzadas a las tablas de procesos. Por ejemplo, las tablas de memoria pueden organi­
zarse de manera que ofrezcan un mapa de la memoria principal con indicaciones sobre
que proceso esta asignado a cada region de memoria. Referencias similares aparece­
ran en las tablas de archivos y de E/S. Cuando los procesos se comunican unos cOQ
otros, se utiliza el identificador de proceso para informar al sistema operativo del des­
tino de cada comunicacion en particular. Cuando se permite que los procesos creen
otros procesos, se utilizan identificadores para sefialar al padre y a los descendientes
de cada proceso.
Ademas de estos identificadores de proceso, un proceso tam bien puede tener asignado un
identificador de usuario que indica quien es el usuario responsable del trabajo.
EI siguiente conjunto importante de informacion es la informacion de estado del proce­
sador. Basicamente, esta formada por el contenido de los registros del procesador. Por su­
puesto, mientras un proceso esta ejecutandose, la informacion esta en los registros. Cuando
se interrumpe el proceso, toda la informacion de los registros debe salvarse de forma que
pueda restaurarse cuando el proceso reanude su ejecucion. La naturaleza y el numero de los
registros involucrados depende del disefio del procesador. Normalmente, en el conjunto de
registros se incluyen los registros visibles para el usuario, los registros de control y de estado
121
"" Descripcion de procesos

TABLA 3.8 Elementos Bcisicos de un Bloque de Control de Proceso


Identificacion de Proceso
Identificadores
Los identificadores numericos que se pueden guardar en el bloque de control de proceso inciuyen:
• Identificador de este proceso
• Identificador del proceso que creO a este proceso (el proceso padre)
• Identificador del usuario
Informacion de Estado del Procesador
'" Registros Visibles para el Usuario
Un registro visible para el usuario es aquel al que puede hacerse referencia por medio dellenguaje
maquina que ejecuta el procesador. Normalmente, existen de 8 a 32 de estos registros, aunque al­
gunas implementaciones RISC tienen mas de 100.
Registros de Gantrol y de Estado
Hay VlJrios registros del procesador que se emplean para controlar su fu·ncionamiento. Entre estos se
incluyen:
• Contador de programa: Contiene la direcci6n de la pr6xima instruccion a ser tratada.
• C6digos de condici6n: Muestran el resultado de la operacion aritmeticao logica mas reciente
(signo, cero, acarreo, igualdad, desbordamiento).
• Informaci6n de estado: Incluye los indicadores de habilitaci6n 0 inhabilitacion de interrupciones
y el modo de ejecucion.
Punteros de pila
Cada p'roceso tiene una 0 mas pilas LIFO del sistema asociadas. Las pilas se utilizan para almacenar
t" los parametros y las direcciones de retorno de los procedimientos y de las lIamadas al sistema. EI
puntero de pila siempre apunta a la cima de la pila.
Informacion de Control del Proceso
Informacion de Planificacion y de Estado
Esta es la informacion que se necesita por el sistema operativo para Ilevar a cabo sus funciones de
planificacion. Los elementos tfpicos de esta informacion son los siguientes:
• Estado del proceso: Define la disposicion del proceso para ser planificado para ejecutar (en ejecu­
cion, listo, esperando, detenidol.
• Prioridad: Se puede usar uno 0 mas campos para describir la prioridad de planificaci6n de los pro­
cesos. En algunos sistemas se necesitan varios valores (por omision, actual, la mas alta permitida).
• Informaci6n de planificaci6n: Esta dependera del algoritmo de planificaci6n utilizado. Como
" ejemplos se tlenen la cantldad de tiempo que el proceso ha estado esperando y la cantidad de
tiempo que el proceso ejecut6 la ultima vez.
• Suceso: La identidad del suceso que el proceso esta esperando antes de poder reanudarse.
Estructuradon de Datos
Un proceso puede estar enlazadocon otros procesos en una cola, un anillo 0 alguna otra estructura.
Por ejemplo todos los procesos que estan en estado de espera de un nivel determinado de priori­
dad pueden estar enlazados en una cola. Un proceso puede mostrar una relacion padre-hijo (crea­
dor-creado) con otro proceso. EI bloque de control de proceso puede contener punteros a otros
procesos para dar soporte a estas estructuras.
Comunicacion entre Procesos
Puede haper varios indicadores, sefiales y mensajes asociados con la comunicacion entre dos proce­
50S independientes. I::Jna parte de esta informacion 0 toda ella se puede guardar en el bloque de
control de proceso.
• (continua)
JIll"

122 Descripcion y control de procesos

TABLA 3.8 (Continuacion)


Informacion de Control del Proceso
Privilegios de los procesos
A los pracesos se les otorgan p~ivilegios en terminos de la memoria a la que pueden acceder y el
tipo de instrucciones que.pueden ejecutar. Ademas, tambien se pueden aplicar privilegios al usa de
los servicios y utilidades del sistema.
Gestion de Memoria
Bta secci6n puede incluir punteros a las tablas de paginas y/o segmentos que describen la memoria
virtual asignada al proceso.
Propiedad de los Recursos y Utilizacion
Se pueden indicar los recursos contralados por el praceso, tales como los archivos abiertos. Tambien
se puede incluir un historico de la utilizaci6n del pracesador a de otros recurSOSi esta informacion
ser .rwcesaria para el

Ylos punteros de pila. Los registros visibles para el usuario son aquellos accesibles para los
programas de usuario y que se usan para almacenar datos temporalmen"ie. La mayoria de los
procesadores incluyen de 8 a 32 registros. Algunas arquitecturas recientes con juegos redu­
cidos de instrucciones (RISC, 'Reduced-Instruction Set Computer) disponen de mas de 100
registros.
Se emplean varios registros de control y de estado para controlar la operacion del pro­
cesador: La mayoria de estos, en la mayoria de las maquinas, no son visibles para los
usuarios, Algunos de ellos pueden ser visibles para las instrucciones de maquina ejecuta­
das en modo de control 0 del sistema operativo. Un registro de control que se encuentra
en todos los procesadores es el contador de programa 0 registro de instruccion, que con­
tiene la direcci6n de la proxima instruccion que debe leerse. Ademas, todos los disefios
de procesadores incluyen un registro 0 conjunto de registros, a menudo conocido como
palabra de estado del programa (PSW, Program Status Word), que contiene la informa­
cion de estado. Normalmente, la PSW contiene los codigos de condicion junto a otra in­
formacion de estado.
Un buen ejemplo de palabra de estado del programa es la de las maquinas VAX, que se
muestra en la figura 3.lO y en la tabla 3.9. Este formato es el que utiliza el sistema operativo
VMS y el UNIX BSD de Berkeley, que se ejecutan en los VAX. #

Por ultimo, uno 0 mas registros de pita proporcionan los punteros a las pilas empleadas
por el sistema operativo para controlar la ejecucion de los program as y llevar la cuenta de
las interrupciones.
Ala tercera categoria general de informacion del bloque de control de proceso se Ie puede
llamar, a falta de un nombre mejor, informacion de control del proceso. Esta es la infor­
macion adicional necesaria para que el sistema operativo controle y coordine los diferentes
procesos activos. La ultima parte de la tabla 3.8 indica el ambito de esta informacion. A me­
dida que se examinen los detalles de la funcionalidad de los sistemas operativos en los capf­
tulos sucesivos, quedara mas clara la necesidad de algunos de los elementos de esta !ista.
La figura 3.11 muestta la estructura de la imagen de un proceso en memoria virtual. Cada
imagen de proceso consta de un bloque de control de proceso, una pila de usuario, el espa­
cio de direcciones privadas del proceso y cualquier otro espacio de direcciones que com­
.... Oescripcion de procesos 123

.
FIGURA 3.10 Palabra del estado del procesador VAX

TABLA 3.9 de la Palabra de Estado del Procesador VAX


C6digos de condici6n (N, Z, V, C)
Est~ bits reflejan el resultado de la instruccion mas reciente que les afecto: N = .negatlvo, Z = cero (zero),
)/= desbordamiento (oveti/ow), C =acarreo (carry). Las instrucciones de saito condicional deben com­
probar estos bits.
Indicadores de Habilitaci6n de Cepos (DV, FU, IV, T)
Estos bits se utilizan para habilitar e inhabilitar 105 tipos de interrupcion Ilamados cepos: DV desbor­
damiento decimal (decima/ overflow), FU desbordamiento de coma flotante (floating undetilowl,
IV = desbordamiento de enteros (integer oveti/ow), T traza.
§t Nivel de Prioridad de Interrupciones (IPC Interrupt Priority Leve~
EI nivel actual de prioridad del procesador. Solo seran reconocidas las interrupciones de mayor prioridad.
Modo Previo
Valor del modo de acceso anterior al actual
Modo Actual
Modo actual de acceso del procesador, que determina las instrucciones que el procesador puede ejecu­
tar y las posiciones de la memoria virtual a las que puede acceder la instruccion actual. Los cuatro mo­
dos son: nucleo, ejecutor, supervisor y usuario. Vease el problema 3.5.
Pila de Interrupciones (IS, Interrupt Stack)
1 Indica si el procesador esta procesando una interrupcion. Si es as!, el procesador hace uso de una pila es­
pecial lIamada pila de interrupciones.

Primera Parte Hecha (FPD, First Part Done)


Usado en las instrucciones que pueden ser interrumpidas durante su ejecucion. Si FDP 1, cuando el
procesador retorne de una interrupcion, se reanudara la operacion en donde se dejo, en vez de reini­
ciar la instruccion.
Traza Pendiente (TP, Trace Pending)
EI servicio de traza 0 seguimiento permite al depurador tomar el control despues de la ejecucion de cada ins­
truccion, usando una interrupcion de seguimiento. Cuando las interrupciones de seguimiento estan habili­
tadas, ~I bit TP asegura que solo se puede producir una determinada interrupcion para cada instruccion.
Modo de Compatibilidad (CM, Compatibility Mode)
Cuando el procesador VAX~ 11 esta en modo de compatibilidad, ejecuta instrucciones del PDP-11 en vez
de instrucciones del VAX. Otros miembros de la familia VAX ofrecen esta funcion por emulacion de
... software.
124 Descripci6n y control de procesos

CI
~··---1
Identificaci6n
de~E!0ceso_~ •
-------J
! Identificaci6n
L~ ______ ~_
del proceso
Bloque de
Informacion de
Control de
I Informacion de
. estado del Proceso . l'stado del Proceso
-.----.~.~
Proceso
Informacion de Informacion de
control del proceso control del proceso

Pila de Usuario Pi!: U,u",io I Pila de Usuario

I
Espacio
Espacio
E"pacio
privado de
privado de
privado de
direcciones del
direcciones dd
direcciones del
tlsuario
uSllario
uSliario
(programas, datos)
(Programa", datos)
(Programas, datos)

Espacio de ESpcKio de Espadode


Direcciones Direcciones Direcciones
Compartido Compartido Compartido
Proceso 1 Proceso 2 Proceso 11

FIGURA 3.11 Procesos de usuario en memoria virtual

parta con otros procesos. En la figura, cada imagen de proceso aparcce como un rango CO\1­
tiguo de direcciones. En una implementaci6n real, cste puede que no sea el caso, sino que
dependa del esquema de gestion de memoria y de la forma en la que el sistema operativo or­
ganiza las estructuras de control.
Como se indica en la tabla 3.8, el bloque de control de proceso puede contener informa­
cion de estructuraci6n, incluyendo punteros que penni ten enlazar los bloques de control de
procesos. Por tanto, las colas que se describieron en la secci6n precedente podrian imple­
mentarse como listas enlazadas de los bloques de control de procesos. Por ejemplo, la es­
tructura de cola de la figura 3.6a podrfa implementarse como se propone en la figura 3.12.

EI papel del bloque de control del proceso


EI bloque de control de proceso es la estructura de datos central y mas importante de un sis­
tema operativo. Cada bloque de control de proceso contiene toda la informacion de un pro­
ceso necesaria para el sistema operativo. Los bloques son lefdos y/o modificados por casi to­
dos los modulos de un sistema operativo, inc\uyendo aquellos que tienen que ver con la
planificacion, la asignacion de recursos, el tratamiento de interrupciones y el analisis y su­
pervisi6n del rendimiento. Puede decirse que el conjunto de los bloques de control de pro­
cesos defim'l1 ;,,1 ""Iado del sistema operativo.
Esto saca a rdm.u Ulla cu.:sli6n importante de disefio. Una serie de rutin as del sistema ope­
rativo necesitaran acceder a la informacion de los bloques de control de procesos. La provi­
sion de acceso directo a estas tablas no es dificil. Cada proceso esta dotado de un unico ID
que puede utilizarse como Indice en una tabla de punteros a los bJoques de control de proce­
sos. La dificultad no esta en el acceso, sino mas bien en la protecci6n. Existen dos problemas:
Control de procesos 125

Bloque de
Control
de Proceso

U
FIGURA 3.12 Estructuras de colas de procesos
L
• Un error en una sola rutina, como la de tratamiento de interrupciones, puede danar los
bloques de control deprocesos, 10 que destruirfa la capacidad del sistema para adminis­
trar los procesos afectados .
• Un cambio de disefio en la estructura 0 en la semantica del bloque de control de proce­
sos podrfa afectar a varios m6dulos del sistema operativo.
Estos problemas se pueden abordar exigiendo a todas las rutinas del sistema operativo
que pasen a traves de una rutina de manejo, cuya iinica tarea sena la de proteger los bloques
de control de proceso y que se constituiria en el unico arbitro para leer y escribir en estos
bloques. La concesi6n en el empleo de una rutina tal esta en el rendimiento y en el grado con
el que pueda confiarse en que el resto del software del sistema sea correcto.

3.3
CONTROL DE PROCESOS

Modos de ejecuci6n
Antes de continu.ar la discusi6n sobre la forma en que el sistema operativo gestiona los
procesos, hace falta distinguir entre el modo de ejecucion del procesador que normalmente
se asocia con el sistema operativo y el modo que normalmente se asocia con los programas
126 Descripcion y control de procesos

de usuario. La mayona de los procesadores dan soporte para dos modos de ejecudon por 10
menos. Ciertas instrucciones pueden ejecutarse s610 en modo privilegiado. Entre estas estan
la lectura 0 modificacion de registros de control (como la palabra de estado del programa),
instrucciones primitivas de E/S e instrucciones relativas a la gestion de memoria. Ademas,
se puede acceder a ciertas regiones de memoria solo en el modo mas privilegiado.
El modo menos privilegiado a menudo se conoce como modo de usuario, ya que los pro­
gramas de ·usuario ejecutan normalmente en ese modo. Al modo mas privilegiado normal­
mente se Ie conoce como modo del sistema, modo de control 0 modo del nucleo. Este ultimo
termino se refiere al nucleo del sistema operativo, que es la parte del sistema operativo que
Heva a cabo las funciones importantes del sistema. La tabla 3.10 enumera las funciones que
normalmente se haHan en el nucleo de un sistema operativo.
La razon por la que se usan dos modos debe quedar clara. Es necesario proteger al sistema
operativo y a las tablas importantes del mismo, tales como los bloques de cOI1trol de procesos,
de las injerencias de los programas de usuario. En el modo del nucleo, el software tiene control
completo del procesador y de todas sus instrucciones, registros y memoria. Este myel de con­
trol no es necesario y, por seguridad, tampoco conveniente para los programas de usuario.
/ Surgen dos preguntas: lC6mo conoce el procesador en que modo va a ejecutar?

lComo se cambia de modo? Para la'primera pregunta, normalmente hay un bit en la PSW

que indica el modo de ejecucion. El bit es cambiado como respuesta a ciertos sucesos.

Por ejemplo, cuando un usuario hace una Hamada a un servicio del sistema operativo, el

modo se cambia al de nucleo. Esto se suele llevar a cabo ejecutando una instruccion que

cambia el modo. Un ejemplo de como se hace esto es la instruccion de Cambio de Modo

(CHM, Change Made) del VAX. Cuando el usuario hace una Hamada a un servicio del

TABLA 3.10 Funciones Basicas del Nucleo de un Sistema Operativo


Gestion de Procesos
• Creaci6n y terminaci6n de los procesos
• Planificaci6n y expedici6n de los procesos
• Cambio de procesos
• Sincronizaci6n de procesos y soporte para la comunicaci6n entre procesos
• Gestion de los bloques de control de procesos \
Gestion de memoria
• Asignacion de espacios de direcciones a los procesos
• Intercambio
• Gesti6n de paginas y segmentos

Gestion de E/S
• Gesti6n de buffers
• Asignaci6n de canales de E/S y dispositivos a los procesos

Funciones de Soporte
• Tratamiento de interrupciones
• Contabilidad
• Supervision
4w Control de procesos 127

sistema 0 cuando una interrupcion transfiere el control a una rutina del sistema, la rutina
ejecuta CHM para entraren un modo mas privilegiado y la ejecuta de nuevo para pasar a
un modo menos privilegiado, antes de devolver el control al proceso del usuario. Si un
programa de usuario intenta ejecutar un CHM, se originara simplemente una Hamada al
sistema operativo, que. devolvera un error a menos que este permitido el cambio de
modo.

Creaci6n de procesos
1\. Anteriormente, en la seccion 3.1, se discutieron los sucesos que conducfan a la creacion de
un nuevo proceso. Una vez tratadas las estructuras de datos asociadas a los procesos, se esta
en condiciones de describir brevemente los pasos que entran en juego en la creacion real de
los procesos.
Una vez que el sistema operativo decide, por alguna razon (tabla 3.1), crear un nuevo pro­
ceso, este puede proceder como sigue:
1. Asignar un unico identificador al nuevo proceso. En ese momento se afiade una nueva
entrada a la tabla principal de procesos, que contiene una entrada por proceso.
2. Asignar espacio para el proceso. Esto incluye todos los elementos de la imagen del pro­
ceso. As! pues, el sistema operativo debe saber cuanto espacio se necesitara para el espa­
cio privado de direcciones del usuario (programas y datos) y para la pila del usuario. Es­
tos va!0res se pueden asignar por omision en funcion del tipo de proceso 0 bien se puede

{ asignar a partir de la solicitud del usuario cuando se crea el trabajo. Si un proceso es ge­
nerado por otro, el proceso padre puede pasarle al sistema operativo los valores necesarios
como parte de la solicitud de creacion del proceso. Si algtin espacio de direcciones exis­
tente se va a compartir con este nuevo proceso, entonces se deben establecer los enlaces
adecuados. Por ultimo, se debe asignar espacio para el bloque de control del proceso.
3. Debe inicializarse el bloque de control del proceso. La parte de identificacion del pro­
ceso contiene el ID de este proceso junto a otros ID apropiados, tales como el del pro­
ceso padre. La parte de informacion del estado del procesador normalmente se inicia­
liza con la mayor parte de las entradas acero, excepto para el contador de programa
(que se prepara con el punto de entrada del programa) y los punteros a las pilas del sis­
tema (que establecen los limites de la pila del proceso). La parte de informacion de
control del procesador se inicializa a partir de los valores estandares por omision y los
atributos que se han solicitado para el proceso. Por ejemplo, el estado del proceso
suele inicializarse a Listo 0 a Listo y suspendido. La priori dad puede asignarse por
omision al valor mas bajo, a menos que se haya hecho una solicitud explfcita de un va­
lor mayor. Inicialmente, puede que el proceso no posea ningun recurso (dispositivos
de E/S, archivos), a menos que se haya hecho una solicitud explicita de los mismos 0
a menos que se hayan heredado del proceso padre.
4. Se deben establecer los enlaces apropiados. Por ejemplo, si el sistema operativo man­
tien~ cada cola de planificacion como una lista enlazada, entonces el proceso nuevo se
debe poner en la cola de Listos 0 de Listos y suspendidos.
5. Puede haber otras estructuras de datos que crear 0 ampliar. Por ejemplo, el sistema
operativo puede mantener un archivo de contabilidad para cada proceso que sea utili­
zado mas tarde conpropositos de facturacion y/o evaluacion del rendimiento.
128 Descripcion y control de procesos

Cambio de proceso
A primera vista, la funci6n de cambio de proceso parece sencilla. En cierto momento, un
proceso que esta ejecutandose se interrumpe, el sistema operativo pone a otro proceso en el
estado de Ejecuci6n y pasa el control a dicho proeeso. Sin embargo, surgen diversas cues­
tiones de disefio. En primer lugar, l,que sucesos provocan un eambio de proeeso? Otra cues­
ti6n es que se debe hacer una distinci6n entre cambio de contexto y cambio de proceso. Por
ultimo, l,que debe haeer el sistema operativo con las diferentes estrueturas de datos bajo su
control para llevar a cabo un cambio de proceso?

Cuando cambiar de proceso


Un cambio de proeeso puede producirse en eualquier momento en que el sistema operativo
haya tornado el eontrol a partir del proceso que esta actual mente ejecutandose. La tabla 3.11
propone los sueesos posibles que pueden dar el control al sistema operativo.
En primer lugar, se van a tener en cuenta las interrupeiones d'eI sistema. Se pueden distin­
guir, como hacen muchos sistemas, dos c1ases de interrupciones del sistema, una conocida
simplemente como interrupei6n y otra conocida como cepo. La primera es originada por al­
gun tipo de suceso que es extemo e independiente del proceso que esta ejecutandose, como
la eulminaci6n de una operaci6n de E/S. La segunda tiene que ver eon una eondici6n de
error 0 de excepci6n generada dentro del proceso que esta ejeeutAndose, como un intehto
ilegal de aeceso a un arehivo. En una interrupcion ordinaria, el control se transfiere pri­
mero a un gestor de interrupciones, quien lleva a eabo algunas tareas basieas y, despues, se
salta a' una rutina del sistema operativo que se ocupa del tipo de interrupci6n que se ha pro­
( ducido. Algunos ejemplos son los siguientes:
• Interrupci6n de reloj: EI sistema operativo determina si el proeeso que esta en ejeeu­
ci6n ha estado ejeeutando durante la fracci6n maxima de tiempo permitida. Si esto ocu­
rre, el proeeso debe pasar al estado Listo y se debe expedir otro proeeso.
• Interrupci6n de EIS: EI sistema operativo determina exactamente que se ha pro­
dueido. una acei6n de E/S. Si la acci6n eonstituye un sueeso que estan esperando
uno 0 mas proeesos, entonees el sistema operativo traslada todos los procesos
bloqueados correspondientes al estado Listo (y los procesos Bloqueados y sus­
pendidos pasan al estado de Listos y suspendidos). El sistema operativo debe en­
tonees decidir si se reanuda la ejeeuci6n del proceso que esta aetualmente en eS'­
tado de Ejeeuei6n 0 se expulsa a dicho proceso en favor de un proeeso Listo de
mayor prioridad.

TABLA 3.11 Mecanismos para la interrupcion de la Ejecucion de un Proceso [KRAK88]


Mecanismo Causa Uso
Interrupcion Externa a la ejecucion de Reacci6n a un suceso
la instrucci6n en curso asincr6nico externo
Cepo Asociada con la ejecuci6n de Tratamiento de un error 0 de
la instrucci6n en curso una condici6n excepcional
Llamada del supervisor Solicitud explfcita Llamada a una funci6n
del sistema operativo
.
Control de procesos 129

• F allo de memoria: El procesador encuentra una referencia a una direccion de memoria


virtual de una palabra que no esta en memoria principal. El sistema operativo debe traer
el bloque (pagina 0 segmento) que contiene la referencia, de la memoria secundaria a la
memoria principal. Despues de hacer la solicitud de E/S para traer el bloque de memo­
ria, el sistema operativo' puede llevar a cabo un cambio de contexto para reanudar la eje­
cucion de otro proceso; el proceso que cometio el fallo de memoria se pasa a estado
Bloqueado. Despues de que el bloque en cuestion se cargue en memoria, dicho proceso
se pondra en estado Listo.
'1­
En los cepos, el sistema operativo determina si el error es fatal. Si 10 es, el proceso que se
estaba ejecutando pasa al estado de Terminado y se produce un cambio de proceso. Si no es
fatal, la accion del sistema operativo dependera de la naturaleza del error y del disefio del
sistema operativo. Se puede intentar algun procedimiento de recuperacion 0, simplemente,
notificarlo al usuario. Se puede hacer un cambio de proceso 0, simplemente, reanudar el
mismo proceso que se estaba ejecutando.
Finalmente, el sistema operativo puede activarse mediante una Hamada del supervisor
desde el programa que se esta ejecutando. Por ejemplo, esta ejecutandose un proceso de
usuario y se llega a una instrucci6n que solicita una operaci6n de E/S, tal como abrir un ar­
chivo. Esta Hamada provoca'la transferencia a una rutina que forma parte del c6digo del sis­
tema operativo. Por 10 general, el uso de una llamada al sistema hace que el proceso de usua­
rio pase al estado Bloqueado.

..
Cambio de contexto
En el capitulo 1 se discutio sobre la inclusion de un cicio de interrupcion como parte del ci­
cio dj instruccion. Recuerdese que, en el cicio de interrupcion, el procesador comprueba si
se h( producido alguna interrupcion, 10 que se indicaria por la presencia de una senal de in­
terrupcion. Si no hay pendiente ninguna interrupcion, el procesador continua con el cicio de
lectura de la instruccion siguiente del program a en curso del proceso actual. Si hay alguna
interrupcion pendiente, el'procesador hace 10 siguiente:
1. Salva el contexto del program a que esta ejecutandose.
2. Asigna al contador de programa el valor de la direccion de comienzo de un programa
{t
de tratamiento de fa interrupci6n.
EI procesador continua entonces con el cicIo de lectura de instruccion y trae la primera
instruccion del programa de tratamiento de interrupciones, que atendera a la interrupcion.
Una pregunta que puede plantearse es: l,Que es 10 que constituye el contexto que se salva?
La respuesta es que se debe incIuir cualquier informacion que pueda alterarse por la ejecu­
cion de la rutina de tratamiento de la interrupcion y que pueda ser necesaria para reanudar el
program a que fue interrumpido. Asi pues, debe salvarse la parte del bloque de control del
proceso que se denomina informacion de estado del procesador. Esto incluye el contador de
programa, otros registros del procesador y la informacion de la pila.
l,Hace falta hacer algo mas? Ello dependenl de 10 que ocurra a continuacion. La rutina de
tratamiento de la interrupcion es normal mente un programa corto que lleva a cabo unas pocas
tareas basic as relacionadas con una interrupcion. Por ejemplo, se marca el indicador que se­
;;.
nala la presencia de una interrupci6n, puede enviar un acuse de recibo a la entidad que pro­
dujo la interrupcion (como un modulo de E/S) y puede hacer algunas labores basicas relacio­
1 30 Descripcion y control de procesos

nadas con los efectos del suceso que causo la interrupcion. Por ejemplo, si la interrupcion esta
relacionada con un suceso de E/S, el gestor de interrupciones comprobara condiciones de
error. Si se ha producido un error, la rutina de tratamiento puede enviar una sefial al proceso
que solicito originalmente la operacion de E/S. Si la interrupcion es de reloj, el gestor debera
dar1e el control al distribuidor,quien querra pasarle el control a otro proceso, puesto que la
fraccion de tiempo asignada al proceso que estaba ejecutandose habra expirado.
l,Que sucede con el resto de informacion del bloque de control del proceso? Si la inte­
rrupcion va a venir seguida de un cambio a otro proceso, entonces hace falta hacer cierto tra­
bajo. No obstante, la palabra clave en la oracion anterior es la condicional si. En la mayorfa
de los sistemas operativos, el acontecimiento de una interrupcion no provoca necesaria­
mente un cambio de proceso. Es posible que despues de que el gestor de interrupciones haya
ejecutado, el proceso que estaba ejecutandose reanude su ejecucion. En tal caso, todo 10 que
hayque hacer es salvar la informacion de estado del procesador cuando se produzca la inte­
rrupcion y restaurar dicha informacion cuando el control vuelva al prbgrama que estaba en
marcha. Las funciones de salvar y restaurar sue1en llevarse a cabo en el hardware.

Cambia de estado de los procesos


Esta claro entonces que el campio de contexto es un concepto distinto del cambio de pro­
ceso. 6 Puede producirse un cambio de contexto sin cambiar el estado del proceso que esta
actualmente en estado de Ejecucion. En tal caso, salvar el contexto y restaurarlo posterior­
mente involucra un pequefio coste extra. Sin embargo, si el proceso que estaba ejecutandose
tiene que pasar a otro estado (Usto, Bloqueado, etc.), el sistema operativo tiene que llevar a
cabo cambi<j'> substancia1es en su entorno. Los pasos involucrados en un cambio completo
de proceso rm los siguientes:
1. Salvar el contexto del procesador, incluyendo el contador de programa y otros registros.
2. Actualizar el bloque de control del proceso que estaba en estado de Ejecucion. Esto
implica cambiar el estado del proceso a alguno de los otros estados (Listo, Bloqueado,
Usto y suspendido, Terminado). Tambien se tienen que actualizar otros campos signi­
ficativos, incluyendo la razon por la que se abandona el estado de Ejecucion y la in­
formacion de contabilidad.
3. Mover el bloque de control del proceso a la cola apropiada (Listos, Bloqueados por el
Suceso i, Ustos y suspendidos).
4. Seleccionar otro proceso para ejecucion; este tema se explora en los capftulos 6 y 7.
5. Actualizar el bloque de control del proceso seleccionado. Esto incluye cambiar el es­
tado del proceso a Ejecucion.
6. Actualizar las estructuras de datos de gestion de memoria. Esto puede hacer falta de­
pendiendo de como se gestione la traduccion de direcciones; este tern a se analiza en
los capftulos 6 y 7.
7. Restaurar el contexto del procesador a aquel que existfa en el momento en el que el
proceso seleccionado dejo por ultima vez el estado de Ejecucion, cargando los valores
previos del contador de programa y de otros registros.

6 Desafortunadamente, algunos libros de texto sobre el tema usan el termino cambio de contexto queriendo decir cambio de
proceso y no tienen un termino particular para la sencilla acci6n que aquf se ha definido como cambio de contexto.
-61­
Control de procesos 131

As! pues, el cambio de proceso, que supone un cambio de estado, requiere un esfuerzo
considerablemente mayor que un cambio de contexto.
Ejecuci6n del sistema operativo
En el capitulo 2 se sefialaron algunos hechos curiosos sobre los sistemas operativos:
• El sistema operativo funciona de la misma forma que un software corriente, es decir, es
un programa ejecutado por el procesador.
• El sistema operativo abandon a frecuentemente el control y debe depender de que el
~
procesador Ie permita recuperarlo.
Si el sistema operativo es solamente una coleccion de programas y si es ejecutado por el
procesador, como cualquier otro programa, ~es el sistema operativo un proceso? Si 10 fuese,
~como se controla?

Estas interesantes preguntas han merecido variadas respuestas de los disefiadores de sis­
temas operativos. La figura 3.13 Hustra un rango de enfoques que pueden encontrarse en va­
rios de los sistemas operativos contemponineos.

Nucleo fuera de todo proceso


Un enfoque bastante tradicional y habitual en muchos de los sistemas operativos mas anti­
guos es ejecutar el nueleo del sistema operativo fuera de cualquier proceso (figura 3.13a).
Con este enfo~, cuando el proceso en ejecucion es interrumpido 0 hace una Hamada de su­
pervisor, se·salva el contexto del procesador para este proceso y se pasa el control al Olicleo.
El sistema operativo tiene su propia region de memoria y su propia pila del sistema para

controlar las llamadas y retomos de procedimientos. El sistema operativo puede llevar a
cabo cualquier funcion deseada y luego restaurar el contexto del proceso interrumpido para
reanudarlo. Otra solucion sena que el sistema operativo pudiese completar la funcion de sal­
var el entomo del proceso y continuar con la planificacion y expedici6n de otro proceso.
Que sea esto 10 que pase depende de la causa de la interrupcion y de las circunstancias del
momento.
En cualquier caso, el punto clave es que se considera que el concepto de proceso se aplica
s610 a los programas del usuario. El c6digo del sistema operativo se ejecuta como una enti­
dad separada que opera en modo privilegiado.
"
Ejecuci6n dentro de los procesos de usuario
Una altemativa que es comtin en los sistemas operativos de maquinas pequefias (minicom­
putadores y microcomputadores) es ejecutar casi todo el software del sistema operativo en el
contexto de un proceso de usuario. EI enfoque es que el sistema operativo es principalmente
una coleccion de rutinas que el usuario llama para llevar a cabo varias funciones y que son
ejecutadas dentro del entomo del proceso de usuario, como se ilustra en la figura 3.13b. En
un punto dadocualquiera, el sistema operativo estara gestionando N imagenes de procesos.
Cada imagen ineluye no s6lo las regiones que se ilustran en la figura 3.11, sino tambien zo­
nas de prpgrama, de datos y de pila para los programas del ntieleo.
La figura 3.14 propone una estructura tipka para la imagen de un proceso de usuario segun esta
estrategia. Un pila del micIeo separada se utiliza para gestionar las llamadas y los retomos rnien­
.;j
tras que e1 proceso este en el modo del nueleo. El cooigo y los datos del sistema operativo estan en
el espacio de direcciones compartidas y son compartidos por todos los procesos de usuario.
132 Descripci6n y control de procesos

Nlic1eo

(a) Nuc1eo separado

(b) Las funciones del SO se ejecutan dentro de los procesos de usuario

(c) Las funciones del SO que ejecutan como procesos separados


FIGURA 3.13 Relaci6n entre el sistema operativo y los procesos de usuario

Cuando se produce una interrupci6n, un cepo 0 una Hamada del supervisor, el procesador
se pone en modo del mic1eo y el control pasa al sistema operativo. Con tal fin, se salva el
contexto del procesador y tiene lugar un cambio de contexto hacia una rutina del sistema
operativo. Sin embargo, la ejecuci6n continua dentro del proceso de usuario en curso. De
esta manera, no se ha llevado a cabo un cambio de proceso, sino un cambio de contexto den­
tro del mismo proceso.
Si el sistema operativo, al completar su trabajo, determina que el proceso en curso debe
continuar ejecutando, entonces se lleva a cabo un cambio de contexto para reanudar el pro­
grama interrumpido del proceso en curso. Esta es una de las ventajas clave de este enfoque:
Un programa de usuario se interrumpe para emplear alguna rutina del sistema operativo,
luego se reanuda y todo se produce sin la penalizaci6n de dos cam bios de proceso. No obs­
tante, si se determina que va a producirse un cambio de proceso en vez de retornar al pro­
grama que estaba ejecutandose previamente, entonces se pasa el control a una rutina que
hace el' cambio entre procesos. Esta rutina puede 0 no ejecutar en el proceso en curso, de­
pendiendo del disenodel sistema. Sin embargo, en algun punto, el proceso en curso debe po­
nerse en estado de No'Ejecuci6n y otro proceso debe designarse como proceso en Ejecu­
ci6n. Durante esta fase, es 16gicamente mas conveniente considerar que la ejecuci6n tiene
lugar fuera de todos los procesos.
.. Control de procesos 133

Identificaci6n
del proceso
Infonnaci6n de
estado del proceso
Informaci6n de
lBloqu, d, Control
J d,1 Pro",,,
control del proceso

Pila del Usuario


~

Espacio privado

; de direcciones del
usuario

Pila del N6.cleo

'4

FIGURA 3.14 Imagen del proceso: el sistema operativQ ejecuta dentro del proceso de usuario

En cierto sentido, este enfoque del sistema operativo es bastante singular. Expuesto de
forma simple, cada cierto tiempo, se salvara la informaci6n de estado de un proceso, se esco­
gera otro proceso para ejecutar de entre todos los que esten listos y se cedera el control a di­
cho proceso. La raz6n por la que esta no es una situaci6n arbitraria ni mucho menos ca6tica
es que, durante el tiempo critico, el c6digo que se ejecuta en el proceso de usuario es c6digo
j
compartido por el sistema operativo y no c6digo del usuario. Debido al concepto de modo de
usuario y modo del nueleo, el usuario no puede entrometerse ni estorbar a las rutinas del sis­
tema operativo, aun cuando estas esten ejecutando en el entomo del proceso de usuario. Esto
sirve para recordar una vez mas que existe una distinci6n entre los conceptos de proceso y
program a y que la relaci6n entre los dos no es de uno a uno. Dentro de un proceso pueden eje­
cutarse tanto un programa de usuario como uno del sistema operativo y los programas del sis­
tema operativo que ejecutan en los diferentes procesos de usuario son identicos.

Sistema operativo basado en procesos


Una ultima altemativa, ilustrada en la figura 3.13c, es la de implementar el sistema operativo
como una colecci6n de procesos del sistema. Al igual que enlas otras opciones, el software que
forma parte del nucleo ejecutara en modo de nueleo. En este ca'>o, sin embargo, las funciones
mas importantes del nueleo se organizan en procesos separados. Una vez mas, puede haber una
pequefia cantidad de cOdigo de cambio de procesos que se debe ejecutar fuera de todo proceso.
134 Descripcion y control de procesos

Este enfoque tiene varias ventajas. Impone unas nonnas de disefio de programas que pro­
mueven el uso de un sistema operativo modular con unas interfaces minimas y claras entre
los m6dulos. Ademas, algunas funciones no crfticas del sistema operativo se pueden imple­
mentar como procesos separados. Por ejemplo, se mencion6 anterionnente un programa su­
pervisor que registrara el ni'veI de utilizaci6n de los recursos (procesador, memoria, canales)
y la velocidad de progreso de los procesos de usuario en el sistema. Como este programa no
provee un servicio particular a ningun proceso activo, puede ser invocado solamente por el
sistema operativo. Como un proceso, la funci6n podra ejecutar con un nivel de prioridad
asignado y ser intercalada con Olros procesos bajo el control del distribuidor. Por ultimo, im­
plementar el sistema operativo como un conjunto de procesos es util en un entomo de mul­
tiprocesador 0 de varios computadores, en el cual algunos de los servicios del sistema ope­
rativo pueden enviarse a procesadores dedicados, mejorando asi el rendimiento.

Micronucleos
Un concepto que ha recibido mucha atenci6n ultimamente es el de micronuc1eo (microker­
nel). Un micronucleo es un pequefio nueleo de sistema operativo que proporciona las bases
para ampliaciones modulares. Sin embargo, el tennino es algo conflfso, pues hay una serie
de cuestiones sobre los micronueleos cuyas respuestas son diferentes segun los distintos
equipos de disefio de sistemas operativos. Estas cuestiones son sobre lopequefio que debe
ser el nueleo para ser calificado de micronueleo, sobre como disefiar los controladores (dri­
vers) de dispositivos para alcanzar el mejor rendimiento ala vez que sus funciones se inde­
pendizan del hardware, si las operaciones que no sean del nueleo deben ejecutar en el espa­
cio del nueleo 0 en el del usuario, y si se debe mantener el codigo de los subsistemas
existentes (por ejemplo, una versi6n de UNIX) 0 empezar desde cero.
El enfoque de los micronueleos fue popularizado por el sistema operativo Mach y sus im­
plementaciones en la linea de computadores de Next. En teona, el enfoque del nucleo se su­
pone que brinda una gran flexibilidad y modularidad. En la pnictica, este beneficio fue hasta
cierto punto denegado por el sistema operativo servidor monolitico BSD 4.3 que Next cons­
truy6 en tomo a Mach. Otra aplicaci6n muy conocida del enfoque de micronucleos es Win­
dows NT, que proelama no s6lo la modularidad, sino la portabilidad, como los beneficios
clave. El nueleo esta rodeado por una serie de subsistemas compactos de fonna que facilita
la tarea de implementar NT en una gran varied ad de platafonnas. Actualmente, otros pro- •
ductos presumen de tener implementaciones de micronueleo y este enfoque general de di­
sefio parece que va asentarse en casi todos los computadores personales, estaciones de tra­
bajo y sistemas operativos servidores que se desarrollen en el futuro proximo [VARH94].
La filosofia en que se basa el micronueleo es que solo las funciones absolutamente esen­
ciales del nueleo del sistema operativo deben pennanecer en el nueleo. Las aplicaciones y
los servicios menos esenciales se construyen sobre el micronueleo. Aunque la linea diviso­
ria de 10 que esta dentro y 10 que esta fuera del micronueleo varia de un disefio a otro, la ca­
ractenstica comun es que muchos servicios que tradicionalmente han fonnado parte del sis­
tema eperativo son ahora subsistemas extemos que interactuan con el nucleo y con otros
subsistemas; aqul se ineluyen los sistemas de archivos, los sistemas de ventanas y los servi­
cios de seguridad .
Una vez mas, aunque los disefios espedficos de cada micronucleo pueden diferir, en ge­
neralla arquitectura de micronucleo tiende a reemplazar la estratificacion tradicional, en ca­
" Procesos e hilos 135

pas verticales, de un sistema operativo, por una horizontal. Las componentes del sistema
operativo extemas al micromlc1eo interactuan una con otra sobre una base comun, normal­
mente a traves de mensajes distribuidos a traves del micronucleo. De este modo, el micro­
nuc1eo funciona como un distribuidor de mensajes: Valida los mensajes, los pasa entre las
componentes y otorga el acceso al hardware. Esta estructura es ideal para entomos de pro­
ceso distribuido, ya que el micronucleo puede pasar mensajes tanto en local como en re­
moto, sin necesidad de cambios en otras componentes del sistema operativo.
j.

3.4
PROCESOS E HllOS
En la discusi6n llevada a cabo, se ha presentado el concepto de pro~eso inc1uyendo las dos
caracterfsticas siguientes:
• Unidad de propiedad de los recursos: A cada proceso se Ie asigna un espacio de direc­
ciones virtuales para albergar a la imagen del proceso y, de cuando en cuando, al pro­
ceso se Ie puede asignar memoria virtual y otros recursos, tales como canales de E/S,
dispositivos de E/S y arc.hivos .
• Unidad de expedici6n: Un proceso es un camino de ejecuci6n (traza) a traves de uno 0
mas programas. Esta ejecuci6n puede ser intercalada con la de otros procesos. De este
modo, un proceso tiene un estado de ejecucion (Ejecucion, Listo, etc.) y una prioridad
;, de expedicion. La unidad planificada y expedida por el sistema operativo es el proceso.
En la mayorfa de los sistemas operativos, estas dos caracteristicas son, de hecho, la
esencia de un proceso. Sin embargo, algunos argumentos pueden convencer de que estas
dos caracterfsticas son independientes y que deben ser tratadas de manera independiente
por el sistema operativo. Esto se hace asf en una serie de sistemas operativos, en particu­
lar en algunos sistemas operativos de desarrollo reciente. Para distinguir estas dos carac­
teristicas, la unidad de expedicion se conoce como hilo (thread) 0 proceso Iigero (light­
weight process), mientras que a la unidad de propiedad de los recursos se Ie sueIe llamar
proceso 0 tarea. 7

;to Varios hilos en un solo proceso

La utilizacion que mas salta a la vista del concepto de hilo es la de una disposicion en la que

pueden existir varios hilos dentro de un mismo proceso. Algo aproximado a este enfoque es

10 que se haceen MVS. De una forma mas explicita, este enfoque es el asumido por Win­

dows NT, OS/2, la versi6n que tiene Sun del UNIX y un importante sistema operativo cono­

cido como Mach [BLAC92, RASH89, TEVA89]. Mach es una evolucion ampliada de

UNIX que se utiliza en las estaciones Next y que forma la base de la version de UNIX de la

Fundacion para elSoftware Abierto (OSF, Open Softvvare Foundation). Este apartado des­

cribe el enfoque tornado en Mach; las tecnicas utilizadas en Windows NT y MVS se discu­

ten en la seccion 3.5.

7 Desafortunadamente, incluso este grado de consistencia no se puede mantener. En el MVS, los conceptos de espacio de di­
recciones y tarea, respectivamente, se corresponden a grandes rasgos con los conceptos de proceso e hilo que se describen en
esta secci6n.
136 Oescripci6n y control de procesos

Mach esta disefiado especfficamente para trabajar en un entomo multiprocesador, aunque


tambien se adapta bien a los sistemas monoprocesadores. En Mach, una tarea se define
como la unidad de proteccion 0 unidad de asignacion de recursos. A las tareas se les asocian
los siguientes elementos:
• Un espacio de direcciones virtuales, que contiene la imagen de la tarea
• Acceso protegidoa los procesadores, otros procesos (para la comurucacion entre proce­
sos), archivos y recursos de E/S (dispositivos y canales)
En una tarea pueden haber uno 0 mas hilos, cada uno con 10 siguiente:
• El estado de.ejecucion del hilo (Ejecucion, Listo, etc.)
• El contexto del procesador, que se salva cuando no esm ejecutando; una forma de contem­
plar al hilo'es con un contador de programa independiente operando dentro de una tare41
• Una pila de ejecucion
• Almacenamiento estatico para las variables locales
• Acceso a la memoria y a los recurs os de la tarea, que se com parten con todos los otros
hilos de la tarea
Los beneficios clave de los hilos se derivan de las implicaciones del rendimiento: Se tarda
mucho menos tiempo en crear un nuevo hilo en un proceso existente que en crear una nueva
tarea, menos tiempo para terminar un hilo y menos tiempo para cambiar entre dos hilos de
un mismo proceso. Por tanto, si hay una aplicacion 0 una funcion que pueda implementarse
como un conjunto de unidades de ejecucion relacionadas, es mas eficiente hacerlo con una
coleccion de hilos que con una coleccion de tareas separadas. 8 Algunos estudios llevados a
cabo por los desarrolladores de Mach demuestran que la aceleracion en la creacion de pro­
cesos, comparada con lade las implementaciones de UNIX que no utilizan hilos, esm en un
factor de 10 [TEVA87].
Un ejemplo de aplicacion que podrfa hacer uso de hilos es un servidor, como puede ser
un servidor de archivos de una red de area local. Cada vez que Hegue una solicitud de un
nuevo archivo, se puede generar un nuevo hila para el program a de gestion de archivos.
Puesto que el servidor debe manejar muchas solicitudes, se crearan y destruiran muchos hi­
los en un corto periodo de tiempo. Si el servidor es un multiprocesador, se pueden ejecutar
varios hilos de una misma tarea simultaneamente y en diferentes procesadores. Los hilos
son tambien utiles en los monoprocesadores para simplificar la estructura de los programas

que Heven a cabo diversas funciones. Otros ejemplos de uso efectivo de los hilos es en las
aplicaciones de proceso de comunicaciones [COOP90] yen los supervisores de proceso de
transacciones [BERN90].
Otra forma en la que los hilos aportan eficiencia es en la comunicacion entre diferentes pro­
gramas en ejecucion. En la mayorfa de los sistemas operativos, la comunicacion entre procesos
independientes requiere la intervencion del nucleo para ofrecer proteccion y para proporcionar

, Es interesante comentar que han apareddo conceptos similares al mismo tiempo en campos tales como los protocolos de co­
municaci6n, Iii arquitectura d~ computadores y los sistemas operativos, En la arquitectura de computadores, el enfoque de las
computadores con juego reducido de instrucciones (RISe, Reduced lnstruction Set Computer) ha mejorado la velocidad del
procesador, perfecciommdo la arquitectura del procesador. En los protocol os de comunicaci6n. la necesidad de altas velocida­
des de transferencia de datos entre las redes de computadores ha provocado el desarrollo de protocolos Jigeros de transporte.
Estos dos conceptos se discuten con atuplitud en {STAL93aj y [STAL94a], respectivar:1ente.
.
Procesos e hilos 137

los mecanismos necesarios para la comunicacion. Sin embargo, puesto que los hilos de una
misma tarea comparten memoria y archivos, pueden comunicarse entre sf sin invocar al nuc1eo.
[LETW88] da cuatro ejemplos de uso de los hilos en un sistema de multitarea:
• Trabajo interactivo y de fondo: Esto se produce en el sentido de la interaccion di­
recta con el usuario,no en el de sesiones interactivas y de fondo. Por ejemplo, en un
programa de hoja de d.lculo, un hilo puede estar visualizando los menus y leyendo
. la entrada del usuario mientras que otro hila ejecuta las ordenes y actualiza la hoja
'r de calculo. Esta medida suele aumentar la velocidad que se percibe de la aplicacion,
permitiendo que el programa pida la orden siguiente antes de terminar la anterior.
• Proceso aSlncrono: Los elementos asincronos del programa se pueden implementar como
hilos. Por ejemplo, para protegerse de un corte de alimentacion, se puede disefiar un proce­
~ sador de textos que escriba su buffer de la RAM al disco una vez por minuto. Se puede crear
un hila cuya Unica tarea sea hacer estas copias de respaldo periodicaS y que se planifique di­
rectarnente con el sistema operativo; no hay necesidad de ningiln c6digo superfluo en el pro­
grama principal que haga la comprobacion de tiempo 0 que coordine Ja entrada y la salida.
• Aceleracion de La ejecucion: Un proceso con hilos multiples puede computar un lote de
datos mientras lee ellote .siguiente de un dispositivo. En un sistema con multiproceso,
varlos hilos de un mismo proceso podran ejecutar realmente a la vez.
• Organizacion de los programas: Los programas que suponen una variedad de activida­
des 0 varios orfgenes y destinos de entrada y salida pueden hacerse mas faciles de dise­
oil
fiar e implementar mediante hilos.
La planificacion y la expedicion se llevan a cabo con los hilos; por tanto, la mayor parte
de la informacion de estado relacionada con la ejecucion se mantiene en estructuras de datos
al nivel de los hilos. Sin embargo, hay varlas acciones que afectan a todos 10 hilos de una ta­
rea y que el sistema operativo debe gestionar al nivel de las tareas.La suspension implica la
descarga del espacio de direcciones fuera de la memoria principal. Puesto que todos los hi­
los de una tarea comparten el mismo espacio de direcciones, todos deben entrar en el estado
Suspendido al mismo tiempo. De manera similar, la terminaci6n de una tarea supone termi­
nar con todos los hilos dentro de dicha tarea.
4
Ejemplo - Aldus PageMaker
Como ejemplo del uso de los hilos, considerese la aplicacion Aldus PageMaker, que se eje­
cuta para OS/2. PageMaker es una herramienta de composicion, disefio y produccion de pu­
blicaciones. La estructura de hilos, que se muestra en la figura 3.15 [KRON90], se escogio
para optimizar el grado de respuesta de la aplicacion. Siempre hay tres hilos activos: un hilo
de gestion de sucesos, un hilo para el dibujo de la pantalla y un hila de servicio.
En general, OS/2 responde peor en la gestion de las ventanas si hay algun mensaje de en­
trada que necesita mucho procesamiento. Los principios generales de OS/2 establecen que
ningun mensaje puede necesitar mas de 1/10 de segundo. Por ejemplo, Hamar a una subru­
tina para' imprimir una pagina mientras se esta procesando una orden de impresion podrfa
impedir que el sistema at~ndiera a rugun mensaje posterior para alguna aplicacion, 10 que ra­
lentiza el rendimiento. Para satisfacer este criterio, las operaciones largas del usuario con
~ PageMaker, como la impresion, la importacion de datos y el flujo de textos, se Bevan a cabo
mediante un hilo de servicio. La inicializacion del programa tambien se lleva a cabo con un
138 Descripdon y control de procesos

Hilode Queia1iza .
Sel'Vicio ~Il
ortaci '
~
!.ltof)
~presion

~. FIGURA 3.15 Estructura de hilos de Aldus Page Maker

hilo de servicio, que aprovecha el tiempo libre mientras que el usuario invoca un diaJogo
. para la creacion de un nuevo documento 0 para abrir un documento existente. Un hilo aparte
espera nuevos mensajes de sucesos.
La sincronizacion entre el hilo de servicio y el hilo de gestion de sucesos es complicada
porque el usuario puede seguir tecleando 0 moviendo el raton, 10 que activa el hilo de ges­
tion de sucesos, mientras que el hilo de servicios se mantiene ocupado. Si este conflicto se
produce, PageMaker filtra estos mensajes y acepta solo algunos basicos, como cambiar el
tamaiio de las ventanas.
El hilo de servicio envia un mensaje para indicar que ha terminado su tarea. Hasta que
esto ocurra, la actividad del usuario en PageMaker esui limitada. El programa indica esta
restriccion inhabilitando los elementos de los menus y visualizando un cursor de "ocupado".
El usuario es libre de cambiarse a otra aplicacion y, cuando el cursor "ocupado" se traslada
a otra ventana, se cambiara por el cursor adecuado para la aplicacion.
Se utiliza un hilo independiente para dibujar la pantalla por dos razones:
1. PageMaker no limita el numero de objetos que pueden aparecer en una pagina; por
tanto, procesar una peticion de dibujo puede exceder facilmente de la pauta de 1/10 sg.
2. Utilizar un hilo separado permite que el usuario abandone el dibujo. En este caso,
cuando el usuario cambia la escala de una pagina, esta puede dibujarse de inmediato.
EI programa es menos sensible si termina visualizando la pagina en la esc ala anterior
y despues la vuelve a dibujar por completo con la nueva escala.
EI desplazamiento dinamico (dynamic scrolling) -volver a dibujar la pantalla a medida
que el usuario mueve el indicador de desplazamiento-- tambien es posible. EI hilo de ges­
tion de suceSQs supervisa la barra de desplazamiento y vuelve a dibujar las reglas de los
margenes (que se vuelven a dibujar rapidamente, ofreciendole al usuario una sensacion de
respuesta inmediata). Mientras tanto, el hilo de dibujo de la pantalla trata constantemente de
volver a dibujar la pantalla y as! ponerse al corriente.
Implementar .el dibujo dinamico sin el uso de varios hilos impone una gran sobrecarga a la
aplicacion, al obligarla a sondear los mensajes en varios puntos. Los multiples hilos permiten
que se puedan separar las actividades concurrentes en el codigo de una manera mas natural.
.. Procesos e hilos 139

Otras estructuras
Como se ha dicho, los conceptos de unidad de asignacion de recursos y de unidad de expe­
dicion se han englobado tradicionalmente dentro del concepto unico de proceso, es decir,
como una relaci6n de uno a uno entre hilos y procesos. Recientemente, ha habido un gran
interes en disponer de varios hilos dentro de un mismo proceso, es decir, una reIaci6n de
muchos a uno. Sin embargo, como se muestra en la tabla 3.12, tambien se han investigado
las otras dos combinaciones, las llamadas relaciones de muchos a muchos y las relaciones
de uno a muchos.
if

Relaci6n de muchos a muchos


La idea de t~ner una relaci6n muchos a muchos entre los hilos y los procesos se ha explo­
·rado en el sistema operativo experimental TRIX [SIEB83, WARD80]. En TRIX, se tienen
los conceptos de dominio y de hilo. Un dominio es una entidad estatica que consta de un es­

~
pacio de direcciones y de unos "puertos" a traves de los cuales se envian y reciben los men­
sajes. Un hilo es un camino sencillo de ejecucion, con una pila de ejecuci6n, el estado del
procesador y la informacion de planificaci6n.
Al igual que Mach, se pueden ejecutar varios hilos en un solo dOniinio, 10 que aporta el
aumento de efieiencia discutido anteriormente. Sin embargo, tambien es posible que una ac- .
tividad de un solo usuario 0 aplicaci6n se pueda llevar a cabo en varios dominios. En tal
caso, existira un hilo que se puede mover de un dominio a otro.
El uso de un mismo hilo en varios dominios parece motivado, mas que nada, por el deseo
.. de brindar al programador una herramienta de estructuraci6n. Por ejemplo, considerese un
programa que utiliza un subprograma de E/S. En un entorno de multiprogramacion que per­
mita la generacion de procesos de usuario, el programa principal puede generar un nuevo
proceso que se encargue de la E/S y luego continue ejecutandose. Sin embargo, si el pro­
greso futuro del programa principal depende del resultado de la operaci6n de E/S, el pro­
grama principal tendra que esperar a que termine el programa de E/S. Hay varias formas de
implementar esta aplicacion:
I. El programa entero se puede implementar como un unieo proceso. Esta es una solu­
cion razonable y sencilla. Hay algunos inconvenientes relativos a la gestion de memo­
,. ria. El proceso global puede exigir un volumen considerable de memoria principal ~

para ejecutar eficientemente, mientras que el subprogram a de E/S requiere un espacio

TABLA 3.12 Relaci6n Entre Hilos v Procesos


Hilos: Procesos Descri pci6n Sistemas de Ejemplo
~---

1:1 Cada hila de ejecuci6n es un unico proceso UNIX System V


con sus propios recursos y espacio de direcciones.
M:l Un proceso define un espacio de direcciones OS/2, MVS, MACH
y recursos dinamicos propios. Pueden crearse
varios hilos que ejecuten en dicho proceso.
l:M Un hila puede emigrar del entorno de un proceso Ra
aotro. Esto permite que un hila se pueda mover
facilmente entre sistemas distintos.

" M:M Combina los atributos de los casos M:1 y 1 :M TRIX


140 Descripcion y control de procesos

de direcciones relalivamente pequeno para el buffer de E/S y para manejar la pequena


cantidad de codigo del programa. Puesto que el programa de E/S se ejecuta en el espa­
cio de direcciones del programa mayor, 0 bien el proceso entero debe permanecer en
memoria principal durante la operacion de E/S 0 bien la operacion de E/S esta sujeta al
intercambio. Este efecto en la gestion de memoria tambien se produce si el programa
principal y el subprograma de E/S se implementaran cOmo hilos del mismo espacio de
direcciones.
2. El programa principal y el subprograma de E/S pueden implementarse como dos pro­
cesos separados. Esto incurre en la sobrecarga de crear el proceso subordinado. Si las
actividades de E/S son frecuentes, se puede dejar vivo al proceso subordinado, 10 que
consume recursos de gestion 0 bien crear y destruir frecuentemente el subprograma, 10
que es ineficiente.
3. Tratar al programa principal y al subprograma de E/S como una actividad unica que se

~ debe implementar como un u.nico hilo. Sin embargo, puede crearse un espacio de di­
recciones (dominio) para el programa principal y otro para el subprogram a de E/S. Asi
pues, el hilo puede moverse entre los dos espacios de direcciones a medida que avanza
la ejecucion. El sistema operativo puede administrar los dosespacios de direcciones
independientemente,. sin incurrir en sobrecarga alguna de creacion de procesos. Mas
aun, el espacio de direcciones usado por el subprograma de E/S puede estar compar­
tido tambien por otros subprogramas sencillos de E/S.
La experiencia de los desarrolladores de TRIX observa el merito de la tercera opcion y
demuestra que esta puede ser la solucion mas eficaz para algunas aplicaciones.

Relaci6n de uno a muchos


En el campo de los sistemas operativos distribuidos (disenados para controlar sistemas in­
formaticos distribuidos), ha habido un gran interes en el concepto de hilo, principalmente
como una entidad que se puede mover entre los espacios de direcciones. 9 Un ejemplo nota­
ble de esta investigaci6n es el sistema operativo Clouds [DASG88] y, especialmente, su nu­
cleo, conocido como Ra [BERN89]. Otro ejemplo es el sistema Emerald [JUL88].
Un hila en Clouds es una unidad de actividad desde la perspectiva del usuario. Un pro­
ceso es un espacio de direcciones virtuales con un bloque de control de proceso asociado. AI
crearse, un hilo comienza a ejecutar en un proceso invocando un punto de entrada a un pro.l
grama de dicho proceso. Los hilos se pueden mover de un espacio de direcciones a otro,
atravesando de hecholas fronteras de una maquina (es decir, se mueven de un computador a
otra). Al trasladarse, un hilo debe llevar consigo cierta informacion, tal como el terminal de
control, unos parametros globales y las guias de planificacion (por ejemplo, la prioridad).
El enfoque de Clouds ofrece una forma efectiva de aislar al usuario y al programador de
los detalles del entomo distribuido. Una actividad del usuario puede estar representada por
un solo hila y el movimiento de dicho hilo entre las maquinas puede estar dictado por el sis­
tema operativo, debido a razones propias del sistema, tales como la necesidad de acceder a
un recurso remoto 0 equilibrar la carga.

9El traslado de los procesos 0 hilos entre espacios de direcciones de maquinas diferentes se ha convertido en un lema candente
en los ultimos afios (vease, por ejemplo, [ARTS89a,b]). Este tema se exploranl en d capitulo 13.
.. Ejemplos de descripcion y control de procesos 141

3.5
EJEMPlOS DE DESCRIPCION YCONTROL DE PROCESOS
Sistema UNIX, version V

UNIX utiliza un serviciode procesos simple pero potente, que es muy visible para el usua­

rio. Todos los procesos del sistema, excepto dos procesos basicos, son creados por ordenes

de programas del usuario .


Estados de un proceso
Un total de nueve estados de proceso son los reconocidos por el sistema operativo UNIX;
.estos estan reflejados en la tabla 3.13 y un diagrama de transici6n de estados se muestra en
la ~ura 3.16. Esta figura es bastante similar a la figura 3.7, con los dos estados de Dormido
de ~IX correspondientes a los dos estados de Bloqueado. Las diferencias pueden resu­
mirse rapidamente a continuacion:
• UNIX emplea dos estados de Ejecucion, que indican si el proceso esta ejecutando en
modo de usuario 0 en modo mic1eo.
• Se hace una distinci6n entre los estados: Listo para Ejecutar y en Memoria, frente
al estado de Expulsado. Estos dos estados son, basicamente, el mismo, como se in­
dica por la linea de puntos que los une. Se hace la distincion para enfatizar la
forma'en que se pasa al estado Expulsado. Cuando un proceso este ejecutandose
<1 en modo nucleo (como resultado de una Hamada del supervisor, una interrupci6n
de reloj, 0 una interrupcion de E/S), Hegara un momento en el que el mlcleo ter­
mine su trabajo y este listo para devolver el control al programa de usuario. En
este punto, el nuc1eo puede decidir expulsar el proceso en curso en favor de alguno
que este listo y tenga mayor prioridad. En tal caso, el proceso en curso se pasa al

TABLA 3.13 Estados de un Proceso en UNIX


Ejecucion en modo de usuario Ejecutando en modo usuario.
Ejecucion en modo del nucleo Ejecutando en modo del nucleo.

• Usto para ejecutar y en memoria Usto para ejecutar tan pronto como el nucleo 10 planifique.
Dormido y en memoria No dispuesto para ejecutar hasta que se produzca un suceso; el
proceso esta en memoria principal.
Usto para ejecutar y descargado EI proceso esta listo para ejecutar, pero se debe cargar el
proceso en memoria principal antes de que el nucleo pueda
planificarlo para su ejecucion.
Dormido y descargado EI proceso esta esperando un suceso y ha sido expulsado al
almacenamiento secundario.
Expulsado EI proceso retorna del modo nucleo al modo usuario pero
el nucleo 10 expulsa y realiza un cambio de contexto para
para planificar otro proceso.
Creado EI proceso esta recien creado y aun no esta aun listo para
ejecutar.

.. Zombie EI proceso ya no existe, pero deja un registro para que 10


recoja el proceso padre.
142 Descripci6n y control de procesos • •

Ejecuci6n en modo usuario

Ilamadaal

interruption, retornoal
retorno de interrupci6

expulsar

volver a planificar ...........

el proceso ..........

{~~~ para ejecutar


~
.
Dormido
despertar

descargar descargar fork

6
despertar

Dormido y Descargado Listo para ejecutar

y descargado

FIGURA 3.16 Diagrama de transici6n de estados de los procesos en UNIX [BACH86]

estado Expulsado. Sin embargo, a efectos de la expedicion, aquellos procesos que


estan en estado Expulsado y aquellos que estan en Listos para Ejecutar y en Me­
moria forman una sola cola.
La expUlsion puede producirse s610 cuando va a moverse un proceso del modo nucleo al
modo usuario. Mientras un proceso este ejecut:iudose en modo nucleo no puede ser expul­
sado. Esto hace que UNlX sea inadecuado para el procesamiento en tiempo reaL EI capitulo
9 discute los requisitos del procesamiento en tiempo real.
Hay dos procesos que son unicos en UNlX. El proceso 0 que se crea cuando el sistema
arranca; en realidad, es una estructura de datos predefinida que se carga en el momento del
arranque y que se denomina proceso de intercambio. Ademas, el proceso 0 genera el proceso
1, conocido como proceso init; todos los demas procesos del sistema tienen at proceso 1
como antepasado. Cuando se conecta un nuevo usuario interactivo en el sistema, es el pro­
ceso 1 el que crea un nuevo proceso para dicho usuario. Acontinuacion, el programa de usua­
rio puede crear procesos hijos en forma de arbol, de forma que una aplicacion en particular
puede qmstar de un conjunto de procesos relacionados.

Descripci6n de procesos
Un proceso en UNIX es un conjunto mas bien complejo de estructuras de datos que propor­
cionan al sistema operativo toda la informacion necesaria para administrarlos y expedirlos.
it
Ejemplos de descripcion y control de procesos 143

La tabla 3.14 resume los eiementos de la imagen de un proceso, los cliales se organizan en
tres partes: contexto del usuario, contexto de los registros y contexto del sistema.
EI contexto del usuario contiene los elementos Msicos de un programa de usuario y
puede ser generado directamente a partir un archivo de codigo compilado. EI programa del
usuario se separa en zonas de texto y datos; la zona de texto es solo de lectura y esta desti­
nada a albergar las instrucciones del programa. Mientras que el proceso esta ejecutando, el
procesador utiliza la zona de pila del usuario para las llamadas a procedimientos, los retor­
nos y el paso de parametros. La region de memoria compartida es una zona de datos que es

compartida con otros procesos. Hay una sola copia fisica de una region de memoria com­
partida, pero gracias a la memoria virtual, a cada proceso Ie parece que esta region compar­
tida esta en su propio espacio de direcciones.
; Cuando un proceso no esta ejecutandose, la informacion del estado del procesador se al­
I'

macena en la zona de contexto de los registros.


Por ultimo, el contexto del sistema contiene la informacion restante que el sistema ope­
rativo necesita para administrar el proceso. Esta form ada por una parte estatica, que tiene un
tamatio fijo y permanece asociada a un proceso durante toda su existencia y una parte dina­
mica q~ varia de tamafio durante la vida del proceso. Un elemento de la parte estatica es la
entrada de la tabla de procesos. Esta es, en realidad, una parte de la tabla de procesos que

TABLA 3.14 Imagen de un proceso en UNIX


.t
Contexto del Usuario
Texto del Proceso Instrucciones de maquina ejecutables del programa.

Datos del proceso Datos del proceso accesibles por el programa.

Pila del usuario Contiene los argumentos, las variables locales, y los punteros de las

funciones que ejecutan en modo usuario.


Memoria compartida Memoria com partida con otros procesos, utilizada para la comunicaci6n
i nterproceso.
Contexto de los Registros
Contador de programa Direcci6n de la pr6xima instrucci6n a ejecutar; puede estar
en el espacio de memoria del nucleo 0 del usuario, de este proceso.
Registro de estado Contiene el estado del hardware en el momenta de la expulsi6n;
• del procesador el formato y el contenido dependen del hardware.
Puntero de pila Senala a la cima de la pila del nucleo 0 de la pila del usuario,
dependiendo del modo de operaci6n en el momento de la expulsi6n.
Registros de prop6sito Dependientes del hardware.
general
Contexto del Sistema
Entrada de la tabla Define el estado de un proceso; esta informaci6n esta siempre
de procesos accesible para el sistema operativo.
Area U (de usuario) La informaci6n de control del proceso a la que se necesita acceder 5610
en el contexto del proceso.
Tabla de ~egiones Define una traducci6n de direcciones virtuales a ffsicas; tambien contiene
de preproceso . un campo de permiso que indica el tipo de acceso permitido para el
proceso: 5610 lectura, lectura/escritura 0 lectura/ejecuci6n.
Pila del nucleo Contiene los marcos de pila de los procedimientos del nucleo cuando
...
el proceso ejecuta en modo del nucleo.
144 Descripci6n y control de procesos

mantiene el sistema operativo, que dispone de una entrada por proceso. La entrada de la ta­
bla de procesos contiene la informaci6n de control accesible para el micleo en todo mo­
mento; de. ahf que en un sistema de memoria virtual todas las entradas de la tabla de proce­
sos se mantengan en memoria principal. La tabla 3.15 enumera los contenidos de una
entrada de la tabla deprocesos. La zona de usuario 0 zona U, contiene informaci6n de con­
trol adicional del proceso que es necesaria para el nucleo s610 cuando esta ejecutando en el
contexto del proceso. La tabla 3.16 muestra el contenido de esta tabla.
La distinci6n entre la entrada de la tabla de procesos y la zona U refleja el hecho de que el
nucleo de UNIX siempre ejecuta en el contexto de algful proceso. Durante una gran parte del
tiempo, el nucleo tendra que estar tratando con todo 10 relativo al proceso. Sin embargo, du­
rante algun tiempo, como cuando el nucleo esta ejecutando un algoritmo de planificaci6n
para preparar la expedicion de otro proceso, el nucleo necesitara acceder a la informacion de
otros procesos.
La tercera parte estatica del contexto del sistema es la tabla de regiones de los procesos,
que es utilizada por el sistema gestor de memoria. Por ultimo, la pila nucleo es la parte di­
narnica'lel contexto del sistema. Esta pila se utiliza cuando el proceso esta ejecutando en el
modo nu~o. Contiene la informacion que se debe salvar y restaurar cada vez que se produ­
cen interrupciones y llamadas a procedimientos.

Control de procesos
Como ya se menciono, el Sistema UNIX, versi6n V, sigue el modelo de la figura 3.13b, en
el que la mayor parte del sistema operativo ejecuta en el entomo de un proceso de usuario.

TABLA 3.15 Entradas de la Tabla de Procesos en UNIX


Estado Proceso Estado actual del proceso.
Punteros AI area U y a la zona de memoria del proceso (texto, datos, pila).
Tamano del proceso Permite que el sistema operativo sepa cuanto espacio asignar al proceso.
Identificadores EI ID real de usuario identifica al usuario que es responsable del proceso que
de usuario se esta ejecutando. EIID efectivo de usuario sirve para que un proceso dis­
ponga temporalmente de los privilegios asociados a un program a particular;
mientras se ejecuta el programa como parte del proceso, este opera con el
ID efectivo de usuario.
Identificadores ID del proceso; ID del proceso padre.
de proceso
Descriptor de suceso Valido cuando el proceso esta en un estado dormido cuando se produce el
suceso, el proceso pasa al estado de listo para ajecutar.
Prioridad Empleada en la planificaci6n del proceso.
Serial Enumera las senales enviadas a un proceso y que adn no se han tratado.
Temporizadores . Incluye el tiempo de ejecuci6n del proceso, el uso de los recursos
del ndcleo y un temporizador de usuario empleado para enviar senales
de alarma al proceso.
Enlace-P Puntero al siguiente enlace en la cola de listos (valido si el proceso esta listo
para ejecutarse).
Estado de la memoria Indica si la imagen del proceso esta en memoria principal ose ha descargado
al disco. Si esta en memorid, este campo tambien indica si el proceso se
M"<;r:lr",,r 0 si esta temporal mente bloqueado en memoria principal.
Ejemplos de descripci6n y control de procesos 145

TABLA 3.16 Area U de UNIX


Puntero a la Tabla de Procesos Indica la entrada que corresponde al area U.

Identificadores de usuario Los IDs de usuario reales yefectivos.

Temporizadores Registro del tiempo que el proceso (y sus descendil:'ntes) dedicaron

ejecutando en modo usuario y et') modo nucleo.


Vector de tratamiento de seiiales Para cada tipo de seiial definida en el sistema, indica c6mo
reaccionara el proceso al recibirla (terminar, ignorar, ejecutar una
funci6n especificada por el usuario).
Terminal de control Indica el terminal de conexi6n para el proceso (si procede).
Campo de error Registra los errores producidos durante una lIamada al sistema.
Valor de retorno Contiene el resultado de las lIamadas al sistema.
Parametros de E/S Describen la cantidad de datos a transferir, la direcci6n origen
(0 destino) del vector de datos del espacio de usuario y los
desplazamientos en los archivos para la'E/S.
Parametros de archivos EI directorio actual yel directorio raiz actual describen el entorno
del sistema de archivos para el proceso.
Tabla de descriptores Registra los archivos que el proceso tiene ilbiertos.
de los archivos del usuario
Campos de limit~ Restringe el tamaiio del proceso y el tamaiio de un archivo en que
este puede escribir. .
Campos de modos ~ protecci6n Mascara con los modes de protecci6n de los archivos creados por
el proceso.

Por tanto, hacen falta dos modos, el de usuario y el del m.1cleo. Algunas partes del sistema
operativo, en especial el proceso de intercambio (swapper), operan como procesos separa­
dos y se les conoce como procesos del nucleo.
La creacion de procesos en UNIX se hace por medio de la Hamada fork al m1cleo del sis­
tema. Cuando un proceso emite una peticion de fork, el sistema operativo realiza las si­
guientes operaciones [BACH86]:
1. Asigna una entrada en la tabla de procesos para el nuevo proceso.
2. Asigna un ID unieo de proceso al proceso hijo.
3. Hace una copia de la imagen del proceso padre, a excepci6n de la memoria compartida. '
4. Incrementa los contadores de los archivos que son propiedad del padre, para reflejar el
hecho que hay un nuevo proceso ahora que tambien es propietario de esos archivos.
5. Pone al proceso hijo en el estado Listo para Ejecutar.
6. Devuelve al proceso padre el n6mero de ID del hijo y devuelve un valor cero al pro­
ceso hijo.
Todo este trabajo se acomete en el modo nucleo en el proceso padre. Cuando el nucleo
haya terminado con estas funciones, podni realizar alguna de las siguientes como parte de la
rutina Qistribuidora:
1. Permanecer enel proceso padre. El control vuelve al modo de usuario en el punto de
la Hamada fork del padre.
2. Transferirel control al proceso hijo. EI proceso hijo comienza ejecutando en el mismo
punto del c6digo que el padre, es decir, en el punto de retorno de la llamadafork.

IllLtOTECI\ (tNTRAL
~.N,A.j£,
III

146 Oescripdon y control de procesos

3. Transferir el control a.otro proceso. Tanto el padre como el hijo sedejan en el estado
Listo para Ejecutar.
Puede que sea diffcil hacer ver este metodo de creacion de procesos, porque tanto el padre
como el hijo estan ejecutando el mismo trozo de codigo. La diferencia es la siguiente:
Cuando se retorna del/ork, se pregunta por el parametro de retorno. Si el valor es cero, en­
tonces se esta en el proceso hijo y se puede ejecutar una bifurcacion hacia el programa de
usuario apropiado para continuar la ejecucion. Si el valor es diferente de cero, entonces se
esta en el proceso padre y puede continuar la linea principal de ejecucion.

WINDOWS NT
El diseno de los procesos de Windows NT esta dirigido por la necesidad de dar soporte a va­
rios entornos de sistemas operativos. Los procesos aportados por los distintos sistemas ope­
rativos son diferentes en varios aspectos, incluyendo los siguientes: .
• Como se les denomina a los procesos
• Si hay hilos disponibles dentro de los procesos
• C6mo se representan los procesos
• Como se protegen los recursos de los procesos
• Que mecanismos ~e emplean para la comunicaci6n y la sincronizacion entre procesos
• Como estan relacionados los procesos entre sf
Por consiguiente, la estructura nativa de los procesos y de los servicios que brinda el n6­
cleo de NT es relativamente simple y de prop6sito general, permitiendo a cada subsistema
emular la estructura y la funcionalidad particular de los procesos de un sistema operativo.
Las caracteristicas mas importantes de los procesos de NT son las siguientes:
• Los procesos de NT se implementan como objetos.
• Un proceso ejecutable puede tener uno 0 mas hilos.
• Los objetos proceso y los objetos hilo tienen capacidades predefinidas de sincronizacion.
• El nucleo de NT no conserva ninguna relacion entre los procesos que crea, incluyendo
las relaciones padre-hijo.
La figura 3.17 ilustra la forma en que un proceso se refiere a los recursos que control a *
o utiliza. La senal de acceso (access token), descrita en el capitulo 2, control a si el pro­
ceso puede cambiar sus propios atributos. En tal caso, el proceso no tendra un descriptor
abierto de su senal de acceso: Si el proceso intenta abrir un descriptor, el sistema de se­
guridad determinara si se Ie permite y, por tanto, si el proceso puede cambiar sus propios
atributos.
Tambien tienen que ver con el proceso una serie de bloques que definen el espacio de di­
recciones virtuales asignado. EI proceso no puede modificar directamente estas estructuras,
sino qu~ debe depender del administrador de memoria virtual, quien Ie proporciona al pro­
ceso un servicio de asignaci6n de memoria.
Finalmente, el proceso incorpora una tabla de objetos, con los descriptores de otros obje­
tos que conoce. Existe un descriptor para cada hilo del proceso. En la figura se muestra un
solo hilo. Ademas, el proceso tiene acceso a un objeto archivo y a un objeto seccion que de­
fine una seccion de llwn:t0ria compartida.
.. t
Ejemplos de descripci6n y control de procesos 147

Descripcion del espacio de direcciones virtuales

Proceso

it Objetos

Descriptor 1 • CHilo x
Descriptor 2 Archivo y
I I S "-
Descriptor 3 ~ eCClOn z

I : I
FIGURA 3.17 Un proceso de NT y sus recursos [CUST931

Objetos proceso y objetbs hilo


La estructura orientada a objetos de NT facilita el desarrollo de un servicio de procesos de
• prop6sito generaL NT hace uso de dos tipos de objetos relacionados con los procesos: los
procesos y los hilos. Un proceso es una entidad correspondiente a un trabajo de usuario 0
una aplicaci6n, que dispone de sus propios recursos, tales como memoria y archivos abier­
tos. Un hilo es una unidad de trabajo que se puede expedir para su ejecuci6n secuencial y
que es interrumpible, de forma que el procesador pueda pasar de un hilo a otro.
Cada proceso de NT esta representado por un objeto, cuya estructura general se muestra
en la figura 3.18a. Cada proceso queda definido por una serie de atributos y encapsula una
serie de acciones 0 servicios que puede desempefiar. Un proceso realizara un servicio cada
vez que reciba un mensajeapropiado; la unica manera de invocar a dichos servicios es por
. medio de mensajes al objeto proceso que ofrece el servicio.
Cada vez que NT crea un proceso nuevo, utiliza la clase de objeto 0 tipo de objeto defi­
nido para los procesos de NT como plantilla para generar nuevos casos 0 instancias de obje­
tos. En el momenta de la creaci6n, se asignan un os valores a los atributos. La tabla 3.17 da
una definici6n breve de cada uno de los atributos de un objeto proceso.
Un proceso de NT debe tener, al menos, un hilo para ejecutar. Dicho hila puede crear en­
tonces otros hilos: En un sistema multiprocesador, pueden ejecutarse en paralelo varios hi­
los de un mismo proceso.
La figura 3.l8b representa la estructura de objeto para un objeto hilo y la tabla 3.18 define
los atributos de un objeto hilo: n6tese que alguno de los atributos de un hilo se parecen a los
deun proceso. En tales casas, el valor del atributo del hilo se obtiene a partir del valor del
atributo del proceso. Por ejemplo, la afinidad que tiene el hila con los procesadores es el con­
junto de procesadores de un sistema multiprocesador que pueden ejecutar al hilo; este con­
• junto es igual 0 es un subconjunto de la afinidad que tiene el proceso con los procesadores.
"

....
...

==
o
,Tipo de Objeto Proceso Tipo de Objeto / Hilo
ill del cliente
..01

t'\
-6'
ID del proceso t'\
Sefial de acceso S~
Contexto del hilo ::I
Prioridad de base Prioridad dina mica '<
Afinidad por omision del t'\
Prioridad de base C
procesador ::I
Afinidad del hilo con el
Atributos del Cuerpo
Umites de cuota
Tiempo de ejecucion Atributos del Cuerpo procesador i
Q.
/I)
delObjeto Contadores de E/S delObjeto Tiempo de ejecucion del hilo
."
Contadores de operaciones de MV Estado de alerta ~

,
t'\
Puertos de excepciones y de Contador de suspensi6n /I)

depuracion Sefial de imitacion .~


Estado de Terminaci6n Puerto de terminacion
Crear proceso Estado de terminaci6n del hilo
Abrir proceso Crear hilo
ConsuJtar Informaci6n del Abrirhilo
proceso Consultar informacion del hilo
Cambiar informacion del proceso Cambiar informaci6n del hilo
Proceso actual Hilo actual
Servicios Terminar proceso Servicios
Terminar hilo
Asignar /liberar memoria virtual
Obtener contexto
Leer / Escribir memoria virtual
Proteger memoria virtual Poner contexto
Bloquear I desbloquear memoria Suspender
virtual Reanudar
Consultar memoria virtual Alerta hilo
~aciar memoria virtual ./ Consultar alerta del hilo
Registrar puerto de
"-terminaci6n ./
(a) Objeto Proceso

(b) Objeto hilo


FIGURA 3.18 Objeto proceso y objeto hilo en Windows NT

...

" Ejemplos de descripci6n y control de procesos 149

TABLA 3.17 Atributos de un Obieto Proceso en Windows NT


I D de proceso Un valor unico que identifica al proceso ante el sistema operativo,

Senal de acceso Un objeto del ejecutor que contiene informacion de seguridad sobre el usuario

conectado al sistema y representado por el proceso,


Priori dad de base Prioridad de partida para los hilos del proceso,
Afinidad por omisi6n Conjunto de procesadores por omisi6n en los cuales se puede ejecutarse
los hilos del proceso.
Limites de cuota La cantidad maxima de memoria paginada y no paginada del sistema,
... el espacio para los archivos de paginaci6n y el tiempo de procesador que
un proceso de usuario puede emplear.
Tiempo de ejecuci6n La cantidad total de tiempo que todos los hilos del proceso han consumido en
ejecuci6n
Contadores de E/S Variables que registran el numero y el tipo de las operaciones de E/s que han
lIevado a cabo los hilos del proceso.
Contadores de Variables que registran el numero y el tipo de las operaciones de memoria
operaciones de MV virtual que los hilos del proceso han realizado.
Puertos de Canales de comunicaciQn entre procesos a los que el administrador de procesos
excepci6n/depuracion envfa mensajes cuanoo uno de los hilos del proceso provoca una excepci6n.
Estado de terminacion La razon de la terminacio~ de un proceso.

Notese que uno de los atributos del objeto hilo es el contexto. Esta infonnacion pennite
que los hilos puedan ser suspendidos y reanudados. Ademas, se puede alterar el comporta­
miento de un hilo modificando su contexto cuando este suspendido.
6
HUos multiples
NT da soporte para la concurrencia entre procesos, pues los hilos de procesos diferentes pue­
den ejecutarse concurrentemente. Es mas, pueden asignarse varios hilos del mismo proceso a
distintos procesadores y as! ejecutarse concurrentemente. Un proceso con hilos multiples
puede lograr la concurrencia sin la sobrecarga del empleo de varios procesos. Los hilos de un
mismo proceso pueden intercambiar infonnacion a traves de la memoria compartida y tener
acceso a los recursos compartidos del proceso.
Un proceso orientado a objetos con hilos multiples es una fonna eficiente de construir
• aplicaciones servidoras. La figura 3.19 describe el concepto general. Un unico proceso ser­
vidor puede dar servicio a varios clientes. Cada demanda de un cliente provoca la creaci6n
de un nuevo hila en el servidor.

Soporte para subsistemas


Los servicios generales de procesos e hilos deben dar soporte a las estructuras de hilos y
procesos particulares de varios clientes del SO. Es responsabilidad de cada subsistema el
aprovechar las caracterfsticas de los procesos e hilos de NT para emular los servicios de pro­
cesos e hilos del sistema operativo correspondiente.
Obsel'Vando como es la creaci6n de un proceso, se puede esbozar una idea de c6mo se
proporciona soporte para hilos y procesos. La creacion de un proceso comienza con la peti­
cion de un proceso nuevo desde una aplicacion del SO. La peticion de crear un proceso se
emite desde una aplicacion hacia el subsistema protegido correspondiente. El subsistema, a
• su vez, emite una peticion de un nuevo proceso al ejecutor de NT. NT crea un objeto proceso
150 Descripci6n y control de procesos

TABLA 3.18 Atributos de un Objeto Hilo en Windows NT


ID del cliente Valor unico que identifica a un hilo cuando llama al servidor.
Contexto hila EI conjunto de valores de registros y otros datos volatiles que definen el estado
de ej~cuci6n de un hilo.
Priori dad dinamica La -prioridad de ejecuci6n del hilo en un momento dado.
Priori dad de base EI limite inferior de la prioridad dinamica del hilo.
Afinidad del hila EI conjunto de procesadores en los que puede ejecutar el hilo, que es
con el procesador un subconjunto 0 coincide con la afinidad con el procesador del proceso que
contiene el hilo.
Tiempo de ejecuci6n EI tiempo acumulado que el hila ha ejecutado en modo usuario y en modo
del hila nucleo.
Estado de alerta Un indicador que dice si el hilo debe ejecutar una lIamada a un procedimiento
asfncrono.
Contador EI numero de veces que la ejecuci6n del hilo se ha suspendido sin reanudarse
de suspensi6n.
Senal de imitaci6n Una senal de acceso temporal que permite a.un hilo realizar operaciones en
nombre de otro proceso (utilizado por los subsistemas).
Puerto de terminaci6n Un canal de comunicaci6n entre procesos al que el administrador de procesos
envfa \.In mensaje cuando el hilo term ina (utilizado por los subsistemas).
Estado de terminaci6n La raz6n de terminaci6n del hilo.

y Ie devuelve un descriptor de dicho objeto al subsistema. Ahora, cuando NT crea un pro­


ceso, no crea automiticamente un hilo. En los casos de Win32 y OS/2, siempre se crea un
hilo junto con el nuevo proceso. Por tanto, para estos sistemas operativos, el subsistema Ha­
mara de nuevo al administrador de procesos de NT para crear un hilo para el nuevo proceso,
recibiendo de NT el descriptor del hiIo. La informaci6n correspondiente sobre el hilo y el

Proceso Cliente --
Proceso Servidor

Hilos del
Servidor

S S S

Proceso Cliente S
s
Modo de Usuario
Modo servidor

Servido de paso
de mensajes

FIGURA 3.19 Servidorde hilos multiples en Windows NT [CUST93]


1#1
Ejemplos de descripd6n y control de procesos 151

proceso es devuelta a la aplicacion. Windows de 16 bits y POSIX no tienen soporte de hUos.


Por tanto, para estos sistemas operativos el subsistema obtiene de NT un hilo para el nuevo
proceso, de forma que se pueda activar el proceso, pero solo se devuelve a la aplicaci6n la
informacion del proceso. EI hecho de que el proceso de la aplicacion se implemente me­
diante un hila no es visible para la aplicacion.
Cuando se crea un proceso nuevo en Win32 0 en OS/2, este hereda muchos de sus atri­
butos del proceso creador. Sin embargo, en el entorno de NT, esta creacion del proceso se
.. fiace indirectamente. Un proceso cliente de aplicacion envia su peticion de crear un pro­
ceso al subsistema del SO; despues, un proceso del subsistema enviara a su vez una solici­
tud de creacion de proceso al ejecutor de NT. Puesto que '~l efecto deseado es que el nuevo
proceso herede las caracterfsticas del proceso cliente yrto las del proceso servidor, NT per­
mite que el subsistema especifique el padre del nuevo··proceso. El nuevo proceso hereda
entonces la senal de acceso del padre, los limites de cuota, la prioridad de base y la afinidad
por omision con los procesadores.

MVS

Tareas de MVS
El sistema operativo MVS emplea un entorno de procesos muy estructurado. En MVS, la me­
moria virtual se divide en grandes regiones llamadas espacios de direcciones. A grandes rasgos,
a cada aplicaci6n Ie corresponde un s610 espacio de direcciones. Dentro del espacio de direc­
ciones, se pueden generar varias tareas. La tarea de MVS constituye la unidad de expedicion .
• Normalmente, existen ala vez mas de un centenar de espacios de direcciones, cada uno
de los cuales puede tener muchas tareas. De este modo, el MVS puede manejar y, a menudo,
maneja miles de tareas concurrentemente.
La figura 3.20, basada en otra de Leban y Arnold [LEBA84a], ofrece un ejemplo de la
forma en la que se generan varias tareas en un mismo espacio de direcciones. La aplicaci6n
da soporte para trans.acciones de consulta desde una serie de terminales. El programa esta
dividido en cuatro m6dulos, un programa principal y tres programas para las tres clases de
consulta: de clientes, de pedidos y de productos. Cuando se carga la aplicaci6n en el sis­

.. tema, el espacio de direcciones comienza con una parte de la memoria reservada para MVS •
y con el programa principal cargado (figura 3.20a). Despues, un usuario introduce una con­
sulta de clientes desde un terminal. Como resultado, el programa principal realiza una soli­
citud de creacion de una nueva tarea para ejecutar el modulo cliente y este se carga en el es­
pacio de direcciones (figura 3.20b). Mientras esta transacci6n esta en curso, un segundo
terminal realiza un pedido y se carga el modulo correspondiente como una tarea separada
(figura 3.20c). A continuaci6n, mientras ambas transacciones siguen en curso, un tercer ter­
minal realiza otro pedido. EI c6digo del modulo solicitado ya esta enel espacio de direc­
ciones y puede ser utilizado por mas de una tarea. Sin embargo, cada tarea necesita su pro­
pia region privada de memoria para las variables locales y el tratamiento de la pila, como
se ilustra en la figura 3.20d.
Explicitamente, el MVS hace uso de solo tres estados para una tarea: Listo, Activo (en
ejecucion) y Esperando. Sin embargo, se puede descargar a memoria secundaria un espacio
de direcciones entero. Por tanto, segun se ha venido usando el termino, todas las tareas de
11
dicho espacio de direceiones van a quedar suspendidas.
152 Descripcion y control de procesos

r MVS MVS
I

I
i ~ ~

L Cliente
Pedido

Client~
~
~i
Principal

MVS

(a) (b)
P::ru ll--I Principal

MVS
_-----.J

(c)
I Principal

MVS

(d)

FIGURA 3.20 Esquema del espacio de direcci6n para una aplicaci6n MVS

Cada tarea esta representada por un bloque de control de tarea (TCB, Task Control Block).
Ademas, existe otro tipo de entidad que se puede expedir, la peticion de servicio. La peticion
de servicio es una "tarea del sistema", de la que existen dos clases. Algunas tareas del sis­
tema ofreceri servicios a una aplicacion especifica y se ejecutan en el espacio de direcciones
de dicha aplicacion; otras estan involucradas en las operaciones realizadas entre espacios de
direcciones y no ejecutan en ningun espacio de direcciones de usuario, sino en el espacio de
direcciones reservado para el sistema. Estas tareas pueden considerarse en conjunto como e]
nucleo del sistema operativo MVS. Cada tarea del sistema tiene su propio bloque de peti­
cion de servicio (SRB, Service Request Block) y, cuando llega el momenta de expedir una
nueva tarea, el distribuidor escoge de entre todos los SRBs y TCBs que esten listos.
De esta forma, en MVS se pueden hallar, a su manera, dos conceptos aparentemente tan
modemos como son el de hilos dentro de un proceso y el de contemplar al sistema operativo
como un conjunto de procesos (figura 3.13c).

Estructuras de control de tareas


La tabla 3.19 enumera las estructuras principales de control que utiliza el MVS para admi­
nistrar las tareas de usuario y las tareas del sistema. En conjunto, estas estructuras agrupan
gran parte de 10 que se ha venido en llamar bloque de control de proceso. Los bloques glo­
bales de peticion de servicio se usan para administrar las tare as del sistema que no ejecutan
en un espacio de direcciones de usuario. Las estructuras restantes tienen que ver con la ges­
tion del espacio de direcciones. El bloque de control de espacio de direcciones (ASCB, Ad­
dress Space Control Block) y e1 bloque ampliado de espacio de direcciones (ASXB, Address
Space eXtension Block) contienen informacion sobre los espacios de direcciones. La distin­
cion es que MVS necesita la informacion del ASCB cuando esm ejecutando en el espacio de
direcciones reservado dt'(l sistema, mientras que el ASXB contiene informacion adicional
necesaria solo cuando MVS esta tratando con un espacio de direcciones especifico de un
usuario. Por ultimo, los SRBs y TCBs locales contienen informacion sobre las entidades que
se pueden expedir en uri espacio de direcciones.
• Ejemplos de descripcion y control de procesos 153

La figura 3.21 muestra como se organizan estas estructuras y propone Ia disciplina de expe­
dici6n aplicada en MVS. Los SRBs globales se mantienen en una cola de prioridades descen­
dentes, en la zona de colas del sistema, que es una regi6n de la memoria principal que no puede
descargarse al disco. De este modo, los SRBs globales siempre estan disponibles en la memo­
ria principal. Cuando un procesador esta disponible, MVS mira primero en esta cola en busca
de algun SRB que este Listo. Si no encuentra ninguno, entonces busca un espacio de direccio­
nes que tenga al menos un TCB 0 un SRB Listo. Con tal prop6sito se mantiene una cola de

.. ASCB en la zona de colas del sistema. A cada espacio de direcciones se Ie asigna un nivel de
prioridad global y, por tanto, los ASCBs se pueden ordenar por prioridades descendentes .

TABLA 3.19 Estructuras de Control de Procesos en MVS


Bloque Global de Petici6n f(L!Presenta a una tarea del sistema que es independiente de cual­
de Servicio (SRB) quier espacio pe direcciones del usuario. Incluye:
• Direcci6n del ASCB al que atendera la rutina
• Punto de entrada a la rutina
• Direccion de la lista de parametros que pasar ala rutina
• Nivel de prioridad
Bloque de Control de Espacio Contiene informacion del sistema sobre un espacio de direcciones,
de direcciones (ASCB) es decir, la informacion que necesita MVS del espacio de
direcciones cuando no esta ejecutando en ningun espacio de

direcciones particular. La informacion incluye:

• Punteros a las colas de creacion de ASCBs


• • Si el espacio de direccion ha side descargado a disco.
• Prioridad de expedicion
• Memoria real y virtual asignada al espacio de direcciones
• Numero de TCBs listos en este espacio de direcciones
• Puntero al ASXB
Bloque Ampliado de Espacio Contiene informaci6n sobre un espacio de direcciones que no es
de direcciones (ASXB) de interes global. Incluye:
• Numero de TCBs en el espacio de direcciones
• Puntero a la cola de expedici6n de TCB para este espacio
• de direcciones
• Puntero a la cola de SRB locales para el espacio de direcciones
• Puntero a la zona de salvaguarda del gestor de interrupciones
Bloque Local de direcciones (SRB) Representa a una tarea del sistema que se ejecuta en un espacio
de direcciones del usuario, Incluye:
• Direcci6n del ASCB al que atendera la rutina
• Punto de entrada a la rutina
• Direcci6n de la lista de parametros que pasara a la rutina
• Nivel de prioridad
Bloque de Control de Tareas (TCB) Representa a un programa de usuario en ejecuci6n, Contiene la
informacion necesaria para administrar una tarea en un espacio
de direcciones, Incluye:
• Informacion del estado del procesador
'.
• Punteros a los forman parte de la tarea,
154 Descripcion y control de procesos

SRBs Globales i SRB ! -I SRB H4----


Espacios de Direcciones

Ubicados en la SQA
... , .. ........ ......

' ,

Ubicados en las LSQA

SRB
locales

TCB

Rcr DUMP STC INIT USUARIO

TCB Bloque de petici6n de servicio LSQA = Zona local de colas del sistema
. ASCB =Bloque de control de espacio de direcci6n RCT = Tarea de control de regiones
ASXB = Bloque ampJiado de espaci6 de direcd6n STC = Tarea de control iniciada
TCB Bloque de control de tarea INIT Iniciador
SQA Zona de colas del sistema
FIGURA 3.21 Colas de planificaci6n de MVS [PAAN861

Una vez que se selecciona un espacio de direcciones, MVS puede trabajar con las estruc­
turas de dicho espacio, conocidas como la zona local de colas del sistema. MVS expide al
SRB que tenga prioridad mayor y, si no hay ninguno, elige al TCB de prioridad mayor. En
este ejemplo se muestra la estructura de colas de los TCB para un lote de trabajos, que
consta de las siguientes tareas:

• Tarea de Control de Regiones (RCT, Region Control Task): Responsable de la adminis­


tracion del espacio de direcciones en nombre de todas las tareas que ejecutan en eI.
• Volcado (dump): Responsable de volcar a disco el espacio de direcciones si este termina
de una forma anormal.
• Tarea de Control Inidada (STC, Started Control Task): EI TCB del programa que da
inicio al espacio de direcciones.
• Iniciador: Responsable de cargar el flujo de trabajos por Iotes.
• Tarea de usuario: La aplicacion puede estar formada por una 0 mas tareas de usuario.

La ventaja de dividir la informacion de control en global y local es que, si es necesario, se


puede descargar al disco tanta informacion de un espacio de direcciones como sea posible,
reservando asi la memoria principal.
. lecturas recomendadas 155

3.6
RESUMEN
La piedra angular de los s,stemas operativos modemos es el pr~a funci6n principal
del sistema operativo escrear, administrar y terminar los proc~sos. Mientras que haya pro­
cesos activos, el sistema operativo debe velar por que se Ie asigne a cada uno un tiempo de
ejecuci6n en el procesador, por coordinar sus actividades, gestionar los conflictos en las so­
. licitudes y asignar recursos del sistema a los procesos .
Para llevar a cabo las funciones de gesti6n de procesos, el sistema operativo debe dispo­
ner de una descripci6n de cada proceso. Cada proceso esta representado por una imagen de
proceso, que incluye el espacio de direcciones en el que ejecuta el proceso y un bloque de
. control del proceso. Este ultimo contiene toda la informaci6n necesaria para que el sistema
operativo administre el proceso, incluyendo su estado actual, los recursos que Ie han sido
asignados, la priori dad y otros datos relevantes.
Durante su existencia, un proceso transita por varios estados. Los mas importantes son:
Listo, ~nJ~j~£Il~i6!1Y Bloquead().Un proceso Listo es aquel que no esta ejecutandose en un
ITrtrmento dado, pero que esta preparado para ejecutar tan pronto como el sistema operativo
10 dec ida. Un proceso en Ejecuci6n es aquel que esta ejecutfu:J.dose en el procesador. En un
sistema multiprocesador puede haber mas de un proceso en este estado. Un proceso blo­
queado es el que esta esperando a que termine algun suceso (como una operaci6n de E/S).
Un proceso en Ejecuci6n puede verse cortado por una interrupci6n, que es un suceso que
se produce fuera del proceso y que es reconocido por el procesador 0 bien puede ser inte­
• rrumpido por una Hamada del supervisor al sistema operativo. En ambos casos, el procesa­
dor lleva a cabo un cambio de contexto y pasa el control a una rutina del sistema operativo:
Despues de que esta haya terminado su trabajo, el sistema operativo podra reanudar al pro­
ceso interrumpido ocambiar a otro proceso.
Algunos sistemas operativos hacen una distinci6n entre los conceptos de proceso e hilo. El pri­
mero se refiere a la propiedad de los recursos y el segundo se refiere a la ejecuci6n de programas.
Este enfoque puede llevar a una mejora de la eficiencia y hacer mas c6moda la programaci6n.

,.. 3.7
LECTURAS RECOMENDADAS
Todos los libros de texto enumerados en la secci6n 2.6 cubren los temas de este capitUlo: Algunas
referencias buenas sobre UNIX, Windows NT y MVS son [BACH86], [POWE93) y [KATZ84], res­
pectivamente. lNEHM75] es un estudio interesante sobre los estados de un proceso y sobre las pri­
mitivas de un sistema operativo necesarias para la expedici6n de los procesos.
BACH86 BACH, M. The Design of the UNIX Operating System. Prentice Hall, Englewood Cliffs,
NJ,1986.
KATZ84 KATZAN, H. y THnRAYIL, D. Invitation to MVS; Logic and Debugging. Petrocelli,
Nueva York, 1984.
NEHM75 NEHMER, 1. -"Dispatcher Primitives for the Construction of Operating System Kernels".
Acta Informatica,voL 5, 1975
.'to
POWE93 POWELL, LMultitask Windows NT. Waite Group Press, Corte Madera, CA, 1993.

También podría gustarte