Stallings W. Sist Op
Stallings W. Sist Op
Stallings W. Sist Op
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 •
-
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
Final
Programador •
Programas de
Aplicad6n
Utilidades
Sistema Operativ~
Hardware de 1a computadora
>
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
• 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
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.
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.
,.......
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
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.
Programa a Compilar ~
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
Prograrna A ~
·s Jecu-
Esperar
(a) Monoprograrnaci6n
~
Ejecu-
tar Esperar
Esperar Esperar
Esperar Esperar
Tiernpo •
Esperar Esperar
Esperar Esperar
Tiernpo ..
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
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 "
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
Proceso
PC ~_---!..=::t---,
Base
Lista de Limite
Procesos
~:;t""j,--___-,
Proceso
A
Proceso Datos
h
B
Programa
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
• 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
DO
Leer, Escribir COfliar o
Memoria
Almacen a largo plazo
Virtual
----------------------~----------:
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.
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.
• Multics
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
cas mas simples, pero un concepto importante en el disefio de sistemas operativos, es el sema
• 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
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
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
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.
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
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
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........................................................................................
Comunicaci6n
entre Procesos
Subsistemas de Archivos
Subsistemas
de Control de Planificador
Procesos
Gesti6n de
Memoria
Nucleo
·Ni~~l·d~i·H~;~-:~~~ ..·..···········..·····.. ···..··········....................................................................................................
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
.
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
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
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
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
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
algunos aspectos relativos a laE/S con el disco, inc1uyendo la planificacion de discos yel
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.
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
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
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
50K~=~~~
f.
Proceso B
140K ----~
1-1
Proceso C
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.
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
3 0:+2 29 8+0
4 0:+3 30 8+1
5 0:+4 31 8+2
6 0:+5 32 8+3
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
15 13+2 41 8+0
16 13+3 42 8+1
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
27 ')'+4
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
Cola
Entrar
----r
Interrumpir
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.
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
.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
Pasar a Ejecucion
"\ II
Listo
Bloqueado
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.
"
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).
Admitir
Ocurre
suceso Cola de Bloqueados
(a) Una sola cola de bloqueados
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
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
,,
,Admitir
'I.,
\ Suspender
--- - -. ......~ - - -- - - - - .... - ...............
Expedir
Ocurre
suceso suceso
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:
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.
".
... .. ~ . ~
,
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.
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'
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?
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
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.
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.
, 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.
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
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
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)
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.
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
(CHM, Change Made) del VAX. Cuando el usuario hace una Hamada a un servicio del
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?
..
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.
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.
Nlic1eo
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
Espacio privado
; de direcciones del
usuario
'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.
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
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
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
, 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
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
~
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 ~
~ 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.
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
•
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
• 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.
Ilamadaal
interruption, retornoal
retorno de interrupci6
expulsar
el proceso ..........
6
despertar
y descargado
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'
Pila del usuario Contiene los argumentos, las variables locales, y los punteros de las
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.
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
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
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
....
...
==
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)
...
Senal de acceso Un objeto del ejecutor que contiene informacion de seguridad sobre el usuario
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.
Proceso Cliente --
Proceso Servidor
Hilos del
Servidor
S S S
•
Proceso Cliente S
s
Modo de Usuario
Modo servidor
Servido de paso
de mensajes
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).
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 .
Ubicados en la SQA
... , .. ........ ......
' ,
SRB
locales
TCB
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:
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.