Libro Sistemas Operativos Una Visión Aplicada 2 Edición

1
CONCEPTOS ARQUITECTNICOS
DEL COMPUTADOR
En este captulo se presentan los conceptos de arquitectura de computadores ms relevantes desde el punto
de vista de los sistemas oprativos. El captulo no pretende convertirse en un tratado de arquitectura, puesto
que su objetivo es el de recordar y destacar los aspectos arquitectnicos que afectan de form a directa al sis
tema operativo.
Para alcanzar este objetivo el captulo se estructura en los siguientes grandes temas:
Funcionamiento bsico de los computadores y estructura de los mismos.
Modelo de programacin con nfasis en su secuencia de ejecucin.
Concepto de interrupcin y sus tipos.
Diversas acepciones de reloj.
Aspectos ms relevantes de la jerarqua de memoria y, en especial, de la memoria virtual.
Concurrencia de la E/S con el procesador.
Mecanismos de proteccin.
Multiprocesador y multicomputador.
Prestaciones del sistema.
Sistemas operativos. Una visin aplicada
1.1.
ESTRUCTURA Y FUNCIONAMIENTO DEL COMPUTADOR
El computador es una mquina destinada a procesar datos. En una visin esquemtica, como la que muestra
la figura 1.1, este procesamiento involucra dos flujos de informacin: el de datos y el de instrucciones. Se
parte del flujo de datos que han de ser procesados. Este flujo de datos es tratado mediante un flujo de instruc
ciones mquina, generado por la ejecucin de un programa, produciendo el flujo de datos resultado.
Para llevar a cabo la funcin de procesamiento, un computador con arquitectura von Neumann est
compuesto por los cuatro componentes bsicos representados en la figura 1.2 .
La memoria principal se construye con memoria RAM (.Random Access Memory) y memoria ROM
(Read Only Memory). En ella han de residir los datos a procesar, el programa mquina a ejecutar y los resul
tados (aclaracin 1.1). La memoria est formada por un conjunto de celdas idnticas. Mediante la informa
cin de direccin se selecciona de forma nica la celda sobre la que se quiere realizar el acceso, pudiendo ser
ste de lectura o de escritura. En los computadores actuales es muy frecuente que el direccionamiento se re
alice a nivel de byte, es decir, que las direcciones 0, 1, 2,... identifiquen los bytes 0 , 1, 2,... de memoria. Sin
embargo, el acceso se realiza generalmente sobre una palabra de varios bytes (tpicamente de 4 o de 8 bytes)
cuyo primer byte se sita en la direccin utilizada.
Aclaracin 1.1. Se denomina programa mquina (o cdigo) al conjunto de instrucciones mquina que tiene
por objeto que el computador realice una determinada funcin. Los programas escritos en cualquiera de los
lenguajes de programacin han de convertirse en programas mquina para poder ser ejecutados por el com
putador^
La unidad aritmtica permite realizar una serie de operaciones aritmticas y lgicas sobre uno o dos
operandos. Los datos sobre los que opera esta unidad estn almacenados en un conjunto de registros o bien
provienen directamente de la memoria principal. Por su lado, los resultados tambin se almacenan en regis
tros o en la memoria principal.
La unidad de control es la que se encarga de hacer funcionar al conjunto, para lo cual realiza cclicaComputador
Datos
Resultados
Jt :
Instrucciones
de mquina
Figura 1.1 Esquema de funcionamiento del computador.
Registros
generales
M E M O R IA
P R IN C IP A L
PE R IF R IC O S
Cdigo
,
U N ID A D
A R IT M T IC A
U N ID A D DE C O N T R O L
Estado
I Contador de programa"!
I Registro de instruccin I
1
Hunlero de pila
Figura 1.2 Componentes bsicos del computador con arquitectura von Neumann.
Conceptos arquitectnicos del computador
mente la siguiente secuencia:
Lee de memoria la siguiente instruccin mquina que forma el programa.

Interpreta la instruccin leda: aritmtica, lgica, de salto, etc.
Lee, si los hay, los datos de memoria referenciados por la instruccin.
Ejecuta la instruccin.
Almacena, si lo hay, el resultado de la instruccin.
La unidad de control tiene asociados una serie de registros, entre los que cabe destacar: el contador de
programa (PC, Program Counter), que indica la direccin de la siguiente instruccin mquina a ejecutar; el
puntero de pila (SP, Stack Pointer), que sirve para manejar cmodamente una pila en memoria principal; el
registro de instruccin (RI), que permite almacenar una vez leda de la memoria principal la instruc
cin mquina a ejecutar, y el registro de estado (RE), que almacena diversa informacin producida por la
ejecucin de alguna de las ltimas instrucciones del programa (bits de estado aritmticos) e informacin so
bre la forma en que ha de comportarse el computador (bits de interrupcin, modo de ejecucin, etc.).
. Finalmente, la unidad de entrada/salida (E/S) se encarga de hacer la transferencia de informacin en
tre la memoria principal (o los registros generales) y los perifricos. La entrada/salida se puede hacer bajo el
gobierno de la unidad de control (E/S programada) o de forma independiente (acceso directo a memoria o
DMA), como se ver en la seccin 1.6 Entrada/Salida.
Se denomina procesador o unidad central de proceso (UCP) al conjunto de la unidad aritmtica y de la
unidad de control. Actualmente, el procesador suele construirse en un nico circuito integrado, que tambin
incluye la unidad de gestin de memoria que se describe en la seccin 1.5.7 Concepto de memoria virtual.
Desde el punto de vista de los sistemas operativos, nos interesa ms profundizar en el funcionamiento
interno del computador que en los componentes fsicos que lo constituyen.
1.2.
MODELO DE PROGRAMACIN DEL COMPUTADOR
El modelo de programacin a bajo nivel de un computador define los recursos y caractersticas que ofrece
ste al programador de bajo nivel. Este modelo se caracteriza por los siguientes aspectos, que se muestran
grficamente en la figura 1.3.
Elementos de almacenamiento. Son los elementos de almacenamiento del computador que son vi
sibles a las instrucciones mquina. En esta categora estn incluidos los registros generales, el conta-
Registro de estado
\ Registros de datos
Modo Traza I
Sistema/Usuario f!
Mscara
de
Interrupciones
Registros de direocin
E xtensin
Mapa de
memoria
2 -ll
Puntero de pila de usuario

Puntero de pila de sistema
Contador de programa
Mapa de
E/S
Figura 1.3 Modelo de programacin de un computador.
15
14
13 l
12 \(
11 /
15 10
11
BJ 8
7 >
6
9J
5\
/ Usuario
X 4
Negativo fj 3
Cero
Desbordamiento
1
Acarreo c 0
Juego de instrucciones
dor de programa, el o los punteros de pila, el registro de estado, la memoria principal y los registros
de los controladores de E/S. La memoria principal se ubica en el mapa de memoria, mientras que los
registros de E/S se ubican en el mapa de E/S.
Juego de instrucciones, con sus correspondientes modos de direccionamiento. El juego de instruc
ciones mquina define las operaciones que es capaz de hacer el computador. Los modos de direccio
namiento determinan la forma en que se especifica la localizacin de los operandos, es decir, los
elementos de almacenamiento que intervienen en las instrucciones mquina.
Secuencia de funcionamiento. Define el orden en que se van ejecutando las instrucciones mquina.
Modos de ejecucin. Un aspecto crucial de los computadores, que est presente en todos ellos me
nos en los modelos ms simples, es que disponen de ms de un modo de ejecucin, concepto que se
analiza en la seccin siguiente y que es fundamental para el diseo de los sistemas operativos.
Aclaracin 1.2. Por mapa se entiende todo el conjunto de posibles direcciones y, por tanto, de posibles pala
bras de memoria o de posibles registros de E/S que se pueden incluir en el computador. Es muy frecuente que
los computadores incluyan el mapa de E/S dentro del mapa de memoria, en vez de incluir un mapa especfico
de E/S, reservando para ello un rango de direcciones del mapa de memoria (vase la seccin 1.6.3 Buses y
direccionamiento). En este caso, se utilizan las mismas instrucciones mquina para acceder a la memoria
principal y a los registros de E/S.
1.2.1. Modos de ejecucin

La mayora de los computadores de propsito general actuales presentan dos o ms modos de ejecucin. En
el modo menos permisivo, generalmente llamado modo usuario, el computador ejecuta solamente un subconjunto de las instrucciones mquina, quedando prohibidas las dems, que se consideran privilegiadas.
Adems, el acceso a determinados registros, o a partes de esos registros, y a determinadas zonas del mapa de
memoria y de E/S tambin queda prohibido. En el modo ms permisivo, denominado modo ncleo o modo
privilegiado, el computador ejecuta todas sus instrucciones sin restriccin, y permite el acceso a todos los
registros y mapas de direcciones.
Se puede decir que el computador presenta ms de un modelo de programacin. Uno ms restrictivo,
que permite realizar un conjunto limitado de acciones, y otros ms permisivos, que permiten realizar un ma
yor conjunto de acciones. Uno o varios bits del registro de estado establecen el modo en el que est ejecutan
do. Modificando estos bits se cambia de modo de ejecucin.
Como veremos ms adelante, los modos de ejecucin se incluyen en los computadores para dar soporte
al sistema operativo. Los programas de usuario, por razones de seguridad, no podrn realizar determinadas
acciones, al ejecutar en modo usuario. Por su lado, el sistema operativo, que ejecuta en modo privilegiado,
podr ejecutar todo tipo de acciones. Cuando arranca el computador lo hace en modo privilegiado, puesto que
lo primero que se debe hacer es cargar el sistema operativo, que debe ejecutar en modo privilegiado. El sis
tema operativo se encargar de poner en ejecucin en modo usuario a los programas de los usuarios.
Generalmente, el modo usuario no permite operaciones de E/S, ni modificar una gran parte del registro
de estado, ni modificar los registros de soporte de gestin de memoria. La figura 1.4 muestra un ejemplo de
dos modelos de programacin de un computador. Tambin es frecuente que el procesador incluya dos punte
ros de pila (SP y SP'), el SP para usarlo en modo usuario y el SP' para usarlo en modo privilegiado.
1.2.2. Secuencia de funcionamiento del procesador

La unidad de control del procesador es la que establece el funcionamiento del mismo. Este funcionamiento
est basado en una secuencia sencilla, que se repite sin cesar y a muy alta velocidad (miles de millones de
veces por segundo). Como muestra la figura 1.5, esta secuencia consiste en tres pasos: a) lectura de memoria
principal de la instruccin mquina apuntada por el contador de programa, b) incremento del contador de
programa para que apunte a la siguiente instruccin mquina y c) ejecucin de la instruccin. Esta se
C onceptos arquitectnicos del c o m p u ta d o r
Figura 1.4 Modelos de programacin de usuario y de privilegiado.

cuencia tiene dos propiedades fundamentales: es lineal, es decir, ejecuta de forma consecutiva las instruccio
nes que estn en direcciones consecutivas, y forma un bucle infinito. Esto significa que la unidad de control
del procesador est continua e ininterrumpidamente realizando esta secuencia (advertencia 1. 1).
Advertencia 1.1. Algunos procesadores tienen una instruccin de parada (p. ej;: HALT) que hace que la uni
dad de control se detenga hasta que llegue una interrupcin. Sin embargo, esta instruccin es muy poco utili
zada (salvo en equipos porttiles en los que interesa ahorrar batera), por lo que, a efectos prcticos, podemos
considerar que la unidad de control no para nunca de realizar la secuencia de lectura de instruccin, incre
mento de PC y ejecucin de la instruccin.
Podemos decir, por tanto, que lo nico que sabe hacer el procesador es repetir a gran velocidad esta se
cuencia. Esto quiere decir que, para que realice algo til, se ha de tener adecuadamente cargado en memoria
un programa mquina con sus datos y se ha de conseguir que el contador de programa apunte a la instruccin
mquina inicial de dicho programa.
El esquema de ejecucin lineal es muy limitado, por lo que se aaden unos mecanismos que permiten
alterar esta ejecucin lineal. Todos ellos se basan en algo muy simple: modifican el contenido del contador de
programa, con lo que se consigue que se salte o bifurque a otra seccin del programa o a otro programa (que,
lgicamente, tambin ha de residir en memoria).
Los tres mecanismos bsicos de ruptura de secuencia son los siguientes:
Las instrucciones mquina de salto o bifurcacin, que permiten que el programa rompa su secuencia
lineal de ejecucin, pasando a otra seccin de s mismo.
Las interrupciones extemas o internas, que hacen que la unidad de control modifique el valor del
contador de programa, saltando a otro programa (que deber ser el sistema operativo).
Una instruccin mquina de llamada al sistema (p. ej.: TRAP, INT o SC), que produce un efecto
a) Lectura de la Instruccin apuntada por PC

b) Increm ento del PC
c) Ejecucin de la instruccin
Figura 1.5 Secuencia de ejecucin del procesador.
similar a la interrupcin, haciendo que se salte a otro programa (que deber ser el sistema operativo).
Si desde el punto de vista de la programacin el inters se centra en las instrucciones de salto, y, en es
pecial en las de salto a procedimiento y retomo de procedimiento, desde el punto de vista de los sistemas
operativos son mucho ms importantes las interrupciones y las instrucciones mquina de llamada al sistema.
Por tanto, centraremos nuestro inters en resaltar los aspectos fundamentales de estas dos ltimas.
1.2.3. Registros de control y estado

Como se ha indicado anteriormente, la unidad de control tiene asociada una serie de registros que denomi
namos de control y estado. Estos registros dependen de la arquitectura del procesador. Muchos de ellos se
refieren a aspectos que se analizarn a lo largo del texto, por lo que no se intentar explicar aqu su funcin.
Entre los ms importantes se pueden encontrar los siguientes:
Contador de programa PC. Contiene la direccin de la siguiente instruccin mquina.
Puntero de pila SP. Contiene la direccin de la cima de la pila. En algunos casos existen dos pilas:
una para el sistema y otra para el usuario.
Registro de instruccin RI. Contienen la instruccin en curso de ejecucin.
Registro de estado, que contiene entre otros los bits siguientes:
Bits de estado aritmticos como: Signo, Acarreo, Cero o Desbordamiento.

Bits de modo de ejecucin. Indican el modo en el que ejecuta el procesador.
Bits de control de interrupciones. Establecen las interrupciones que se pueden aceptar.
Registros de gestin de memoria, como pueden ser los registros de proteccin de memoria o el regis
tro identificador del espacio de direccionamiento (vase la seccin 1.7.2 Mecanismos de proteccin
de memoria).
Algunos de estos registros son visibles en el modo de ejecucin de usuario, como el PC, el SP y parte
del estado, pero otros no lo son, como los de gestin de memoria.
Al contenido de todos los registros del procesador en un instante determinado le denominamos estado
del procesador, trmino que utilizaremos profusamente a lo largo del libro. Un subconjunto del estado del
procesador lo constituye el estado visible del procesador, formado por el conjunto de los registros visibles en
modo usuario.
1.3.
INTERRUPCIONES
Una interrupcin se solicita activando una seal que llega a la unidad de control. El agente generador o soli
citante de la interrupcin ha de activar la mencionada seal cuando necesite que se le atienda, es decir, que se
ejecute un programa que le atienda.
Ante la solicitud de una interrupcin, siempre y cuando est habilitada ese tipo de interrupcin, la uni
dad de control realiza un ciclo de aceptacin de interrupcin. Este ciclo se lleva a cabo en cuanto termina la
ejecucin de la instruccin mquina que se est ejecutando, y los pasos que realiza la unidad de control son
los siguientes:
Salva algunos registros del procesador, como son el de estado y el contador de programa. Normal
mente utiliza para ello la pila de sistema, gestionada por el puntero de pila SP'.
Eleva el modo de ejecucin del procesador, pasndolo a ncleo.
Carga un nuevo valor en el contador de programa, por lo que se pasa a ejecutar otro programa,
que, generalmente, ser el sistema operativo.
En muchos procesadores inhibe las interrupciones (vase ms adelante Niveles de Interrupcin).
La figura 1.6 muestra la interrupcin vectorizada, solucin usualmente utilizada para determinar la di
reccin de salto. Se puede observar que el agente que interrumpe suministra el llamado vector de interrup
cin que determina la direccin de comienzo del programa que desea que le atienda (programa que se suele
denominar rutina de tratamiento de interrupcin). La unidad de control, utilizando un direccionamiento indi
recto, toma la mencionada direccin de una tabla de interrupciones IDT {Interrupt Descriptor Table) y la
carga en el contador de programa. El resultado de esta carga es que la siguiente instruccin mquina ejecuta
da es la primera del mencionado programa de tratamiento de interrupcin.
Observe que se han incluido como parte del sistema operativo tanto la tabla IDT como la rutina de tra
tamiento de la interrupcin. Esto debe ser as por seguridad, ya que la rutina de tratamiento de interrupcin
ejecuta en modo privilegiado. En caso contrario, un programa de usuario ejecutara sin limitacin ninguna,
por lo que podra acceder a los datos y programas de otros usuarios. Como se ver en el captulo 11 Seguri
dad y proteccin, la seguridad es una de las funciones primordiales del sistema operativo.
Se dice que la interrupcin es sncrona cuando es consecuencia directa de las instrucciones mquina
que se estn ejecutando. En el resto de ios casos se dice que es asincrona. Las interrupciones se pueden ge
nerar por diversas causas, que clasificaremos de la siguiente forma:
Excepciones hardware sncronas. Hay determinadas causas que hacen que un programa presente
una incidencia en sii ejecucin, por lo que se generar una interrupcin, para que el sistema operativo
entre a ejecutar y decida lo que debe hacerse. Dichas causas se pueden estructurar en las tres clases
siguientes:
Problemas de ejecucin:
Operacin invlida en la unidad aritmtica.
Divisin por cero.
Operando no normalizado.
Desbordamiento en el resultado, siendo demasiado grande o demasiado pequeo.
Resultado inexacto en la unidad aritmtica.
Dispositivo no existente (p. ej.: no existe coprocesador).
Regin de memoria invlida.
Desbordamiento de la pila.
Violacin de los lmites de memoria asignada.
Error de alineacin en acceso a memoria.
Cdigo de operacin mquina invlido.
Depuracin:
Punto de ruptura.
Fallo de pgina.
Todas ellas son producidas directa o indirectamente por el programa en ejecucin, por lo que deci
mos que se trata de interrupciones sncronas (advertencia 1.2 ).
Excepciones hardware asincronas. Se trata de interrupciones asincronas producidas por un error
en el hardware. En muchos textos se denominan simplemente excepciones hardware. Ejemplos son
los siguientes:
Error de paridad en bus.

Error de paridad en memoria.
Figura 1.6 Acceso a la rutina de tratamiento de la interrupcin.
Fallo de alimentacin.
Lmite de temperatura excedido.
En las excepciones hardware, tanto sncronas como asincronas, ser el mdulo del computador que
produce la excepcin el que genere el vector de interrupcin. Adems, dicho mdulo suele cargar en
un registro o en la pila un cdigo que especifica el tipo de problema encontrado.
Interrupciones externas. Se trata de interrupciones asincronas producidas por elementos externos
al procesador como son: a) el reloj, que se analizar en detalle en la seccin siguiente, b) los contro
ladores de los dispositivos de E/S, que necesitan interrumpir para indicar que han terminado una ope
racin o conjunto de ellas, o que necesitan atencin, y c) otros procesadores.
Instrucciones mquina de llamada al sistema (p. ej.: TRAP, INT o SC). Estas instrucciones permi
ten que un programa genere una interrupcin de tipo sncrono. Como veremos ms adelante, estas
instrucciones se incluyen para que los programas de usuario puedan solicitar los servicios del sistema
operativo.
Advertencia 1.2: Las excepciones hardware sncronas se denominan muy frecuentemente excepciones
software, pero en este texto reservamos dicho nombre para el concepto de excepcin soportado por el sistema
operativo (vase seccin 3.6.2 Excepciones, pgina 94 ).
Como complemento al mecanismo de aceptacin de interrupcin, los procesadores incluyen una ins
truccin mquina para retomar desde la rutina de tratamiento de interrupcin (p. ej.: RETI). El efecto de esta
instruccin es restituir los registros de estado y PC, desde el lugar en que fueron salvados al aceptarse la inte
rrupcin (p. ej.: desde la pila del sistema).
Niveles de interrupcin
Como muestra la figura 1.7, los procesadores suelen incluir varias lneas de solicitud de interrupcin, cada
una de las cuales puede tener asignada una determinada prioridad. En caso de activarse al tiempo varias de
estas lneas, se tratar la de mayor prioridad, quedando las dems a la espera de ser atendidas. Las ms priori
tarias suelen ser las excepciones hardware asincronas, seguidas por las excepciones hardware sncronas (o
de programa), las interrupciones extemas y las de llamada al sistema o TRAP.
Adems, el procesador suele incluir un mecanismo de inhibicin selectiva que permite detener todas o
determinadas lineas de interrupcin. Este mecanismo, que es muy especfico de cada mquina, puede estar
basado en los dos registros de mscara y de nivel, y en el biestable general de inhibicin de interrupcin
(BGII). El comportamiento de estos mecanismos es el siguiente. Mientras est activo BGII no se admitir
ninguna interrupcin. El registro de nivel inhibe todas las interrupciones con prioridad menor o igual que el
valor que contenga. Finalmente, el registro de mscara tiene un bit por lnea de interrupcin, por lo que per
mite inhibir de forma selectiva cualesquiera de las lneas de interrupcin.
Las interrupciones de las lneas inhibidas no son atendidas hasta que, al modificarse los valores de
mscara, nivel o BGII, dejen de estar inhibidas. Dependiendo del mdulo que las genera y del hardware de
interrupcin, se pueden encolar o se pueden llegar a perder algunas de las interrupciones inhibidas. Estos
valores de mscara, nivel y BGII deben incluirse en la parte del registro de estado que solamente es modificable en modo privilegiado, por lo que su modificacin queda restringida al sistema operativo. La unidad de
control, al aceptar una interrupcin, suele modificar determinados valores de los registros de inhibicin para
facilitar el tratamiento de las mismas. Las alternativas ms empleadas son dos: inhibir todas las interrupcio
nes o inhibir las interrupciones que tengan prioridad igual o menor que la aceptada.
INT1
INT2
INT3
INT4
INTn
.-------
Prioridad/Inhibicin
de interrupciones
I
M scara
Nivel
Prioridad .
INT
llB G Ill
Figura 1.7 Mecanismo de inhibicin/prioridad de interrupcin.
Unidad de control
del procesador
Tratamiento de interrupciones
En el ciclo de aceptacin de una interrupcin se salvan algunos registros, pero un correcto tratamiento de las
interrupciones exige preservar los valores del resto de los registros del programa interrumpido. De esta for
ma, se podrn restituir posteriormente dichos valores, para continuar con la ejecucin del programa como si
no hubiera pasado nada. Tngase en cuenta que el nuevo programa, que pone en ejecucin la interrupcin,
cargar nuevos valores en los registros del procesador. Tambin es necesario mantener la informacin que
tenga el programa en memoria, para lo cual basta con no modificar la zona de memoria asignada al mismo.
Adems, la rutina de tratamiento de interrupciones deber, en cuanto ello sea posible, restituir los valo
res de los registros de inhibicin de interrupciones para admitir el mayor nmero posible de interrupciones.
La instruccin mquina de retomo de interrupcin RETI realiza una funcin inversa a la del ciclo de
aceptacin de la interrupcin. Tpicamente, restituye el valor del registro de estado E y el del contador de
programa PC. En muchos casos, la instruccin RETI producir, de forma indirecta, el paso del procesador a
modo usuario. En efecto, supngase que est ejecutando el programa A en modo usuario y que llega una inte
rrupcin. El ciclo de aceptacin salva el registro de estado (que tendr un valor Ea) y el contador de progra
ma (que tendr un valor PCa). Como el bit que especifica el modo de funcionamiento del procesador se
encuentra en el registro de estado, Ea tiene activo el modo usuario. Seguidamente, el ciclo de aceptacin
cambia el registro de estado activando el modo privilegiado. Cuando ms tarde se restituya al registro de es
tado el valor salvado Ea, que tiene activo el modo usuario, se pone el procesador en este modo. Por otro lado,
al restituir el valor de contador de programa, se consigue que el procesador siga ejecutando a continuacin
del punto en el que el programa A fe interrumpido.
En las seccin 3.11 Tratamiento de interrupciones se detalla el tratamiento de las interrupciones rea
lizado por el sistema operativo, dando soluciones al anidamiento de las mismas, fenmeno que se produce
cuando se acepta una interrupcin sin haberse completado el tratamiento de la anterior.
1.4.
EL RELOJ
El trmino reloj se aplica a los computadores con tres acepciones diferentes, si bien relacionadas, como se
muestra en la figura 1.8. Estas tres acepciones son las siguientes:
Seal que gobierna el ritmo de ejecucin de las instrucciones mquina (CLK).
Generador de interrupciones peridicas o temporizador.
Contador de fecha y hora, o reloj de tiempo real RTC (Real Time Clock).
El oscilador que gobierna las fases de ejecucin de las instrucciones mquina se denomina reloj. Cuan
do se dice que un microprocesador es de 5 GHz, se est especificando que el oscilador que gobierna su ritmo
de funcionamiento interno produce una onda cuadrada con una frecuencia de 5 GHz.
La seal producida por el oscilador anterior, o por otro oscilador, se divide mediante un divisor de fre
cuencia para generar una interrupcin extema cada cierto intervalo de tiempo. Estas interrupciones, que se
estn produciendo constantemente, se denominan interrupciones de reloj o tics, dando lugar al segundo
concepto de reloj. El objetivo de estas interrupciones es, como veremos ms adelante, hacer qu el sistema
operativo entre a ejecutar de forma peridica. De esta manera, podr evitar que un programa monopolice el
uso del computador y podr hacer que entren a ejecutarse programas en determinados instantes de tiempo.
Estas interrupciones se producen cada varios ms; por ejemplo, en la arquitectura PC clsica para MS-DOS el
temporizador 8254 produce un tic cada 54,926138 ms.
Figura 1.8 Relojes del computador:
23
sectores consecutivos. Existen otros dispositivos de bloques como las cintas magnticas, los DVD y los CD.
Todos ellos se caracterizan por tener un tiempo de acceso importante comparado con el tiempo de transferen
cia de una palabra, por lo que interesa amortizar este tiempo de acceso transfiriendo bastantes palabras.
Otros dispositivos como el teclado se denominan de caracteres. Son una fuente o sumidero de bytes no
direccionables. Muchos de estos dispositivos se caracterizan por ser lentos, aunque algunos como los contro
ladores de red pueden ser muy rpidos.
1.6.2. E/S y concurrencia

Los perifricos son sensiblemente ms lentos que el procesador, por ejemplo, durante el tiempo que se tarda
en acceder a una informacin almacenada en un disco, un procesador moderno es capaz de ejecutar cientos o
miles de millones de instrucciones mquina. Es, por tanto, muy conveniente que el procesador, mientras se
est esperando a que se complete una operacin de E/S, est ejecutando un programa til y no un bucle de
espera.
Los computadores presentan tres modos bsicos de realizar operaciones de E/S: E/S programada, E/S
por interrupciones y E/S por DMA (Direct Memory Access). La E/S programada exige que el procesador est
ejecutando un programa de E/S, por lo que no existe ninguna concurrencia entre el procesador y la E/S. Sin
embargo, en los otros dos modos de E/S el procesador no tiene que estar atendiendo directamente la E/S, por
lo que puede estar ejecutando otro programa. Se dice, entonces, que existe concurrencia entre la E/S y el
procesador. Esta concurrencia permite optimizar el uso del procesador, pero exige que los controladores de
los perifricos sean ms inteligentes, lo que supone que sean ms complejos y ms caros.
En trminos generales, una operacin de E/S se compone de tres fases: envo de la orden al perifrico,
lectura o escritura de los datos y fin de la operacin.
La fase de envo de la orden consiste en escribir la orden en los registros del controlador del perifrico,
operacin que puede hacerse mediante unas cuantas instrucciones mquina. Dado que el controlador es un
dispositivo electrnico, estas escrituras se hacen a la velocidad del bus de E/S, sin esperas intermedias.
En la fase de transferencia de los datos interviene el perifrico, en general, mucho ms lento que el pro
cesador. Imaginemos una lectura a disco. Para realizar esta operacin con E/S programada debemos ejecutar
un bucle que lea el registro de estado del controlador, observe si est activo el bit de dato disponible y, en
caso positivo, que lo lea. El bucle podra tener la estructura que se muestra en los ejemplos del programa 1.1.
Programa 1.1 Bucle de E/S programada.
Ejemplo de bucle simplificado de lectura en pseudocdigo
n = 0
while n < m
read registro_control
if (registro_control = dato_disponible)
read registro_datos
store en memoria principal
n = n + 1
endif
endwhile
;Ejemplo de bucle simplificado de lectura en ensamblador
H'0045
,-Direccin del puerto de estado del perifrico
ASSIGN
P_ESTADO
H 10046
,
-Direccin del puerto de datos del perifrico
ASSIGN
PJDATO
H' 00000002 /Definicin de la mscara que especifica el bit
ASSIGN
MASCARA
;de dato disponible
H'0100
,
-Definicin del tamao del sector en bytes
ASSIGN
SECTOR
[100]
/Direccin del buffer donde se almacena el
DATA
BUFFER:
24
;sector ledo
SUB .RI,.RI
IN
R2,/P_ESTADO
AND .R 2 ,#MASCARA
BZ
/BUCLE
IN
,R2,/P_DATO
ST
R2,/BUFFER[.1]
ADD RI,#4
CMP .R I ,#SECTOR
BLT /BUCLE
Se pone a "0" el registro R1

;Se lee el puerto de estado del perifrico al
registro R2
Ser <> 0 si el bit de dato disponible est a
Si cero se repite el bucle
Se lee el puerto de datos del perifrico a R2
Se almacena el dato en la posicin de memoria
obtenida de sumar BUFFER al registro R1
Se incrementa R1 en 4 (palabras de 4 bytes)
Se compara el registro R1 con el tamao del sector
Si menor (Rl<SECTOR)se repite el bucle
Observe que, hasta que no se disponga del primer dato, el bucle puede ejecutarse millones de veces, y
que, entre dato y dato, se repetir varias decenas de veces. Al llegar a completar el nmero m de datos a leer,
se termina la operacin de E/S.
Se denomina espera activa cuando un programa queda en un bucle hasta que ocurra un evento. La es
pera activa consume tiempo del procesador, por lo que es muy poco recomendable cuando el tiempo de espe
ra es grande en comparacin con el tiempo de ejecucin de una instruccin.
En caso de utilizar E/S con interrupciones, el procesador, tras enviar la orden al controlador del perif
rico, puede dedicarse a ejecutar otro programa. Cuando el controlador disponga de un dato generar una inte
rrupcin extema. La rutina de interrupcin deber hacer la lectura del dato y su almacenamiento en memoria
principal, lo cual conlleva un cierto tiempo del procesador. En este caso se dice que se hace espera pasiva,
puesto que el programa que espera el evento no est ejecutndose. La interrupcin extema se encarga de
despertar al programa cuando ocurre el evento.
Finalmente, en caso de utilizar E/S por DMA, el controlador del dispositivo se encarga directamente de
ir transfiriendo los datos entre el perifrico y la memoria, sin interrumpir al procesador. Una vez terminada la
transferencia de todos los datos, el controlador genera una interrupcin extema de forma que se sepa que ha
terminado. Un controlador que trabaje por DMA dialoga directamente con la memoria principal del compu
tador. La fase de envo de una orden a este tipo de controlador exige incluir la direccin de memoria donde
est el buffer de la transferencia, el nmero de palabras a transmitir y la direccin de la zona del perifrico
afectada.
Existe un tipo evolucionado de DMA llamado canal, que es capaz de leer las rdenes directamente de
una cola de trabajos, construida en memoria principal, y de almacenar los resultados de las rdenes en una
cola de resultados, construida tambin en memoria principal, y todo ello sin la intervencin del procesador.
El canal solamente interrumpe al procesador cuando terminado un trabajo encuentra vaca la cola de trabajos.
Tabla 1.2 Ocupacin del procesador en operaciones de entrada/salida.
E/S
E/S
E/S
E/S
programada
por interrupciones
por DMA
por canal
Enviar orden
Procesador
Procesador
Procesador
Controlador
Esperar dato
Procesador
Controlador
Controlador
Controlador
Transferir dato
Procesador
Procesador
Controlador
Controlador
Fin operacin
Procesador
Procesador
Procesador
Controlador
La tabla 1.2 presenta la ocupacin del procesador en la realizacin de las distintas actividades de una
operacin de E/S segn el modelo de E/S utilizado.
Puede observarse que la solucin que presenta la mxima concurrencia, y que descarga al mximo al proce
sador, es la de E/S por canal. Por otro lado, es la que exige una mayor inteligencia por parte del controlador.
Un aspecto fundamental de esta concurrencia es su explotacin. En efecto, de nada sirve descargar al
procesador del trabajo de E/S si durante ese tiempo no tiene nada til que hacer. Ser una funcin importante
25
del sistema operativo explotar esta concurrencia entre la E/S y el procesador, haciendo que este ltimo realice
trabajo til el mayor tiempo posible.
1.6.3. Buses y direccionamiento

Un computador moderno incluye diversos buses para interconectar el procesador, la memoria principal y los
controladores de los perifricos. Estos buses pueden utilizar espacios de direcciones propios, lo que obliga a
disponer de puentes que traduzcan las direcciones de unos espacios a otros. Por otro lado, cada vez son ms
utilizados los buses serie, en los que la informacin de direccin circula por el bus en la cabecera de las tra
mas.
Por ejemplo, el procesador PXA-255 de Intel (comercializado en el ao 2003 para diseo de PDA (Per
sonal Data Assistant)), cuenta con un nico espacio de direcciones que se utiliza para la memoria principal,
para dos buses PCMCIA, para los perifricos integrados y para los perifricos extemos. Este espacio se re
parte segn lo indicado en la tabla 1.3. Por tanto, se trata de una mquina con mapa de memoria y E/S
comn.
Se puede observar en dicha tabla que los buses PCMCIA/CF estn proyectados en las direcciones 0x2000
0000 y 0x3000 0000 respectivamente. Esto significa que la direccin 0 del PCMCIA/CF - bus 0 se proyecta
en la direccin 0 x2000 0000 del procesador, por lo que los perifricos conectados al bus ven unas direcciones
distintas de las que ve el procesador.
Por otro lado, el bus I2C, incluido en este procesador, es un bus serie de dos hilos a 400 kb/s que permi
te conectar una gran variedad de pequeos perifricos. La informacin circula en tramas que incluyen una
direccin de 7 bits, lo que permite diferenciar hasta 128 perifricos distintos.
1.7.
PROTECCIN
Como veremos ms adelante, una de las funciones del sistema operativo es la proteccin de unos usuarios
contra otros: ni por malicia ni por descuido un usuario deber acceder a la informacin de otro, a menos que
el propietario de la misma lo permita. Para ello es necesario imponer ciertas restricciones a los programas en
ejecucin y es necesario comprobar que se cumplen. Dado que, mientras se est ejecutando un programa de
usuario, no se est ejecutando el sistema operativo, la vigilancia de los programas se ha de basar en meca
nismos hardware (aclaracin 1.4). En esta seccin se analizarn estos mecanismos, para estudiar en captulos
posteriores cmo resuelve el sistema operativo los conflictos detectados. Se analizar en primer lugar el me
canismo de proteccin que ofrece el procesador, para pasar seguidamente a los mecanismos de proteccin de
memoria y a la proteccin de E/S.
Tabla 1.3 Reparto del mapa de direcciones del PXA-255.

Direccin
OxAOOO 0000
0xA400 0000
0xA800 0000
OxACOO 0000
0x4800 0000
0x4400 0000
0x4000 0000
0x3000 0000
0 x2000 0000
0 x 0000 0000
Tamao
(64 MB)
(64 MB)
(64 MB)
(64 MB)
(64 MB)
(64 MB)
(64 MB)
(256 MB)
(256 MB)
(384 MB)
Uso inicial
SDRAM banco 3
SDRAM banco 2
SDRAM banco 1
SDRAM banco 0
Registros del controlador SDRAM
Registros del controlador LCD
Registros de los controladores de ios perifricos internos
PCMCIA/CF - bus 1
PCMCIA/CF - bus 0
Perifricos extemos del 0 al 5, dedicando 64 MB a cada uno
INTRODUCCION A LOS SISTEMAS

OPERATIVOS
Un sistema operativo es un programa que tiene encomendadas una serie de fimciones cuyo objetivo es sim
plificar el manejo y optimizar la utilizacin del computador, hacindole seguro y eficiente. En este captulo,
prescindiendo de muchos detalles en aras a la claridad, se introducen varios conceptos sobre los sistemas
operativos. Muchos de los temas tratados se plantearn con ms detalle en los captulos posteriores, dado el
carcter introductorio empleado aqu. De forma ms concreta, el objetivo del captulo es presentar una vi
sin globalizadora de los siguientes aspectos:
Definicin y funciones del sistema operativo.
Arranque del computador y del sistema operativo.
Activacin del sistema operativo.
Tipos de sistemas operativos.
Gestin de procesos.
Gestin de memoria.
Gestin de la E/S.
Gestin de ficheros y directorios.
Comunicacin y sincronizacin entre procesos.
Seguridad y proteccin.
Activacin del sistema operativo y llamadas al sistema.
Inte)fa z de usuario del sistema operativo e inte)faz del programador.
Diseo de los sistemas operativos.
Historia y evolucin de los sistemas operativos.
'
34
2.1^ QU ES UN SISTEMA OPERATIVO?

En esta seccin se plantea los conceptos de mquina desnuda, ejecutable y usuario, para pasar acto seguido a
introducir el concepto de sistema operativo, as como sus principales funciones.
M quina desnuda
El trmino de mquina desnuda se aplica a un computador carente de sistema operativo. El trmino es intere
sante porque resalta el hecho de que un computador en s mismo no hace nada. Como se vio en el captulo
anterior, un computador solamente es capaz de repetir a alta velocidad la secuencia de: lectura de instruccin
mquina, incremento del contador de programa o PC y ejecucin de la instruccin leda. Para que realice una
funcin determinada ha de tener en memoria principal un programa mquina especfico para realizar dicha
funcin y ha de conseguirse que el registro PC contenga la direccin de comienzo del programa.
La misin del sistema operativo, como se ver en la siguiente seccin, es completar ('vestir') la mquina
mediante una serie de programas que permitan su cmodo manejo y utilizacin]
Programa ejecutable
Un programa ejecutable, tambin llamado simplemente ejecutable, es un programa en lenguaje mquina que
puede ser cargado en memoria para su ejecucin. Cada ejecutable est normalmente almacenado en un fiche
ro que contiene la informacin necesaria para ponerlo en ejecucin. La estructura tnica de un ejecutable es la
siguiente:
"
---------- Cabecera que contiene, entre otras informaciones, las siguientes:
Estado inicial de los registros del procesador.

Tamao del cdigo y de los datos.
Palabra mgica que identifica al fichero como un ejecutable.
d ieo en lenguaje mouina.

Datos con valor inicial.
"Tabla de smbolos.
La preparacin del ejecutable, sigue los pasos de la figura 2.1.
Figura 2.1 Preparacin del cdigo ejecutable.
Introduccin a ios sistemas operativos
35
Los primeros pasos se refieren a la fase de programacin de la aplicacin, que desembocan en un objeto
ejecutable que queda almacenado en un fichero ejecutable. En muchos casos este objeto ejecutable no es el
programa mquina completo, puesto que no incluye las bibliotecas dinmicas, que estn almacenadas en sus
propios ficheros. Esta solucin tiene la ventaja de no repetir en cada fichero ejecutable estas bibliotecas, con
el consiguiente ahorro de espacio de disco.
Usuario
En primera instancia podemos decir que un usuario es una persona autorizada a utilizar un sistema inform
tico.
2.1.1. Sistema operativo

Un sistema operativo (SO) es un programa que tiene encomendadas una serie de funciones cuyo objetivo es
simplificar el manejo y la utilizacin del computador, hacindolo seguro y eficiente. Histricamente se han
ido completando las misiones encomendadas al sistema operativo, por lo que los productos comerciales ac
tuales incluyen una gran cantidad de funciones, como son interfaces grficas, protocolos de comunicacin,
bases de datos, etc.
1 T a s funciones clsicas del sistema operativo se pueden agrupar en las tres categoras siguientes:
Gestin de los recursos del computador.
Ejecucin de servicios para los programas en ejecucin.
Ejecucin de los mandatos de los usuarios.
El_objetivo del computador es ejecutar programas, por lo que el objetivo del sistema operativo es facilitar la iecucWtTde"dichosprogramasTT aiecu cin de programas en una mquina con sistema operativo da
lugar af concepto de proceso. Un proceso se puede definir de forma simplificada como un programa en eje
cucin.
Como muestra la figura 2.2, el sistema operativo est formado conceptualmente por tres capas principa
les. La capa ms cercana al hardware se denomina ncleo (kernel), y es la que gestiona los recursos hardwa
re del sistema y la que suministra la funcionalidad bsica del sistema operativo. Esta capa ha de ejecutar en
modo privilegiado, mientras que las otras pueden ejecutar en modos menos permisivos.
La capa de servicios, o de llamadas al sistema, ofrece a los procesos unos servicios a travs de una interfaz de programacin o API (Application Programming Interface). Desde el punto de vista de los procesos
esta capa extiende la funcionalidad del computador, por lo que se suele decir que el sistema operativo ofrece
una mquina extendida a los procesos. De esta forma se facilita la elaboracin de los programas, puesto que
se apoyan en las funciones que les suministra el sistema operativo.
La capa de intrprete de mandatos o shell suministra una interfaz a travs de la cual el usuario puede
dialogar de forma interactiva con el computador. El shell recibe los mandatos u rdenes del usuario, los in
terpreta y, si puede, los ejecuta. Dado que el shell suele ejecutar en modo usuario, algunos autores consideran
que no forma parte del sistema operativo. En opinin de los autores de este texto, el shell es uno ms de los
elementos del sistema operativo.
Seguidamente se analizarn cada una de estas tres facetas del sistema operativo.
Usuarios
Procesos de usuario
| Shell
Sistema
operativo
Servicios
Ncleo
Hardware
Figura 2.2 Niveles del sistema operativo.
36
El sistema operativo como gestor de recursos

Recurso es todo medio o bien que sirve para conseguir lo que se pretende. En un computador la memoria y el
procesador son recursos fsicos y un temporizador o un puerto de comunicaciones son ejemplos de recursos
lgicos. Los recursos son limitados y son reutilizados una vez que el proceso que los disfruta ya no los nece
site.
En un computador actual suelen coexistir varios procesos, del mismo o de varios usuarios, ejecutando
simultneamente. Estos procesos compiten por los recursos, siendo el sistema operativo el encargado de arbi
trar su asignacin y uso. El sistema operativo debe asegurar que no se produzcan violaciones de seguridad,
evitando que los procesos accedan a recursos a los que no tienen derecho Adems, ha de suministrar infor
macin sobre el uso que se hace de los recursos.
Asignacin de recursos
Para asignar los recursos a los procesos, el sistema operativo ha de mantener unas estructuras que le permitan
saber qu recursos estn libres y cules estn asignados a cada proceso. La asignacin de recursos se realiza
segn la disponibilidad de los mismos y la prioridad de los procesos, debindose resolver los conflictos cau
sados por las peticiones coincidentes.
Especial mencin reviste la recuperacin de los recursos cuando los procesos ya no los necesitan. Una
mala recuperacin de recursos puede hacer que el sistema operativo considere, por ejemplo, que ya no le
queda memoria disponible cuando, en realidad, s la tiene. La recuperacin se puede hacer o bien porque el
proceso que tiene asignado el recurso le comunica al sistema operativo que ya no lo necesita, o bien porque el
proceso haya terminado.
Las polticas de gestin de recursos determinan los criterios seguidos para asignar los recursos. Estas
polticas dependen del objetivo a alcanzar por el sistema. No tienen las mismas necesidades los sistemas per
sonales, los sistemas departamentales, los sistemas de tiempo real, etc.
Muchos sistemas operativos permiten establecer cuotas o lmites en los recursos asignados a cada pro
ceso o usuario. Por ejemplo, se puede limitar la cantidad de disco, memoria o tiempo de procesador asigna
dos.
Proteccin
El sistema operativo ha de garantizar la proteccin entre los usuarios del sistema: ha de asegurar la confiden
cialidad de la informacin y que unos trabajos no interfieran con otros. Para conseguir este objetivo ha de
impedir que unos procesos puedan acceder a los recursos asignados a otros procesos.
Contabilidad
La contabilidad permite medir la cantidad de recursos que, a lo largo de su ejecucin, utiliza cada proceso.
De esta forma se puede conocer la carga de utilizacin o trabajo que tiene cada recurso y se pueden imputar a
cada usuario los recursos que ha utilizado. Cuando la contabilidad se emplea meramente para conocer la car
ga de los componentes del sistema se suele denominar monitorizacin La monitorizacin se utiliza, espe
cialmente, para determinar los puntos sobrecargados del computador y, as, poder corregirlos.
ÊTsistema operativo como mquina extendida'
El sistema operativo ofrece a los programas un conjunto de servicios, o llamadas al sistema, proporcionndo
les una visin de mquina extendida. El modelo de programacin que ofrece el hardware se complementa
con estos servicios software, que permiten ejecutar de forma cmoda y protegida ciertas operaciones comple
jas. La alternativa consistira en complicar los programas de usuario y en no tener proteccin frente a otros
usuarios.
Las funciones de mquina extendida se pueden agrupar en las cuatro clases s ig u ie n te s - e je r.n r.ip n de
programas, operaciones de E/S, operaciones sobre ficheros y deteccin y tr a ta m ie n to de e r ro re s. Gran parte
de este texto se dedicar a explicar los servicios ofrecidos por los sistemas operativos, por lo que aqu nos
limitaremos a hacer unos simples comentarios sobre cada una de estas cuatro clases.
Introduccin a los sistemas operativos
37
Ejecucin de programas
E f sistema operativo incluye servicios para lanzar la ejecucin de un programa, creando un proceso, as como
para parar o abortar la ejecucin de un proceso. Tambin existen servicios para conocer y modificar las con
diciones de ejecucin de los procesos y para comunicar y sincronizar unos procesos con otros.
Bajo la peticin de un usuario, el sistema operativo leer un ejecutable, para lo cual deber conocer su
estructura, lo cargar en memoria y lo pondr en ejecucin. Observe que varios procesos pueden estar ejecu
tando el mismo programa, por ejemplo, varios usuarios pueden haber pedido al sistema operativo la ejecu
cin del mismo programa editor.
rdenes de E/S
Los servicios de E/S ofrecen una gran comodidad y proteccin al proveer a los programas de operaciones de
lectura, escritura y modificacin del estado de los perifricos, puesto que la programacin de las operaciones
de E/S es muy compleja y dependiente del hardware especfico de cada perifrico. Los servicios del sistema
operativo ofrecen un alto nivel de abstraccin, de forma que el programador de aplicaciones no tenga que
preocuparse de esos detalles.
Operaciones sobre ficheros
LosTcEr ofrecen un nivel de abstraccin mayor que el de las rdenes de E/S, permitiendo operaciones
tales como creacin, borrado, renombrado, apertura, escritura y lectura de ficheros. Observe que muchos de
los servicios son parecidos a las operaciones de E/S y terminan concretndose en este tipo de operacin.
Deteccin y tratamiento de errores
Xdems de analizar detalladamente todas las rdenes que recibe, para comprobar que se pueden realizar, el
sistema operativo se encarga de tratar todas las condiciones de error que detecte el hardware. Como ms re
levantes, destacaremos las siguientes: errores en las operaciones de E/S, errores de paridad en los accesos a
memoria o en los buses y errores de ejecucin en los programas, tales como los desbordamientos, las viola
ciones de memoria, los cdigos de instruccin prohibidos, etc.
El sistema operativo como interfaz de usuario
ETniduio del sistema operativo que permite que los usuarios dialoguen de forma interactiva con l es el
intrprete de mandatos o shell. El shell se comporta como un bucle infinito que est repitiendo constantemen
te la siguiente secuencia:
Espera una orden del usuario. En el caso de interfaz textual, el shell est pendiente de lo que escribe
el usuario en la lnea de mandatos. En las interfaces grficas est pendiente de los eventos del apun
tador (ratn) que manipula el usuario, adems, de los del teclado.
Analiza la orden y, en caso de ser correcta, la ejecuta, para lo cual emplea los servicios del sistema
operativo.
Concluida la orden muestra un aviso o prom pt y vuelve a la espera.
El dilogo mediante interfaz textual exige que el usuario memorice la sintaxis de los mandatos, con el
agravante de que son distintos para cada sistema operativo (p. ej.: para mostrar el contenido de un fichero en
Windows se emplea el mandato t y p e , pero en UD se usa el mandato c a t ) . Por esta razn, cada vez son
ms populares los intrpretes de mandatos con interfaz grfica, como el que se encuentra en las distintas ver
siones de Windows o el KDE o Gnome de Linux/
Sin embargo, la interfaz textual es ms potente que la grfica y permite automatizar operaciones (vase
ficheros de mandatos a continuacin), lo cual es muy interesante para administrar los sistemas.
Ficheros de mandatos
Casi todos los intrpretes de mandatos pueden ejecutar ficheros de mandatos, llamados shell scripts. Estos
ficheros incluyen varios mandatos totalmente equivalentes a los mandatos que se introducen en el terminal.
38
Adems, para realizar funciones complejas, pueden incluir mandatos especiales de control del flujo de ejecu
cin como pueden ser los bucles, las secuencias condicionales o las llamadas a funcin, as como etiquetas
para identificar lneas de mandatos.
Para ejecutar un fichero de mandatos basta con invocarlo de igual forma que un mandato estndar del
intrprete de mandatos.
2.1.2. Concepto de usuario y de grupo de usuarios

Como ya se ha visto, un usuario es una persona autorizada a utilizar un sistema informtico. El usuario se
autentica mediante su nombre de cuenta y su contrasea o password. Sin embargo, el sistema operativo no
asocia el concepto de usuario con el de persona fsica sino con un nombre de cuenta. Una persona puede te
ner ms de una cuenta y una cuenta puede ser utilizada por ms de una persona. Es ms, el usuario puede ser
un computador remoto. Internamente, el sistema operativo suele asignar a cada usuario (cuenta) un identificador uid (user identifier) y un perfil.
El sistema de proteccin de los sistemas operativos est basado en la entidad usuario. Cada usuario tie
ne asociados en su perfil unos permisos, que definen las operaciones que le son permitidas.
Existe un usuario privilegiado, denominado superusuario o administrador, que no tiene ninguna res
triccin, es decir, que puede hacer todas las operaciones sin ninguna traba. La figura del superusuario es ne
cesaria para poder administrar el sistema (recomendacin 2 . 1).
Recomendacin 2.1. La figura del superusuario entraa no pocos riesgos, por su capacidad de accin. Es,
por tanto, muy importante que la persona o personas que estn autorizadas a utilizar tina cuenta de superusua
rio sean de toda confianza y que las contraseas utilizadas sean difciles de adivinar. Adems, como una bue
na norma de administracin de sistemas, siempre se deber utilizar la cuenta con los menores permisos
posibles que permiten realizar la funcin deseada. De esta forma se minimiza la posibilidad de cometer errores irreparables.________________ ____________________________ .
Los usuarios se organizan en grupos (p. ej.: en una universidad se puede crear un grupo para los alum
nos de cada curso y otro para los profesores). Todo usuario debe pertenecer a un grupo. Los grupos tambin
se emplean en la proteccin del sistema, puesto que los derechos de un usuario son los suyos propios ms los
del grupo al que pertenezca. Internamente se suele asignar un identifcador gid {group identifier) a cada
grupo.
2.2. ARRANQUE Y PARADA DEL SISTEMA

El arranque de un computador actual tiene dos fases: la fase de arranque hardware y la fase de arranque del
sistema operativo. La figura 2.3 resume las actividades ms importantes que se realizan en el arranque del
computador.
Iniciador ROM
Como se ha indicado con anterioridad, el computador solamente es capaz de realizar actividades tiles si
cuenta con el correspondiente programa cargado en memoria principal. Ahora bien, la memoria principal de
los computadores es de tipo RAM, que es voltil, lo que significa que, cuando se enciende la mquina, no
contiene ninguna informacin vlida. Por tanto, al arrancar el computador no es capaz de realizar nada.
Para resolver esta situacin, los computadores antiguos tenan una serie de conmutadores que permitan
introducir, una a una, palabras en la memoria principal y en los registros. El usuario deba introducir a mano,
y en binario, un primer programa que permitiese cargar otros programas almacenados en algn soporte, como
la cinta de papel. En la actualidad, la solucin empleada es mucho ms cmoda, puesto que se basa en un
programa permanente grabado en una memoria ROM no voltil que ocupa, como muestra figura 2.4, una
41
MS-DOS o los .l o g i n y .c s h r c en UNIX. A continuacin, el shell se queda esperando rdenes de los

usuarios, ya sean textuales o acciones sobre un men o un icono. Es frecuente que el shell genere uno o va
rios procesos para llevar a cabo cada operacin solicitada por el usuario.
En algunos de los sistemas operativos monousuario utilizados en los computadores personales no hay
fase de login, crendose directamente el proceso shell para atender al usuario.
2.2.3. Parada del computador

Para garantizar una alta velocidad, el sistema operativo mantiene en memoria principal una gran cantidad de
informacin crtica, entre la que cabe destacar parte de los ficheros que se estn utilizando. Para que toda esa
informacin no se pierda o corrompa al apagar el computador, el sistema operativo debe proceder a un apa
gado ordenado, que consiste en copiar a disco toda la informacin crtica que mantiene en memoria y en ter
minar todos los procesos activos. Este apagado ordenado lleva un cierto tiempo, pero es imprescindible para
que no se produzcan prdidas de informacin.
Cuando se produce un apagn brusco, por ejemplo, porque se interrumpe la alimentacin o porque se
pulsa el RESET del computador, se corre el riesgo de perder informacin importante y de que el sistema de
ficheros quede inconsistente. Por esta razn, despus de un apagado brusco se debe comprobar siempre la
consistencia del sistema de ficheros y se deben reparar los posibles problemas detectados.
En los sistemas multiusuario el apagado del computador debe anunciarse con suficiente antelacin para
que los usuarios cierren sus aplicaciones y salven en disco su informacin.
En los computadores personales se puede hibernar el sistema. Esta operacin se diferencia del apagado
en que los procesos no se cierran, simplemente se hace una copia a disco de toda la memoria principal.
Cuando se vuelve a arrancar, se recupera esta copia, quedando el computador en el estado que tena antes de
hibernar, con todos los procesos activos. La hibernacin y rearranque posterior suelen ser bastante ms rpi
das que el apagado y arranque normal.
Los computadores porttiles suelen incorporar una funcin de apagado en espera (standby). En este
modo se para todo el computador, pero se mantiene alimentada la memoria principal, de forma que conserve
toda su informacin. Se trata de un apagado parecido a la hibernacin pero que es mucho ms rpido, puesto
que no se copia la informacin al disco, pero se necesita una batera para mantener la memoria alimentada.
Del apagado en espera se sale mediante una interrupcin, como puede ser de un temporizador o batera baja.
Este apagado no se puede utilizar, por ejemplo, en los aviones, puesto que el computador puede despertar,
aunque est cerrado, violando las normas de aviacin civil.
2.3._ ACTIVACIN DEL SISTEMA OPERATIVO

Una vez finalizada la fase de arranque, el sistema operativo cede la iniciativa a los procesos y a los perifri
cos, que, mediante interrupciones, solicitarn su atencin y servicios. Desde ese momento, el sistema opera
tivo est dormido y solamente se pone en ejecucin, se despierta, mediante una interrupcin.
El sistema operativo es, por tanto, un servidor que est a la espera de que se le encargue trabajo mediante
interrupciones. Este trabajo puede provenir delaJsguientes fuentes:
Llamadas al sistema emitidas por los programas mediante la instruccin mquina TRAP o de llama
da al sistema. Esta instruccin genera un ciclo de interrupcin por lo que pone al procesador en mo
do privilegiado. Observe que los servicios del sistema operativo no se pueden solicitar mediante una
instruccin mquina normal de llamada a procedimiento o funcin. Estas instrucciones no cambian
el modo de ejecucin, por lo que no sirven para activar el sistema operativo.
Interrupciones extemas. Se considerarn tres tipos de interrupciones: de E/S, de reloj y de otro pro
cesador. Las de E/S estn producidas por los perifricos para indicar, por ejemplo, que tienen o nece
sitan un dato, que la operacin ha terminado o que tienen algn problema.
42
Excepciones hardware sncronas (vase seccin 1.3 Interrupciones, pgina 6 ).

Excepciones hardware asincronas (vase seccin 1.3 Interrupciones, pgina 6 ).
Las llamadas al sistema y las excepciones hardware sncronas son interrupciones sncronas, puesto que
las produce directa o indirectamente el programa, mientras que el resto son asincronas. En todos los casos, el
efecto de la interrupcin es que se entra a ejecutar el sistema operativo en modo privilegiado.
La secuencia simplificada de activacin del sistema operativo es la mostrada en la figura 2.6, que cons
ta de los siguientes pasos:
Est ejecutando un proceso A y, en un instante determinado, se genera una interrupcin para solicitar
la atencin del sistema operativo. Dicha interrupcin pone el computador en modo privilegiado.
El sistema operativo entra en ejecucin y salva el estado del proceso A.
Seguidamente, el sistema operativo realiza la tarea solicitada.
Una vez finalizada la tarea, entra en accin el planificador, modulo del sistema operativo que selec
ciona un proceso B para ejecutar (que puede volver a ser el A).
La actuacin del sistema operativo finaliza con el activador, modulo que se encarga de restituir los
registros con los valores previamente almacenados del proceso B y de poner el computador en modo
usuario. El instante en el que el activador restituye el contador de programa marca la transicin del
sistema operativo a la ejecucin del proceso B.
Ms adelante se completar este modelo para tener en cuenta aspectos de diseo del sistema operativo.
2.3.1. Servicios del sistema ^nprativo v funcione? rie llamada

Los servicios del sistema operativo forman un puente entre el espacio de usuario y el espacio de ncleo.
Tambin son el puente entre las aplicaciones de usuario y el hardware, puesto que es la nica forma que tie
nen stas de acceder al hardware. Cada servicio tiene su propio nmero identificador interno.
En esta seccin se tratar primero la ejecucin de los servicios, para pasar seguidamente a analizar las
funciones de biblioteca.
Ejecucin de los servicios
Cuando el sistema operativo recibe la solicitud de un servicio pueden ocurrir dos cosas: que el servicio se
pueda realizar de un tirn o que requiera acceder a un recurso lento, como puede ser un disco, por lo que re
quiere una o varias esperas. Lgicamente, el sistema operativo no har una espera activa y pondr en ejecu
cin otros procesos durante las esperas, lo que significa que el servicio no se realiza de un tirn, requiriendo
varias fases de ejecucin.
La figura 2.7 muestra la ejecucin del servicio en el caso de requerir una sola fase y en el caso de re
querir dos. En este ltimo se puede observar que, una vez completada la primera fase del servicio, se pasa a
ejecutar otro proceso, que puede ser interrumpido o puede, a su vez solicitar un servicio. Cuando llega el
evento por el que est esperando el servicio A (interrupcin A), se ejecuta la segunda fase del servicio A.
Se dice que el servicio es sncrono cuando el proceso que lo solicita queda bloqueado hasta que se
completa el servicio. Por el contrario, se dice que el servicio es asincrono si el proceso que lo solicita puede
P roceso A = = |
tSe solicita el SO mediante una interrupcin

El SO salva el estado del proceso A
Sistem a |
El SO realiza la fu n d n pedida
ope rativo ======
Planificador del SO
. Activador del SO
Proceso B
....
Figura 2.6 Modelo simplificado de la activacin del sistema operativo.
2 .4 .
45
TIPOS DE SISTEMAS OPERATIVOS
Existe una gran diversidad de sistemas operativos diseados para cubrir las necesidades de los distintos dis
positivos y de los distintos usos. Dependiendo de sus caractersticas, un sistema operativo puede ser:
Segn el nmero de procesos simultneos que permita ejecutar: monotarea o monoproceso y multitarea o multiproceso.
Segn la forma de interaccin con el usuario: interactivo o por lotes.
Segn el nmero de usuarios simultneos: monousuario o personal y multiusuario o de tiempo com
partido.
Segn el nmero de procesadores que pueda atender: monoprocesador y multiprocesador.
Segn el nmero de threads que soporte por proceso: monothread y multithread, (vase seccin 3.9
Threads)
Segn el uso: cliente, servidor, empotrado, de comunicaciones o de tiempo real.
Segn la movilidad: fijos y mviles.
Estas clasificaciones no son excluyentes, as un sistema operativo servidor ser generalmente tambin
multiprocesador, multithread y multiusuario.
Un sistema operativo monotarea, tambin llamado monoproceso, solamente permite que exista un pro
ceso en cada instante. Si se quieren ejecutar varias procesos, o tareas, hay que lanzar la ejecucin de la prime
ra y esperar a que termine antes de poder lanzar la siguiente. El ejemplo tpico de sistema operativo
monoproceso es el MS-DOS, utilizado en los primeros computadores PC. La ventaja de estos sistemas opera
tivos es que son muy sencillos.
Por el contrario, un sistema operativo multitarea, o multiproceso (recordatorio 2.1), permite que co
existan varios procesos activos a la vez. El sistema operativo se encarga de ir repartiendo el tiempo del pro
cesador entre estos procesos, para que todos ellos vayan avanzando en su ejecucin.
Recordatorio 2.1. No confundir el trmino multiproceso con multiprocesador. El trmino multiproceso se
refiere a los sistemas que permiten que existan varios procesos activos al mismo tiempo, mientras que el
trmino multiprocesador se refiere a un computador con varios procesadores. El multiprocesador exige un
sistema operativo capaz de gestionar simultneamente todos sus procesadores, cada uno de los cuales estar
ejecutando su propio proceso.
. ,
^
1
. . Y .Y ; y . :
Un sistema interactivo permite que el usuario dialogue con los procesos a travs, por ejemplo, de un
terminal. Por el contrario, en un sistema por lotes o batch se parte de una cola de trabajos que el sistema va
ejecutando cuando tiene tiempo y sin ningn dilogo con el usuario.
Un sistema monousuario, o personal, est previsto para soportar a un solo usuario interactivo. Estos
sistemas pueden ser monoproceso o multiproceso. En este ltimo caso el usuario puede solicitar varias tareas
al mismo tiempo, por ejemplo, puede estar editando un fichero y, simultneamente, puede estar accediendo a
una pgina Web.
El sistema operativo multiusuario es un sistema interactivo que da soporte a varios usuarios, que traba
jan simultneamente desde varios terminales locales o remotos. A su vez, cada usuario puede tener activos
ms de un proceso, por lo que el sistema, obligatoriamente, ha de ser multitarea. Los sistemas multiusuario
reciben tambin el nombre de tiempo compartido, puesto que el sistema operativo ha de repartir el tiempo
del procesador entre los usuarios, para que las tareas de todos ellos avancen de forma razonable.
La figura 2.9 recoge estas alternativas.
Un sistema operativo servidor est optimizado para que sus usuarios sean sistemas remotos. Por el con
trario, un sistema operativo cliente es un sistema operativo personal diseado para poder conectarse a servi
dores. Los sistemas operativos personales interactivos incluyen soporte grfico, para construir interfaces
grficas (GUI Graphical User Interface), con el objetivo de facilitar la interaccin con el usuario, as como
herramientas que permitan gestionar con facilidad el sistema. Existen versiones de Windows y de Linux con
perfil servidor y con perfil personal.
46
N usuarios )
simultneos 'S
/ ms de 1
Monoproceso
Monousuario
Multiproceso
Monousuario
--------
Multiproceso
Multiusuario
Figura 2.9 Tipos de sistemas operativos en funcin del nmero de procesos y usuarios.
Los sistemas operativos empotrados interaccionan con un sistema fsico y no con un usuario. Suelen
ejecutar en plataformas con poca memoria, poca potencia de proceso y sin disco duro, por lo que suelen ser
sencillos, limitndose a las fimciones imprescindibles para la aplicacin. Se almacenan en memoria ROM y
en muchos casos no cuentan con servidor de ficheros ni interfaz de usuario.
Los sistemas operativos de tiempo real permiten garantizar que los procesos ejecuten en un tiempo
predeterminado, para reaccionar adecuadamente a las necesidades del sistema, como puede ser el guiado de
un misil o el control de una central elctrica. Con gran frecuencia entran tambin en la categora de sistemas
operativos empotrados. Como ejemplos se puede citar el VxWorks de Wind River o el RTEMS de OAR.
Para atender las peculiaridades de los dispositivos mviles (PDA, telfono inteligente, pocket PC, etc.)
existen una serie de sistemas operativos mviles. Tienen un corte parecido a los destinados a los computado
res personales, pero simplificados, para adecuarse a estos entornos. Adems, estn previstos para que el dis
positivo se encienda y apague con frecuenta y para reducir al mximo el consumo de las bateras. Ejemplos
son las familias PALM OS, Windows CE, Windows Mobile y Symbian OS, este ltimo muy utilizado en los
telfonos mviles.
Para las tarjetas inteligentes se construyen sistemas operativos empotrados muy simples pero con fun
cionalidades criptogrficas. Ejemplos son MULTOS, SOLO (de Schlumberger) y Sun's JavaCard.
2.5.
COMPONENTES DEL SISTEMA OPERATIVO
El sistema operativo est formado por una serie de componentes especializados en determinadas funciones.
Cada sistema operativo estructura estos componentes de forma distinta. En una visin muy general, como se
muestra en la figura 2 . 10 , se suele considerar que un sistema operativo est formado por tres capas: el ncleo,
los servicios y el intrprete de mandatos o shell.
Elncleo es la parte del sistema operativo que interacciona directamente con el hardware de la mqui
na. Las funciones del ncleo se centran en la gestin de recursos, como es el procesador, tratamiento de inte
rrupciones y las funciones bsicas de manipulacin de memoria.
Los servicios se suelen agrupar segn su funcionalidad en varios componentes, como los siguientes:
Gestor de procegos. Encargado de la creacin, planificacin y destruccin de procesos.
Gestor de memoria. Componente encargado de saber qu partes de la memoria estn libres y cules
Usuarios
Shell 1
Programas de usuario
Windows
Shell 2
UNIX
Gestin de Seguridad Comunlcac

GesUn de Gestin da GesUn de ficheros y
y
y
procesos memoria
la E/S
directorios proteccin sincronfct.
Ncleo
Hardware
Figura 2.10 Componentes del sistema operativo.
47
ocupadas, as como de la asignacin y liberacin de memoria segn la necesiten los procesos.

Gestor de la E/S. Se ocupa de facilitar el manejo de los dispositivos perifricos.
( lis tar de ficheros v directorios. Se encarga del manejo de ficheros y directorios, y de la administracdel almacenamiento secundario.
Gestor de comunicacin v sincronizacin entre procesos. Ofrecer mecanismos para que los procesos
puedan comunicarse y sincronizarse.
Gestor de seguridad frente a ataques del exterior y proteccin interna. Este componente debe encar
garse Te~feat^lTdentificacin de los usuarios, de definir lo que pueden hacer cada uno de ellos
con los recursos del sistema y de controlar el acceso a estos recursos.
Todos estos componentes ofrecen una serie de servicios a travs de una interfaz de llamadas al sistema.
Aunque no es muy frecuente, la figura 2.10 muestra que un sistema operativo puede incluir ms de una inter
faz de servicios, definiendo cada interfaz una mquina extendida propia. En la figura se han considerado las
interfaces Windows y UNIX, interfaces que sern descritas a lo largo del presente libro. En este caso, los
programas podrn elegir sobre qu mquina extendida quieren ejecutar, pero no podrn mezclar servicios de
varias mquinas extendidas.
De igual forma, el sistema operativo puede incluir varios intrpretes de mandatos, unos textuales y
otros grficos, pudiendo el usuario elegir los que ms le interesen, debiendo utilizar, en cada caso, los manda
tos correspondientes.
En las secciones siguientes de este captulo se van a describir, de forma muy breve, cada uno de los
componentes anteriores.
2.5.1. Gestin de procesos
J t c w * 1 *t J
Como se indic anteriormente, proceso es un programg.n_ejcin. De una forma ms precisa, se puede

definir el proceso coma la unidad d& preG&samielp gestionada por el sistema operativo. No hay que confun
dir eFconcepto de programa con el concepto de proceso. Un programa no es ms que un conjunto de instruc
ciones mquina, mientras que el proceso surge cuando un programa se pone en ejecucin. Esto hace que
varios procesos puedan ejecutar el mismo programa a la vez (por ejemplo, que varios usuarios estn ejecu
tando el mismo navegador). Para que un programa se pueda ejecutar tiene que estar preparado en un fichero
ejecutable, que contiene el cdigo y algunos datos iniciales (vase captulo 5 Gestin de memoria).
Dado que un computador est destinado a ejecutar programas, podemos decir que la misin ms impor
tante del sistema operativo es la generacin de procesos y la gestin de los mismos.
Para ejecutar un programa ste ha de residir, junto con sus datos, en el mapa de memoria principal, tal y
como muestra la figura 2.11. Se denomina imagen de memoria a la informacin que mantiene el proceso en
el mapa de memoria.
Durante su ejecucin, el proceso va modificando los contenidos de los registros del computador, es de
cir, va modificando el estado del procesador. Tambin va modificando los datos que tiene en memoria, es
decir, su imagen de memoria.
El sistema operativo mantiene, por cada proceso, una serie de estructuras de informacin, que permiten
identificar las caractersticas de ste, as como los recursos que tiene asignados. Una parte muy importante de
Cdigo
fdatosv
Mapa
de
E/S
BC Pr : '" M
Registros generales
PC
SP
Estado
Figura 2.11 Elementos que constituyen un proceso.
48
esta informacin est en el bloque de control del proceso (BCP), que se estudiar con detalle en la seccin
3.3.3 Informacin del bloque de control de proceso (BCP). El sistema operativo debe encargarse tambin
de ofrecer una serie de servicios para la gestin de procesos y para su planificacin, as como para gestionar
los posibles interbloqueos que surgen cuando los procesos acceden a los mismos recursos.
Una buena parte de la informacin del proceso se obtiene del ejecutable, pero otra la produce el sistema
operativo. A diferencia del ejecutable, que es permanente, la informacin del proceso es temporal y desapa
rece con el mismo. Decimos que el proceso es voltil mientras que el ejecutable perdura hasta que se borre el
fichero.
En el captulo 3 Procesosse estudiarn en detalle los procesos, en el captulo 4 Planificacin de pro
cesos se tratarn las tcnicas de planificacin de procesos y en el captulo 6 Comunicacin y sincronizacin
de procesos se estudiarn los interbloqueos y los mecanismos para manejarlos.
Servicios de procesos
El sistema operativo ofrece una serie de servicios que permiten definir la vida de un proceso, vida que consta
de las siguientes fases: creacin, ejecucin y muerte del proceso, que se analizan seguidamente:
O p a r nn proceso El proceso es creado por el sistema operativo cuando as lo solicita otro proceso,
que se convierte en el padre del nuevo. Existen dos modalidades bsicas para crear un proceso en los
sistemas operativos:
Creacin a partir de la imagen del proceso padre. En este caso, el proceso hijo es una copia
exacta o clon del proceso padre. Esta variante es la que utiliza el servicio f o rk de UNIX.
Creacin a partir de un fichero ejecutable. Esta modalidad es la que se utiliza en el servicio
C r e a teProcess de Windows.
E jecutar un proceso. Los procesos se pueden ejecutar de tres formas: batch, interactivaj/ segundo
plano.
Un proceso que ejecuta en modo de lotes o batch, no est asociado a ningn terminal. Deber
tomar sus datos de entrada de ficheros y deber depositar sus resultados en ficheros. Un ejem
plo tpico de un proceso batch es un proceso de nminas, que parte del fichero de empleados y
del fichero de los partes de trabajo para generar un fichero de rdenes bancadas de pago de
nminas.
Por el contrario, un proceso que ejecuta en modo interactivo est asociado a un terminal, por
el que recibe la informacin del usuario y por el que contesta con los resultados. Un ejemplo
tpico de un proceso interactivo es un proceso de edicin.
Los sistemas interactivos permiten lanzar procesos en segundo plano o background. Se trata
de procesos similares a los de lotes, que no estn asociado a ningn terminal.
Terminar la ejecucin de unjumceso. Un proceso puede finalizar su ejecucin por varias causas,
entre las que se encuentranTssiguientes:
El programa ha llegado a su final.

Se produce una condicin de error en su ejecucin, como divisin por cero o acceso de memo
ria no permitido.
Otro proceso o el usuario decide que ha de terminar y lo mata, por ejemplo, con el servicio
k i l l de UNIX.
Cambiar eLojecutahle de un procego. Algunos sistemas operativos incluyen un servicio que cam
bia, por otro, el ejecutable que est ejecutando un proceso. Observe que esta operacin no consiste
en crear un nuevo proceso que ejecuta ese nuevo ejecutable, se trata de sustituir el ejecutable que
est ejecutando el proceso por un nuevo ejecutable que se trae del disco, manteniendo el mismo pro
ceso. El servicio e x e c de UNIX realiza esta funcin.
2.5.2. Gestin de memoria
49
7<}h u ( / c,
El componente del sistema operativo llamado gestor de memoria se encarga de:

Asignar memoria a los procesos para crear su imagen de memoria.
Proporcionar memoria a los procesos cuando la soliciten y liberarla cuando as lo requieran.
Tratar los errores de acceso a memoria, evitando que unos procesos interfieran en la memoria de
otros.
Permitir que los procesos puedan compartir memoria entre ellos. De esta forma los procesos podrn
comunicarse entre ellos.
Gestionar la jerarqua de memoria y tratar los fallos de pgina en los sistemas con memoria virtual.
Servicios
Adems de las funciones vistas anteriormente, el gestor de memoria ofrece los siguientes servicios:
Solicitar memoria. Este servicio aumenta el espacio de la imagen de memoria del proceso. El sis
tema operativo satisfar la peticin siempre y cuando cuente con los recursos necesarios para ello y
no se exceda la cuota en caso de estar establecida. En general, el sistema operativo devuelve un
apuntador con la direccin de la nueva memoria. El programa utilizar este nuevo espacio a travs
del mencionado apuntador, mediante direccionamientos relativos al mismo.
Liberar memoria. Este servicio sirve para devolver trozos de la memoria del proceso. El sistema
operativo recupera el recurso liberado y lo aade a sus listas de recursos libres, para su posterior re
utilizacin. Este servicio y el de solicitar memoria son necesarios para los programas que requieren
asignacin dinmica de memoria, puesto que su imagen de memoria ha de crecer o decrecer de
acuerdo a las necesidades de ejecucin.
Compartir memoria. Son los servicios de crear y liberar regiones de memoria compartidas, lo que
permite que los procesos puedan comunicarse escribiendo y leyendo en ellas.
El gestor de memoria establece la imagen de memoria de los procesos. La figura 2.12 muestra algunas
soluciones para sistemas reales y virtuales.
En el captulo 5 Gestin de memoria se estudiarn los conceptos relativos a la gestin de memoria,
los servicios ofrecidos por el gestor de memoria y las tcnicas de gestin de memoria.
2.5.3. Comunicacin y sincronizacin entre procesos

Los procesos son entes independientes y aislados, puesto que, por razones de seguridad, no deben interferir
unos con otros. Sin embargo, cuando se divide un trabajo complejo en varios procesos que cooperan entre s
para realizar dicho trabajo, es necesario que se comuniquen, para transmitirse datos y rdenes, y que se sin
cronicen en la ejecucin de sus acciones. Por tanto, el sistema operativo debe incluir servicios de comunica
cin y sincronizacin entre procesos que, sin romper los esquemas de proteccin, han de permitir la
Memoria
principal
Memoria
principal
Programa A
Programa A
Programa B
Memoria
virtual
Regin 0 '
Regin 1
^Programa A
Programa C
Regin 2
Sistema
operativo
Sistema
operativo
Sistema
operativo
Sistema real monoproceso

una sola regin de memoria
Sistema real mulproceso

una sola regln de memoria
Sistema virtual
varas regiones de memoria
Figura 2.12 Distintas alternativas de asignacin de memoria.
50
cooperacin entre ellos.

El sistema operativo ofrece una serie de mecanismos bsicos de comunicacin que permiten transferir
cadenas de bytes, pero han de ser los procesos que se comunican entre s los que han de interpretar las cade
nas de bytes transferidas. En este sentido, se han de poner de acuerdo en la longitud de la informacin y en
los tipos de datos utilizados. Dependiendo del servicio utilizado, la comunicacin se limita a los procesos de
una mquina (procesos locales) o puede involucrar a procesos de mquinas distintas (procesos remotos). La
figura 2.13 muestra ambas situaciones.
El sistema operativo ofrece tambin mecanismos que permiten que los procesos esperen (se bloqueen) y
se despierten (continen su ejecucin) dependiendo de determinados eventos.
Servicios de comunicacin y sincronizacin
Existen distintos mecanismos de comunicacin (que en muchos casos tambin sirven para sincronizar), como
son las tuberas o pipes, la memoria compartida y los sockets. Cada uno de estos mecanismos se puede utili
zar a travs de un conjunto de servicios propios. Estos mecanismos son entidades vivas, cuya vida presenta
las siguientes fases: creacin del mecanismo, utilizacin del mecanismo y destruccin del mecanismo. De
acuerdo con esto, los servicios bsicos de comunicacin, que incluyen todos los mecanismos de comunica
cin, son los siguientes:
' ------------------------------------- Crear. Permite que el proceso solicite la creacin del mecanismo. Ejemplo p i p e de UNIX y
C r e a t e P ip e de Windows.
Enviar o escribir. Permite que el proceso emisor enve informacin a otro proceso. Ejemplo w r i t e
de UNIX y W r i t e F i l e de Windows.
Recibir o leer. Permite que el proceso receptor reciba informacin de otro proceso. Ejemplo r e a d
de UNIX y R e a d F ile de Windows.
Destruir. Permite que el proceso solicite el cierre o destruccin del mecanismo. Ejemplo c i s e de
UNIX y C lo s e H a n d le de Windows.
Por otro lado, la comunicacin puede ser sncrona o asincrona. En la comunicacin sncrona los dos
procesos han de ejecutar los servicios de comunicacin al mismo tiempo, es decir, el emisor ha de estar eje
cutando el servicio de enviar y el receptor ha de estar ejecutando el servicio de recibir. Normalmente, para
que esto ocurra uno de ellos ha de esperar a que el otro llegue a la ejecucin del correspondiente servicio
(vase la figura 2.14).
En la comunicacin asincrona el emisor no tiene que esperar a que el receptor solicite el servicio reci
bir, por el contrario, hace el envo y sigue con su ejecucin. Esto obliga a que el sistema operativo establezca
un almacenamiento intermedio para guardar la informacin enviada hasta que el receptor la solicite.
Los mecanismos de sincronizacin (como el semforo y el mutex, que se estudian en detalle en el cap
tulo S CoranfccTn y sincronizacin de procesos) suelen incluir los siguientes servicios:
Crear. Permite que el proceso solicite la creacin del mecanismo. Ejemplo s e m _ i n i t de UNIX y
C r e a te S e m a p h o r e de Windows.
Esperar. Permite que el proceso se bloquee en espera hasta que ocurra un determinado evento.
Ejemplo s e m _ w a it de UNIX y W a itF o r S in g le O b j e c t de Windows.
Despertar. Permite despertar a un proceso bloqueado. Ejemplo s e tn _ p o s t de UNIX y R e l e a s e -
Un computador
Figura 2.13 Comunicacin entre procesos locales y remotos.
Dos computadores
El proceso A espera al B
51
El proceso B espera al A
Figura 2.14 Comunicacin sncrona entre procesos.

Semaphore de Windows.
Destruir. Permite que el proceso solicite el cierre o la destruccin del mecanismo. Ejemplo sem_destroy de UNIX y CloseHandle de Windows.
Aunque el sistema operativo es capaz de destruir los mecanismos de comunicacin y sincronizacin
cuando terminan los procesos que los utilizan, el programador profesional debe incluir siempre los pertinen
tes servicios de destruccin.
2.5.4. Gestin de la E/S

El gestor de E/S es el componente del sistema operativo que se encarga de los dispositivos perifricos, con
trolando su funcionamiento para alcanzar los siguientes objetivos:
Facilitar el manejo de los dispositivos perifricos. Para ello debe ofrecer una interfaz sencilla, uni
forme y fcil de utilizar, y debe gestionar los errores que se pueden producir en el acceso a los dispo
sitivos perifricos.
Garantizar la proteccin, impidiendo a los usuarios acceder sin control a los dispositivos perifricos.
Dentro de la gestin de E/S, el sistema operativo debe encargarse de gestionar los distintos dispositivos
de E/S: relojes, terminales, dispositivos de almacenamiento secundario y terciario, etc.
Servicios
El sistema operativo ofrece a los usuarios una serie de servicios de E/S independientes de los dispositivos.
Esta independencia implica que pueden emplearse los mismos servicios y operaciones de E/S para leer, por
ejemplo, datos de un disquete, de un disco duro, de un CD-ROM o de un terminal. Los servicios de E/S estn
dirigidos bsicamente a la lectura y escritura de datos. Segn el tipo de perifrico, estos servicios pueden
estar orientados a caracteres, como ocurre con las impresoras o los terminales, o pueden estar orientados a
bloques, como ocurre con las unidades de disco.
2.5.5. Gestin de ficheros y directorios

El servidor de ficheros es la parte de la mquina extendida, ofrecida por el sistema operativo, que cubre el
manejo de los perifricos. Los objetivos fundamentales del servidor de ficheros son los siguientes:
Facilitar el manejo de los dispositivos perifricos. Para ello ofrece una visin lgica simplificada de
los mismos en forma de ficheros y de ficheros especiales.
Proteger a los usuarios, poniendo limitaciones a los ficheros que es capaz de manipular cada usuario.
El servidor de ficheros ofrece al usuario (figura 2.15) una visin lgica compuesta por una serie de ob
jetos (ficheros y directorios), identificables cada uno por un nombre lgico distinto. Los servicios son de dos
tipos: los servicios dirigidos al manejo de datos (servicios sobre fichero), y los dirigidos al manejo de los
52
a
Visin
lgica
S-------~i
(___J
m
(
Visin
fsica
=1
[.......... . 'i
&
Figura 2.15 Visin lgica y fisica del sistema de ficheros.

nombres (servicios sobre directorio). El servidor de ficheros se suele encargar de ambos tipos de servicios,
aunque, a veces, se incluyen servidores separados para datos y para nombres.
La visin fsica incluye los detalles de cmo estn proyectados estos objetos en los perifricos corres
pondientes (p. ej.: en los discos).
Ficheros
Un fichero es una unidad de almacenamiento lgico no voltil que agrupa bajo un mismo nombre un conjun
to de informaciones normalmente relacionadas entre s. Al fichero se le asocian los llamados atributos que
utilizan tanto los usuarios como el propio servidor de ficheros. Los atributos ms usuales son:
Tipo de fichero (por ejemplo, fichero de datos, fichero ejecutable, directorio, etc.).
Propietario del fichero (identificador del usuario que cre el fichero y del grupo de dicho usuario).
Tamao real en bytes del fichero. Al fichero se le asigna espacio en unidades de varios KB llamadas
agrupaciones. Es muy raro que la ltima agrupacin est completamente llena, quedando, por
trmino medio, sin usarse media agrupacin de cada fichero.
Instantes (fecha y hora) importantes de la vida del fichero, como son los siguientes: a) instante en
que se cre, b) instante de la ltima modificacin y c) instante del ltimo acceso.
Derechos de acceso al fichero (slo lectura, lectura-escritura, slo escritura, ejecucin,...).
Las operaciones sobre ficheros que ofrece el servidor de ficheros estn referidas a la visin lgica de
los mismos. La solucin ms comn es que el fichero se visualice como un vector de bytes o caracteres, tal y
como indica la figura 2.16. Algunos sistemas de ficheros ofrecen visiones lgicas ms elaboradas, orientadas
a registros, que pueden ser de longitud fija o variable. La ventaja de la sencilla visin de vector de caracteres
es su flexibilidad, puesto que no presupone ninguna estructura especfica interna en el fichero.
La visin lgica del fichero incluye normalmente un puntero de posicin. Este puntero permite hacer
operaciones de lectura y escritura consecutivas sin tener que indicar la posicin dentro del fichero. Inicial
mente el puntero indica la posicin 0, pero despus de hacer, por ejemplo, una operacin de lectura de 7845
bytes sealar a la posicin 7845. Otra lectura posterior se referir a los bytes 7845,7846, etc.
La visin fsica est formada por los elementos fsicos del perifrico que almacenan el fichero. En el
caso ms usual de tratarse de discos, la visin fsica consiste en la enumeracin ordenada de los bloques de
disco en los que reside el fichero. El servidor de ficheros debe mantener esta informacin en una estructura
que se denominar, de forma genrica, descripcin fsica del fichero. La descripcin fsica reside en la FAT
en MS-DOS, en el registro MFT en Windows y en el nodo-i en UNIX. Finalmente, es de destacar que estas
estructuras de informacin han de residir en el propio perifrico (p. ej.: disco), para que ste sea autocontenido y se pueda transportar de un sistema a otro. El servidor de ficheros es capaz de encontrar e interpretar es
tas estructuras de informacin, liberando a los programas de usuario de estos detalles.
El servidor de ficheros ofrece una visin lgica similar a la de un fichero, pero sin incluir puntero de
V e c to r de c a ra c te re s o bytes
Figura 2.16 Visin lgica del fichero.
53
posicin, para perifricos tales como terminales, controladores de red, impresoras, etc. Se emplea el trmino
de fichero especial, para diferenciarlos de los ficheros almacenados en disco o cinta magntica.
Servicios de ficheros
Un fichero es una entidad viva, que va evolucionando de acuerdo a los servicios que se solicitan sobre el
mismo. Las fases de esta vida son las siguientes:
Se crea el fichero.
Se abre el fichero para su uso (se genera un descriptor de fichero).
- Se lee y escribe (el fichero puede crecer).
Se cierra el fichero.
Se borra el fichero.
Los servicios que ofrece el servidor de ficheros son los siguientes:
Abrir un fichero. Un fichero debe ser abierto antes de ser utilizado. Este servicio comprueba que el
fichero existe, que el usuario tiene derechos de acceso y trae a memoria informacin del mismo para
optimizar su acceso, creando en memoria el puntero de posicin. Adems, devuelve al usuario un
identificador, descriptor o manejador de fichero de carcter temporal para su manipulacin. Nor
malmente, todos los sistemas operativos tienen un lmite mximo para el nmero de ficheros que
puede tener abierto un usuario. Ejemplos: o p e n y c r e a t en UNIX y C r e a t e F i l e en Windows.
Leer. La operacin de lectura permite traer datos del fichero a memoria. Para ello, se especifica el
descriptor de fichero obtenido en la apertura, la posicin de memoria para los datos y la cantidad de
informacin a leer. Normalmente, se lee a partir de la posicin que indica el puntero de posicin del
fichero. Ejemplos: read en UNIX y ReadFile en Windows.
Escribir. Las operaciones de escritura permiten llevar datos situados en memoria al fichero. Para
ello, y al igual que en las operaciones de lectura, se debe especificar el descriptor obtenido en la
creacin o apertura, la posicin en memoria de los datos y la cantidad de informacin a escribir.
Normalmente se escribe a partir de la posicin que indica el puntero de posicin del fichero. Si apun
ta dentro del fichero, se sobrescribirn los datos, no se aadirn. Si apunta al final del fichero se aa
den los datos aumentando el tamao del fichero. En este caso, el sistema operativo se encarga de
hacer crecer el espacio fsico del fichero aadiendo agrupaciones libres (si es que las hay). Ejemplos:
write en UNIX y WriteFile en Windows.
Posicionar el puntero. Sirve para especificar la posicin del fichero en la que se realizar la siguien
te lectura o escritura. Ejemplos: l s e e k en UNIX y S e t F i l e P o i n t e r en Windows.
Cerrar un fichero. Terminada la utilizacin del fichero se debe cerrar, con lo que se elimina el des
criptor temporal obtenido en la apertura o. creacin y se liberan los recursos de memoria que ocupa el
fichero. Ejemplos: c i s e en UNIX y C lo s e H a n d le en Windows.
Crear un fichero. Este servicio crea un fichero vaco. La creacin de un fichero exige una interpre
tacin del nombre, puesto que el servidor de ficheros ha de comprobar que el nombre es correcto y
que el usuario tiene permisos para hacer la operacin solicitada. La creacin de un fichero lo deja
abierto para escritura, devolviendo al usuario un identificador, descriptor o manejador de fichero de
carcter temporal para su manipulacin. Ejemplos: c r e a t en UNIX y C r e a t e F i l e en Windows.
Borrar un fichero. El fichero se puede borrar, lo que supone que se borra su nombre del correspon
diente directorio y que el sistema de ficheros ha de recuperar los bloques de datos y el espacio de
descripcin fsica que tena asignado. Ejemplos: u n l i n k en UNIX y D e l e t e F i l e en Windows.
Se puede observar que el nombre del fichero se utiliza en los servicios de creacin y de apertura. Am
bos servicios dejan el fichero abierto y devuelven un descriptor de fichero. Los servicios para leer, escribir,
posicionar el puntero y cerrar el fichero se basan en este descriptor y no en el nombre. Este descriptor es sim
plemente una referencia interna que mantiene el sistema operativo para trabajar eficientemente con el fichero
abierto. Dado que un proceso puede abrir varios ficheros, el sistema operativo mantiene una tabla de des-
54
criptores de fichero abiertos por cada proceso. Adems, todo proceso dispone, al menos, de tres elementos
en dicha tabla, que reciben el nombre de estndar, y ms concretamente de entrada estndar, salida estn
dar y error estndar. En un proceso interactivo la salida y error estndar estn asignadas a la pantalla del
terminal, mientras que la entrada estndar lo est al teclado. El proceso, por tanto, se comunica con el usuario
a travs de las entradas y salidas estndar. Por el contrario, un proceso que ejecuta en lotes tendr los descrip
tores estndar asignados a ficheros.
Se denomina redireccin a la accin de cambiar la asignacin de un descriptor estndar.
Varios procesos pueden tener abierto y, por tanto, pueden utilizar simultneamente el mismo fichero,
por ejemplo, varios usuarios pueden estar leyendo la misma pgina de ayuda. Esto plantea un problema de
coutilizacin del fichero, que se tratar en detalle en el captulo 9 Gestin de ficheros y directorios.
Servicios de directorios
Un directorio es un objeto que relaciona de forma unvoca un nombre con un fichero. El servicio de directo
rios sirve para identificar a los ficheros (objetos), por lo tanto, ha de garantizar que la relacin [nombre >
fichero] sea unvoca. Es decir, un mismo nombre no puede identificar a dos ficheros. Por el contrario, que un
fichero tenga varios nombres no presenta ningn problema, son simples sinnimos.
El servicio de directorios tambin presenta una visin lgica y una visin fsica. La visin lgica con
siste, habitualmente, en el bien conocido esquema jerrquico de nombres mostrado en la figura 2.17.
Se denomina directorio raz al primer directorio de la jerarqua, recibiendo los dems el nombre de
subdirectorios o directorios. El directorio raz se representa por el carcter / o \, dependiendo del sistema
operativo. En la figura 2.17, el directorio raz incluye los siguientes nombres de subdirectorios: T e x t o s ,
D i v l l y D iv 2 .
Se diferencia el nombre local, que es el nombre asignando al fichero dentro del subdirectorio en el que
est el fichero, del nombre o camino absoluto, que incluye todos los nombres de todos los subdirectorios
que hay que recorrer desde el directorio raz hasta el objeto considerado, concatenados por el smbolo / o
\. Un ejemplo de nombre relativo es Arll, mientras que su nombre absoluto es
/Textos/Tiro/Secl/Arll.
El sistema operativo mantiene un directorio de trabajo para cada proceso y un directorio home para ca
da usuario. El directorio de trabajo especifica un punto en el rbol que puede utilizar el proceso para definir
ficheros sin ms que especificar el nombre local desde ese punto. Por ejemplo, si el directorio de trabajo es
/Textos/Tiro/, para nombrar el fichero A rll basta con poner Secl/Arll. El sistema operativo
incluye servicios para cambiar el directorio de trabajo. El directorio home es el directorio asignado a un
usuario para su uso. Es donde ir creando sus subdirectorios y ficheros.
La ventaja del esquema jerrquico es que permite una gestin distribuida de los nombres, al garantizar
de forma sencilla que no existan nombres repetidos. En efecto, basta con que los nombres locales de cada
subdirectorio sean distintos entre s. Aunque los nombres locales de dos subdirectorios distintos coincidan, su
nombre absoluto ser distinto (p. ej.: / T e x t o s / T i r o / S e c l y / D i v 2 / P r o d u c / S e c l )
La visin fsica del sistema de directorios se basa en unas estructuras de informacin que permiten re
lacionar cada nombre lgico con la descripcin fsica del correspondiente fichero. En esencia, se trata de una
tabla NOMBRE-IDENTIFICADOR por cada subdirectorio, tabla que se almacena, a su vez, como un ficheDirectorio raz
[textos | Div11 | Div2
Edit | Tiro I Distrib I |Person| C lient I
7)
V 7)
Producf Alm ac | Simin | M ant I
>
...
Sec1 | Sec2 [ Sec3 ]
Arll | Arl2 | Arl3 | | Des |

'
Figura 2.17 Esquema jerrquico de directorios.
| PR1 | PR2 | PR3

"
Activ | Paslv I
i Identificador
I de directorio
|---------- Identificador
'---------- ' de fichero
55
ro. El NOMBRE no es ms que el nombre local del fichero, mientras que el IDENTIFICADOR es una in
fo r m a c i n que permite localizar la descripcin fsica del fichero.
Servicios de directorios
Un objeto directorio es bsicamente una tabla que relaciona nombres con ficheros. El servidor de ficheros
incluye una serie de servicios que permiten manipular directorios. Estos son:
Crear un directorio. Crea un objeto directorio y lo sita en el rbol de directorios. Ejemplos:
mkdir en UNIX y CreateDirectory en Windows.
Borrar un directorio. Elimina un objeto directorio, de forma que nunca ms pueda ser accesible, y
borra su entrada del rbol de directorios. Normalmente, slo se puede borrar un directorio vaco, es
decir, un directorio sin entradas. Ejemplos: rmdir en UNIX y RemoveDirectory en Windows.
Abrir un directorio. Abre un directorio para leer los datos del mismo. Al igual que un fichero, un
directorio debe ser abierto para poder acceder a su contenido. Esta operacin devuelve al usuario un
identificador, descriptor o manejador de directorio de carcter temporal que permite su manipula
cin. Ejemplos: opendir en UNIX y FindFirstFile en Windows.
Leer un directorio. Extrae la siguiente entrada de un directorio abierto previamente. Devuelve una
estructura de datos como la que define la entrada de directorios. Ejemplos: r e a d d i r en UNIX y
F in d N e x t F il e en Windows.
Cambiar el directorio de trabajo. Cambia el directorio de trabajo del proceso. Ejemplos chdir en
UNIX y SetCurrentDirectory en Windows.
Cerrar un directorio. Cierra un directorio, liberando el identificador devuelto en la operacin de
apertura, as como los recursos de memoria y del sistema operativo relativos al mismo. Ejemplos:
c l o s e d i r en UNIX y F in d C lo s e en Windows.
En el captulo 9 Gestin de ficheros y directorios se estudiar en detalle la gestin de ficheros y direc
torios, presentando los conceptos, los servicios y los principales aspectos de implementacin.
2.6.
SEGURIDAD Y PROTECCIN
La seguridad es uno de los elementos fundamentales en el diseo de los sistemas operativos de propsito
general. La seguridad tiene por objetivo evitar la prdida de bienes (datos o equipamiento) y controlar el uso
de los mismos (privacidad de los datos y utilizacin de equipamiento). El captulo 11 Seguridad y protec
cin desarrolla con detalle la seguridad y proteccin del sistema informtico.
El sistema operativo est dotado de unos mecanismos y polticas de proteccin con los que se trata de
evitar que se haga un uso indebido de los recursos del computador. La proteccin reviste dos aspectos: garan
tizar la identidad de los usuarios y definir lo que puede hacer cada uno de ellos. El primer aspecto se trata
bajo el trmino de autenticacin, mientras que el segundo se hace mediante los privilegios.
Autenticacin
El objetivo de la autenticacin es determinar que un usuario (persona, servicio o proceso) es quien dice ser.
El sistema operativo dispone de un mdulo de autenticacin que se encarga de validar la identidad de los
usuarios. La contrasea (password) es, actualmente, el mtodo de autenticacin ms utilizado.
Privilegios
Los privilegios especifican las operaciones que puede hacer un usuario sobre cada recurso. Para simplificar la
informacin de privilegios es corriente organizar los usuarios en grupos y asignar los mismos privilegios a
los componentes de cada grupo. La informacin de los privilegios se puede asociar a los recursos o a los
usuarios.
56
Informacin por recurso. En este caso se asocia una lista, denominada lista de control de acceso o
ACL (Access Control List), a cada recurso. Esta lista especifica los grupos y usuarios que pueden ac
ceder al recurso.
Informacin por usuario. Se asocia a cada usuario, o grupo de usuarios, la lista de recursos que
puede acceder, lista que se llama de capacidades (capabilities).
Dado que hay muchas formas de utilizar un recurso, la lista de control de acceso, o la de capacidades,
ha de incluir el modo en que se puede utilizar el recurso. Ejemplos de modos de utilizacin son: leer, escribir,
ejecutar, eliminar, test, control y administrar.
En su faceta de mquina extendida, el sistema operativo siempre comprueba, antes de realizar un servi
cio, que el proceso que lo solicita tiene los permisos adecuados para realizar la operacin solicitada sobre el
recurso solicitado.
Para llevar a cabo su funcin de proteccin, el sistema operativo ha de apoyarse en mecanismos hard
ware que supervisen la ejecucin de los programas, entendiendo como tal a la funcin de vigilancia que hay
que realizar sobre cada instruccin mquina que ejecuta el proceso de usuario. Esta vigilancia solamente la
puede hacer el hardware, dado que mientras ejecuta el proceso de usuario el sistema operativo no est ejecu
tando, est dormido, y consiste en comprobar que cada cdigo de operacin es permitido y que cada direc
cin de memoria y el tipo de acceso estn tambin permitidos.
2.7.
INTERFAZ DE PROGRAMACIN
La interfaz de programacin o API que ofrece un sistema operativo es una de sus caractersticas ms impor
tantes, ya que define la visin de mquina extendida que tiene el programador del mismo. En este libro se
presentan dos de las interfaces ms utilizadas en la actualidad: UNIX y Windows.
Actualmente, una gran cantidad de aplicaciones utilizan la codificacin Unicode, por lo que los siste
mas operativos tambin soportan este tipo de codificacin. Sin embargo, esta codificacin no aporta ningn
concepto adicional desde el punto de vista de los sistemas operativos, por lo que, para simplificar, los ejem
plos presentados en el presente libro no soportan Unicode.
2.7.1. Single UNIX Specification

La definicin de UNIX ha ido evolucionando a lo largo de sus 30 aos de existencia, siendo el estndar ac
tual el Single UNIX Specification UNIX 03 mantenido por un equipo (llamado el Austin Group) forma
do por miembros de IEEE Portable Applications Standards Committee, miembros de The Open Group y
miembros de ISO/DEC Joint Technical Committee 1. Este estndar engloba los estndares anteriores XPG4
de X/Open, POSD del IEEE y C de ISO.
Aclaracin 2.2. UNIX 03 es una especificacin estndar, no define una implementacin. Los distintos sistemas operativos pueden ofrecer los servicios UNIX con diferentes implementaciones.______________________
La parte bsica del estndar Single UNIX Specification UNIX 03 se divide en los siguientes docu
mentos:
Base Definitions (XBD). Incluye una serie de definiciones comunes a los dems documentos, por
lo que es necesario conocerlo antes de abordar los otros documentos.
System Interfaces (XSH). Describe una serie de servicios ofrecidos a los programas de aplicacin.
Shell and Utilities (XCU). Describe el intrprete de mandatos (shell) y las utilidades disponibles a
los programas de aplicacin.
Rationale (XRAT). Este documento es una ayuda para entender el resto del estndar.
59
Comunicacin con otros sistemas. Existirn herramientas para acceder a recursos localizados en
otros sistemas accesibles a travs de una red de conexin. En esta categora se consideran herramien
tas bsicas, tales como f t p y t e l n e t (aclaracin 2.3), dejando fuera aplicaciones de ms alto nivel
como un navegador web.
Informacin de estado del sistema. El usuario dispondr de utilidades para obtener informaciones ta
les como la fecha, la hora, el nmero de usuarios que estn trabajando en el sistema o la cantidad de
memoria disponible.
Configuracin de la propia interfaz y del entorno. Cada usuario tiene que poder configurar el modo
de operacin de la interfaz de acuerdo a sus preferencias. Un ejemplo sera la configuracin de los
aspectos relacionados con las caractersticas especficas del entorno geogrfico del usuario (el idio
ma, el formato de fechas, de nmeros y de dinero, etc.). La flexibilidad de configuracin de la inter
faz ser una de las medidas que exprese su calidad.
Intercambio de datos entre aplicaciones. El usuario va a disponer de mecanismos que le permitan es
pecificar que, por ejemplo, una aplicacin utilice los datos que genera otra.
Control de acceso. En sistemas multiusuario, la interfaz debe encargarse de controlar el acceso de los
usuarios al sistema para mantener la seguridad del mismo. Normalmente, el mecanismo de control
estar basado en que cada usuario autorizado tenga una contrasea que deba introducir para acceder
al sistema.
Sistema de ayuda interactivo. La interfaz debe incluir un completo entorno de ayuda que ponga a
disposicin del usuario toda la documentacin del sistema.
Copia de datos entre aplicaciones. Al usuario se le proporciona un mecanismo del tipo copiar y pegar
(copy-and-paste) para poder pasar informacin de una aplicacin a otra.
Aclaracin 2.3. La aplicacin f t p (file transfer proiocol) permite transferir ficheros entre computadores
conectadas por una red de conexin. La aplicacin t e l n e t permite a los usuarios acceder a computadores
remotas, de tal manera que el computador en la que se ejecuta la aplicacin t e l n e t se convierte en un trminal del computador remoto.
' : :
;
v
, . :
Para concluir esta seccin, es importante resaltar que en un sistema, adems de las interfaces disponi
bles para los usuarios normales, pueden existir otras especficas destinadas a los administradores del sistema.
Ms an, el propio programa (residente normalmente en ROM) que se ocupa de la carga del sistema operati
vo proporciona generalmente una interfaz de usuario muy simplificada y rgida que permite al administrador
realizar operaciones tales como pruebas y diagnsticos del hardware o la modificacin de los parmetros
almacenados en la memoria no voltil de la mquina que controlan caractersticas de bajo nivel del sistema.
2.8.2. Interfaces alfanumricas

La caracterstica principal de este tipo de interfaces es su modo de trabajo basado en lneas de texto. El usua
rio, para dar instrucciones al sistema, escribe en su terminal un mandato terminado con un carcter de final de
lnea. Cada mandato est normalmente estructurado como un nombre de mandato (por ejemplo, borrar) y
unos argumentos (por ejemplo, el nombre del fichero que se quiere borrar). Observe que en algunos sistemas
se permite que se introduzcan varios mandatos en una lnea. El intrprete de mandatos lee la lnea escrita por
el usuario y lleva a cabo las acciones especificadas por la misma. Una vez realizadas, el intrprete escribe una
indicacin (prompt) en el terminal para notificar al usuario que est listo para recibir otro mandato. Este ciclo
repetitivo define el modo de operacin de este tipo de interfaces.
El carcter | se utiliza para enlazar mandatos mediante tuberas (mandato 1 | mandato2). El shell crea
un proceso por mandato y los une mediante tina tubera, de forma que la salida estndar del primero queda
conectada a la entrada estndar del segundo: lo que escribe el primero por su salida es lo que lee el segundo
por su entrada. Por otro lado, los caracteres < y > se utilizan para redirigir la entrada y salida estndar,
respectivamente, es decir, para cambiar el fichero o fichero especial al que estn asignadas.
Esta forma de operar, basada en lneas de texto, viene condicionada en parte por el tipo de dispositivo
que se usaba como terminal en los primeros sistemas de tiempo compartido. Se trataba de teletipos que im
66
2.9.
DISEO DE LOS SISTEMAS OPERATIVOS
^^2.9.1. Estructura del sistema operativo

Un sistema operativo es un programa extenso y complejo que est compuesto, como se ha visto en las sec
ciones anteriores, por una serie de componentes con fiinciones bien definidas. Cada sistema operativo estruc
tura estos componentes de distinta forma. Los sistemas operativos se pueden clasificar, de acuerda a su
estructura, en sistemas operativos monolticos^ sistemas operativos estructurados.
Analizaremos en esta seccin estas dos alternativas, as como la estructura de las mquinas virtuales y
de los sistemas distribuidos.
Sistemas operativos monolticos
Un sistema operativo monoltico no tiene una estructura clara y bien definida. Todos sus componentes se
encuentran integrados en un nico programa (el sistema operativo) que ejecuta en un nico espacio de direc
ciones. Adems, todas las funciones que ofrece se ejecutan en modo privilegiado.
Ejemplos claros de este tipo de sistemas son el OS-360, el MS-DOS y el UNIX Estos dos ltimos co
menzaron siendo pequeos sistemas operativos, que fueron hacindose cada vez ms grandes, debido a la
gran popularidad que adquirieron.
El problema que plantea este tipo de sistema radica en lo complicado que es modificarlos para aadir
nuevas funcionalidades y servicios. En efecto, aadir una nueva caracterstica al sistema operativo implica la
modificacin de un gran programa, compuesto por miles o millones de lneas de cdigo fuente y de infinidad
de funciones, cada una de las cuales puede invocar a otras cuando as los requiera. Adems, en este tipo de
sistemas no se sigue el principio de ocultacin de la informacin. Para solucionar estos problemas es necesa
rio dotar de cierta estructura al sistema operativo.
Sistemas operativos estructurados.
Cuando se quiere dotar de estructura a un sistema operativo, normalmente se recurren a dos tipos de solucio
nes: sistemas por capas y sistemas cliente-servidor.
Sistemas p o r capas
En un sistema por capas, el sistema operativo se organiza como una jerarqua de capas, donde cada capa
ofrece una interfaz clara y bien definida a la capa superior y solamente utiliza los servicios que le ofrece la
capa inferior.
La principal ventaja que ofrece este tipo de estructura es la modularidad y la ocultacin de la informa
cin. Una capa no necesita conocer cmo se ha implementado la capa sobre la que se construye, nicamente
necesita conocer la interfaz que sta ofrece. Esto facilita enormemente la depuracin y verificacin del siste
ma, puesto que las capas se pueden ir construyendo y depurando por separado.
Este enfoque lo utiliz por primera vez el sistema operativo THE, un sistema operativo sencillo forma
do por seis capas, como se muestra en la figura 2.18. Otro ejemplo de sistema operativo diseado por capas
fue el OS/2, descendiente de MS-DOS.
_________ Capa 5: Programas de usuario_________

___________ Capa 4: Gestin de la E/S___________
________ Capa 3: Controlador de la consola________
__________ Capa 2: Gestin de memoria _________
Capa 1: Planificacin de la CPU y multiprogramacin
_______________ Capa 0: hardware_______________
Figura 2.18 Estructura p or capas del sistema operativo THE.
67
Modelo cliente-servidor
En este tipo de modelo, el enfoque consiste en implementar la mayor parte de los servicios y funciones del
sistema operativo para que ejecute como procesos en modo usuario, dejando slo una pequea parte del sis
tema operativo ejecutando en modo privilegiado. Esta parte se denomina microncleo y los procesos que
ejecutan el resto de funciones se denominan seryidores. Cuando se lleva al extremo esta idea se habla de nanoncleo. La figura 2.19 presenta la estructura de un sistema operativo con estructura cliente-servidor. Como
puede apreciarse en la figura, el sistema operativo est formado por diversos mdulos, cada uno de los cuales
puede desarrollarse por separado.
No hay una definicin clara de las funciones que debe llevar a cabo un microncleo. La mayora inclu
yen la gestin de interrupciones, gestin bsica de procesos y de memoria, y servicios bsicos de comunica
cin entre procesos. Para solicitar un servicio en este tipo de sistema, como por ejemplo crear un proceso, el
proceso de usuario (proceso denominado cliente) solicita el servicio al servidor del sistema operativo corres
pondiente, en este caso al servidor de procesos. A su vez, el proceso servidor puede requerir los servicios de
otros servidores, como es el caso del servidor de memoria. En este caso, el servidor de procesos se convierte
en cliente del servidor de memoria.
Una ventaja de este modelo es la gran flexibilidad que presenta. Cada proceso servidor slo se ocupa de
una funcionalidad concreta, lo que hace que cada parte pueda ser pequea y manejable. Esto a su vez facilita
el desarrollo y depuracin de cada uno de los procesos servidores. Por otro lado, al ejecutar los servicios en
espacios separados aumenta la fiabilidad del conjunto, puesto que un fallo solamente afecta a un mdulo.
En cuanto a las desventajas, citar que estos sistemas presentan una mayor sobrecarga en el tratamiento
de los servicios que los sistemas monolticos. Esto se debe a que los distintos componentes de un sistema
operativo de este tipo ejecutan en espacios de direcciones distintos, lo que hace que su activacin requiera
mayor tiempo.
Minix, Mach, Amoeba y Mac OS X, son ejemplos de sistemas operativos que siguen este modelo.
Windows NT tambin sigue esta filosofa de diseo, aunque muchos de los servidores (el gestor de procesos,
gestor de E/S, gestor de memoria, etc.) se ejecutan en modo privilegiado por razones de eficiencia (vase la
figura 2 .20 ).
Mquina virtual
E conceptcT de mquina virtual se basa en un monitor capaz de suministrar m versiones del hardware, es
decir m mquinas virtuales. Cada copia es una rplica exacta del hardware, incluso con modo privilegiado y
modo usuario, por lo que sobre cada una de ellas se puede instalar un sistema operativo convencional. Como
muestra la figura 2 .21 , una peticin de servicio es atendida por la copia de sistema operativo sobre la que
ejecuta. Cuando dicho sistema operativo desea acceder al hardware, por ejemplo, para leer de un perifrico,
se comunica con su mquina virtual, como si de una mquina real se tratase. Sin embargo, con quien se est
comunicando es con el monitor de mquina virtual que es el nico que accede a la mquina real.
El ejemplo ms relevantes de mquina virtual es el VM/370, que genera m copias de la arquitectura
EBM370.
Otra forma distinta de construir una mquina virtual es la mostrada en la figura 2.22. En este caso, el
monitor de mquina virtual no ejecuta directamente sobre el hardware, por el contrario, lo hace sobre un sis
tema operativo.
La mquina virtual generada puede ser una copia exacta del hardware real, como es el caso del VMware, que genera una copia virtual de la arquitectura Pentium, o puede ser una mquina distinta como es el caso
de la mquina virtual de Java (JVM Java Virtual Machine) o la CLI (Common Language Injrastructure) inP ro ce s o s clie n te
P r o g ra m a
de u s u a rio
P r o g ra m a
d e u s u a rio
API
API
P ro c e s o s s e rv id o r
Servidor de
procesos
Servidor de
memoria
Servidor de
la E/S
Servidor de
ficharos y
directorios
M ic ro n c le o
H ard w a re
Figura 2.19 Estructura cliente-servidor en un sistema operativo.
Servidor de
Seguridad
Servidor
de
Com unicac.
Modo
usuario
Modo
privilegiado
68
Figura 2.20 Estructura del sistema operativo Windows NT.

To
8
QSO 1
CM
8
8
CL
c
o
8
L
Llamada al sistema
Salta al SO
SO 2
SO m
Instrucciones de E/S
Monitor de mquina virtual
Salta al monitor de
mquina virtual
Hardware
Figura 2.21 Esquema de mquina virtual soportando varios sistemas operativos.

cluida en Microsoft.NET.
Las ventajas e inconvenientes de la mquina virtual son los siguientes:
Aade un nivel de multiprogramacin, puesto que cada mquina virtual ejecuta sus propios procesos.
IBM introdujo de esta forma la multiprogramacin en sus sistemas 370.
Aade un nivel adicional de aislamiento, de forma que si se compromete la seguridad en un sistema
operativo no se compromete en los dems. Esta funcionalidad puede ser muy importante cuando se
estn haciendo pruebas.
Si lo que se genera es una mquina estndar, como es el caso de JVM o CLI, se consigue tener una
plataforma de ejecucin independiente del hardware, por lo que no hay que recompilai los progra
mas para pasar de un computador a otro.
Tiene el inconveniente de aadir una sobrecarga computacional, lo que puede hacer ms lenta la eje-
SO 2
SO 1
Monitor de
mquina virtual
Hardware
Figura 2.22 Esquema de mquina virtual sobre sistema operativo.
69
cucin.
En algunos diseos se incluye una capa, llamada exokernel, que ejecuta en modo privilegiado y que se
encarga de asignar recursos a las mquinas virtuales y de garantizar que ninguna mquina utilice recursos de
otra.
Por otro lado, dada la importancia que est tomando el tema de las mquinas virtuales, algunos fabri
cantes de procesadores estn incluyendo mecanismos hardware, tales como modos especiales de ejecucin,
para facilitar la construccin de las mismas.
Sistema operativo distribuido
tTrssfmi operativo distribuido es un sistema operativo diseado para gestionar un multicomputador, como
muestra la figura 2.23. El usuario percibe un nico sistema operativo centralizado, haciendo, por tanto, ms
fcil el uso de la mquina. Un sistema operativo de este tipo sigue teniendo las mismas caractersticas que un
sistema operativo convencional pero aplicadas a un sistema distribuido. Estos sistemas no han tenido xito
comercial y se han quedado en la fase experimental.
Middleware
Un middleware es una capa de software que se ejecuta sobre un sistema operativo ya existente y que se en
carga de gestionar un sistema distribuido o un multicomputador, como muestra la figura 2.24. En este senti
do, presenta una funcionalidad similar a la de un sistema operativo distribuido. La diferencia es que ejecuta
sobre sistemas operativos ya existentes que pueden ser, adems, distintos, lo que hace ms atractiva su utili
zacin. Como ejemplos de middleware se puede citar: DCE, DCOM, COM+ y Java RM3.
2.9.2. Carga dinmica de mdulos

En los sistemas operativos convencionales su configuracin tena que incluir la definicin de todos los ele
mentos hardware del sistema y de todos los mdulos software. Cualquier cambio en estos elementos hard
ware o mdulos software exiga la configuracin y rearranque del sistema operativo. En este sentido, se
puede decir que la configuracin era esttica.
Con el desarrollo de los buses con capacidad de conexionado en caliente (esto es sin apagar el sistema),
como son el bus USB el bus PCMCIA o el bus Firewire, aparece la necesidad de la carga dinmica de mdu
los del sistema operativo. En efecto, al conectar un nuevo perifrico es necesario cargar los mdulos del sis
tema operativo que le dan servicio y dar de alta a dicho recurso para poder ser utilizado por los procesos. Una
situacin parecida puede producirse al instalarse un nuevo software. Todo ello da lugar a la configuracin
dinmica del sistema operativo.
Programas
Sistema operativo distribuido
Hardware
~
Hardware
;___ i.............................................. l
|____________ Red de Interconexin____________
Figura 2.23 Estructura de un sistema operativo distribuido.
Programas
Sistema operativo
Hardware
1
Red de interconexin
Figura 2.24 Estructura de un middleware.
72
por ejemplo, existir un gestor de ventanas para mantener el estado de las mismas y permitir su manipula
cin, un administrador de programas que permita al usuario arrancar aplicaciones, un gestor de ficheros
que permita manipular ficheros y directorios, o una herramienta de configuracin de la propia interfaz y
del entorno. Observe la diferencia con las interfaces alfanumricas, en las que exista un programa por cada
mandato.
2.10. HISTORIA DE LOS SISTEMAS OPERATIVOS

Como se deca al comienzo del captulo, el sistema operativo lo forman un conjunto de programas que ayu
dan a los usuarios en la explotacin de un computador, simplificando, por un lado, su uso, y permitiendo, por
otro, obtener un buen rendimiento de la mquina. Es difcil tratar de dar una definicin precisa de sistema
operativo, puesto que existen muchos tipos, segn sea la aplicacin deseada, el tamao del computador usado
y el nfasis que se d a su explotacin. Por ello, se va a realizar un bosquejo de la evolucin histrica de los
sistemas operativos, ya que as quedar plasmada la finalidad que se les ha ido atribuyendo.
Se pueden encontrar las siguientes etapas en el desarrollo de los sistemas operativos, que coinciden con
las cuatro generaciones de los computadores.
Prehistoria
Durante esta etapa, que cubre los aos cuarenta, se construyen los primeros computadores. Como ejemplo de
computadores de esta poca se pueden citar el ENIAC (Electronic Numerical Integrator Analyzer and Com
puter) financiado por el Laboratorio de Investigacin Balstica de los Estados Unidos. El ENIAC era una
mquina enorme con un peso de 30 toneladas, que era capaz de realizar 5.000 sumas por segundo, 457 multi
plicaciones por segundo y 38 divisiones por segundo. Otro computador de esta poca fue el EDVAC (.Elec
tronic Discrete Variable Automatic Computer).
En esta etapa no existan sistemas operativos. El usuario deba codificar su programa a mano y en ins
trucciones mquina, y deba introducirlo personalmente en el computador, mediante conmutadores o taijetas
perforadas. Las salidas se impriman o se perforaban en cinta de papel para su posterior impresin. En caso
de errores en la ejecucin de los programas, el usuario tena que depurarlos examinando el contenido de la
memoria y los registros del computador.
En esta primera etapa todos los trabajos se realizaban en serie. Se introduca un programa en el compu
tador, se ejecutaba y se impriman los resultados. A continuacin, se repeta este proceso con otro programa.
Otro aspecto importante de esta poca es que se requera mucho tiempo para preparar y ejecutar un programa,
ya que el programador deba encargarse de todo: tanto de codificar todo el programa como de introducirlo en
el computador de forma manual y de ejecutarlo.
Primera generacin (aos cincuenta)
Con la aparicin de la primera generacin de computadores (aos cincuenta), se hace necesario racionalizar
su explotacin, puesto que ya empieza a haber una mayor base de usuarios. El tipo de operacin segua sien
do en serie, como en el caso anterior, esto es, se trataba un trabajo detrs de otro, teniendo cada trabajo las
fases siguientes:
Instalacin de cintas o fichas perforadas en los dispositivos perifricos. En su caso, instalacin del
papel en la impresora.
Lectura mediante un programa cargador del programa a ejecutar y de sus datos.
Ejecucin del programa.
Impresin o grabacin de los resultados.
Retirada de cintas, fichas y papel.
La realizacin de la primera fase se denominaba montar el trabajo.
El problema bsico que abordaban estos sistemas operativos primitivos era optimizar el flujo de traba
jos, minimizando el tiempo empleado en retirar un trabajo y montar el siguiente. .Tambin empezaron a abor
73
dar el problema de la E/S, facilitando al usuario paquetes de rutinas de E/S, para simplificar la programacin
de estas operaciones, apareciendo as los primeros manejadores de dispositivos. Se introdujo tambin el
concepto de system file ame que empleaba un nombre o nmero simblico para referirse a los perifricos,
haciendo que su manipulacin fiiera mucho ms flexible que mediante las direcciones fsicas.
Para minimizar el tiempo de montaje de los trabajos, estos se agrupaban en lotes (batch) del mismo tipo
(p. ej.: programas Fortran, programas Cobol, etc.), lo que evitaba tener que montar y desmontar las cintas de
los compiladores y montadores, aumentando el rendimiento.
En las grandes instalaciones se utilizaban computadores auxiliares o satlites para realizar las funciones
de montar y retirar los trabajos. As se mejoraba el rendimiento del computador principal, puesto que se le
suministraban los trabajos montados en cinta magntica y sta se limitaba a procesarlos y a grabar los resul
tados tambin en cinta magntica. En este caso se deca que la E/S se haca fuera de lnea (off-line).
Los sistemas operativos de las grandes instalaciones teman las siguientes caractersticas:
Procesaban un nico flujo de trabajos en lotes.

Disponan de un conjunto de rutinas de E/S.
Usaban mecanismos rpidos para pasar de un trabajo al siguiente.
Permitan la recuperacin del sistema si un trabajo acababa en error.
Tenan un lenguaje de control de trabajos denominado JCL (Job Conti-ol Language). Las instrucciones
JCL formaban la cabecera del trabajo y especificaban los recursos a utilizar y las operaciones a realizar por
cada trabajo.
Como ejemplos de sistemas operativos de esta poca se pueden citar el FMS (Fortran Monitor System),
el IBYSS y el sistema operativo de la IBM 7094.
Segunda generacin (aos sesenta)
Con la aparicin de la segunda generacin de computadores (principios de los sesenta), se hizo ms necesa
rio, dada la mayor competencia entre los fabricantes, mejorar la explotacin de estas mquinas de altos pre
cios. La multiprogramacin se impuso en sistemas de lotes como una forma de aprovechar el tiempo
empleado en las operaciones de E/S. La base de estos sistemas reside en la gran diferencia que existe, como
se vio en el captulo 1, entre las velocidades de los perifricos y de la UCP, por lo que esta ltima, en las ope
raciones de E/S, se pasa mucho tiempo esperando a los perifricos. Una forma de aprovechar ese tiempo con
siste en mantener varios trabajos simultneamente en memoria principal (tcnica llamada de
multiprogramacin), y en realizar las operaciones de E/S por acceso directo a memoria. Cuando un trabajo
necesita una operacin de E/S la solicita al sistema operativo que se encarga de:
Congelar el trabajo solicitante.
Iniciar la mencionada operacin de E/S por DMA.
Pasar a realizar otro trabajo residente en memoria. Estas operaciones las realiza el sistema operativo
multiprogramado de forma transparente al usuario.
Tambin en esta poca aparecieron otros modos de funcionamiento muy importantes:
Se construyeron los primeros multiprocesadores, en los que varios procesadores formaban una sola
mquina de mayores prestaciones.
Surgi el concepto de servicio del sistema operativo, siendo el sistema operativo Atlas I Supervisor
de la Universidad de Manchester el primero en utilizarlo.
Se introdujo el concepto de independencia de dispositivo. El usuario ya no tena que referirse en
sus programas a una unidad de cinta magntica o a una impresora en concreto. Se limitaba a especi
ficar que quera grabar un fichero determinado o imprimir unos resultados. El sistema operativo se
encargaba de asignarle, de forma dinmica, una unidad disponible, y de indicar al operador del sis
tema la unidad seleccionada, para que ste montara la cinta o el papel correspondiente.
Comenzaron los sistemas de tiempo compartido o timesharing. Estos sistemas, a los que estamos
muy acostumbrados en la actualidad, permiten que varios usuarios trabajen de forma interactiva o
conversacional con el computador desde terminales, que en aquellos das eran teletipos electro
mecnicos. El sistema operativo se encarga de repartir el tiempo de la UCP entre los distintos usua-
74
nos, asignando de forma rotativa pequeos intervalos de tiempo de UCP denominadas rodajas (time
slice). En sistemas bien dimensionados, cada usuario tiene la impresin de que el computador le
atiende exclusivamente a l, respondiendo rpidamente a sus rdenes. Aparecen as los primeros
planificadores. El primer sistema de tiempo compartido fue el CTSS (Compatible Time-Sharing Sys
tem) desarrollado por el MIT en 1961. Este sistema operativo se utiliz en un IBM 7090 y lleg a
manejar hasta 32 usuarios interactivos.
En esta poca aparecieron los primeros sistemas de tiempo real. Se trataba de aplicaciones militares,
en concreto para deteccin de ataques areos. En este caso, el computador est conectado a un siste
ma externo y debe responder velozmente a las necesidades de ese sistema extemo. En este tipo de
sistema las respuestas deben producirse en periodos de tiempo previamente especificados, que en la
mayora de los casos son pequeos. Los primeros sistemas de este tipo se construan en ensamblador
y ejecutaban sobre mquina desnuda, lo que haca de estas aplicaciones sistemas muy complejos.
Finalmente, cabe mencionar que Burroughs introdujo, en 1963, el Master Control Program, que
adems de ser multiprograma y multiprocesador inclua memoria virtual y ayudas para depuracin en lengua
je fuente.
Durante esta poca se desarrollaron, tambin, los siguientes sistemas operativos: El OS/360, sistema
operativo utilizado en las mquinas de la lnea 360 de IBM; y el sistema MULTICS, desarrollado en el MIT
con participacin de los laboratorios Bell. MULTICS fue diseado para dar soporte a cientos de usuarios; sin
embargo, aunque una versin primitiva de este sistema operativo ejecut en 1969 en un computador GE 645,
no proporcion los servicios para los que fue diseado y los laboratorios Bell finalizaron su participacin en
el proyecto.
Tercera generacin (aos setenta)
La tercera generacin es la poca de los sistemas de propsito general y se caracteriza por los sistemas opera
tivos multimodo de operacin, esto es, capaces de operar en lotes, en multiprogramacin, en tiempo real, en
tiempo compartido y en modo multiprocesador. Estos sistemas operativos fueron costossimos de realizar e
interpusieron entre el usuario y el hardware una gruesa capa de software, de forma que ste slo vea esta
capa, sin tenerse que preocupar de los detalles de la circuitera.
Uno de los inconvenientes de estos sistemas operativos era su complejo lenguaje de control, que deban
aprenderse los usuarios para preparar sus trabajos, puesto que era necesario especificar multitud de detalles y
opciones. Otro de los inconvenientes era el gran consumo de recursos que ocasionaban, esto es, los grandes
espacios de memoria principal y secundaria ocupados, as como el tiempo de UCP consumido, que en algu
nos casos superaba el 50% del tiempo total.
Esta dcada fue importante por la aparicin de dos sistemas que tuvieron una gran difusin, UNIX y
MVS de IBM. De especial importancia es UNIX, cuyo desarrollo empieza en 1969 por Ken Thompson, Dennis Ritchie y otros sobre un PDP-7 abandonado en un rincn en los Bell Laboratories. Su objetivo fue disear
un sistema sencillo en reaccin contra la complejidad del MULTICS. Pronto se transport a una PDP-11,
para lo cual se reescribi utilizando el lenguaje de programacin C. Esto fue algo muy importante en la histo
ria de los sistemas operativos, ya que hasta la fecha ninguno se haba escrito utilizando un lenguaje de alto
nivel, recurriendo para ello a los lenguajes ensambladores propios de cada arquitectura. Slo una pequea
parte de UNIX, aquella que acceda de forma directa al hardware, sigui escribindose en ensamblador. La
programacin de un sistema operativo utilizando un lenguaje de alto nivel como es C, hace que un sistema
operativo sea fcilmente transportable a una amplia gama de computadores. En la actualidad, prcticamente
todos los sistemas operativos se escriben en lenguajes de alto nivel, fundamentalmente en C.
La primera versin ampliamente disponible de UNIX fue la versin 6 de los Bell Laboratories, que apa
reci en 1976. A esta le sigui la versin 7 distribuida en 1978, antecesora de prcticamente todas las versio
nes modernas de UNIX. En 1982 aparece una versin de UNIX desarrollada por la Universidad de California
en Berkeley, la cual se distribuy como la versin BSD (Berkeley Software Distribution) de UNIX. Esta ver
sin de UNIX introdujo mejoras importantes como la inclusin de memoria virtual y la interfaz de sockets
para la programacin de aplicaciones sobre protocolos TCP/IP.
Ms tarde AT&T (propietario de los Bell Laboratories) distribuy la versin de UNIX conocida como
System V o RVS4. Desde entonces, muchos han sido los fabricantes de computadores que han adoptado a
Introduccin a los sistemas operativos 7 5
UNIX como sistema operativo de sus mquinas. Ejemplos de estas versiones son: Solaris de SUN, HP UNIX,
IRIX de SGI y AIX de IBM.
Cuarta generacin (aos ochenta hasta la actualidad)
La cuarta generacin se caracteriza por una evolucin de los sistemas operativos de propsito general de la
tercera generacin, tendente a su especializacin, a su simplificacin y a dar ms importancia a la productivi
dad del usuario que al rendimiento de la mquina.
Adquiere cada vez ms importancia el tema de las redes de computadores, tanto de redes de largo al
cance como locales. En concreto, la disminucin del coste del hardware hace que se difunda el proceso dis
tribuido, en contra de la tendencia centralizadora anterior. El proceso distribuido consiste en disponer de
varios computadores, cada uno situado en el lugar de trabajo de las personas que las emplean, en lugar de una
sola central. Estos computadores suelen estar unidos mediante una red, de forma que puedan compartir in
formacin y perifricos.
Se difunde el concepto de mquina virtual, consistente en que un computador X, que incluye su siste
ma operativo, sea simulado por otro computador Y. Su ventaja es que permite ejecutar, en el computador Y,
programas preparados para el computador X, lo que posibilita el empleo de software elaborado para el com
putador X, sin necesidad de disponer de dicho computador.
Durante esta poca, los sistemas de bases de datos sustituyen a los ficheros en multitud de aplicacio
nes. Estos sistemas se diferencian de un conjunto de ficheros en que sus datos estn estructurados de tal for
ma que permiten acceder a la informacin de diversas maneras, evitar datos redundantes, y mantener su
integridad y coherencia.
La difusin de los computadores personales ha trado una humanizacin en los sistemas informticos.
Aparecen los sistemas amistosos o ergonmicos, en los que se evita que el usuario tenga que aprenderse
complejos lenguajes de control, sustituyndose stos por los sistemas dirigidos por men, en los que la selec
cin puede incluso hacerse mediante un manejador de cursor. En estos sistemas, de orientacin monousuario,
el objetivo primario del sistema operativo ya no es aumentar el rendimiento del sistema, sino la productividad
del usuario.
Los sistemas operativos que dominaron el campo de los computadores personales fueron UNIX, MSDOS y los sucesores de Microsoft para este sistema: Windows 95/98, Windows NT y Windows 200X. El
incluir un intrprete de BASIC en la ROM del PC de IBM ayud a la gran difusin del MS-DOS, al permitir
a las mquinas sin disco que arrancasen directamente dicho intrprete. La primera versin de Windows NT
(versin 3.1) apareci en 1993 e inclua la misma interfaz de usuario que Windows 3.1. En 1996 apareci la
versin 4.0, que se caracteriz por incluir, dentro del ejecutivo de Windows NT, diversos componentes grfi
cos que ejecutaban anteriormente en modo usuario. Durante el ao 2000, Microsoft distribuy la versin de
nominada Windows 2000 que ms tarde pas a ser Windows 2002, Windows XP y Windows 2003.
Tambin tiene importancia durante esta poca el desarrollo de GNU/Linux. Linux es un sistema opera
tivo de la familia UNIX, desarrollado de forma desinteresada durante la dcada de los 90 por miles de volun
tarios conectados a Internet. Linux est creciendo fuertemente debido sobre todo a su bajo coste y a su gran
estabilidad, comparable a cualquier otro sistema UNIX. Una de las principales caractersticas de Linux es que
su cdigo fuente est disponible, lo que le hace especialmente atractivo para el estudio de la estructura inter
na de un sistema operativo. Su aparicin ha tenido tambin mucha importancia en el mercado del software ya
que ha hecho que se difunda el concepto de software libre y abierto.
Durante esta etapa se desarrollaron tambin los sistemas operativos de tiempo real, encargados de
ofrecer servicios especializados para el desarrollo de aplicaciones de tiempo real. Algunos ejemplos son:
QNX, RTEMS y VRTX.
A mediados de los ochenta, aparecieron varios sistemas operativos distribuidos experimentales, que
no despegaron como productos comerciales. Como ejemplo de sistemas operativos distribuidos se puede ci
tar: Mach, Chorus y Amoeba.
Los sistemas operativos distribuidos dejaron de tener importancia y fueron evolucionando durante la
dcada de los 90 a lo que se conoce como middleware. Dos de los middleware ms importantes de esta dca
da han sido DCE y CORBA. Microsoft tambin ofreci su propio middleware conocido como DCOM que ha
evolucionado al COM+. En el entorno Java se ha desarrollado el RMI.
76
Durante esta etapa es importante el desarrollo del estndar UNIX, que define la interfaz de programa
cin del sistema operativo. Este estndar persigue que las distintas aplicaciones que hagan uso de los servi
cios de un sistema operativo sean portables sin ninguna dificultad a distintas plataformas con sistemas
operativos diferentes. Cada vez es mayor el nmero de sistemas operativos que ofrecen esta interfaz. Otra de
las interfaces de programacin ms utilizada es la interfaz Windows, interfaz de los sistemas operativos Win
dows 95/98, Windows NT, Windows 2000 y sucesivos.
Interfaces grficas
Las primeras experiencias con este tipo de interfaces se remontan a los primeros aos de la dcada de los
setenta. En Xerox PARC (un centro de investigacin de Xerox) se desarroll lo que actualmente se considera
la primera estacin de trabajo a la que se denomin Alto. Adems de otros muchos avances, esta investiga
cin estableci los primeros pasos en el campo de los GUI.
Con la aparicin, al principio de los ochenta, de los computadores personales dirigidos a usuarios no
especializados, se acentu la necesidad de proporcionar este tipo de interfaces. As, la compaa Apple
adopt muchas de las ideas de la investigacin de Xerox PARC para lanzar su computador personal Macin
tosh (1984) con una interfaz grfica que simplificaba enormemente el manejo del computador. El otro gran
competidor en este campo, el sistema operativo MS-DOS, tard bastante ms en dar este paso. En sus prime
ras versiones proporcionaba una interfaz alfanumrica similar a la de UNIX pero muy simplificada. Como
paso intermedio, hacia 1988, incluy una interfaz denominada DOS -SHELL que, aunque segua siendo alfanumrica, no estaba basada en lneas, sino que estaba orientada al uso de toda la pantalla y permita realizar
operaciones mediante mens. Por fin, ya en los noventa, lanz una interfaz grfica, denominada Windows,
que tomaba prestadas muchas de las ideas del Macintosh.
En el mundo UNIX se produjo una evolucin similar. Cada fabricante inclua en su sistema una interfaz
grfica adems de la convencional. La aparicin del sistema de ventanas X a mediados de los ochenta y su
aceptacin generalizada, que le ha convertido en un estndar de facto, ha permitido que la mayora de los
sistemas UNIX incluyan una interfaz grfica comn. Como resultado de este proceso, prcticamente todos
los computadores de propsito general existentes actualmente poseen una interfaz de usuario grfica.
La tendencia actual consiste en utilizar sistemas operativos multiprogramados sobre los que se aade un
gestor de ventanas, lo que permite que el usuario tenga activas, en cada momento, tantas tareas como desee
y que los distribuya, a su antojo, sobre la superficie del terminal. Este tipo de interfaces tiene su mayor repre
sentante en los sistemas operativos Windows de Microsoft. En la figura 2.25 se muestra uno de los elementos
clave de la interfaz grfica de este tipo de sistemas, el explorador de Windows, que da acceso a los recursos
de almacenamiento y ejecucin del sistema.
Efc Ecft tfew Favorites look HeJp

*& ' $ IP 5*
1I
X & ' X ) \&
Address13 MyConvuter
Folders
X Name *
- -.... 1TLn*
1
^ LocalDisk(C:)
ocalDisk
esktop
( j) D
vDVD-RWDrive(0:>
CDDrive
a 10M
yDocuments
c,DVDDrive(E:)
CDDrive
a 3ls33S!l
recesoson'dehesa*(Z:)
DisconnectedNetworkDrive
a LocalDisk(C:)
G *C
ontrolPanel
SystemFolder
ffi j, DVD-RWDrive(D:)
a DVDDrive(C:)
95 recursosondehesa1(Z:)
S Q * ControlPanel
3 *3M
yNetviorkPlaces
2) R
ecycleBn
2006-10-05
]s
objects
Figura 2.25 Explorador de Windows.
1 "a 1
TotalSbeI
46,5GB
FreeSpacefComments
4,28G
B
zJH* 1
Providesoptionsfor..,
1y M
yCompUer
77
La revolucin mvil (desde finales de los noventa)

El final de los aos noventa se han caracterizado por el despegue de los sistemas mviles y conectados por
radio. Buena prueba de ello son los dispositivos PDA, pocket PC, telfonos mviles y los innumerables dis
positivos industriales remotos. Para estos sistemas personales aparece una nueva clase de sistema operativo,
ms simple pero incorporando caractersticas multimedia.
Por su lado, los dispositivos industriales remotos utilizan sistemas operativos de tiempo real.
El futuro previsible es que la evolucin de los sistemas operativos se va a seguir orientando hacia las
plataformas distribuidas y la computacin mvil. Gran importancia consideramos que tendr la construccin
de sistemas operativos y entornos que permitan utilizar sistemas de trabajo heterogneos (computadores fijos
y dispositivos mviles de .diferentes fabricantes con sistemas operativos distintos), conectados por redes de
interconexin. Estos sistemas se han de poder utilizar como una gran mquina centralizada, lo que permitir
disponer de una mayor capacidad de cmputo, y han de facilitar el trabajo cooperativo entre los distintos
usuarios.
La ley de Edholm [Cherry, 2004] estipula que el ancho de banda disponible en un computador se dupli
ca cada 18 meses y que la tendencia es a tener el 100% de los computadores conectados. La figura 2.26
muestra esta ley para comunicacin por cable y por radio.
2.11. LECTURAS RECOMENDADAS

Son muchos los libros sobre sistemas operativos que cubren los temas tratados en este captulo. Algunos de
ellos son [Crowley, 1997], [Milenkovic, 1992], [Silberchatz, 2005], [Stallings, 2001] y [Tanenbaum, 2006].
Sobre sistemas operativos distribuidos puede consultarse [Tanenbaum, 2002] y [Galli, 1999]. En cuanto a
sistemas operativos concretos, en [Bach, 1986] y [McKusick, 1996] se describe UNIX System V y la versin
4.4 BSD de UNIX respectivamente; en [Solomon, 1998] se describe la estructura interna de Windows NT, y
en [Beck, 1998] se describe la de Linux.
2.12. EJERCICIOS
2.1.
2.2.
2.3.
Cules son las principales funciones de un

sistema operativo?
Qu diferencia existe entre un mandato y
una llamada al sistema?
Definir los trminos de visin externa e

interna de un sistema operativo. Cul de
las dos determina mejor a un sistema opera
tivo concreto? Por qu?
100.000 .000.000
10 . 000 . 000.000
Ethernet 10 Gb/s
1 .000 .000.000
Ethemet 1 Gb/s
-eab^-
100 .000.000
Ethernet 100 Mb/s
10 .000.000
0J
X
1.000.000
)
O
100.000
10.000
1.000
Ethernet 10 Mb/s
Ethernet 2,94 Mb/s
1970
Radio modem Ricochet
GSM
Pager alfanumrico
100
10
UMTS
&
''Pager de banda ancha

1980
1990
2000
Figura 2.26 Evolucin de los anchos de banda disponibles en los computadores.
PROCESOS
Este captulo se dedica a estudiar todos los aspectos relacionados con los procesos, conceptos fundamenta
les para comprender el funcionamiento de un sistema operativo. Los temas que se tratan en este captulo
son:
Procesos.
Multitarea.
Informacin del proceso.
Vida del proceso.
Threads.
Planificacin.
Seales y excepciones.
Temporizadores.
Tipos de procesos.
Conceptos de ejecucin del sistema operativo.
Tratamiento de las interrupciones.
Estructuras del sistema operativo.
Servicios UNIX y Windows relacionados con la gestin de procesos.
80
3.1.
CONCEPTO DE PROCESO
Todos los programas, cuya ejecucin solicitan los usuarios al sistema operativo, se ejecutan en forma de pro
cesos, de ah la importancia de conocerlos en detalle. Como ya se vio en el captulo 2 '
Introduccin a los sistemas operativos, el proceso se puede definir como un programa en ejecucin y, de una
forma un poco ms precisa, como la unidad de procesamiento gestionada por el sistema operativo.
Se vio, en el captulo 1 Conceptos arquitectnicos del computador, que para ejecutar un programa
ste ha de residir con sus datos en el mapa de memoria. Adems, el sistema operativo mantiene una serie de
estructuras de informacin por cada proceso, estructuras que permiten identificar al proceso y conocer sus "J
caractersticas, as como los recursos que tiene asignados. En esta ltima categora entran los descriptores de
las regiones de memoria asignadas, los descriptores de los ficheros abiertos, los descriptores de los puertos de
comunicaciones, etc. Una parte muy importante de estas informaciones se encuentra, como ya sabemos, en el
bloque de control del proceso (BCP) que tiene asignado cada proceso en la tabla de procesos y que se analiza
ms adelante.
Jerarqua de procesos
La secuencia de creacin de procesos vista en la seccin 2.2.2 Arranque del sistema operativo genera un
rbol de procesos como el incluido en la figura 3.1.
Para referirse a las relaciones entre los procesos de la jerarqua se emplean los trminos de padre e hijo
(a veces se emplea el de hermano y abuelo). Cuando el proceso A solicita al sistema operativo que cree el
proceso B se dice que A es padre de B y que B es hijo de A. Bajo esta ptica la jerarqua de procesos puede
considerarse como un rbol genealgico.
Algunos sistemas operativos como UNIX mantienen de forma explcita esta estructura jerrquica de
procesos un proceso sabe quin es su padre , mientras que otros sistemas operativos como Windows no
la mantienen.
Entorno del proceso
El entorno del proceso consiste en un conjunto de variables que se le pasan al proceso en el momento de su
creacin. El entorno est formado por una tabla NOMBRE=VALOR que se incluye en la pila del proceso. El
NOMBRE especifica el nombre de la variable y el VALOR su valor. Un ejemplo de entorno en UNIX es el
siguiente:
PATH=/usr/bin /home/pepe/bin
TERM=vtl00
HOME=/home/pepe
PWD=/home/pepe/libros/primero
PATH indica la lista de directorios en los que el sistema operativo busca los programas ejecutables, V
(Proclnic;
c Edito
(Proceso B>
Figura 3.1 Jerarqua de procesos.
iProcesoD1
(ProcasoCi
Procesos
81
TERM el tipo de terminal, HOME el directorio inicial asociado al usuario y PWD el directorio de trabajo
a c tu a l.
El sistema operativo ofrece servicios para leer, modificar, aadir o eliminar variables de entorno. Por lo
que los procesos pueden utilizar las variables del entorno para definir su comportamiento. Por ejemplo, un
programa de edicin analizar la variable TERM, que especifica el terminal, para interpretar adecuadamente
las teclas que pulse el usuario.
Grupos de procesos
Los procesos forman grupos que tienen diversas propiedades. El conjunto de procesos creados a partir de un
shell puede formar un grupo de procesos. Tambin pueden formar un grupo los procesos asociados a un ter
minal.
El inters del concepto de grupo de procesos es que hay determinadas operaciones que se pueden hacer
sobre todos los procesos de un determinado grupo, como se ver al estudiar algunos de los servicios. Un
ejemplo es la posibilidad de terminar todos los procesos pertenecientes a un mismo grupo.
3.2.
MULTITAREA
Como se vio en la seccin 2.4 Tipos de sistemas operativos, dependiendo del nmero de procesos que pue
da ejecutar simultneamente, un sistema operativo puede ser monotarea o multitarea.
3.2.1. Base de la multitarea

La multitarea se basa en las tres caractersticas siguientes:
Paralelismo real entre E/S y procesador.
Alternancia en los procesos de fases de E/S y de procesamiento.
Memoria capaz de almacenar varios procesos.
En la seccin 1.6.2 Conceptos arquitectnicos del computador se vio que existe concurrencia real en
tre el procesador y las funciones de E/S realizadas por los controladores de los perifricos. Esto significa que,
mientras se est realizando una operacin de E/S de un proceso, se puede estar ejecutando otro proceso.
Como se muestra en la figura 3.2, la ejecucin de un proceso alterna fases de procesamiento con fases
de E/S, puesto que, cada cierto tiempo, necesita leer o escribir datos en un perifrico. En un sistema monota
rea el procesador no tiene nada que hacer durante las fases de entrada/salida, por lo que desperdicia su poten
cia de procesamiento. En un sistema multitarea se aprovechan las fases de entrada/salida de unos procesos
para realizar las fases de procesamiento de otros.
La figura 3.3 presenta un ejemplo de ejecucin multitarea con cuatro procesos activos. Observe que, al
finalizar la segunda fase de procesamiento del proceso C, hay un intervalo de tiempo en el que no hay trabajo
para el procesador, puesto que todos los procesos estn bloqueados.
Como muestra la figura anterior, el sistema operativo entra a ejecutar al final de las fases de procesa
miento y al final de las fases de entrada/salida. Esto es as puesto que las operaciones de E/S no las gobiernan
directamente los procesos, sino que se limitan a pedir al sistema operativo que las realice. Del mismo modo,
el sistema operativo trata las interrupciones externas que generan los controladores para avisar que han com
pletado una operacin.
Procesamiento
Entrada/salida
- Tiempo
Figura 3.2 Un proceso alterna entre fases de procesamiento y de E/S.
82
Figura 3.3 Ejemplo de ejecucin en un sistema multitarea.

Finalmente, es importante destacar que la multitarea exige tener ms de un proceso activo y cargado en
memoria. Por tanto, hay que disponer de suficiente memoria para albergar a estos procesos.
Proceso nulo
Como se ha indicado en la seccin 1.2.2 Secuencia de funcionamiento del procesador, el procesador no
para nunca de ejecutar. Esto parece que contradice la figura 3.3, puesto que muestra un intervalo en el que el
procesador no tiene nada que hacer. Para evitar esta contradiccin los sistemas operativos incluyen el deno
minado proceso nulo. Este proceso consiste en un bucle infinito que no realiza ninguna operacin til. El
objetivo de este proceso es entretener al procesador cuando no hay ninguna otra tarea. En una mquina
multiprocesadora es necesario disponer de un proceso nulo por procesador.
Estados de los procesos
De acuerdo con la figura 3.3, un proceso puede estar en determinadas situaciones (ejecucin, listo y bloquea
do), que denominaremos estados. A lo largo de su vida, el proceso va cambiando de estado segn evolucio
nan sus necesidades. En la seccin 3.4.5 Estados del proceso, pgina 90, se describirn con mayor detalle
los estados de un proceso.
3.2.2. Ventajas de la multitarea

La multiprogramacin presenta varias ventajas, entre las que se pueden resaltar las siguientes:
Facilita la programacin. Permite dividir las aplicaciones en varios procesos, lo que beneficia su modularidad.
Permite prestar un buen servicio, puesto que se puede atender a varios usuarios de forma eficiente,
interactiva y simultnea.
Aprovecha los tiempos muertos que los procesos pasan esperando a que se completen sus operacio
nes de E/S.
Aumenta el uso de la UCP, al aprovechar los intervalos de tiempo que los procesos estn bloquea
dos.
Todas estas ventajas hacen que, salvo para situaciones muy especiales, no se conciba actualmente un
sistema operativo que no soporte la multitarea.
Grado de multiprogramacin y necesidades de memoria principal
Se denomina grado de multiprogramacin al nmero de procesos activos que mantiene un sistema. El grado
de multiprogramacin es un factor que afecta de forma importante al rendimiento que se obtiene de un com
putador. Mientras ms procesos activos haya en un sistema, mayor es la probabilidad de encontrar siempre un
Procesos
83
proceso en estado de listo para ejecutar, por lo que entrar a ejecutar menos veces el proceso nulo. Sin em
bargo, a mayor grado de multiprogramacin, mayores son las necesidades de memoria. Veamos este fenme
no con ms detalle para los dos casos de tener o no tener memoria virtual.
En un sistema con m em oria real los procesos activos han de residir totalmente en memoria principal,
por tanto, el grado de multiprogramacin viene limitado por el tamao de los procesos y por la memoria
principal disponible. Adems, como se indica en la figura 3.4, el rendimiento de la utilizacin del procesador
aumenta siempre con el grado de multiprogramacin (pero, al ir aumentando el grado de multiprogramacin
hay que aumentar la memoria principal). Esto es as ya que los procesos siempre residen en memoria principal.
En los sistemas con m em oria virtual la situacin es ms compleja, puesto que los procesos slo tienen
en memoria principal su conjunto residente (recordatorio 3.1), lo que hace que quepan ms procesos. Sin
embargo, al aumentar el nmero de procesos, sin aumentar la memoria principal, disminuye el conjunto resi
dente de cada uno, situacin que se muestra en la figura 3.5.
Recordatorio 3.1. Se denomina conjunto residente a las pginas que un proceso tiene en memoria principal
y conjunto de trabajo al conjunto de pginas que un proceso est realmente utilizando en un instante deter
minado________ _______________________________
.. . . . . --
'
Cuando el conjunto residente de un proceso se hace menor de un determinado valor, ya no representa

adecuadamente al conjunto de trabajo del proceso, lo que tiene como consecuencia que se produzcan muchos
fallos de pgina. Cada fallo de pgina consume tiempo de procesador, porque el sistema operativo ha de tra
tar el fallo, y tiempo de E/S, puesto que hay que hacer una migracin de pginas. Todo ello hace que, al cre
cer los fallos de pginas, el sistema dedique cada vez ms tiempo al improductivo trabajo de resolver estos
fallos de pgina.
La figura 3.6 muestra que, en un sistema con memoria virtual, el aumento del grado de multiprograma
cin conlleva primero un aumento del rendimiento del procesador. Sin embargo, superado un determinado
valor de grado de multiprogramacin, los conjuntos residentes de los procesos empiezan a ser demasiado
pequeos, por lo que el sistema baja su rendimiento al perder el tiempo paginando. Se denomina hiperpaginacin (trashing) a la situacin de alta paginacin producida cuando los conjuntos residentes de los procesos
Proceso N
SO
Memoria
principal
Cada procesa reside
totalmente en memoria
Figura 3.4 Grado de multiprogramacin y rendimiento del procesador. En un sistema real con suficiente
memoria al aumentar el grado de multiprogramacin aumenta la utilizacin del procesador.
G rado de Multiprogramacin
Figura 3.5 Para una cantidad de memoria principal dada, el conjunto residente medio decrece con el grado
de multiprogramacin.
84
Grado de Multlprogramacin*
Momorla grande
Figura 3.6 Rendimiento del procesador y grado de multiprogramacin.

son demasiado pequeos.
Cuando la memoria principal disponible es pequea, se llega a la situacin de hiperpaginacin antes de
alcanzar una cota alta de utilizacin del procesador. Para aumentar el rendimiento de un sistema que est en
esta situacin es necesario aadir ms memoria principal. Cuando la memoria principal es grande se llega a
saturar el procesador con menos procesos de los que caben en memoria. En este caso se puede aumentar el
rendimiento del sistema manteniendo la memoria pero aumentando la potencia del procesador o aadiendo
otro procesador.
3.3.
INFORMACION DEL PROCESO
Como se indic anteriormente, el proceso es la unidad de procesamiento gestionada por el sistema operativo.
Para poder realizar este cometido el proceso tiene asociado una serie de elementos de informacin, que se
resumen en la figura 3.7, y que se organizan en tres grupos: estado del procesador, imagen de memoria y ta
blas del sistema operativo.
Es de destacar que el proceso no incluye informacin de E/S, puesto que sta suele estar reservada al
sistema operativo.
3.3.1. Estado del procesador

Como ya sabemos, el estado del procesador est formado por el contenido de todos sus registros (aclaracin
3.1), que se enumeran seguidamente, mientras que el estado visible del procesador se refiere al contenido de
los registros accesibles en modo usuario.
Registros accesibles en modo usuario:
Registros generales. De existir registros especficos de coma flotante tambin se incluyen

aqu.
Contador de programa.
Puntero o punteros de pila.
- Registros -espedales-
- Registros -generales.
r~ p c - 1
i p i
I
Estado
Figura 3.7 Informacin del proceso.
Tablas del sistema operativo

Tabla de procesos
BCP Proceso A BCP Proceso B BCP Proceso C
- Estado
- Estado
- Estada
(registros)
(registros)
(registros)
- Identificacin - Identificacin - Identificacin
- Control
- Control
Control
-Tabla de memoria
. -Tabla de E/S
: -Tabla de ficheros
Procesos
85
Parte del registro de estado accesible en modo usuario.
Registros especiales solamente accesibles en modo privilegiado:
Parte del registro de estado accesible en modo privilegiado.

Registros de control de memoria. Como puede ser los registros de borde o el RIED (Registro
Identificador de Espacio de Direccionamiento).
Aclaracin 3.1. No con fu nd ir el estado del procesad or co n el estado del proceso.
Cuando el proceso no est en ejecucin, su estado debe estar almacenado en el bloque de control de
proceso (BCP). Por el contrario, cuando el proceso est ejecutando, el estado del procesador reside en los
registros y vara de acuerdo al flujo de instrucciones mquina ejecutado. En este caso, la copia que reside en
el BCP no est actualizada. Tngase en cuenta que los registros de la mquina se utilizan para no tener que
acceder a la informacin de memoria, dado que es mucho ms lenta que stos.
Sin embargo, cuando se detiene la ejecucin de un proceso, para ejecutar otro proceso, es muy impor
tante que el sistema operativo actualice la copia del estado del procesador en el BCP. En trminos concretos,
la rutina del sistema operativo que trata las interrupciones lo primero que ha de hacer es salvar el estado del
procesador del proceso interrumpido en su BCP.
3.3.2. Imagen de memoria del proceso

La imagen de memoria del proceso est formada por los espacios de memoria que ste est autorizado a usar.
Las principales caractersticas de la imagen de memoria son las siguientes:
El proceso solamente puede tener informacin en su imagen de memoria y no fuera de ella. Si genera
una direccin que est fuera de ese espacio, el hardware de proteccin deber detectarlo y generar
una excepcin hardware sncrona de violacin de memoria. Esta excepcin activar la ejecucin del
sistema operativo, que se encargar de tomar las acciones oportunas, como puede ser abortar la eje
cucin del proceso.
Dependiendo del computador, la imagen de memoria estar referida a memoria virtual o a memoria
real. Observe que esto es transparente (irrelevante) para el proceso, puesto que l genera direcciones
de memoria, que sern tratados como virtuales o reales segn el caso.
Los procesos suelen necesitar asignacin dinmica de memoria. Por tanto, la imagen de memoria de
los mismos se deber adaptar a estas necesidades, creciendo o decreciendo adecuadamente.
No hay que confundir la asignacin de memoria con la asignacin de marcos de memoria. El primer
trmino contempla la modificacin de la imagen de memoria y se refiere al espacio virtual en los sis
temas con este tipo de espacio. El segundo trmino slo es de apilicacin en los sistemas con memo
ria virtual y se refiere a la modificacin del conjunto residente del proceso.
El sistema operativo asigna la memoria al proceso, para lo cual puede emplear distintos modelos de
imagen de memoria, que se analizan seguidamente.
Proceso con una nica regin de tamao fijo
Es el modelo ms sencillo de imagen de memoria y su uso se suele restringir a los sistemas con memoria real.
El proceso recibe un nico espacio de memoria que, adems, no puede variar de tamao.
Proceso con una nica regin de tamao variable
Se puede decir que esta solucin no se emplea. En sistemas con memoria real las regiones no pueden crecer,
a menos que se deje espacio de memoria principal de reserva en caso contrario se solapara con el proceso
siguiente . Ahora bien, la memoria principal es muy cara como para dejarla de reserva. En sistemas con
memoria virtual s se podra emplear, dado que el espacio de reserva no tiene asignados recursos fsicos, pero
86
es ms conveniente usar un modelo de varias regiones, pues es mucho ms flexible y se adapta mejor a las
necesidades reales de los procesos.
Proceso con un nmero fijo de regiones de tamao variable
Un proceso contiene varios tipos de informacin, cuyas caractersticas se analizan seguidamente:
Texto o cdigo. Bajo este nombre se considera el programa mquina que ha de ejecutar el proceso.
Aunque el programa podra automodificarse, no es sta una prctica recomendada, por lo cual se
considerar que esta informacin es fija y que solamente se harn operaciones de ejecucin y lectura
sobre ella (aclaracin 3.2).
Datos. Este bloque de informacin depende mucho de cada proceso. Los lenguajes de programacin
actuales permiten asignacin dinmica de memoria, lo que hace que vare el tamao del bloque de
datos al avanzar la ejecucin del proceso. Cada programa estructura sus datos de acuerdo a sus nece
sidades, pudiendo existir los siguientes tipos:
Datos con valor inicial. Estos datos son estticos y su valor se fija al cargar el proceso desde el
fichero ejecutable. Estos valores se asignan en tiempo de compilacin.
Datos sin valor inicial. Estos datos son estticos, pero no tienen valor asignado, por lo que no
estn presentes en el fichero ejecutable. Ser el sistema operativo el que, al cargar el proceso,
rellene o no rellene esta zona de datos con valores predefinidos.
Datos dinmicos. Estos datos se crean y se destruyen de acuerdo a las directrices del progra
ma.
Los datos podrn ser de lectura-escritura o solamente de lectura.
Pila. A travs del puntero de pila, los programas utilizan una estructura de pila residente en memo
ria. En ella se almacenan, por ejemplo, los bloques de activacin de los procedimientos llamados. La
pila es una estructura dinmica, puesto que crece y decrece segn avanza la ejecucin del proceso.
Recordemos que hay procesadores que soportan una pila para modo usuario y otra para modo privi
legiado.
Aclaracin 3.2. Dado que tambin se pueden incluir cadenas inmutables de texto en el cdigo, tambin se
han de permitir las operaciones de lectura, adems de las de ejecucin.__________________________________
Para adaptarse a estas informaciones, se puede utilizar un modelo de imagen de memoria con un nme
ro fijo de regiones de tamao variable.
El modelo tradicional utilizado en UNIX contempla tres regiones: texto, pila y datos. La figura 3.8 pre
senta esta solucin. Observe que la regin de texto es de tamao fijo (el programa habitualmente no se modi
fica) y que las regiones de pila y de datos crecen en direcciones contrarias.
Este modelo se adapta bien a los sistemas con memoria virtual, puesto que el espacio virtual reservado
para que puedan crecer las regiones de datos y pila no existe fsicamente. Solamente se crea, gastando recur
sos de disco y memoria, cuando se asigna. No ocurrir lo mismo en un sistema real, en el que el espacio re
servado para el crecimiento ha de existir como memoria principal, dando como resultado que hay un recurso
costoso que no se est utilizando.
Si bien este modelo es ms flexible que los dos anteriores, tiene el inconveniente de no prestar ayuda
para la estructuracin de los datos. El sistema operativo ofrece un espacio de datos que puede crecer y decreEspacio de direcciones
Figura 3.8 Modelo de imagen de memoria con estructura de regiones fija.
Procesos
87
cer, pero deja al programa la gestin interna de este espacio,

proceso con un nm ero variable de regiones de tam ao variable
Esta solucin es ms avanzada que la anterior, al permitir que existan las regiones que desee el proceso. La
figura 3.9 presenta un caso de 7 regiones, que podrn ser de texto, de pila o de datos.
Es la solucin ms flexible y, por tanto, la utilizada en las versiones actuales de Windows y UNIX.
3.3.3. Informacin del bloque de control de proceso (BCP)

Cada proceso dispone, en la tabla de procesos, de un BCP que contiene la informacin bsica del proceso,
entre la que cabe destacar la siguiente:
Inform acin de identificacin
Informacin de identificacin del usuario y del proceso. Como ejemplo, se incluyen los siguientes datos:
Identificador del proceso.
Identificador del proceso padre, en caso de existir relaciones padre-hijo como en UNIX.
Informacin sobre el usuario (identificador de usuario, identificador de grupo).
Estado del procesador
Contiene los valores iniciales del estado del procesador o su valor en el instante en que fue expulsado el pro
ceso.
Informacin de control del proceso
En esta seccin se incluye diversa informacin que permite gestionar al proceso. Destacaremos los siguientes
datos, muchos de los cuales se detallarn a lo largo del libro:
Informacin de planificacin y estado.
Estado del proceso.

Evento por el que espera el proceso cuando est bloqueado.
Prioridad del proceso.
Informacin de planificacin.
Descripcin de las regiones de memoria asignadas al proceso.

Recursos asignados, tales como:
Ficheros abiertos (tabla de descriptores o manejadores de fichero).

Puertos de comunicacin asignados.
Temporizadores.
Punteros para estructurar los procesos en colas o anillos. Por ejemplo, los procesos que estn en es
tado de listo pueden estar organizados en una cola, de forma que se facilite la labor del planificador.
Comunicacin entre procesos. El BCP puede contener espacio para almacenar las seales y para
Espacio de direcciones
Regiones
Figura 3.9 Modelo de imagen de memoria con estructura de regiones variable.
88
algn mensaje enviado al proceso.
3.4.
VIDA DE UN PROCESO
Como ya sabemos, la vida de un proceso consiste en su creacin, su ejecucin y su muerte o terminacin. Sin
embargo, la ejecucin del proceso no se suele hacer de un tirn, puesto que surgen interrupciones y el propio
proceso puede necesitar servicios del sistema operativo. De acuerdo con ello, en esta seccin se analizarn de
forma general la creacin, interrupcin, activacin y terminacin del proceso.
3.4.1. Creacin del proceso

La creacin de un proceso la realiza el sistema operativo bajo peticin expresa de otro proceso (con excep
cin del o de los procesos iniciales creados en el arranque del sistema operativo). Esta creacin consiste en
completar todas las informaciones que constituyen un proceso, como se muestra en la figura 3 . 10 .
De forma ms especfica, las operaciones que debe hacer el sistema operativo son las siguientes:
Asignar un espacio de memoria para albergar la imagen de memoria. En general, este espacio ser
virtual y estar compuesto de varias regiones.
Seleccionar un BCP libre de la tabla de procesos.
Rellenar el BCP con la informacin de identificacin del proceso, con la descripcin de la memoria
asignada, con los valores iniciales de los registros indicados en el fichero objeto, etc.
Cargar en la regin de texto el cdigo ms las rutinas de sistema y en regin de datos los datos ini
ciales contenidos en el fichero objeto.
Crear en la regin de pila la pila inicial del proceso. La pila incluye inicialmente el entorno del pro
ceso y los argumentos que se pasan en la invocacin del mandato.
Una vez completada toda la informacin del proceso, se puede marcar como listo para ejecutar, de for
ma que el planificador, cuando lo considere oportuno, lo seleccione para su ejecucin. Una vez seleccionado,
el activador lo pone en ejecucin.
3.4.2. Interrupcin del proceso

Mientras est ejecutando un proceso puede ocurrir interrupciones. Veamos detalladamente los pasos involu
crados:
Un proceso est en ejecucin, por lo tanto, parte de su informacin reside en los registros de la
mquina, que estn siendo constantemente modificados por la ejecucin de sus instrucciones mqui
na.
Bien sea porque llega una interrupcin externa, una excepcin hardware o porque el proceso solicita
un servicio del sistema operativo, el proceso para su ejecucin.
Inmediatamente entra a ejecutar el sistema operativo ya sea para atender la interrupcin o para atenTabla de procesos
BCP
Figura 3.10 Formacin de un proceso.
Procesos
89
der el servicio demandado.

La ejecucin del sistema operativo, como la de todo programa, modifica los contenidos de los regis
tros de la mquina, destruyendo sus valores anteriores.
Segn la secuencia anterior, si ms adelante se desea continuar con la ejecucin del proceso, se presenta
un grave problema: los registros ya no contienen los valores que deberan. Supongamos que el proceso est
ejecutando la secuencia siguiente:
L D .5,#CANT
<=
En este punto llega una interrupcin y se pasa al SO
L D .l, [.5 ]
Supongamos que el valor de CANT es H exA4E78, pero que el sistema operativo al ejecutar modifica el
registro . 5 , dndole el valor HexEB7A4. Al intentar, ms tarde, que siga la ejecucin del mencionado pro
ceso, la instruccin LD . 1 , [ . 5] cargar en el registro . 1 el contenido de la direccin HexEB7A4 en
vez del contenido de la direccin H exA4E78.
Para evitar esta situacin, lo primero que hace el sistema operativo al entrar a ejecutar es salvar el con
tenido de todos los registros de usuario, teniendo cuidado de no modificar el valor de ninguno de ellos antes
de salvarlo. Como muestra la figura 3.11, al interrumpirse la ejecucin de un proceso el sistema operativo
almacena los contenidos de los registros en el BCP de ese proceso (recordatorio 3.2). Para ms detalles ver la
seccin 3.11.2 Detalle del tratamiento de interrupciones.
Recordatorio 3.2. Como sabemos, la propia interrupcin modifica el contador de programa y el registro de
estado (cambia el bit que especifica el modo de ejecucin para pasar a modo privilegiado, as como los bits
de inhibicin de interrupciones). Sin embargo, esto no presenta ningn problema puesto que el propio hard
ware se encarga de salvar estos registros en la pila antes de modificarlos._______ _______________________
3.4.3. Activacin del proceso

Activar un proceso es ponerlo en ejecucin. Para que la activacin funcione correctamente ha de garantizar
que el proceso encuentra el computador exactamente igual a como lo dej, para que pueda seguir ejecutando
sin notar ninguna diferencia.
El mdulo del sistema operativo que pone a ejecutar un proceso se denomina activador o dispatcher.
La activacin de un proceso consiste en copiar en los registros del procesador el estado del procesador, que
est almacenado en su BCP. De esta forma, el proceso continuar su ejecucin en las mismas condiciones en
las que fue parado. El activador termina con una instruccin de retomo de interrupcin (p. ej.: RETI). El
efecto de esta instruccin es restituir el registro de estado y el contador de programa, lo cual tiene los impor
tantes efectos siguientes:
Al restituir el registro de estado, se restituye el bit que especifica el modo de ejecucin. Dado que
cuando fue salvado este registro el bit indicaba modo usuario, puesto que estaba ejecutando un pro-
Figura 3.11 Al interrumpirse la ejecucin de un proceso, se salva su estado en el BCP.
90
ceso de usuario, su restitucin garantiza que el proceso seguir ejecutando en modo usuario.
Igualmente, al restituir el registro de estado se restituyen los bits de inhibicin de interrupcin, segn
los tena el proceso cuando fue interrumpido.
Al restituir el contador de programa, se consigue que la siguiente instruccin mquina que ejecute el
procesador sea justo la instruccin en la que fue interrumpido el proceso. En este momento es cuan
do se ha dejado de ejecutar el sistema operativo y se pasa a ejecutar el proceso.
3.4.4. Terminacin del proceso

Cuando el proceso termina, ya sea porque ha completado su ejecucin o porque se ha decidido que debe mo
rir, el sistema operativo tiene que recuperar los recursos que tiene asignando el proceso. Al hacer esta recupe
racin hay que tener en cuenta dos posibles situaciones:
Si el recurso est asignado en exclusividad al proceso, como puede ser el BCP o una regin de datos
no compartidos, el sistema operativo debe aadir el recurso a sus listas de recursos libres.
Si el recurso es compartido, el sistema operativo tiene que tener asociado un contador, para llevar la
cuenta del nmero de procesos que lo estn utilizando. El sistema operativo decrementar dicho con
tador y, solamente cuando alcance el valor 0 , deber aadir el recurso a sus listas de recursos li
bres.
3.4.5. Estados del proceso

Como muestra la figura 3.3, pgina 82, no todos los procesos activos de un sistema multitarea estn en la
misma situacin. Se diferencian, por tanto, tres estados bsicos en los que puede estar un proceso, estados
que detallamos seguidamente:
Ejecucin. El proceso est ejecutando en el procesador, es decir, est en fase de procesamiento. En
esta fase el estado del procesador reside en los registros del procesador.
Bloqueado. Un proceso bloqueado est esperando a que ocurra un evento y no puede seguir ejecu
tando hasta que suceda dicho evento. Una situacin tpica de proceso bloqueado se produce cuando
el proceso solicita una operacin de E/S u otra operacin que requiera tiempo. Hasta que no termina
esta operacin el proceso queda bloqueado. En esta fase el estado del procesador est almacenado en
el BCP.
Listo. Un proceso est listo para ejecutar cuando puede entrar en fase de procesamiento. Dado que
puede haber varios procesos en este estado, una de las tareas del sistema operativo ser seleccionar
aqul que debe pasar a ejecucin. El mdulo del sistema operativo que toma esta decisin se deno
mina planificador. En esta fase el estado del procesador est almacenado en el BCP.
La figura 3.12 presenta estos tres estados, indicando algunas de las posibles transiciones entre ellos.
Puede observarse que slo hay un proceso en estado de ejecucin, puesto que el procesador solamente ejecu
ta un programa en cada instante (aclaracin 3.3). Del estado de ejecucin se pasa al estado de bloqueado al
solicitar, por ejemplo, una operacin de E/S (flecha de Espera evento). Tambin se puede pasar del estado de
ejecucin al de listo cuando el sistema operativo decida que ese proceso lleva mucho tiempo en ejecucin o
cuando pase a listo un proceso ms prioritario (flecha de Expulsado). Del estado de bloqueado se pasa al es
tado de listo cuando se produce el evento por el que estaba esperando el proceso (p. ej.: cuando se completa
la operacin de E/S solicitada). Finalmente, del estado de listo se pasa al de ejecucin cuando el planificador
lo seleccione para ejecutar. Todas las transiciones anteriores estn gobernadas por el sistema operativo, lo
que implica la ejecucin del mismo en dichas transiciones.
Aclaracin 3.3. En una mquina multiprocesador se tendrn simultneamente en estado de ejecucin tantos
procesos como procesadores.
Procesos
91
Figura 3.12 Estados bsicos de un proceso.
3.4.6. Estados de espera y suspendido

Adems de los estados bsicos vistos en las secciones anteriores, los procesos pueden estar en los estados de
espera y de suspendido. Completando el esquema de la figura 3.12 con estos nuevos estados se obtiene el
diagrama representado en la figura 3.13.
Los procesos entran en el sistema porque lo solicita un proceso, como puede ser el shell, o porque est
prevista su ejecucin batch. Es frecuente tener una lista de procesos batch en espera para ser ejecutados
cuando se pueda. El sistema operativo ha de ir analizando dicha lista para lanzar la ejecucin de los procesos
a medida que disponga de los recursos necesarios.
Los procesos salen del sistema cuando mueren, es decir, al ejecutar el servicio correspondiente o al
producir algn error irrecuperable.
El sistema operativo puede suspender algunos procesos para disminuir el grado de multiprogramacin
efectivo, lo que implica que les retira todos sus marcos de pginas, dejndolos enteramente en la zona de in
tercambio. En la figura 3.13 se muestra como los procesos listos o bloqueados pueden suspenderse. El objeti
vo de la suspensin estriba en dejar suficiente memoria principal a los procesos no suspendidos para que su
conjunto residente tenga un tamao adecuado que evite la hiperpaginacin (ver captulo 5 "Gestin de me
moria).
No todos los sistemas operativos tienen la opcin de suspensin. Por ejemplo, un sistema operativo
monousuario puede no incluir la suspensin, dejando al usuario la labor de cerrar procesos si observa que no
ejecutan adecuadamente.
Los procesos batch que entran en el sistema lo pueden hacer pasando al estado de listo o al de listo sus
pendido.
Ejecucin
Planificado
Termina
Espera evento
Entra al
sistema
| Expulsado
Bloqueado
Se produce el evento
Entra al
sistema
| Recuperado del disco"]
Expulsado al disco
I Expulsado al disco
Listo y
suspendido
Procesos por lotes
Figura
Se produce el evento
[Bloqueado y]
[suspendido J
92
3.5.
PLANIFICACIN
El objetivo de la planificacin de procesos es el reparto del tiempo de procesador entre los procesos. Como
hemos visto, el planificador es el mdulo del sistema operativo que realiza la funcin de seleccionar el proce
so en estado de listo que pasa a estado de ejecucin, mientras que el activador es el mdulo que pone en eje
cucin el proceso planificado.
J
Los sistemas pueden incluir varios niveles de planificacin de procesos. La figura 3.14 muestra el caso
de tres niveles: corto, medio y largo plazo.
La planificacin a largo plazo tiene por objetivo aadir nuevos procesos al sistema, tomndolos de la
lista de espera. Estos procesos son procesos de tipo batch, en los que no importa el instante preciso en el que
se ejecuten (siempre que se cumplan ciertos lmites de espera).
La planificacin a medio plazo trata la suspensin de procesos. Es la que decide qu procesos pasan a
suspendido y cules dejan de estar suspendidos. Aade o elimina procesos de memoria principal modifican
do, por tanto, el grado de multiprogramacin.
La planificacin a corto plazo se encarga de seleccionar el proceso en estado de listo que pasa a estado
de ejecucin. Es, por tanto, la que asigna el procesador.
Planificacin de E/S
Dado que los perifricos son relativamente lentos, es frecuente que se acumulen las peticiones de acceso sin
haber completado las anteriores. Surge, por tanto, la necesidad de planificacin de entrada/salida, cuya mi
sin consiste en decidir el orden en que se ejecutan las operaciones de entrada/salida que estn pendientes
para cada perifrico.
Colas
Para tener anotados los candidatos que desean ser atendidos ya sean procesos listos para ejecutar u operacio
nes de E/S solicitadas, el sistema operativo debe mantener unas colas con dichos candidatos.
El planificador seleccionar un candidato de entre los listos para ejecutar, de acuerdo a los criterios o
algoritmos que tenga establecidos, algoritmos que se analizarn en detalle en el captulo 4 Planificacin de
Procesos.
3.6.
SEALES Y EXCEPCIONES
Cuando un sistema operativo desea notificar a un proceso la ocurrencia de un determinado evento, o error,
recurre al mecanismo de las seales en UND o al de las excepciones en Windows.
Figura 3.14 Tipos de planificacin.
Procesos
97
cesos trabajadores de ncleo.

Hay que resaltar que, aunque en la mayora de los casos estos procesos de ncleo tienen una prioridad
alta, debido a la importancia de las labores que realizan, no siempre es as. Un ejemplo evidente es el proceso
nulo, que es un proceso de ncleo pero que, sin embargo, tiene prioridad mnima, para de esta forma slo
conseguir el procesador cuando no hay ningn otro proceso listo en el sistema.
Es importante notar la gran diferencia que hay entre estos procesos de ncleo y los procesos de usuario
creados por el superusuario del sistema. Los procesos de superusuario son procesos convencionales: ejecutan
en modo usuario el cdigo del ejecutable correspondiente. No pueden, por tanto, utilizar instrucciones
mquina privilegiadas. Su poder proviene de tener como propietario al superusuario, por lo que no tienen
restricciones a la hora de realizar llamadas al sistema aplicadas a cualquier recurso del sistema. Algunos
ejemplos de procesos de superusuario son los que proporcionan servicios de red y spooling (los tpicos de
monios de los sistemas UNIX). Ntese que, aunque muchos de estos procesos se crean tambin en el arran
que del sistema, hay una diferencia significativa con los procesos de ncleo: los procesos de superusuario los
crea siempre otro proceso, en muchos casos el proceso inicial (en UNIX, i n i t ) , mientras que los procesos
de ncleo los crea el propio sistema operativo en su fase inicial. Tngase en cuenta que, en el caso de un sis
tema operativo con una estructura de tipo microkemel, los procesos que proporcionan las funcionalidades
bsicas del sistema, como, por ejemplo, la gestin de ficheros, no son procesos de ncleo, sino que tienen las
mismas caractersticas que los procesos de superusuario.
Las principales caractersticas de los procesos de ncleo son las siguientes:
Se crean mediante un servicio especial distinto del utilizado para los procesos de usuario.
Se crean dentro del dominio de proteccin del sistema operativo.
Tienen acceso a todo el mapa de memoria del sistema operativo.
Su imagen de memoria se encuentra dentro del mapa de memoria del sistema operativo.
Pueden utilizar un conjunto restringido de llamadas al sistema, adems de los servicios generales que
utilizan los procesos de usuario.
Ejecutan siempre en modo privilegiado.
Son flujos de ejecucin independientes dentro del sistema operativo.
El diseo de los procesos de ncleo ha de ser muy cuidadoso puesto que trabajan en el dominio de pro
teccin del sistema operativo y tienen todos los privilegios. Un proceso de ncleo, antes de terminar, ha de
liberar toda la memoria dinmica y todos los cerrojos asignados, puesto que no se liberan automticamente.
3.9.
THREADS
Un proceso se puede considerar formado por un activo y por un flujo de ejecucin. El activo es el conjunto
de todos los bienes y derechos que tiene asignados el proceso. En el activo se incluye la imagen de memoria
del proceso, el BCP, los ficheros abiertos, etc. El flujo de ejecucin est formado por el conjunto ordenado de
instrucciones mquina del programa que va ejecutando el proceso. Denominaremos thread a esta secuencia
de ejecucin (otros nombres utilizados son hilo o proceso ligero). ntimamente ligado al thread e.st el estado
del procesador, que va cambiando segn avanza el thread, el estado de ejecucin (listo, bloqueado o en eje
cucin) y la pila.
En los procesos clsicos, que hemos estudiado hasta ahora, solamente existe un nico thread de ejecu
cin, por lo que les denominamos monothread. La extensin que se plantea en esta seccin consiste en dotar
al proceso de varios threads. Llamaremos proceso multithread a este tipo de proceso, mostrado la figura
3.19. El objetivo de disponer de varios threads es conseguir concurrencia dentro del proceso, al poder ejecu
tar los mismos simultneamente.
Cada thread tiene informaciones que le son propias, informaciones que se refieren fundamentalmente al
contexto de ejecucin, pudindose destacar las siguientes:
Estado del procesador: Contador de programa y dems registros visibles.
Pila.
98
Figura 3.19 Proceso monothready multithread.

Estado del thread (ejecutando, listo o bloqueado).
Prioridad de ejecucin.
Bloque de control de thread.
Todos los threads de un mismo proceso comparten el activo del mismo, en concreto comparten:
Espacio de memoria.
Variables globales.
Ficheros abiertos.
Procesos hijos.
Temporizadores.
Seales y semforos.
Contabilidad.
Es importante destacar que todos los threads de un mismo proceso comparten el mismo espacio de di
recciones de memoria, que incluye el cdigo, los datos y las pilas de los diferentes threads. Esto hace que no
exista proteccin de memoria entre los threads de un mismo proceso y que un thread pueda, aunque no sea
recomendable, acceder a la informacin propia de otro thread, como puede ser su pila.
El thread constituye la unidad ejecutable en Windows. La figura 3.20 representa de forma esquemtica
la estructura de un proceso de Windows con sus threads.
3.9.1. Gestin de los threads

Hay dos formas bsicas de gestionar los threads: la ULT (User Level Threads) y la KLT (Kernel Level Thre
ads), que se diferencian por el conocimiento que tiene el sistema operativo de los mismos.
ULT. Los threads de nivel de usuario o threads de biblioteca los gestiona totalmente una bibliote
ca de threads, que ha de incluirse en el proceso como una capa software sobre la que ejecutan los
threads. El sistema operativo desconoce la existencia de estos threads, para l se trata de un proceso
normal de un solo thread. Es la capa de software la que crea, planifica, activa y termina los distintos
threads.
KLT. Los threads de nivel de ncleo o threads de sistema los gestiona el sistema operativo. Es el
ncleo del sistema operativo el que crea, planifica, activa y termina los distintos threads.
Cdigo
Datos
Recursos (ficheros,...)
Enlomo del proceso
Hi| 1
|Registros]
I Pila I
Figura 3.20 Estnictura de un proceso en Windows.
118
Compartir la informacin
Cuando la informacin ha de ser compartida por varios procesos, no ha de residir en el BCP, que es de acceso 4
restringido al proceso que lo ocupa. A lo sumo, el BCP contendr un apuntador que permita alcanzar esa in
formacin.
Un ejemplo de esta situacin lo presentan los procesos en relacin con los punteros de posicin de los
ficheros que tienen abiertos. Dos procesos pueden tener simultneamente abierto el mismo fichero por dos
razones: el fichero se hered abierto de un proceso ancestro o el fichero se abri de forma independiente por
los dos procesos. En el primer caso se trata de procesos diseados para compartir el fichero, por lo que deben >
compartir el puntero de posicin (PP). En el modelo UNIX existe una tabla nica llamada intermedia que
mantiene los punteros de posicin de todos los ficheros abiertos por todos los procesos.
Finalmente diremos que otra razn que obliga a que las tablas de pginas sean externas al BCP es para
permitir que se pueda compartir memoria. En este caso, como se analizar en detalle en el captulo 5 Ges
tin de memoria, dos o ms procesos comparten parte de sus tablas de pginas.
3.13. SERVICIOS
Esta seccin describe los principales servicios que ofrecen UNIX y Windows para la gestin de procesos,
threads y planificacin. Tambin se presentan los servicios que permiten trabajar con seales (UNIX), ex
cepciones (Windows) y temporizadores.
3.13.1. Servicios UNIX para la gestin de procesos

En esta seccin se describen los principales servicios que ofrece UND para la gestin de procesos. Estos
servicios se han agrupado segn las siguientes categoras:
Identificacin de procesos.
El entorno de un proceso.
Creacin de procesos.
Terminacin de procesos.
En las siguientes secciones se presentan los servicios incluidos en cada una de estas categoras, utili
zando sus prototipos en lenguaje C.
Identificacin de procesos
UNIX identifica cada proceso por medio de un entero nico denominado identificador de proceso de tipo
p i d _ t . Los servicios relativos a la identificacin de los procesos son los siguientes:
ffl pid_t getpid (void) ;
'Vi!
Este servicio devuelve el identificador del proceso que lo solicita.

SI pid_t getppid (void) ;
Devuelve el identificador del proceso padre.
El programa 3.1 muestra un ejemplo de utilizacin de ambos servicios.
Programa 3.1 Programa que imprime su identificador de proceso y el identificador de su proceso padre.
#include <sys/types.h>
ttinclude <stdio.h>
fj
Procesos
119
int main(void)
{
pid_t id_proceso;
pid_t idjpadre;
id_proceso = getpidO;
id_padre = getppid();
printf("Identificador de proceso: %d\n", id_proceso);
printf("Identificador del proceso padre: %d\n", id_padre)
return 0 ;
Cada usuario en el sistema tiene un identificador nico denominado identificador de usuario, de tipo
u i d t . Cada proceso lleva asociado un usuario que se denomina propietario o usuario real. El proceso tiene
tambin un identificador de usuario efectivo, que, como se ver en el captulo 11 Seguridad y proteccin,
determina los privilegios de ejecucin que tiene el proceso. Generalmente el usuario real es el mismo que el
efectivo. El sistema incluye tambin grupos de usuarios, cada usuario debe ser miembro al menos de un gru
po. Al igual que con los usuarios, cada proceso lleva asociado el identificador de grupo real al que pertenece
y el identificador de grupo efectivo. Los servicios que permiten obtener estos identificadores son los siguien
tes:
0
uid_t getuid(void);
Este servicio devuelve el identificador de usuario real del proceso que lo solicita.
uid_t geteuid(void);
Devuelve el identificador de usuario efectivo.
gid_t getgid(void);
Este servicio permite obtener el identificador de grupo real.
gid_t getegid(void);
Devuelve el identificador de grupo efectivo.

El programa 3.2 muestra un ejemplo de utilizacin de estos cuatro servicios.
P rogram a 3.2 Programa que imprime la informacin de identificacin de un proceso.
#include <stdio.h>
int main(void)
{
printf("Identificador
return 0 ;
de
de
de
de
ario: %d\n", getuidO);

ario efectivo: %d\n" , geteuidO);
po: %d\n", getgid());
po efectivo: %d\n", getegidO);
120
El entorno de un proceso
El entorno de un proceso viene definido por una lista de variables que se pasan en el momento de comenzar
su ejecucin. Estas variables se denominan variables de entorno y se puede acceder a ellas a travs de la va
riable global e n v i r o n , declarada de la siguiente forma:
extern char *environ[];
El entorno es un vector de cadenas de caracteres de la forma n o m b r e = v a lo r , donde n o m b re hace
referencia al nombre de una variable de entorno y v a l o r al contenido de la misma.
Este mismo entorno lo recibe el m a in como tercer parmetro. Basta con declararlo de la siguiente for
ma:
int main(int argc, char *argv[], char *envp[])
El programa 3.3 imprime las variables de entorno de un proceso.
Program a 3.3 Programa que imprime el entorno del proceso dos veces, usando e n v i r o n y e n v p .
#include <stdio.h>
#include <stdlib.h>
extern char **environ;
int maintint argc, char *argv[], char *envp[])
{
int i ;
printf("Lista de variables de entorno usando environ de %s\n", argvfo]);
for(i=0; environ[i] != NULL; i++)
printf(environ[%d] = %s\n", i, environ[i];
printf("Lista de variables de entorno usando envp de %s\n", argv[0]);
for(i=0; envpfi] != NULL; i++)
printf("envp[%d] = %s\n", i, envp[i];
return 0 ;
}
Cada aplicacin interpreta la lista de variables de entorno de forma especfica. UNIX establece el signi
ficado de determinadas variables de entorno. Las ms comunes son:
HOME, directorio de trabajo inicial del usuario.

LOGNAME, nombre del usuario asociado a un proceso.
PATH, prefijo de directorios para encontrar ejecutables.
TERM, tipo de term inal.
TZ, informacin de la zona horaria.
char *getenv(const char *name);_
El servicio g e t e n v permite obtener el valor de una variable de entorno. Devuelve un puntero al valor de la
variable de entorno de nombre am e, o NULL si la variable de entorno no se encuentra definida.
El programa 3.4 utiliza el servicio g e t e n v para imprimir el valor de la variable de entorno HOME.
P ro g ram a 3.4 Programa que imprime el valor de la variable HOME.
# in c lu d e < s td io .h >
Procesos
121
#include <stdlib.h>
int main(void)
{
char *home;
home = getenv("HOME");
if (home == NULL)
printf("HOME no se encuentra definida\n");
else
printf("El valor de HOME es %s\n", home);
return 0 ;
Creacin de procesos
3 p id t fo rk O ; .
;y[,' -
La forma de crear un proceso en un sistema operativo que ofrezca la interfaz UNIX es invocando el servicio
f o r k . El sistema operativo trata este servicio realizando una clonacin del proceso que lo solicite. El proce
so que solicita el servicio se convierte en el proceso padre del nuevo proceso, que es, a su vez, el proceso
hijo.
La figura 3.35 muestra que la clonacin del proceso padre se realiza copiando la imagen de memoria y
el BCP. Observe que el proceso hijo es una copia del proceso padre en el instante en que ste solicita el ser
vicio f o r k . Esto significa que los datos y la pila del proceso hijo son los que tiene el padre en ese instante de
ejecucin. Es ms, dado que al entrar el sistema operativo a tratar el servicio, lo primero que hace es salvar
los registros en el BCP del padre, al copiarse el BCP se copian los valores salvados de los registros, por lo
que el hijo tiene los mismos valores que el padre. Esto significa, en especial, que el contador de programa de
los dos procesos tiene el mismo valor, por lo que van a ejecutar la misma instruccin mquina. No hay que
caer en el error de pensar que el proceso hijo empieza la ejecucin del cdigo en su punto de inicio; repeti
mos: el hijo empieza a ejecutar, al igual que el padre, en la sentencia que est despus del f o r k .
El servicio f o r k es invocado una sola vez por el padre, pero retoma dos veces, una en el padre y otra
en el hijo.
En realidad el proceso hijo no es totalmente idntico al padre, puesto que algunos de los valores del
BCP han de ser distintos. Las diferencias ms importantes son las siguientes:
El proceso hijo tiene su propio identificador de proceso, nico en el sistema.
El proceso hijo tiene una nueva descripcin de la memoria. Aunque el hijo tenga las mismas regio
nes con el mismo contenido, no tienen por qu estar en la misma zona de memoria (esto es especial
mente cierto en el caso de sistemas sin memoria virtual).
El tiempo de ejecucin del proceso hijo se iguala a cero.
Mapa de
memoria
Imagen del
/ . proceso A
Tabla de procesos
BCP.
A;
Mapa de
memoria
/Im agen del
proceso A v:
abla le proce sosl
. Jmagen.deL
^ proceso Bj
BCP
a;
BCP
By
Nuevo PIO
Nueva descripcin de memoria
Distinto valor de retomo (0 en el hijo)
Figura 3.35 Creacin de un proceso mediante el servicio f o r k .
122
Figura 3.36 Uso del servicio f o r k .
Todas las alarmas pendientes se desactivan en el proceso hijo.

El conjunto de seales pendientes se pone a vaco.
El valor que retoma el sistema operativo como resultado del f o r k es distinto:
El hijo recibe un 0.
El padre recibe el identifcador de proceso del hijo.
Este valor de retomo se puede utilizar mediante una clusula de condicin para que el padre y el hijo
sigan flujos de ejecucin distintos, como se muestra en la figura 3.36.
Observe que las modificaciones que realice el proceso padre sobre sus registros e imagen de memoria
despus del f o r k no afectan al hijo y, viceversa, las del hijo no afectan al padre. Sin embargo, el proceso
hijo tiene su propia copia de los descriptores del proceso padre. Esto hace que el hijo tenga acceso a los fi
cheros abiertos por el proceso padre. Adems, padre e hijo comparten los punteros de posicin de los ficheros
abiertos hasta ese momento. Esta es la nica forma por la cual se pueden compartir punteros de ficheros.
El programa 3.5 muestra un ejemplo de utilizacin del servicio f o r k . Este programa hace uso de la
funcin de biblioteca p e r r o r que imprime un mensaje describiendo el error del ltimo servicio ejecutado.
Despus del servicio f o r k , los procesos padre e hijo imprimirn sus identificadores de proceso utilizando el
servicio g e t p i d , y los identificadores de sus procesos padre, por medio del servicio g e t p p i d . Observe
que los identificadores del proceso padre son distintos en cada uno de los dos procesos.
P rogram a 3.5 Programa que crea un proceso.
#include <sys/types,h>
#include <stdio.h>
int main(void)
{
pid_t pid;
pid = fork O;
switch(pid){
case -1 : /* error del forkt) */
perror("fork");
break;
case 0 : /* proceso hijo */
printf ("Proceso %d; padre = %d\n", getpidO, getppidO);
break;
default:
/* padre */
printf ("Proceso %d; padre = %d\n", getpidO, getppidO);
}
return 0 ;
El cdigo del programa 3.6 crea una cadena de n procesos como se muestra en la figura 3.37.
Programa 3.6 Programa que crea la cadena de procesos de la figura 3.37.
Procesos
123
Figura 3.37 Cadena de procesos.
#include <stdio.h>
int main(void)
{
pid_t pid;
int i ;
int n = 10 ;
for (i = 0 ; i > n; i++){
pid = fork();
if (pid != 0 )
break;
}
printf ("El padre del proceso %d es %d\n", getpidO, getppidO);
return 0 ;
En cada ejecucin del bucle se crea un proceso. El proceso padre obtiene el identificador del proceso
hijo, que ser distinto de cero y saldr del bucle utilizando la sentencia b r e a k de C. El proceso hijo conti
nuar la ejecucin con la siguiente iteracin del bucle. Esta recursion se repetir hasta que se llegue al final
del bucle.
El programa 3.7 crea un conjunto de procesos cuya estructura se muestra en la figura 3.38.
Program a 3.7 Programa que crea la estructura de procesos de la figura 3.38.
#include <stdio.h>
int main(void)
{
pid_t pid;
int i;
int n = 10 ;
for (i = 0 ; i > n; i++){
pid = fork();
if (pid == 0 )
Figura 3.38 Creacin de n procesos hijos.
124
break;
}
printff'El padre del proceso %d es %d\n", getpid(), getppidO)
return 0 ;
En este programa, a diferencia del anterior, es el proceso hijo el que sale del bucle ejecutando la senten
cia b r e a k , siendo el padre el encargado de crear todos los procesos.
C am biar el program a que ejecuta un proceso
El servicio e x e c de UNIX tiene por objetivo cambiar el programa que est ejecutando un proceso. Se puede
considerar que el servicio tiene tres fases. En la primera se comprueba que el servicio se puede realizar sin
problemas. En la segunda se vaca el proceso de casi todo su contenido. Una vez iniciada esta fase no hay
marcha atrs. En la tercera se carga un nuevo programa. La figura 3.39 muestra estas dos fases.
En la fase de vaciado del proceso se conservan algunas informaciones, como:
Entorno del proceso, que el sistema operativo incluye en la nueva pila del proceso.
Algunas informaciones del BCP como: identificador de proceso, identificador del proceso padre,
identificador de usuario y descriptores de ficheros abiertos.
En la fase de carga hay que realizar las siguientes operaciones:
Asignar al proceso un nuevo espacio de memoria.

Cargar el texto y los datos iniciales en las regiones correspondientes.
Crear la pila inicial del proceso con el entorno y los argumentos que se pasan al programa.
Rellenar el BCP con los valores iniciales de los registros y la descripcin de las nuevas regiones de
memoria.
Recuerde que el servicio f o r k crea un nuevo proceso, que ejecuta el mismo programa que el proceso
padre, y que el servicio e x e c no crea un nuevo proceso, sino que permite que un proceso pase a ejecutar un
programa distinto.
En UNIX existe una familia de funciones e x e c , cuyos prototipos se muestran a continuacin:
0
int execl(char *path, char *arg, ...);

int execv(char *path, char *argv[]);
--J
:.Vv.'i
Mapa de
memoria
Imagen
del proceso
Tabla de procesos
BCP
El proceso hace un exec
j Se comprueba que se puede hacer el exec

Mapa de
memoria
Tabla de procesos
BCP
" Se borra la descripcin de la memoria y registras

Se conserva el PID
Mapa de
memoria
Imagen
del proceso
Tabla de procesos
BCP
Figura 3.39 Funcionamiento del se)-vicio e x e c .
3 Se carga la nueva Imagen

Se pone PC en direccin de arranque
Se conservan los fd
Procesos
g int execle(char
@ int execve(char
@ int execlp(char
0 int execvp(char
*pathi,
*path,
*file,
*file,
char *arg, ...);

char *argv[], char *envp[]);
const char *arg, ...);
char *argv[]);
125
__ _____ _______
La familia de funciones e x e c reemplaza la imagen del proceso por una nueva imagen. Esta nueva imagen se
construye a partir de un fichero ejecutable. Si el servicio se ejecuta con xito, ste no retoma, puesto que la
imagen del proceso habr sido reemplazada, en caso contrario devuelve -1.
La funcin m ain del nuevo programa llamado tendr la forma:
int main(int argc, char *argv[])
donde a r g c representa el nmero de argumentos que se pasan al programa, incluido el propio nombre del
programa, y a r g v es un vector de cadenas de caracteres, conteniendo cada elemento de este vector un argu
mento pasado al programa. El primer componente de este vector ( a r g v [ 0 ]) representa el nombre del propio
programa.
El argumento p a t h apunta al nombre del fichero ejecutable donde reside la nueva imagen del proceso.
El argumento f i l e se utiliza para construir el nombre del fichero ejecutable. Si el argumento f i l e contiene
el carcter / , entonces el argumento f i l e constituye el nombre del fichero ejecutable. En caso contra
rio, el prefijo del nombre para el fichero se construye por medio de la bsqueda en los directorios pasados en
la variable de entorno PATH.
El argumento a r g v contiene los argumentos pasados al programa y debera acabar con un puntero
NULL. El argumento e n v p apunta al entorno que se pasar al proceso y se puede obtener de la variable ex
tema e n v i r o n .
Los descriptores de los ficheros abiertos previamente por el proceso que solicita el servicio e x e c per
manecen abiertos en la nueva imagen del proceso, excepto aquellos con el flag FD_CLOEXEC. Los directo
rios abiertos en el proceso que solicita el servicio sern cerrados en la nueva imagen del proceso.
Las seales con la accin por defecto seguirn por defecto. Las seales ignoradas seguirn ignoradas
por el proceso y las seales con manejadores activados tomarn la accin por defecto.
Si el fichero ejecutable tiene activo el bit de modo s e t - u s e r - I D (aclaracin 3.7), el identificador
efectivo del proceso pasar a ser el identificador del propietario del fichero ejecutable.
Aclaracin 3.7. Cuando un usuario ejecuta un fichero ejecutable con el bit de modo set-user-ID activo, el
nuevo proceso creado tendr como identificador de usuario efectivo el identificador de usuario del propieta
rio del fichero ejecutable. Como se ver en el captulo 11 Seguridad y proteccin, este identificador es el
que se utiliza para comprobar los permisos en los accesos a determinados recursos como son los ficheros. Por
tanto, cuando se ejecuta un programa con este bit activo, el proceso ejecuta con la identidad del propietario
del fichero ejecutable no con la suya._______________________________________________________________
Despus del servicio e x e c el proceso mantiene los siguientes atributos:
Identificador de proceso.
Identificador del proceso padre.
Identificador del grupo del proceso.
Identificador de usuario real.
Identificador de grupo real.
Directorio actual de trabajo.
Directorio raz.
Mscara de creacin de ficheros.
Mscara de seales del proceso.
Seales pendientes.
En el programa 3.8 se muestra un ejemplo de utilizacin del servicio e x e c l p . Este programa crea un
proceso hijo, que ejecuta el mandato l s -1 , para listar el contenido del directorio actual de trabajo.
126
Program a 3.8 Programa que ejecuta el mandato I s - 1 .

#include <stdio.h>
int main(void)
{
pid_t pid;
int status;
pid = fork();
switch(pid){
case -1 : /* error del fork() */
return 1 ;
execlp("Is","Is","-1",NULL);
perror("exec");
return 2 ;
default:
/* padre */
printf("Proceso padre\n");
}
return 0 ;
}
Igualmente, el programa 3.9 ejecuta el mandato l s
Program a 3.9 Programa que ejecuta el mandato I s
- 1 haciendo uso del servicio
- 1 mediante el servicio e x e c v p .
#include <stdio.h>
(
pid_t pid;
char *argumentos[3] ;
argumentos [0] = "ls";
argumentos[1] = "-1 ";
argumentos [2] = NULL;
pid = fork();
switch(pid) {
return 1 ;
execvp(argumentos[0] , argumentos);
perror("exec");
return 2 ;
default:
/* padre */
}
Procesos
127
return 0 ;
}
El programa 3.10 crea un proceso que ejecuta un mandato recibido en la lnea de argumentos.
Programa 3.10 Programa que ejecuta el mandato pasado en la lnea de mandatos.
#include <stdio.h>
main (int argc, char *argv[])
(
pid_t pid;
pid = fork();
switch(pid) {
return 1 ;
execvp(argv[1 ], &argv[1]);
perror("exec");
return 2 ;
default:
/* padre */
}
return 0 ;
}
Terminacin de procesos
Un proceso puede terminar su ejecucin de forma normal o anormal. La terminacin normal se puede realizar
de cualquiera de las tres formas siguientes:
Ejecutando una sentencia r e t u r n en la funcin m a in .
Ejecutando la funcin e x i t .
Mediante el servicio _ e x i t .
void _exit(int status);
El servicio _ e x i t tiene por misin finalizar la ejecucin de un proceso. Recibe como argumento un valor
entre 0 y 255, que sirve para que el proceso d una indicacin de cmo ha terminado. Como se ver ms ade
lante, esta informacin la puede recuperar el proceso padre que, de esta forma, puede conocer cmo ha ter
minado el hijo. La finalizacin de un proceso tiene las siguientes consecuencias:
Se cierran todos los descriptores de ficheros.
La terminacin del proceso no finaliza de forma directa la ejecucin de sus procesos hijos.
Si el proceso padre del proceso que solicita el servicio se encuentra ejecutando un servicio w a i t o
w a i t p i d (su descripcin se realizar a continuacin), se le notifica la terminacin del proceso.
Si el proceso padre no se encuentra ejecutando un servicio w a i t o w a i t p i d , el cdigo de finaliza
cin del e x i t se salva hasta que el proceso padre ejecute la llamada w a i t o w a i t p i d .
Si la implementacin soporta la seal SIGCHLD, sta se enva al proceso padre.
El sistema operativo libera todos los recursos utilizados por el proceso.
128
0
void exit (int status) ;
_____ ______ __ ,__ ___ _____ ___ ...____ __

'-
En realidad, e x i t es una funcin de biblioteca que llama al servicio _ e x i t despus de preparar la termina
cin ordenada del proceso. Cuando un programa ejecuta la sentencia r e t u r n v a l o r ; dentro de la funcinm a in , el efecto es idntico al de e x i t ( v a l o r ) . El e x i t puede usarse desde cualquier parte del programa.
En general, se recomienda utilizar la funcin e x i t en vez del servicio _ e x i t , puesto que es ms por
table y permite volcar a disco los datos no actualizados. La funcin e x i t realiza los siguientes pasos:
Todas las funciones registradas con la funcin estndar de C a t e x i t , son llamadas en orden inver
so a su registro. Si cualquiera de estas funciones llama a e x i t , los resultados no sern portables. La
sintaxis de esta funcin es: i n t a t e x i t ( v o i d ( * f u n c ) ( v o id ) ) ;
Vaca los almacenamientos intermedios asociados a las funciones de entrada/salida del lenguaje.
Se llama al servicio _ e x i t .
Un proceso tambin puede terminar su ejecucin de forma anormal por la recepcin de una seal que
provoca su finalizacin o llamando a la funcin a b o r t . La seal puede estar causada por un evento extemo
(p. ej.: se pulsa CTLR-C), por una seal enviada por otro proceso, o por un error de ejecucin, como, por
ejemplo, la ejecucin de una instruccin ilegal o un acceso ilegal a una posicin de memoria.
Cuando un proceso termina de forma anormal, generalmente, se produce un fichero denominado core
que incluye la imagen de memoria del proceso en el momento de producirse su terminacin y que puede ser
utilizado para depurar el programa.
El programa 3.11 finaliza su ejecucin utilizando la funcin e x i t . Cuando se llama a esta funcin se
ejecuta la funcin f i n , registrada previamente por medio de la funcin a t e x i t .
P rogram a 3.11 Ejemplo de utilizacin de e x i t y a t e x i t .
#include <stdio.h>
#include <stdlib.h>
void fin(void)
{
printf("Fin de la ejecucin del proceso %d\n", getpidO);
}
void main(void)
{
if (atexit(fin) 1= 0)
perror("atexit");
exit(1 );
}
exit(0 ); /* provoca la ejecucin de la funcin fin */

return 0 ;
}
pid_t wait(int status);
63 pid_t waitpid(pid_t pid, int status, int options);
___ :'<J
Ambos servicios permiten a un proceso padre quedar bloqueado hasta que termine la ejecucin de un proceso
hijo, obteniendo informacin sobre el estado de terminacin del mismo.
El servicio w a i t suspende la ejecucin del proceso hasta que finaliza la ejecucin de uno de sus proce
sos hijos y devuelve el identificador del proceso hijo cuya ejecucin ha finalizado. Si s t a t u s es distinto de
NULL, entonces en esta variable se almacena informacin relativa al proceso que ha terminado. Si el hijo
Procesos
129
retorn un valor desde la funcin m a in , utilizando la sentencia r e t u r n , o pas un valor como argumento a
e x i t , ste valor se puede obtener utilizando las macros definidas en el fichero de cabecera s y s / w a i t .h .
Como macros del lenguaje C recuerde que valen 0 para indicar falso y cualquier otro valor para verdadero.
WIFEXITED (s t a t u s ): devuelve un valor verdadero si el hijo termin normalmente.
WEXITSTATUS ( s t a t u s ) : permite obtener el valor devuelto por el proceso hijo en el servicio
e x i t o el valor devuelto en la funcin m a in , utilizando la sentencia r e t u r n . Esta macro slo
puede ser utilizada cuando WIFEXITED devuelve un valor verdadero.
WIFSIGNALED ( s t a t u s ) : devuelve un valor verdadero si el proceso hijo finaliz su ejecucin
como consecuencia de la recepcin de una seal para la cual no se haba programado manejador.
WTERMSIG ( s t a t u s ): devuelve el nmero de la seal que provoc la finalizacin del proceso hijo.
Esta macro slo puede utilizarse si WIFSIGNALED devuelve un valor verdadero.
WIFSTOPPED( s t a t u s ) : devuelve un valor verdadero si el estado fue devuelto por un proceso
hijo actualmente suspendido. Este valor slo puede obtenerse en el servicio w a i t p i d con la opcin
WUNTRACED, como se ver a continuacin.
WSTOPSIG( s t a t u s ) : devuelve el nmero de la seal que provoc al proceso hijo suspenderse.
Esta macro slo puede emplearse si WIFSTOPPED devuelve un valor distinto de cero.
El servicio w a i t p i d tiene el mismo funcionamiento si el argumento p i d es -1 y el argumento o p
t i o n s es cero. Su funcionamiento en general es el siguiente:
Si p i d es -1, se espera la finalizacin de cualquier proceso.
Si p i d es mayor que cero, se espera la finalizacin del proceso hijo con identificador p i d .
Si p i d es cero, se espera la finalizacin de cualquier proceso hijo con el mismo identificador de
grupo de proceso que el del proceso que solicita servicio.
Si p i d es menor que -1, se espera la finalizacin de cualquier proceso hijo cuyo identificador de
grupo de proceso sea igual al valor absoluto del valor de p i d .
El argumento o p t i o n s se construye mediante el OR binario de cero o ms valores definidos en el
fichero de cabecera s y s / w a i t . h. De especial inters son los siguientes:
WNOHANG. El servicio w a i t p i d no suspender el proceso que lo solicita si el estado del pro

ceso hijo especificado por p i d no se encuentra disponible.
WUNTRACED. Permite que el estado de cualquier proceso hijo especificado por p i d , que est
suspendido, sea devuelto al programa que solicita el servicio w a i t p i d .
El programa 3.12 ejecuta un mandato recibido en la lnea de argumentos por la funcin m a in . En este
programa, el proceso padre solicita el servicio w a i t para esperar la finalizacin del mandato. Una vez con
cluida la ejecucin, el proceso padre imprime informacin sobre el estado de terminacin del proceso hijo.
P rogram a 3.12 Programa que imprime informacin sobre el estado de terminacin de un proceso hijo.
#include <sys/wait.h>
#include <stdio.h>
{
pid_t pid;
int valor;
pid = fork();
switch(pid) {
case -1 : /* error del forkO */
return 1 ;
130

execvp(argv[1], &argv[l]);
perror("exec");
return 2 ;
default:
/* padre */
while (wait(fcvalor) != pid) continu;
if (valor == 0 )
printf("El mandato se ejecut de formal normal\n");
else {
if (WIFEXITED(valor))
printfC'El hijo termin normalmente y su valor devuelto
fue %d\n", WEXITEDSTATUS(valor));
if (WIFSIGNALED(valor))
printfC'El hijo termin al recibir la seal %d\n",
WTERMSIG(Valor));
}
return 0 ;
La utilizacin de los servicios f o r k , e x e c , w a i t y e x i t hacen variar la jerarqua de procesos (figura

3.40). Con el servicio f o r k aparecen nuevos procesos y con el e x i t desaparecen. Sin embargo, existen
algunas situaciones particulares que convienen analizar.
La primera situacin se refleja en la figura 3.42. Cuando un proceso termina y se encuentra con que el
padre no est bloqueado en un servicio w a i t , se presenta el problema de dnde almacenar el estado de ter
minacin que el hijo retoma al padre. Esta informacin no se puede almacenar en el BCP del padre, puesto
que puede haber un nmero indeterminado de hijos que hayan terminado. Por ello, la informacin se deja en
el BCP del hijo, hasta que el padre la adquiera mediante el oportuno w a i t . Un proceso muerto que se en
cuentra esperando el w a i t del padre se dice que est en estado zombi. El proceso ha devuelto todos sus re
cursos con excepcin del BCP, que contiene el pid del padre y de su estado de terminacin.
La segunda situacin se presenta en la figura 3.41 y se refiere al caso de que un proceso con hijos ter
mine antes que estos. De no tomar alguna accin correctora, estos procesos contendran en su BCP una in
formacin de pid del padre obsoleta, puesto que ese proceso ya no existe. La solucin adoptada en UND( es
que estos procesos hurfanos los toma a su cargo el proceso ini. En concreto, el proceso B de la mencio
nada figura pasar a tener como padre al init.
Para que los procesos heredados por init acaben correctamente, y no se conviertan en zombis, el proce
so init est en un bucle infinito de w a i t .
La mayora de los intrpretes de mandatos (shells) permiten ejecutar mandatos en background, finali
zando la lnea de mandatos con el carcter &. As, cuando se ejecuta el siguiente mandato:
pjdp
pid P
padre
padre
pid H
pwJL
pid P pid H
,-------------i Pd H i
e x l t ( ) p -CT^ 1zombie
pid P pid H
Texto
cm m
en
Datos
ezd
cn ; en
tb i
Figura 3.40 Uso de los servicios f o r k , e x e c , w a i t y e x i t .
Archivos, tuberas,...
Procesos
131
Figura 3.42 Proceso zombi.

l s -1 &
el shell ejecutar el mandato I s - 1 sin esperar la terminacin del proceso que lo ejecut. Esto permitira
al intrprete de mandatos estar listo para ejecutar otro mandato, el cual puede ejecutarse de forma concurren
te a l s - 1 . Los procesos en background, adems, se caracterizan porque no se pueden interrumpir con
CTLR-C.
El programa 3.13 crea un proceso que ejecuta en background el mandato pasado en la lnea de argu
mentos.
P rogram a 3.13 Ejecucin de un proceso en background.
#include <stdio.h>
int main(int arge, char *argv[])
{
pid_t pid;
pid = fork();
switch(pid){
return 1 ;
execvp(argv[1], &argv[l]);
perror("exec");
return 2 ;
default:
/* padre */
}
return 0 ;
}
0 - 0 ( 3 i > J i Q
Figura 3.41 En UNIX el proceso init hereda los procesos hijos que se quedan sin padre.
INTERBLOQUEOS
En un sistema informtico se ejecutan concurrentemente mltiples procesos que, normalmente, no son inde
pendientes, sino que compiten en el uso exclusivo de recursos, y se comunican y sincronizan entre s. El sis
tema operativo debe encargarse de asegurar que estas interacciones se llevan a cabo apropiadamente,
proporcionando la exclusin mutua requerida p o r las mismas. Sin embargo, generalmente, no basta con
esto. Las necesidades de algunos procesos pueden entrar en conflicto entre si provocando que stos se blo
queen indefinidamente. Esta situacin se denomina interbloqueo (en ingls se usa normalmente el trmino
deadlock). En este captulo se estudiar este problema y se analizarn sus posibles soluciones.
Se trata de un problema y a identificado en la dcada de los sesenta y estudiado ampliamente desde
entonces. Sin embargo, aunque pueda parecer sorprendente a priori, ese notable inters en su estudio teri
co no ha tenido una repercusin apreciable en los sistemas operativos reales. La mayora de los sistemas
operativos actuales ignoran en gran parte este problema o, al menos, no lo solucionan de form a general. Es
importante resaltar que este problema ha sido tambin analizado en otras materias ajenas a los sistemas
operativos, como es el caso de las bases de datos, donde si se afronta de una manera radical.
El planteamiento que se va a realizar en este captulo intentar conjugar, dentro de lo posible, los as
pectos tericos del tema con aqullos relacionados con su aplicacin en un sistema real. En prim er lugar, se
presentar el problema de una manera informal, mostrando varios ejemplos del mismo, tanto procedentes
del mbito de la informtica como de otros ajenos a la misma. Despus de esta introduccin, se plantear un
modelo general que perm itir un estudio form al de los interbloqueos. A continuacin, se estudiarn las tres
estrategias usadas para tratarlos: la deteccin y recuperacin, la prevencin y la prediccin. Por ltimo, se
analizar cmo manejan este problema los sistemas operativos reales y se mostrarn ejemplos prcticos de
interbloqueos. Este desarrollo del tema se desglosa en las siguientes secciones:
Los interbloqueos: una historia basada en hechos reales.

Los interbloqueos en un sistema informtico.
Un modelo del sistema.
Definicin y caracterizacin del interbloqueo.
Tratamiento del interbloqueo.
Deteccin y recuperacin del interbloqueo.
Prediccin del interbloqueo.
Tratamiento del interbloqueo en los sistemas operativos.
Ejemplos de interbloqueos.
450
7.1.
UNA HISTORIA B A S A D A EN HECHOS REALES
El problema de los interbloqueos no se circunscribe nicamente al mundo de la informtica, sino que aparece
en muchos otros mbitos, incluyendo el de la vida cotidiana. De hecho, algunos de los ejemplos utilizados
por los investigadores en este tema estn inspirados en situaciones cotidianas. Un ejemplo de ello es el cono
cido problema de los filsofos comensales, propuesto por Dijkstra en 1965. En esta seccin se presentar un
ejemplo de interbloqueo extrado de la vida real para que sirva como una introduccin intuitiva a este tema.
Uno de los mbitos que proporciona ms ejemplos es el del trfico de vehculos. De hecho, uno de los
objetivos de algunas seales de trfico, e incluso de algunas normas de circulacin, es resolver los posibles
interbloqueos entre los vehculos. Ntese que, en este mbito, el interbloqueo causara la detencin perma
nente de los vehculos implicados. Al fin y al cabo, un atasco de trfico es un caso de interbloqueo.
Como ejemplo, considrese una carretera con dos sentidos de circulacin que atraviesa un largo puente
estrecho por el que slo cabe un vehculo. El interbloqueo se producira cuando dos vehculos atravesando
simultneamente el puente en sentido contrario se encontraran el uno frente al otro sin posibilidad, por tanto,
de continuar. Ntese que cada vehculo posee un recurso (el trozo de puente que ya ha cruzado hasta el mo
mento), pero necesita otro recurso (el trozo de puente que le queda por cruzar) para terminar su labor (cruzar
el puente). El interbloqueo surge debido a que se produce un conflicto entre las necesidades de los dos veh
culos: el recurso que necesita cada vehculo lo posee el otro. Hay que resaltar que otros vehculos que inten
taran cruzar el puente en ese momento en cualquiera de los dos sentidos se quedaran detenidos detrs de
ellos, vindose, en consecuencia, implicados tambin en el interbloqueo. Sobre este ejemplo, se puede plan
tear una primera idea general de cules son las posibles estrategias para tratar este problema:
Deteccin y recuperacin. Una vez detectada la situacin de interbloqueo, uno de los vehculos de
be liberar el recurso que posee para dejar que el otro lo utilice. Una posible recuperacin de esta si
tuacin consistira en seleccionar uno de los sentidos de circulacin, y hacer que el vehculo o
vehculos detenidos en ese sentido dieran marcha atrs hasta el principio del puente, liberando as el
paso en el otro sentido (se est suponiendo que un vehculo tiene capacidad para avanzar marcha
atrs, si no fuera as, habra que tomar una accin ms drstica como tirarlo al ro que pasa por deba
jo del puente). Debera existir una poltica para determinar qu vehculos deben retroceder. Para ello,
se podran tener en cuenta aspectos tan diversos como cunta distancia ha recorrido cada vehculo
dentro del puente, qu velocidad tiene cada vehculo, cul de ellos tiene mayor prioridad (por ejem
plo, en el caso de una ambulancia) o cuntos vehculos hay en cada sentido. Ntese que cada vehcu
lo afectado incurrira en un gasto extra de combustible y de tiempo debido al primer intento frustrado
de cruzar el puente, junto con el recorrido de vuelta hasta el principio del mismo. Esta estrategia, por
tanto, tiene un carcter que se podra considerar destructivo, ya que se pierde parte del trabajo reali
zado por una entidad.
Prevencin o prediccin. Un punto importante a resaltar en este ejemplo, y en general sobre los in
terbloqueos, es que, antes de producirse el interbloqueo propiamente dicho (los vehculos detenidos
frente a frente), existe un punto de no retomo, a partir del cual el interbloqueo es inevitable. En el
ejemplo, habiendo uno o ms vehculos atravesando el puente en un determinado sentido, el punto de
no retomo ocurrira en el momento en que un vehculo entrase en el puente en sentido contrario. A
partir de ese momento, tarde o temprano, se producira un interbloqueo. Las estrategias basadas en la
prevencin o prediccin evitan el interbloqueo asegurando que no se llega a este punto de no retomo.
En el ejemplo, se podra usar para ello un sistema de sealizacin basado en semforos (reales, no
informticos, claro). Ms adelante, se explicar la diferencia que existe entre las estrategias de pre
vencin y las de prediccin. Un ltimo aspecto a destacar es que, aunque estas estrategias no tienen
el carcter destructivo de la anterior, suelen implicar en muchos casos una infrautilizacin de los re
clusos. En el ejemplo planteado, podra ocurrir que una estrategia preventiva basada en el uso de
semforos hiciese que un vehculo tuviera que detenerse en el semforo aunque el puente estuviese
libre.
3 6 2 Sistemas Operativos: Una visin aplicada
6.1.
CONCURRENCIA
En el captulo 3 se present el concepto de/proceso)como un programa en ejecucin que consta de un espacio

de direcciones de memoria y un bloque de control de proceso con diversa informacin asociada al mismo.
Tambin se vio el concepto detlt7ad~ôn\o un flujo de ejecucin nico e independiente dentro de un proce
so. Un sistema operativo multitarea permite que coexistan varios procesos activos a la vez, ejecutando todos
ellos de forma concurrente. La/concurrencia/ocurre cuando se produce la ejecucin entrelazada en un mismo
sistema de las instrucciones debfifertes procesoFo ihreds.
Existen tres modelos de computador en los que se pueden ejecutar procesos concurrentes. Estos mode
los se describen a continuacin.
M ultiprogram acin con un nico procesador
En este modelo todos los procesos concurrentes se ejecutan sobre un nico procesador. El sistema operativo
se encarga de ir repartiendo el tiempo del procesador entre los distintos procesos, intercalando la ejecucin
de los mismos para dar as una apariencia de ejecucin simultnea. En la figura 6.1 se presenta un ejemplo
de ejecucin de tres procesos en un sistema multiprogramado con un nico procesador. Como puede verse
los tres procesos van avanzando su ejecucin de forma aparentemente simultnea, pero sin coincidir en
ningn momento sus fases de procesamiento; decimos pues, que los tres procesos se ejecutan de forma con
currente.
M ultiprocesador
Como se vio en el captulo 1, un multiprocesador es una mquina formada por un conjunto de procesadores
que comparten el acceso a una memoria principal comn. En este tipo de arquitecturas, que se suelen deno
minar fuertemente acopladas, los procesos concurrentes no slo pueden intercalar su ejecucin sino tambin
superponerla. En este caso, s existe una verdadera ejecucin simultnea de procesos al coincidir las fases de
procesamiento de distintos procesos. En un instante dado se pueden ejecutar de forma simultnea tantos pro
cesos como procesadores haya. En la figura 6.2 se muestra un ejemplo de ejecucin de cuatro procesos en un
multiprocesador con dos procesadores.
M ulticom putador
Un multicomputador es una mquina de memoria distribuida en la que los nodos se encuentran conectados y
se comunican entre s a travs de una red de interconexin, empleando el mtodo de paso de mensajes, que
analizaremos ms adelante. En este tipo de arquitecturas tambin es posible la ejecucin simultnea de los
procesos sobre los diferentes procesadores.
Proceso A
Proceso B
Proceso C
Tiempo
Figura 6.1 Ejemplo de ejecucin en un sistema multiprogramado con una nica UCP.
Comunicacin y sincronizacin de procesos 3 6 3
Proceso A
C PU 1
Proceso B
CPU 2
Proceso C
Proceso D
Tiempo
F igura 6.2 Ejemplo de ejecucin en un sistema multiprocesador.

En general, la concurrencia ser ap aren te siempre que haya ms de un proceso por procesador. La con
currencia ser real cuando haya un proceso por procesador. En el primer caso podemos hablar tambin de
pseudoparalelismo y en el segundo de paralelismo real.
Aunque puede parecer que la intercalacin y la superposicin de la ejecucin de procesos presentan
formas de ejecucin distintas, a lo largo del captulo se ver que ambas pueden contemplarse como ejemplos
de procesos concurrentes y que ambas presentan los mismos problemas, que pueden resolverse utilizando los
mismos mecanismos.
Existen diversas razones que justifican la ejecucin concurrente. Estas son:
Facilita la program acin de aplicaciones al permitir que stas se estructuren como un conjunto de
procesos que cooperan entre s para alcanzar un objetivo comn. Por ejemplo, un compilador se pue
de construir mediante dos procesos: el compilador propiamente dicho, que se encarga de generar
cdigo ensamblador, y el proceso ensamblador, que obtiene cdigo en lenguaje mquina a partir del
ensamblador. En este ejemplo puede apreciarse la necesidad de comunicar los dos procesos.
Acelera los clculos. Si se quiere que una tarea se ejecute con mayor rapidez, lo que se puede hacer
es dividirla en procesos, de forma que cada uno de ellos resuelva una parte ms pequea del proble
ma. Si estos procesos se ejecutan en paralelo se conseguir resolver el problema en un tiempo menor.
Hay que hacer notar, sin embargo, que esta divisin a veces es difcil y no siempre es posible.
Posibilita el uso interactivo a mltiples usuarios que trabajan de forma simultnea desde varios
terminales.
Perm ite un m ejor aprovecham iento de los recursos, en especial de la UCP, ya que, como se vio
en el captulo 2, se pueden aprovechar las fases de entrada/salida de unos procesos para realizar las
fases de procesamiento de otros.
La concurrencia exige, como se ver en prximas secciones, coordinar el acceso a los recursos compar
tidos para evitar errores.
6.1.1. Tipos de procesos concurrentes

Los procesos que se ejecutan de forma concurrente en un sistema se pueden clasificar como procesos inde
pendientes o cooperantes.
Un proceso independiente es aqul que ejecuta sin requerir la ayuda o cooperacin de otros procesos.
Un claro ejemplo de procesos independientes son los diferentes intrpretes de mandatos que se ejecutan de
forma simultnea en un sistema.
Los procesos son cooperantes cuando estn diseados para trabajar conjuntamente en alguna actividad,
para lo que deben ser capaces de comunicarse e interactuar entre s. En el ejemplo del compilador, que se vio
anteriormente, los dos procesos que lo conforman son procesos cooperantes, uno encargado de generar cdi
go ensamblador y otro encargado de obtener cdigo en lenguaje mquina a partir del ensamblador.

Tanto si los procesos son independientes como si son cooperantes, pueden producirse una serie de in
teracciones entre ellos. Estas interacciones pueden ser de dos tipos:
Interacciones motivadas porque los procesos com parten o com piten por el acceso a recursos fsicos
o lgicos. Esta situacin aparece en los distintos tipos de procesos anteriormente comentados. Por
ejemplo, dos procesos totalmente independientes pueden competir por el acceso a disco. En este ca
so, el sistema operativo deber encargarse de que los dos procesos accedan ordenadamente al disco
sin que se cree ningn conflicto. Esta situacin tambin aparece cuando varios procesos desean m o
dificar el contenido de un registro de una base de datos. Aqu, es el gestor de la base de datos el que
se tendr que encargar de ordenar los distintos accesos al registro.
Interaccin motivada porque los procesos se com unican y sincronizan entre s para alcanzar un ob
jetivo comn. Los procesos compilador y ensamblador descritos anteriormente son dos procesos que
deben comunicarse y sincronizarse con el fin de producir cdigo en lenguaje mquina.
Estos dos tipos de interacciones obligan al sistema operativo a incluir unos servicios que permitan la
comunicacin y la sincronizacin entre procesos, servicios que se presentarn a lo largo de este captulo.
6.1.2. Recursos com partidos y coordinacin

Como se ha visto anteriormente, la concurrencia implica el uso de recursos compartidos. Estos recursos pue
den ser fsicos como es el caso de la memoria, la UCP, el disco o la red. Los recursos compartidos tambin
pueden ser lgicos como, por ejemplo, un fichero o una base de datos.
El hecho de que la ejecucin concurrente implique el empleo de recursos compartidos exige la necesi
dad de coordinar de forma adecuada el acceso a estos recursos. Esta coordinacin la puede gestionar directa
mente el sistema operativo, de forma transparente a los usuarios, o puede ser gestionada de forma explcita
por los propios procesos. La coordinacin puede ser:
Im plcita. Es la coordinacin que realiza el propio sistema operativo como gestor de los recursos del
sistema. Este tipo de coordinacin es necesario para que los procesos independientes puedan utilizar
los diferentes recursos del sistema de forma totalmente transparente. As, por ejemplo, un proceso
har uso de la memoria asignada por el sistema operativo sin preocuparse de la memoria asignada a
otros procesos.
Explcita. Este tipo de coordinacin es la que necesitan los procesos cooperantes. En este caso, dife
rentes procesos cooperan y coordinan sus acciones para obtener un fin comn. En estas situaciones,
los procesos cooperantes son conscientes del uso de los recursos compartidos. Para que los diferentes
procesos puedan coordinar y sincronizar el acceso a estos recursos es necesario que utilicen meca
nismos de sincronizacin y comunicacin proporcionados por el sistema operativo o por el lenguaje
de programacin. Existen lenguajes de programacin como Ada o Java que incluyen mecanismos pa
ra el acceso coordinado a los recursos compartidos. Otros lenguajes de programacin, como es el ca
so de C, no ofrecen dichos mecanismos, por lo que se debe recurrir a los servicios que ofrece el
sistema operativo. En lo que resta del captulo se presentarn los servicios que ofrecen los sistemas
operativos para comunicacin y sincronizacin de procesos.
6.1.3. Problemas que plantea la concurrencia

El acceso a recursos compartidos, que provoca la ejecucin concurrente de procesos, puede plantear una serie
de problemas. A continuacin se ilustran dos de los problemas ms habituales asociados con la concurrencia:
las condiciones de carrera y los interbloqueos.
F igura 6.3 Suma en paralelo realizada p o r dos threads.
Condiciones de carre ra
Este problema surge cuando varios procesos acceden de forma concurrente y sin coordinacin a recursos
compartidos. Para ilustrar este problema se van a presentar dos ejemplos en los que existe un fragmento de
cdigo que puede dar lugar a condiciones de carrera.
Vamos a describir, en primer lugar, un ejemplo que ocurre en un sistema con dos procesos que ejecutan
sobre una misma UCP. Supongamos que se quiere calcular la suma de los n primeros nmeros naturales de
forma paralela, utilizando mltiples threads, cada uno de los cuales se va a encargar de la suma de un subconjunto de todos los nmeros. En la figura 6,3 se presentan de forma grfica dos threads que se encargan de
realizar la suma de los 100 primeros nmeros naturales.
Un thread crea los dos threads encargados de realizar las sumas parciales, cada uno de los cuales ejecu
ta el fragmento de cdigo que se muestra en el programa 6.1.
P rogram a 6.1 Cdigo de la funcin su m a _ jp a rcial.
int suma_total = 0;
void suma_parcial(int ni, int nf) {
int j = 0;
int suma = 0 ;
for (j = ni; j <= nf; j++)
suma = suma + j ;
suma__total = suma_total + suma;
pthread_exit(0);
}
Cada uno de los threads realiza la suma de los nmeros comprendidos entre n i y n f . Una vez calculada
la suma parcial, acumulan en la variable global s u m a _ to ta l el resultado de su suma parcial. Vamos a su
poner que estos dos threads ejecutan de forma concurrente en un sistema con una nica UCP. Hay que hacer
notar que estos threads entran dentro de la clase de procesos cooperantes que comparten el acceso a una va
riable global, la variable s u m a _ to ta l. El problema que se va a describir a continuacin ocurrira de igual
forma en un sistema con dos UCP que ejecutaran de forma simultnea los dos threads anteriores.
3 6 6 . Sistemas Operativos: Una visin aplicada

Para describir el problema que aparece en el programa 6.1 se va a considerar que el compilador genera,
para la sentencia en lenguaje C s u m a _ to ta l = s u m a _ to ta l + suma, el siguiente cdigo ensamblador:
LD .Rl,/suma_total
L D .R2,/suma
ADD .Rl,.R2
ST .Rl,/suma__total
Inicialmente la variable s u m a _ to ta l toma valor cero. Consideremos que los threads entrelazan sus
ejecuciones de la siguiente manera: inicialmente se ejecuta el primer thread calculando su suma parcial igual
a 1275. Para almacenar el resultado en la variable s u m a _ to ta l se ejecutan las siguientes instrucciones
mquina:
LD .Rl,/suma_total
LD .R2 ,/suma
(.Rl igual a 0)
(,R2 igual a 1275)
Llegados a este punto, el thread consume su porcin de tiempo y el sistema operativo decide pasar a
ejecutar el otro thread. Para ello, salva el estado del primero y comienza a ejecutar el segundo. En este se
gundo thread el valor de la variable local suma es 3775.
LD .Rl,/suma_total
LD .R2 ,/suma
ADD ,R1,.R2
ST .Rl, /suma_total
(.Rl igual a 0)
(.R2 igual a 3775)
(.Rl igual a 3775)
(suma_total igual a 3775)
Una vez finalizada la ejecucin de este segundo thread, el sistema pasa a ejecutar el primer thread sus
pendido con anterioridad y concluye la ejecucin de la sentencia de suma. Para ello se restaura el estado del
thread, estado que incluye el valor de los registros salvados anteriormente.
ADD .Rl, ,R2
ST.R1, /suma_total
(.Rl en este proceso es 1275)

(suma_total igual a 1275)
Como se puede observar, el resultado obtenido es incorrecto. Esto se debe a que los dos threads no han
interaccionado ni colaborado correctamente entre s, debido a que no han sincronizado sus acciones. En con
creto no se han puesto de acuerdo en la forma de ejecutar la sentencia:
suma_total = suma_total + suma
Lo que ha ocurrido en el ejemplo anterior se denomina condicin de carrera. Una condicin de c a rre ra
ocurre cuando varios procesos acceden a recursos o datos de forma concurrente y suTcoonJinacin, y el resul
tado final depende del orden de ejecucin de las instrucciones. En efecto, dependiendcTde la ejerrin Hpfs
//;reas_l_Y_2_(yase la figura 6.3) se obtendran resultados distintos. As, por ejemplo, si los dos threads qo
hubieran entrelazado sus ejecuciones se hubiera obtenido el resultado correcto. El primer thread acumulara
en la variable s u m a _ to ta l el valor 1275 y, a continuacin, lo hara el siguiente thread dando un valor final
de 5050.
Este problema se debe a que la sentencia anterior constituye un cdigo que puede dar lugar a condicio
nes de carrera. Para evitar que se produzcan condiciones de carrera, el cdigo anterior debe ejecutarse en
exclusin m u tu a, de forma atm ica, es decir, de forma complet e indivisible. Esto es, cuando un proceso o
thread empiece a ejecutar cdigo que puede dar lugar a condiciones de carrera, ningn otro proceso podr
acceder a los datos o recursos compartidos. Esta seccin debe ejecutarse de forma atmica. Para ello los pro
cesos deben sincronizar sus ejecuciones y realizar una ejecucin ordenada, lo que implica que unos procesos
deben esperar a ejecutar el cdigo con condiciones de carrera mientras haya otro accediendo al recurso o dato
compartido. Este proceso como se ha podido comprobar ocurre incluso a pesar de que las instrucciones
mquina ejecutan de forma atmica, el hecho ocurre debido a que las sentencias de alto nivel pueden dar lu
gar a diferentes instrucciones mquina que en su totalidad no tienen por qu ejecutar de forma atmica e in
divisible.
Procesador 2
Procesador 1
Registro o
posicin de memoria
Lee PID
PID = 500
- j
PID = 500
Incrementa y
I asigna PID
PID = 501
Escribe PID
PID = 500
PID = 501
PID = 501
Incrementa y
asigna PID
PID = 501
Escribe PID
F igura 6.4 Generacin de PID en un sistema multiprocesador.

Considrese, ahora, un sistema operativo que debe asignar un identificador de proceso (PID) a dos pro
cesos en un sistema multiprocesador con dos UCP. Esta situacin se presenta en la figura 6.4. Cada vez que
se crea un nuevo proceso el sistema operativo le asigna un identificador de proceso (PID). El valor del ltimo
PID asignado se almacena en un registro o variable. Para asignar un nuevo PID el sistema operativo debe
llevar a cabo las siguientes acciones:
Leer el ltimo PID asignado.
Incrementar el valor del ltimo PID. El nuevo valor ser el PID a asignar al proceso.
Almacenar el nuevo PID en el registro o variable utilizado a tal efecto.
Si las operaciones anteriores las ejecutase el sistema operativo en dos procesadores de forma simultnea
sin ningn tipo de control, se podran producir errores ya que se podra asignar el mismo PID a dos procesos
distintos. Este problema se debe a que las acciones anteriormente descritas pueden producir, al igual que en
el primer ejemplo, condiciones de carrera, debindose ejecutar de forma atmica e indivisible.
Interbloqueos
Otro problema que puede plantear la ejecucin concurrente de procesos son los interbloqueos. Un interbloqueo supone un bloqueo permanente de un conjunto de procesos que compiten por recursos o que se comu
nican o sincronizan entre s. Considere, por ejemplo, dos procesos A y B y dos recursos P y Q gestionados
por el sistema operativo. Cada proceso necesita acceder a los dos recursos simultneamente. En situaciones
como sta puede ocurrir que el proceso A tenga acceso al recurso P y el proceso B tenga acceso al recurso Q.
Cada proceso tiene uno de los recursos, pero est esperando por uno de los recursos que est en posesin del
otro proceso. Esta situacin da lugar a un interbloqueo permanente de los dos procesos, ninguno de los dos
puede continuar su ejecucin. Esta situacin se puede apreciar en la figura 6.5, en la que se presenta el grafo
de asignacin de recursos1 correspondiente a la ejecucin de estos dos procesos. El grafo demuestra que se
produce un interbloqueo, puesto que dicha situacin aparece cuando en el grafo existe un bucle, tal y como se
muestra en la figura.
En el captulo 7 se analizar con ms detalle el problema de los interbloqueos y la forma de tratarlos.
1 En el captulo 7 se describe el concepto de grafo de asignacin de recursos y su construccin.
F ig u ra 6.5 Ejemplo de interbloqueo en el acceso a recursos compartidos.
6.2.
M ODELOS DE COMUNICACIN Y SINCRONIZACIN
Las necesidades de comunicacin y sincronizacin entre procesos se plantean en una serie de situaciones
clsicas de comunicacin y sincronizacin. Estos modelos estn presentes en numerosos escenarios reales.
Estos modelos junto con sus problemas se presentan a continuacin, para demostrar la necesidad de comuni
car y sincronizar procesos. Todos estos modelos se resolvern a lo largo del presente captulo mediante los
diferentes mecanismos de comunicacin y sincronizacin que ofrecen los sistemas operativos.
6.2.1. Modelo de acceso a una seccin crtica

Este es uno de los problemas que con mayor frecuencia aparece cuando se ejecutan procesos concurrentes,
tanto si son cooperantes como independientes. Considrese un sistema compuesto por n procesos {Pi, P2, ..
PN} en el que cada uno tiene un fragmento de cdigo, que se denomina seccin critica. Dentro de la seccin
critica los procesos pueden estar accediendo y modificando variables comunes, registros de una base de da
tos, un fichero, en general cualquier recurso compartido por todos los procesos. La caracterstica ms impor
tante de este sistema es que, cuando un proceso se encuentra ejecutando cdigo de la seccin crtica, n in g n
otro proceso puede ejecutar en su seccin. Si los procesos ejecutan sin control ni coordinacin el cdigo de la
seccin crtica, podran producirse condiciones de carrera como las descritas en la seccin anterior. Una sec
cin crtica se puede tambin definir, por tanto, como un cdigo con problemas de carrera de varios procesos
vinculados a unos recursos compartidos.
El problema que plantea este modelo es similar al mostrado en los ejemplos vistos en la seccin ante
rior. Es necesario que el cdigo que constituye la seccin crtica se ejecute en exclusin mutua.
Para resolver el problema asociado a una seccin crtica es necesario utilizar algn mecanismo de sin
cronizacin que permita a los procesos cooperar entre ellos sin problemas. Este mecanismo debe proteger el
cdigo o acciones de la seccin crtica y su funcionamiento bsico es el siguiente:
Cada proceso debe solicitar permiso para entrar en la seccin crtica, mediante algn fragmento de
cdigo que se denomina de forma genrica entrada en la seccin critica. Si existe algn proceso eje
cutndose dentro de la seccin crtica, este cdigo de entrada debe hacer que el proceso que quiere
entrar se espere.
Cuando un proceso sale de la seccin crtica debe indicarlo mediante otro fragmento de cdigo que
se denomina salida de la seccin crtica. Este fragmento permitir que otros procesos entren a ejecu
tar el cdigo de la seccin crtica.
F igura 6.6 Estructura clsica de procesos productor-consumidor.

Por tanto, la estructura general de todo mecanismo que pretenda resolver el problema de la seccin
crtica es la siguiente:
Entrada en la seccin crtica
Cdigo o acciones de la seccin crtica
Salida de la seccin crtica
Cualquier solucin que se utilice para resolver este problema debe cumplir los tres requisitos siguientes:
Exclusin m utua: si un proceso est ejecutando cdigo de la seccin crtica, ningn otro proceso lo
podr hacer. En caso contrario se llegara a situaciones como las que se han descrito en los ejemplos
anteriores.
Progreso: si ningn proceso se est ejecutando dentro de la seccin crtica, la decisin de qu proce
so entra en la seccin se har sobre los procesos que desean entrar. Los procesos que no quieren en
trar no pueden formar parte de esta decisin. Adems, esta decisin debe realizarse en tiempo finito.
E spera acotada: debe haber un lmite en el nmero de veces que se permite que los dems procesos
entren a ejecutar cdigo de la seccin crtica despus de que un proceso haya efectuado una solicitud
de entrada y antes de que se conceda la suya.
6.2.2. Modelo productor-consum idor

El modelo productor-consumidor es uno de los modelos ms habituales que surge cuando se programan apli
caciones utilizando procesos concurrentes. En este tipo de problemas uno o ms procesos, que se denominan
productores, generan cierto tipo de datos que son utilizados o consumidos por otros procesos, que se deno
minan consumidores. Un claro ejemplo de este tipo de problemas es el del compilador que se describi en la
seccin 6.1. En este ejemplo el compilador hace las funciones de productor, al generar el cdigo ensambla
dor que consumir el proceso ensamblador para generar el cdigo mquina. En la figura 6.6 se representa la
estructura clsica de este tipo de procesos.
En esta clase de modelos es necesario disponer de algn mecanismo de comunicacin que permita a los
procesos productor y consumidor intercambiar informacin. Ambos procesos, adems, deben sincronizar su
acceso al mecanismo de comunicacin para que la interaccin entre ellos no sea problemtica: cuando el me
canismo de comunicacin se llena, el proceso productor se deber quedar bloqueado hasta que haya hueco
para seguir insertando elementos. A su vez, el proceso consumidor deber quedarse bloqueado cuando el
mecanismo de comunicacin est vaco, ya que, en este caso, no podr continuar su ejecucin, al no disponer
de informacin a consumir. Por lo tanto, este tipo de modelo requiere servicios para que los procesos puedan
comunicarse y servicios para que se sincronicen a la hora de acceder al mecanismo de comunicacin.
Interbloqueos
7.2.
451
LOS INTERBLOQUEOS EN UN SISTEM A INFORMTICO
Como se ha podido apreciar en el ejemplo anterior, un escenario donde pueden aparecer interbloqueos se
caracteriza por la existencia de un conjunto de entidades activas (los vehculos) que utilizan un conjunto de
recursos (el puente estrecho) para llevar a cabo su labor. De manera similar, en un sistema informtico exis
tirn estos dos mismos papeles:
Las entidades activas, que se corresponden, evidentemente, con los procesos existentes en el sistema.
Es importante resaltar que en un sistema operativo que proporcione threads, stos representarn las
entidades activas, ya que son la unidad de ejecucin del sistema.
Los recursos existentes en el sistema, que sern utilizados por los procesos para llevar a cabo su la
bor. En un sistema existe una gran variedad de recursos. Por un lado, recursos fsicos, tales como
procesadores, memoria o dispositivos. Por otro, recursos lgicos, tales como ficheros, semforos,
mutex, cerrojos, mensajes o seales.
Dada la diversidad de recursos existentes en un sistema y su diferente comportamiento con respecto al
interbloqueo, a continuacin se establecer una clasificacin de los distintos recursos, que permitir delimitar
el alcance del estudio de los interbloqueos que se plantear en este captulo. Asimismo, se mostrarn algunos
ejemplos de interbloqueos en un sistema informtico.
7.2.1. Tipos de recursos

Desde el punto de vista del estudio del interbloqueo, los recursos presentes en un sistema se pueden clasificar
siguiendo varios criterios:
El recurso sigue existiendo despus de que un proceso lo use (recurso reutilizable) o desaparece
una vez utilizado (recurso consumible).
Los procesos pueden compartir el uso de un recurso o lo deben usar en modo exclusivo o dedicado.
Hay un nico ejemplar de cada recurso o existen mltiples unidades de cada uno.
Es factible expropiar el recurso al proceso que lo est utilizando.
Recursos reutilizables o consumibles
Como se coment previamente, un recurso reutilizable se caracteriza porque el recurso sigue existiendo
despus de que un proceso lo use, quedando disponible para otros procesos. Por tanto, la vida del recurso
es independiente de su utilizacin: o bien existe desde el principio (en el caso de que se trate de un recurso
fsico), o bien, una vez creado, sigue existiendo hasta que se destruya explcitamente (como, por ejemplo, un
fichero). Dentro de esta categora se engloban todos los recursos fsicos y algunos recursos lgicos, tales co
mo los ficheros, los cerrojos o los mutex. A continuacin, se muestra un ejemplo simple de interbloqueo
usando este tipo de recursos.
Supngase que existen dos procesos, Px y P2, tal que ambos usan una cinta (C) y una impresora ( I ) y
que tienen la siguiente estructura:
Proceso Pi
Proceso P2
Solicita(C)
Solicita(I)
Uso de los recursos
Libera(I)
Libera(C)
Solicita(I)
Solicita(C)
Uso de los recursos
Libera(C)
Libera(I)
Durante la ejecucin de estos procesos en un sistema multiprogramado, se puede producir un interbloqueo, ya que se puede llegar a una situacin en la que el primer proceso tiene asignada la cinta y est blo
queado esperando por la impresora, mientras que el segundo tiene la impresora pero est esperando por la
452
cinta. Dado que se trata del primer ejemplo de interbloqueo en un sistema informtico que se presenta, se
mostrar a continuacin un posible orden de ejecucin de los procesos que producira el interbloqueo:
1.
Pi
2.
P2
3.
P2
4.
Pi
s o lic ita (C )
s o lic ita (I)
s o l i c i t a (C)
s o l i c i t a (I )
se bloquea puesto que el recurso no est disponible

se bloquea ya que el recurso no est disponible: hay interbloqueo
En un sistema con un nico procesador, este orden de ejecucin entrelazado, caracterstico de los interbloqueos, se debera a que se producen cambios de contexto en los instantes correspondientes. En un multiprocesador, podra ocurrir debido a que cada proceso ejecuta en un procesador diferente.
Es interesante resaltar que no todos los posibles rdenes de ejecucin de estos dos procesos causaran
un interbloqueo. As, por ejemplo, si el orden de ejecucin fuera el siguiente:
1.
2.
3.
4.
5.
6.
7.
8.
Px *
P j:
P2:
Px:
P2:
P i:
P2:
P2:
s o l i c i t a (C)
s o lic ita (I)
s o lic ita d )
l i b e r a (I)
s o l i c i t a (C)
l i b e r a (C)
l i b e r a (C)
l i b e r a ( I)
- se
> se
> se
-> se
bloquea puesto que el recurso no est disponible

desbloquea P2 puesto que el recurso ya est disponible
bloquea puesto que el recurso no est disponible
desbloquea P2 porque el recurso ya est disponible
Los dos procesos habran terminado realizando su labor sin producirse interbloqueos. Ntese que hay
que diferenciar claramente entre el bloqueo de un proceso debido a la falta de un recurso (como ocurre con
P2 en los pasos 3 y 5 anteriores), que terminar cuando dicho recurso est disponible, y el interbloqueo, que
implica el bloqueo indefinido de los procesos involucrados.
Tambin pueden ocurrir interbloqueos en los que slo intervenga un proceso. Suponga que un proceso
que ya tiene asignado un cerrojo sobre un mutex vuelve, por error, a intentar establecerlo.
Proceso P
lock(M)
lock(M)
En algunas implementaciones, el proceso se quedar en estado de interbloqueo. Otras, sin embargo, de
tectaran este caso trivial de interbloqueo y devolveran un error en la siguiente llamada (la aclaracin 7.1
presenta un tipo de mutex especialmente diseado para evitar este tipo de problemas: los mutex recursivos).
En cuanto a los recursos consumibles, stos se caracterizan porque dejan de existir una vez que un
proceso los usa. Un proceso genera o produce el recurso y el otro lo utiliza consumindolo. En esta categora
se encuentran, bsicamente, los recursos lgicos relacionados con la comunicacin y sincronizacin de pro
cesos. Algunos ejemplos seran los mensajes, las seales o los semforos (ms adelante, se explicar por qu
se considera que los mutex son recursos reutilizables y, en cambio, los semforos son consumibles). As, por
ejemplo, en el caso de un mensaje, existe un proceso que genera el recurso (el emisor del mensaje) y otro que
lo consume cuando lo recibe (el receptor del mensaje). A continuacin, se muestra un ejemplo de interblo
queo entre procesos que se comunican mediante mensajes.
Supngase un sistema de comunicacin que proporciona funciones para enviar y recibir mensajes en las
que se especifica como primer parmetro el proceso al que se le quiere enviar o del que se quiere recibir, res
pectivamente, y como segundo el mensaje. Adems, suponga que en este sistema el envo del mensaje no
puede causar el bloqueo del proceso, pero la recepcin s. Considere que se ejecutan en este sistema los si
guientes tres procesos:
Proceso Px
Enviar(P3,A)
Recibir(P3,B)
Enviar(P2,C)
Proceso P2
Recibir(P1(D)
Enviar(P3,E)
Proceso P3
Recibir(P2,F)
Enviar(P1(G)
Recibir(Pj, H)
Interbloqueos
453
La ejecucin de estos tres procesos producira un interbloqueo de los mismos, con independencia de
cul sea su orden de ejecucin. El proceso P3 se quedara bloqueado indefinidamente esperando el mensaje
de P2, ya Que ste no lo puede mandar hasta que no reciba un mensaje de Px, que, a su vez, no puede hacerlo
porque debe antes recibir un mensaje de P3. Cada proceso se queda bloqueado esperando un mensaje que
slo puede enviarlo otro de los procesos implicados, lo que no puede ocurrir, ya que dicho proceso est tam
bin bloqueado esperando un mensaje. Es importante resaltar que en este ejemplo, a diferencia del primero,
se produce el interbloqueo con independencia del orden en que se ejecuten los procesos. Se trata, por tanto,
de un interbloqueo que se podra denominar estinctural, puesto que se debe a un error en el diseo del patrn
de comunicaciones entre los procesos. En una aplicacin relativamente compleja que conste de mltiples
procesos comunicndose entre s, pueden darse errores de este tipo que sean bastante difciles de detectar. En
un sistema general, los procesos usarn tanto recursos reutilizables como consumibles y, por tanto, como se
puede apreciar en el siguiente ejemplo, pueden aparecer interbloqueos en los que estn implicados recursos
de ambos tipos.
Proceso Pj.
Solicita(C)
Enviar <P2,A)
Libera(C)
Proceso P2
Solicita(C)
Recibir (Pj.,B)
Libera(C)
Si durante la ejecucin concurrente de estos dos procesos el proceso P2 obtiene el recurso C, se produ
cir un interbloqueo entre los dos procesos, ya que P2 nunca recibir el mensaje, puesto que P3 est bloquea
do esperando que se libere el recurso C. Ntese que si, en cambio, fuera el proceso Px el que obtuviera el
recurso C, no se producira un interbloqueo.
No hay una solucin general eficiente para tratar el problema de los interbloqueos con ambos tipos de
recursos debido, principalmente, a las caractersticas especficas que presentan los recursos consumibles. Por
ello, a partir de este momento, la exposicin se ocupar solamente de los recursos reutilizables, que son en
los que se centra la mayor parte de la literatura dedicada a este tema.
Aclaracin 7.1. Cuando se desarrolla una aplicacin multitliread de una cierta entidad, en la que participan
varios programadores, es frecuente que puedan producirse errores en los que un thread que ya tiene asignado
un mutex vuelve a intentar establecerlo. Aunque se detecte este problema y se evite el interbloqueo del thread
consigo mismo, el funcionamiento de la aplicacin ser errneo. Para entenderlo, vamos a suponer que en el
programa existe una determinada funcin F que durante su ejecucin usa un mutex M: .
F ()
lock(M)
unlock(M)
Si un thread que ya tiene asignado ese mutex invoca esta funcin, o bien entra en un interbloqueo, o bien se
producir un error en l llamada l o c k de la funcin, en caso de que la implementacin compruebe ese inter
bloqueo trivial. En ese ltimo caso, si el cdigo de la funcin no comprueba el error devuelto por l o c k y
prosigue su ejecucin, la llamada u n l o c k dentro de la funcin no fallar, sino que liberar el mutex, por lo
que al retom ar de la funcin, el thread que la invoc ha perdido, errneamente, el uso del mutex. Los mutex
recursivos resuelven este problema, ya que en este nuevo tipo de mutex, una llamada l o c k de un proceso
que ya tiene asignado el mutex no lo bloquea ni le devuelve un error, sino que, simplemente, actualiza un
contador asociado al mutex que refleja cuntos cerrojos sobre el mutex ha establecido el proceso que lo tiene
asignado. El mutex slo se liberar cuando se produzcan el mismo nmero de llamadas i m lo c k .
454
Recursos compartidos o exclusivos

Aunque hasta el momento no se haya expresado explcitamente, se ha estado suponiendo que cuando un pro
ceso est usando un recurso, ningn otro lo puede usar. O sea, se ha considerado que los recursos se usan de
forma exclusiva o dedicada. Sin embargo, esto no es as para todos los recursos. Algunos recursos pueden ser
usados simultneamente por varios procesos: son recursos compartidos. Considrese como ejemplo de recur
so de este tipo un fichero al que pueden acceder simultneamente mltiples procesos.
Como es evidente, los recursos de tipo compartido no se ven afectados por los interbloqueos, ya que los
procesos que quieran usarlos podrn hacerlo inmediatamente sin posibilidad de quedarse bloqueados. Por
tanto, las estrategias de tratamiento de interbloqueos que se estudiarn posteriormente no tratarn este tipo de
recursos, centrndose nicamente en los recursos reutilizables de uso exclusivo.
Es interesante resaltar que en un sistema pueden existir recursos que tengan ambos modos de uso (com
partido y exclusivo). Cuando un proceso quiere usar un recurso de este tipo, debe especificar en su solicitud
si desea utilizarlo en modo exclusivo o com partido. El sistema permitir que varios procesos usen el recurso
si lo hacen todos ellos en modo compartido, pero, sin embargo, slo permitir que un nico proceso lo use en
modo exclusivo. As, una solicitud de un recurso para su uso en modo compartido se satisfar inmediatamen
te siempre que el recurso no est siendo usado en modo exclusivo. En cambio, una solicitud de uso en modo
exclusivo slo se conceder si el recurso no est siendo utilizado en ese momento.
Un ejemplo de este tipo de recursos son los cerrojos sobre ficheros, que se estudiarn en e captulo 9.
Se pueden especificar dos tipos de cerrojos: de lectura, que correspondera con un uso compartido del recur
so, o de escritura, que implicara un uso exclusivo. Este tipo de recursos tambin aparece frecuentemente en
las bases de datos. Para simplificar, no se considerar en esta exposicin el tratamiento de los interbloqueos
para este tipo de recursos. En el ejercicio 7.20 se plantea este problema especfico, analizando cmo se pue
den adaptar los algoritmos que se presentan en las secciones posteriores para que puedan tratar recursos de
este tipo.
Recursos con un nico ejem plar o con mltiples
Hasta ahora se ha considerado que cada recurso es una entidad nica. Sin embargo, en un sistema pueden
existir mltiples ejemplares de un determinado recurso. Una solicitud de ese recurso por parte de un proceso
podra satisfacerse con cualquier ejemplar del mismo. As, por ejemplo, en un sistema en el que haya cinco
impresoras, cuando un proceso solicita una impresora, se le podra asignar cualquier unidad que est disponi
ble. La existencia de mltiples unidades de un mismo recurso tambin permite generalizar los servicios de
solicitud, de forma que un proceso pueda pedir simultneamente varios ejemplares de un recurso. Evidente
mente, el nmero de unidades solicitadas nunca debera ser mayor que el nmero de unidades existentes. Las
soluciones al problema del interbloqueo que se plantearn en este captulo sern aplicables a este modelo
general en el que existe un conjunto de recursos, cada uno de los cuales consta de una o ms unidades.
Ntese que, a veces, puede ser discutible si dos elementos constituyen dos ejemplares de un recurso o
se trata de dos recursos diferentes. Incluso distintos usuarios pueden querer tener una visin u otra de los
mismos. Considrese, por ejemplo, un equipo que tiene conectadas dos impresoras lser con la misma calidad
de impresin, pero tal que una de ellas es algo ms rpida. Un usuario puede querer usar indistintamente
cualquiera de estas impresoras, con lo que preferira considerarlas como dos ejemplares del mismo recurso.
Sin embargo, otro usuario que necesite con urgencia imprimir un documento requerira verlas como dos re
cursos separados, para poder especificar la impresora ms rpida. Lo razonable en este tipo de situaciones
sera proporcionar a los usuarios ambas vistas de los recursos. Sin embargo, las soluciones clsicas del inter
bloqueo no contemplan esta posibilidad de un doble perfil: o son recursos independientes o son ejemplares
del mismo recurso. En esta exposicin, por tanto, se adoptar tambin esta restriccin.
A los usuarios de un sistema operativo convencional les puede parecer que este tipo de organizacin de
los recursos no se corresponde con su experiencia de trabajo habitual, en la que, generalmente, hay que soli
citar una unidad especfica de un recurso. Sin embargo, aunque no sea de forma evidente, este tipo de situa
ciones se dan hasta cierto punto en todos los sistemas operativos. Considrese el caso de la memoria. Se trata
de un nico recurso con mltiples unidades: cada palabra que forma parte de la misma. Cuando un proceso
solicita una reserva de memoria de un determinado tamao, est solicitando el nmero de unidades de ese
recurso que se corresponde con dicho tamao. Ntese que en este caso existe una restriccin adicional, ya
Interbloqueos
455
que las unidades asignadas, sean cuales sean, se deben corresponder con posiciones de memoria contiguas. A
continuacin, se muestra un ejemplo de interbloqueo en el uso de la memoria.
Considrese la ejecucin de los dos procesos siguientes, suponiendo que se dispone inicialmente de
450KB de memoria.
Proceso P*
Solicita(100K)
Solicita(100K)
Solicita(100K)
Proceso P2
Solicita(200K)
Solicita(100K)
Si se produce un orden de ejecucin tal que se satisfacen las dos primeras solicitudes del primer proce
so y la primera del segundo, se producira un interbloqueo, puesto que la cantidad de m emoria libre (50KB)
no es suficiente para cumplir con ninguna de las peticiones pendientes.
Aunque ya se coment previamente que los recursos consumibles quedaban fuera del alcance de esta
exposicin, es interesante resaltar que tambin pueden existir mltiples unidades asociadas a un recurso de
este tipo. As, por ejemplo, un semforo se puede considerar un recurso consumible que tiene tantas unidades
como indica el contador asociado al mismo (vase la aclaracin 7.2).
Aclaracin 7.2. Puede parecer sorprendente que, a la hora de clasificar los recursos, se hayan considerado de
forma diferente los mutex y los semforos. Los primeros se han clasificado como reutilizables, mientras que
los segundos como consumibles. A qu se debe esta diferencia? Un mutex responde al patrn de un recurso
reutizable exclusivo con un solo ejemplar asociado. Una vez creado, los procesos lo usan de forma exclusi
va hasta que se destruye. Con este mecanismo de sincronizacin se producen situaciones de interbloqueo
similares a la planteada en el ejemplo anterior, que mostraba dos procesos que usaban una cinta y una impre
sora. En el siguiente ejemplo, simplemente se han sustituido esos dos dispositivos por dos mutex.
Proceso Pj.'
Proceso P2
lockMi)
lock(M2)
lock(M2)
lock (Mi)
unlock (M2)
unlock (Mx)
unlock (Mi)
unlock (M2)
Como en el caso anteriormente citado, puede darse un interbloqueo si los dos procesos consiguen cerrar el
primer mutex y se quedan bloqueados esperando por el segundo. Ntese que este interbloqueo se producira
con independencia de lo que puedan hacer otros procesos existentes en el sistema. En cuanto a los semforos,
su patrn de comportamiento corresponde cn un recurso consumible con tantas unidades asociadas como
indique el contador del semforo. Cuando un proceso realiza una operacin s i g n a l sobre un semforo se
est produciendo una nueva unidad de ese recurso, mientras que cuando hace un w a i t se est consumiendo
una. El comportamiento, por tanto, de este tipo de recursos es diferente al de los mutex. As, considere qu
ocurrira si en el ejemplo anterior se sustituyen los mutex por semforos iniciados con un contador igual a l :
Proceso Px
Proceso P2
wait (Si)
wait (S2)
wait(S2j
wait (Si)
signal(S2)
signal (Si)
signal(Sx)
signal(S2)
fC'
456
Aparentemente, los procesos mantienen el mismo comportamiento. Sin embargo, hay un aspecto sutil muy
importante. En este caso, el comportamiento puede depender de otros procesos externos, que podran generar
nuevas unidades de estos dos recursos (o sea, podran incluir llamadas a s i g n a l sobre cualquiera de los dos
semforos). Por tanto, el posible interbloqueo detectado en el ejemplo anterior, podra no darse en este caso
siempre que algn proceso externo lo rompiera. Ntese que ste es uno de los motivos que complican el tra
tamiento general de los interbloqueos con recursos consumibles._______________________ _________________
Recursos expropiables o no
Algunas de las estrategias para el tratamiento de los interbloqueos que se estudiarn a lo largo de este captu
lo implicarn la expropiacin de recursos, o sea, la revocacin de un recurso asignado a un proceso, mientras
ste lo est usando, para otorgrselo a otro proceso. Para evitar la prdida de informacin, esta expropiacin
implica salvar de alguna forma el trabajo que llevaba hecho el proceso con el recurso expropiado. La posibi
lidad de llevar a cabo esta expropiacin de forma relativamente eficiente va a depender de las caractersticas
especficas del recurso, pudindose, por tanto, clasificar los recursos de acuerdo a este criterio.
Algunos recursos tienen un carcter no expropiable, ya que, o bien no es factible esta operacin o, en
caso de serlo, sera ineficiente. Por ejemplo, no tendra sentido quitarle a un proceso un trazador grfico
cuando lo est usando, porque con ello se perdera todo el trabajo realizado.
Otros recursos, sin embargo, pueden expropiarse de manera relativamente eficiente. Considrese, por
ejemplo, el caso de un procesador. Cada vez que se produce un cambio de proceso, el sistema operativo est
expropiando el procesador a un proceso para asignrselo a otro. La expropiacin de un procesador implicara
nicamente salvar el estado del mismo en el bloque de control del proceso correspondiente, para que as ste
pueda seguir ejecutando normalmente cuando se le vuelva a asignar. Obsrvese que, conceptualmente, el
procesador, como cualquier otro recurso reutilizable de uso exclusivo, puede verse envuelto en interbloqueos.
Suponga, por ejemplo, una situacin en la que existe un proceso que tiene asignada una cinta y est en estado
listo para ejecutar (o sea, no tiene asignado el procesador). Si el proceso que est en ejecucin (o sea, que
tiene asignado el procesador) solicita la cinta, se producir un interbloqueo, ya que cada proceso necesita un
recurso que posee el otro. Este interbloqueo potencial no ocurre en la prctica, puesto que en un sistema multiprogramado, cuando el proceso en ejecucin se bloquea, se asigna automticamente el procesador a otro
proceso (gracias al carcter expropiable de este recurso).
En los sistemas que utilizan un dispositivo de almacenamiento secundario (generalmente un disco) co
mo respaldo de la memoria principal (como son los sistemas con intercambio o con memoria virtual, que se
estudiaron en el captulo dedicado a la gestin de memoria), el recurso memoria tambin es expropiable.
Cuando se requiera expropiar a un proceso parte o toda la memoria que est usando, se copiar el contenido
de la misma en el dispositivo de respaldo, dejndola libre para que pueda usarla otro proceso. El ejemplo de
interbloqueo en el uso de la memoria planteado previamente podra resolverse de esta forma. Ntese que di
cha operacin de copia tiene un coste asociado que afectar al rendimiento del sistema.
El anlisis realizado en esta seccin ha permitido clasificar los diferentes tipos de recursos y delimitar
cules de ellos van a considerarse en el resto de esta exposicin, a saber, los recursos reutilizables exclusivos
compuestos por una o ms unidades. En la siguiente seccin se definir un modelo formal del sistema bajo
estas restricciones que servir de marco de referencia para poder caracterizar el problema del interbloqueo.
7.3.
MODELO DEL SISTEM A
Desde el punto de vista del estudio del interbloqueo, en un sistema se pueden distinguir las siguientes entida
des y relaciones:
Un conjunto de procesos (o threads).
Un conjunto de recursos reutilizables de uso exclusivo. Cada recurso consta, a su vez, de un conjunto
de unidades.
Interbloqueos
457
Un primer conjunto de relaciones entre procesos y recursos que define qu asignaciones de recursos
estn vigentes en el sistema en un momento dado. Esta relacin define si un proceso tiene asignadas
unidades de un determinado recurso y, en caso afirmativo, cuntas.
Un segundo conjunto de relaciones entre procesos y recursos que define qu solicitudes de recursos
estn pendientes de satisfacerse en el sistema en un momento dado. Esta relacin define si un proce
so tiene unidades de u determinado recurso pedidas y no concedidas, y, en caso afirmativo, cuntas.
Estos dos conjuntos de relaciones no pueden tomar cualquier valor, sino que deben cumplir las siguien
tes restricciones de coherencia para que un estado de asignacin de recursos sea vlido:
1.
2.
Restriccin de asignacin: El nmero total de unidades asignadas de un recurso tiene que ser me
nor o igual que el nmero de unidades existentes del mismo (no se puede dar ms de lo que hay).
Restriccin de solicitud: El nmero total de unidades de un recurso solicitadas (tanto asignadas
como pendientes de asignar) por un proceso en un determinado momento tiene que ser menor o
igual que el nmero de unidades existentes del recurso. Ntese que esta restriccin asegura que
ningn proceso quiere usar en un momento dado ms unidades de un recurso que las existentes.
De manera general e independientemente del tipo de cada recurso en particular o de un sistema operati
vo especfico, se van a considerar dos funciones abstractas para trabajar con los recursos que, dado su carc
ter genrico, permiten representar cualquier operacin especfica presente en un sistema operativo
determinado. A continuacin, se especifican estas funciones (la generalidad de estas funciones supera lo que
normalmente proporcionan los sistemas operativos, como se analiza en la aclaracin 7.3).
Solicitud (S (Rj. [Ui] , . . . ,Rn [Un] )): Permite que un proceso, que, evidentemente, no est blo
queado, pida varias unidades de diferentes recursos (Ux unidades del recurso 1, U2 del recurso 2,
etctera). Si todos los recursos solicitados estn disponibles, se conceder la peticin asignando al
proceso dichos recursos. En caso contrario, se bloquear el proceso sin reservar ninguno de los re
cursos solicitados, aunque algunos de ellos estn disponibles. El proceso se desbloquear cuando to
dos estn disponibles (como resultado de una o varias operaciones de liberacin). Obsrvese que se
asume un modo de operacin que se podra calificar como de todo-o-nada: hasta que no estn todos
los recursos disponibles no se asigna ninguno (el ejercicio 7.5 plantea al lector analizar las repercu
siones de modificar este comportamiento).
Liberacin (L{ (Rx [Ui] , . . . ,R n [Un] )): Permite que un proceso, que, evidentemente, no est
bloqueado, libere varias unidades de diferentes recursos que tenga asignadas. La liberacin puede
causar que se satisfagan solicitudes pendientes de otros procesos, provocando su desbloqueo.
Existen diversas maneras de representar esta informacin. Aunque todas las representaciones de este
modelo son lgicamente equivalentes, es conveniente mostrar diferentes alternativas, puesto que un esquema
de representacin puede ser ms adecuado que otro para expresar un determinado algoritmo de tratamiento
del interbloqueo. En concreto, se han seleccionado las dos representaciones ms habituales: el grafo de asig
nacin de recursos y la representacin matricial.
7.3.1. Representacin mediante un grafo de asignacin de recursos

Un grafo de asignacin de recursos G consta de un conjunto de nodos N y un conjunto de aristas A:
G= { {n } , {a }}. El conjunto de nodos N se descompone, a su vez, en dos subconjuntos disjuntos que se co
rresponden con los procesos P y los recursos R. Cada recurso Ri tiene asociado un valor que representa cun
tas unidades del recurso existen (su inventario). El conjunto de aristas tambin se descompone en dos
subconjuntos que se corresponden con las dos relaciones antes planteadas:
1.
2.
Aristas de asignacin que relacionan recursos con procesos. Una arista entre un recurso R* y un
proceso Pj indica que el proceso tiene asignada una unidad de dicho recurso.
Aristas de solicitud que relacionan procesos con recursos. Una arista entre un proceso P i y un re
curso Rj indica que el proceso est esperando la concesin de una unidad de dicho recurso.
458
Aclaracin 7.3. En un sistema real, generalmente, no hay una nica funcin para solicitar recursos o liberar-'los. Dada la gran variedad y heterogeneidad de los recursos, existen servicios especficos para distintos tipos
de recursos. Algunos ejemplos de UNIX seran los siguientes: o p e n y c i s e para el acceso a dispositivos;^
p t h r e a d _ m u t e x _ l o c k y p t h r e a d _ m u t e x _ u n l o c k para manejar mutex, y f c n t l o l o c k f paf|
establecer y quitar cerrojos en ficheros, como se estudiar en el captulo 9. Adems de esta diversidad, otrv
factor que diferencia a las funciones genricas propuestas de las reales es su mayor funcionalidad. Normal
mente, los servicios ofrecidos por los sistemas operativos no permiten solicitar o liberar mltiples recursos
simultneamente. Existen algunos ejemplos reales de servicios que s tienen ese comportamiento, aunque
habitualmente no son tan genricos, no pudindose aplicar a todos los tipos de recursos del sistema. As, por
ejemplo, como se vio en el captulo de comunicacin y sincronizacin de procesos, el servicio W a itF o r M u l t i p l e O b j e c t s de Windows permite solicitar mltiples recursos, tanto correspondientes con elemen-|
tos de sincronizacin como relacionados con la terminacin de procesos o threads (ntese que la
sincronizacin de un proceso con otro que termina se corresponde tambin con una situacin de uso de recur
sos y, por tanto, puede implicar interbloqueos). Sin embargo, a diferencia de la funcin de solicitud abstracta!
especificada anteriormente, este servicio permite especificar dos modalidades de comportamiento: un modo
de operacin todo-o-nada, similar al de la funcin abstracta, y un modo alternativo, en el que la solicitud sel
satisface en cuanto haya al menos un recurso disponible. Se podra considerar que el primer modo de operaTi
cin es una solicitud con un comportamiento lgico Y, mientras que el segundo sigue un modelo lgico 0 :|
Dado que la literatura sobre interbloqueos no ha tratado este segundo modelo, esta exposicin se centrar
nicamente en el primero. En el caso de UNIX, un ejemplo de operaciones que permiten solicitar o liberar*
mltiples recursos simultneamente seran las proporcionadas por los semforos de System V, que permiten
trabajar con vectores de semforos. Por lo que se refiere a servicios que tengan un comportamiento lgico O
se podra considerar como ejemplo la funcin s e l e c t , que permite esperar que se produzca un determinado:
evento en al menos un descriptor del conjunto especificado. Un ltimo aspecto a destacar es que, como se
analizar ms adelante, el uso de operaciones que permitan solicitar mltiples recursos simultneamente fa-;;
vorece el desarrollo de programas libres de interbloqueos.________ __________
- . ' v
Las restricciones de coherencia anteriormente especificadas se plasmaran en el grafo de asignacin de
recursos de la siguiente manera:
Restriccin de asignacin: El nmero de aristas que salen de un recurso debe ser menor o igual que
su inventario.
Restriccin de solicitud: Se debe cumplir que por cada pareja proceso i y recurso j , el nmero de
aristas de asignacin que van de Rj a Pt ms el nmero de aristas de solicitud que conectan Pi a Rj
sea menor o igual que el inventario.
A partir de la especificacin de las funciones genricas de solicitud y liberacin, se puede analizar
cmo afectara su procesamiento al grafo que representa el estado del sistema.
Solicitud del proceso i de Ux unidades del recurso 1, U2 del recurso 2, etc. Se presentan dos situacio
nes dependiendo de si todos los recursos pedidos estn disponibles o no.
Si no lo estn, se bloquea el proceso aadiendo al grafo, por cada recurso pedido j , tantas aris
tas desde el nodo PAhasta Rj como unidades se hayan solicitado (Uj). Cuando el proceso pos
teriormente se desbloquee al quedar disponibles todos los recursos requeridos, se eliminarn
del grafo todas estas aristas de solicitud y se aadirn las mismas aristas de asignacin que en
el caso de que los recursos hubiesen estado disponibles desde el principio.
Si estn disponibles, ya sea desde el principio o posteriormente, se aaden al grafo por cada
recurso pedido j tantas aristas desde el nodo Rj hasta P como unidades se hayan solicitado
(Uj).
Liberacin por parte del proceso i de Uj. unidades del recurso 1, U2 del recurso 2, etc. Por cada recur
so liberado j , se eliminan del grafo tantas aristas desde el nodo Rj hasta Pi como unidades se hayan
dejado libres (Uj).
Interbloqueos
459
Figura 7.1 Grafo de asignacin de recursos despus de la primera secuencia de peticiones.

Ntese que slo se aaden aristas en el grafo durante las solicitudes, tanto si se trata de aristas de solici
tud como de asignacin. En cuanto a la eliminacin de aristas, en la liberacin se quitan las aristas de asigna
cin, mientras que las de solicitud se retiran en el desbloqueo de un proceso que realiz una peticin. A
continuacin, se muestran dos ejemplos del uso de un grafo de asignacin de recursos para representar un
sistema.
En primer lugar, supngase que en un sistema con 3 recursos Rx (2 unidades), R2 (3 unidades) y R3 (2
unidades), se ejecutan tres procesos que realizan la siguiente traza de peticiones:
1.
2.
3.
4.
Px :
P2 :
P2 :
P3 :
so
so
so
so
lic
lic
lic
lic
ita
ita
ita
ita
(Rj [2 ]
(Rj [1 ]
(Rx [1 ]
(R2 [1 ]
)
)
)
> solicita 2 unidades del recurso R|

- se bloquea puesto que el recurso no est disponible
El grafo que representa la situacin del sistema despus de ejecutarse esta secuencia es el siguiente:
N={Pi, P2, P3, R,(2), R2(3), R3(2)}
A={Ri>P1, Rj>P], R2*P2i P2~^Rl) R2~^*3}
Para poder entender de una forma intuitiva el estado de un sistema, es conveniente establecer una repre
sentacin grfica del grafo de asignacin de recursos. La convencin que se suele utilizar es la siguiente:
Cada proceso se representa con un crculo.
Cada recurso con un cuadrado. Dentro del cuadrado que representa a un determinado recurso, se di
buja un crculo por cada unidad existente del recurso.
Las aristas de solicitud se representan como arcos que van desde el proceso hasta el cuadrado que
representa al recurso, mientras que las aristas de asignacin se dibujan como arcos que unen el crcu
lo que representa una unidad determinada del recurso con el proceso correspondiente.
Siguiendo esta convencin, en la figura 7.1 se muestra la representacin grfica del grafo del ejemplo
anterior. Continuando con el ejemplo, considrese que, a continuacin se realizan las siguientes peticiones:
5.
6.
P3 : s o l i c i t a (R2 [1 ] )
Px : s o l i c i t a (R2 [1 ] , R3 [2 ] ) - se bloquea, pues uno de los recursos no est disponible
El grafo que representa la situacin del sistema despus de ejecutarse esa secuencia es el siguiente:
N ={P1,P 2,P 3, R 1(2 ),R 2(3 ),R 3(2)}
A={Ri>P[, Ri>P], R2>P2, P2>Ri, R2>P3, R2-P 3, P i~>R2, P i>R3, P j>R3}
La figura 7.2 muestra la representacin grfica de este grafo resultante.
Generalmente, si en el sistema slo hay una unidad de cada recurso, se prescinde de los pequeos crcu
los que representan los ejemplares del recurso y se dibujan las aristas de asignacin como arcos que unen el
460
F ig u ra 7.2 Grafo de asignacin de recursos despus de la segunda secuencia de peticiones.

cuadrado que representa un determinado recurso con el proceso correspondiente. As, como segundo ejem
plo, considrese un sistema con 3 recursos Ri, R2 y R3, compuestos todos ellos de un solo ejemplar, donde se
ejecutan cuatro procesos que realizan la siguiente traza de peticiones:
1.
Px :
2.
3.
4.
5.
6.
P2 : s o l i c i t a (R2)
P2 : s o l i c i t a ( R i )
Px : s o l i c i t a (R2)
s o l i c i t a (Rx)
> se bloquea, puesto que el recurso no est disponible
El grafo que representa la situacin del sistema despus de ejecutarse esa secuencia es el siguiente:
N ={P|,P2,P3,P4,R|(1).R 2(1),R3(1)}
A={R |>P|, R2>P2) ?2~^P-I) P3~^P-2i P-3- ^P-ti P 1^R-2}
La figura 7.3 muestra la representacin grfica de este grafo de asignacin de recursos.
7.3.2. Representacin matricial

Una forma alternativa de representar esta informacin es mediante el uso de matrices. Para representar el
estado del sistema se usan dos matrices: una matriz de solicitud S y una de asignacin A. Adems, por cada
Figura 7.3 Grafo de asignacin para recursos con un nico ejemplar.
Interbloqueos
2 0 0
lo 1 0
[ OI O
[0
0 0
s= 1 0 0
lo 0 0
461
E= [2 3 2J D=[o 1
Figura 7.4 Representacin matricial correspondiente al grafo de la figura 7.1.

recurso se debe guardar el nmero de unidades existentes del mismo: un vector E que contiene el inventario
de cada recurso. Siendo p el nmero de procesos existentes (o sea,p = | P | ) y r el nmero de recursos diferen
tes que hay en el sistema (o sea, r= | R | ), el significado de las estructuras de datos es el siguiente:
Matriz de asignacin A de dimensinp x r. La componente A [ i , j ] de la matriz especifica cuntas
unidades del recurso j estn asignadas al proceso i.
Matriz de solicitud S de dimensin p x r. La componente S [ i , j ] de la matriz especifica cuntas
unidades del recurso j est esperando el proceso i que se le concedan.
Vector de recursos existentes E de dimensin r. La componente R [ i ] especifica cuntas unidades
del recurso i existen.
En este tipo de representacin, las restricciones de coherencia del sistema implicaran lo siguiente:
1.
2.
Restriccin de asignacin: Se debe cumplir para cada recurso i que la suma de la columna i de la
matriz A ( a [ j , i ] , para j 1, ..., p) sea menor o igual que el nmero de unidades existentes de
dicho recurso (E [ i ] ).
Restriccin de solicitud: Se tiene que verificar para cada proceso i y recurso j la siguiente expre
sin: A [ i , j ] + S [ i , j ] E [ j ] .
Cuando se utiliza una representacin matricial, las repercusiones de las operaciones de solicitud y libe
racin sobre las estructuras de datos que modelan el sistema seran las siguientes:
Solicitud del proceso i de Ui unidades del recurso 1, U2 del recurso 2, etc. Se presentan dos situacio
nes dependiendo de si todos los recursos pedidos estn disponibles o no.
Si no lo estn, se bloquea el proceso y se actualiza la matriz de solicitud: por cada recurso pe

dido j , S [ i , j ] = S [ i , j ] + Uj. Cuando el proceso posteriormente se desbloquee al que
dar disponibles todos los recursos requeridos, se elimina el efecto de esta suma realizando la
resta correspondiente (por cada recurso pedido j , S [ i , j ] = S [ i , j ] - Uj), y se actualiza
la matriz de asignacin de la misma manera que se hace cuando los recursos estn disponibles
desde el principio.
Si estn disponibles, ya sea desde el principio o posteriormente, se actualiza la matriz de asig
nacin: por cada recurso pedido j , A [ i , j ] = A [ i , j ] + U j .
Liberacin por parte del proceso i de Ux unidades del recurso 1, U2 del recurso 2, etc. Por cada recur
so liberado j , se restan de la matriz de asignacin las unidades liberadas: A [ i , j ] = A [ i , j ] - Uj.
Estas estructuras son suficientes para reflejar el estado del sistema. Sin embargo, para simplificar la es
pecificacin de algunos algoritmos que se expondrn ms adelante, es til usar un vector de recursos dispo
nibles D, que refleje el nmero de unidades de cada recurso disponibles en un momento dado. Ntese que
este vector no es estrictamente necesario, ya que su valor se puede deducir directamente a partir de la matriz
de asignacin A y del vector de recursos existentes E: D [ i ] = E [ i ] - D a [ j , i ] , para j = 1, ...,p.
Para hacer ms concisa la especificacin de los algoritmos, se utilizar a partir de ahora la siguiente no
tacin compacta:
Dada una matriz A, el valor A [ i ] representa un vector que corresponde con la fila i-sima de dicha
matriz.
Dados dos vectores A y B de longitud n, se considera que A < B s i A [ i ] < B [ i ] para todo/ = 1,
..., n.
Si se utiliza este modo de representacin para el ejemplo mostrado en la figura 7.1, se obtienen como
resultado las estructuras de datos que aparecen en la figura 7.4.
462

0 o
1 o
o
0 12
10 0
ooo
E [2 3 2}D= [o O 2)
F igura 7.5 Representacin matricial correspondiente al grafo de lafigura 7.2.

La evolucin de este sistema, representada en la figura 7.2, hara que las estructuras de datos quedaran
de la manera que se muestra en la figura 7.5.
Por lo que se refiere al ejemplo con un nico ejemplar por recurso correspondiente a la figura 7.3, las
matrices resultantes seran las que aparecen en la figura 7.6.
Con independencia del esquema de representacin usado, es importante resaltar que un sistema real tie
ne un carcter dinmico. En un sistema informtico se estn continuamente creando y destruyendo tanto pro
cesos como recursos (considere, por ejemplo, ficheros). Por tanto, las estructuras de informacin usadas para
modelar el sistema tendrn tambin una evolucin dinmica.
En el caso de un grafo, no slo se aadirn y eliminarn aristas, sino tambin nodos. En cuanto a la re
presentacin matricial, las dimensiones de las matrices cambiarn dinmicamente. Este aspecto dificulta con
siderablemente el tratamiento de este problema. De hecho, la mayora de las soluciones planteadas en la
literatura que estudia este tema obvian este comportamiento dinmico del sistema.
'M
m
7.4.
DEFINICIN Y CARACTERIZACIN DEL INTERBLOQUEO
Una vez establecido el modelo del sistema, parece que ya es momento de intentar definir ms formalmente el
interbloqueo para poder as caracterizarlo. Una posible definicin de interbloqueo sera la que se presenta a
continuacin:
Un conjunto de procesos est en interbloqueo si cada proceso est esperando un recurso que slo puede litr'
rar (o generar, en el caso de recursos consumibles) otro proceso del conjunto.
Normalmente, cada proceso implicado en el interbloqueo estar bloqueado esperando un recurso, pero
esto no es estrictamente necesario, ya que el interbloqueo tambin existira aunque los procesos involucrados
realizasen una espera activa. La espera activa tiene como consecuencia un uso innecesario del procesador,
pero, por lo que se refiere a los interbloqueos, no implica ninguna diferencia.
Hay que resaltar que existe cierta confusin con el trmino interbloqueo y, a veces, se usa en situacio
nes que no corresponden con su definicin. A continuacin, se plantean dos errores habituales a la hora de
aplicar este trmino:
Un conjunto de procesos compite por el uso de un recurso y un subconjunto de los mismos sufre
inanicin, no pudiendo obtener dicho recurso. Aunque haya procesos esperando indefinidamente pa
ra usar un recurso, no se trata de una situacin de interbloqueo, dado que slo hay un recurso y est
siendo usado por sucesivos procesos. El problema se debe a una poltica de asignacin de recursos
que no es equitativa.
Un conjunto de procesos compite por el uso de un recurso y, debido a un mal diseo del protocolo de
asignacin de recursos, no se cumple la condicin de progreso, y ninguno de ellos consigue obtener
acceso al recurso. Nuevamente, no se trata de un interbloqueo, sino de un problema en la poltica de
asignacin de recursos.
1
0
0
0
0
1
0
0
0
0
0
1
0
1
0
0
1
0
1
0
0
0
0
0
E= [l 1 l] D= [ 0 ]
Figura 7.6 Representacin matricial correspondiente al grafo de la figura 7.3.
31
fS
Interbloqueos
463
A partir de la definicin, es preciso caracterizar un interbloqueo. Coffinan identific las siguientes con
diciones como necesarias para que se produzca un interbloqueo:
1.
2.
3.
4.
Exclusin mutua. Los recursos implicados deben usarse en exclusin mutua, o sea, debe tratarse de
recursos de uso exclusivo. Como se analiz previamente en esta exposicin, los recursos comparti
dos no estn involucrados en interbloqueos.
Retencin y espera. Cuando no se puede satisfacer la peticin de un proceso, ste se bloquea man
teniendo los recursos que tena previamente asignados. Se trata de una condicin que refleja una
forma de asignacin que se corresponde con la usada prcticamente en todos los sistemas reales.
Sin expropiacin. No se deben expropiar los recursos que tiene asignado un proceso. U n proceso
slo libera sus recursos voluntariamente.
Espera circular. Debe existir una lista circular de procesos, tal que cada proceso en la lista est es
perando por uno o ms recursos que tiene asignados el siguiente proceso.
Estas cuatro condiciones no son todas de la misma ndole. Las tres primeras tienen que ver con aspectos
estticos del sistema, tales como qu caractersticas tienen que tener los recursos implicados o cmo debe ser
la poltica de asignacin de recursos. Sin embargo, la condicin de espera circular refleja cmo debe ser el
comportamiento dinmico de los procesos para que se produzca el interbloqueo.
Es importante resaltar que se trata de condiciones necesarias pero no suficientes (o sea, que el cumpli
miento de las condiciones no asegura la presencia del interbloqueo, pero para que exista un interbloqueo tie
nen que cumplirse). Sirvan como ejemplo las dos situaciones estudiadas previamente. En ambos casos se
cumplen las cuatro condiciones (las tres primeras se satisfacen debido a que corresponden con las suposicio
nes que se han hecho sobre el sistema) y, sin embargo, como se analizar ms adelante, slo en el segundo
existe un interbloqueo. En los dos ejemplos, correspondientes a las figuras 7.2 y 7.3 respectivamente, se pue
de identificar la siguiente lista circular de espera:
Px est esperando por un recurso que mantiene P2, que, a su vez, est esperando por un recurso asig
nado a Pi.
Adems de por tratarse de una resea histrica casi obligatoria, estas condiciones necesarias son intere
santes porque, como se analizar ms adelante, sirven de base para el desarrollo de estrategias de prevencin
de interbloqueos. Sin embargo, no bastan para poder caracterizar el interbloqueo adecuadamente: se precisa
establecer las condiciones necesarias y suficientes para que se produzca un interbloqueo.
7.4.1. Condicin necesaria y suficiente para el interbloqueo

La caracterizacin del interbloqueo se va a basar en mirar hacia el futuro del sistema de una manera optimis
ta, siguiendo la idea que se expone a continuacin. Dado un sistema con un determinado estado de asigna
cin de recursos, un proceso cualquiera que no tenga peticiones pendientes (por tanto, desbloqueado) debera
devolver en un futuro ms o menos cercano todos los recursos que actualmente tiene asignados. Esta libera
cin tendra como consecuencia que uno o ms procesos que estuvieran esperando por estos recursos se pu
dieran desbloquear. Los procesos desbloqueados podran, a su vez, devolver ms adelante los recursos que
tuvieran asignados, desbloqueando a otros procesos, y as sucesivamente. Si todos los procesos del sistema
terminan desbloqueados al final de este anlisis del futuro del sistema, el estado actual estar libre de inter
bloqueo. En caso contrario, existir un interbloqueo en el sistema estando implicados en el mismo los proce
sos que siguen bloqueados al final del anlisis. A este proceso de anlisis se le suele denominar reduccin. A
continuacin, se define de una forma ms precisa.
Se dice que el estado de un sistema se puede reducir por un proceso P si se pueden satisfacer las nece
sidades del proceso con los recursos disponibles. Como parte de la reduccin, el proceso devolver los recur
sos asignados, tanto los que tena previamente como los que acaba de obtener, aadindolos al sistema y
crendose un nuevo estado hipottico. Gracias al aporte de recursos fruto de la reduccin por P, ese nuevo
estado podr a su vez reducirse por uno o ms procesos. A partir del concepto de reduccin, se puede esta
blecer la condicin necesaria y suficiente para que se produzca un interbloqueo.
464
La condicin necesaria y suficiente para que un sistema est libre de interbloqueos es que exista una se
cuencia de reducciones del estado actual del sistema que incluya todos los procesos del sistema. En caso con
trario, hay un interbloqueo en el que estn implicados los procesos que no estn incluidos en la secuencia de
reducciones.
Ntese que en un determinado paso de una secuencia de reduccin podra haber varios procesos a los
que aplicar la siguiente reduccin, ya que se satisfacen sus necesidades de recursos. En esta situacin se
podra elegir cualquiera de ellos, puesto que el proceso de reduccin no depende del orden. Para poder de
mostrar esta propiedad slo es necesario darse cuenta de que el proceso de reduccin es acumulativo, esto es,
en cada paso de reduccin se mantienen los recursos disponibles que haba hasta entonces, aadindose los
liberados en la reduccin actual. Por tanto, si en un determinado punto de la secuencia se cumplen las condi
ciones para poder aplicar la reduccin por un proceso, stas se seguirn cumpliendo aunque se realice la re
duccin por otro proceso.
En la seccin que analiza el tratamiento de los interbloqueos basndose en la deteccin y recuperacin,
se presentarn algoritmos que se basan en este principio. A continuacin se aplicar a los ejemplos plantea
dos hasta ahora.
En el ejemplo representado en la figura 7.2, se puede identificar la siguiente secuencia de reducciones:
1.
2.
3.
Se puede reducir el estado por P3, que no est pendiente de ningn recurso. Se liberan dos unidades
de R2.
Gracias a esas dos unidades, se puede reducir por Pj., ya que estn disponibles todos los recursos
que necesita (2 unidades de R 3 y una de R 2). Como resultado de la reduccin, se liberan dos unida
des de Rj.
Se produce la reduccin por P2, puesto que ya est disponible la unidad de Ri que necesitaba.
Dado que la secuencia de reducciones (P3, Px y P2) incluye todos los procesos, el sistema est libre de
interbloqueos. Por lo que se refiere al ejemplo correspondiente a la figura 7.3, la secuencia de reducciones
sera la siguiente:
1.
Se puede reducir el estado por P4,que no est pendiente de ningn recurso, liberndose una unidad
de R3.
Slo se puede realizar esta reduccin; por tanto, existe un interbloqueo en el sistema en el que estn in
volucrados el resto de los procesos. Como se ver ms adelante, la aplicacin directa de este principio lleva a
algoritmos relativamente complejos. Sin embargo, si se consideran sistemas con algn tipo de restriccin, se
reduce apreciablemente el orden de complejidad de los algoritmos. As, en el caso de un sistema con una sola
unidad de cada recurso, la caracterizacin del interbloqueo se simplifica, ya que las condiciones necesarias de
Coffman son tambin suficientes.
7.5.
TRATAMIENTO DEL INTERBLOQUEO
'.i
Como se vio al principio del captulo, las tcnicas para tratar el interbloqueo pueden clasificarse en tres cate
goras: estrategias de deteccin y recuperacin, estrategias de prevencin y estrategias de prediccin. Antes
de analizar en detalle cada una de ellas, es interesante comentar que este tipo de soluciones se emplea tam
bin en otros mbitos diferentes, como puede ser en el mantenimiento de un equipo o en el tratamiento de
una enfermedad. As, por ejemplo, en el caso del mantenimiento de un equipo, la estrategia basada en la de
teccin y recuperacin consistira en esperar a que falle un determinado componente para sustituirlo, con la
consiguiente parada del sistema mientras se produce la reparacin. Una estrategia preventiva, sin embargo,
reemplazara peridicamente los componentes del equipo para asegurar que no se averian. Ntese que esta
sustitucin peridica podra implicar que se descarten componentes que todava estn en buenas condiciones.
Para paliar esta situacin, la prediccin se basara en conocer a priori qu sntomas muestra un determinado
componente cuando se est acercando al final de su vida (por ejemplo, presenta una temperatura excesiva o
produce una vibracin). Esta estrategia consistira en supervisar peridicamente el comportamiento del com
Interbloqueos
465
ponente y proceder a su sustitucin cuando aparezcan los sntomas predeterminados. Aunque, evidentemente,
este ejemplo no presenta las mismas caractersticas que el problema de los interbloqueos, permite identificar
algunas de las ideas bsicas sobre su tratamiento como, por ejemplo, el mal uso de los recursos que pueden
implicar las tcnicas preventivas o la necesidad de un conocimiento a priori que requieren las estrategias
basadas en la prediccin. A continuacin, se comentan los tres tipos de estrategias utilizadas para tratar el
interbloqueo:
Deteccin y recuperacin: Se podra considerar que este tipo de estrategias conlleva una visin op
timista del sistema. Los procesos realizan sus peticiones sin ninguna restriccin pudiendo, por tanto,
producirse interbloqueos. Se debe supervisar el estado del sistema para detectar el interbloqueo me
diante algn algoritmo basado en las condiciones analizadas en el apartado anterior. Ntese que la
aplicacin de este algoritmo supondr un coste que puede afectar al rendimiento del sistema. Cuando
se detecta, hay que eliminarlo mediante algn procedimiento de recuperacin que, normalmente,
conlleva una prdida del trabajo realizado hasta ese momento por algunos de los procesos implica
dos.
Prevencin: Este tipo de estrategias intenta eliminar el problema de raz, fijando una serie de restric
ciones en el sistema sobre el uso de los recursos que aseguran que no se pueden producir interblo
queos. Ntese que estas restricciones se aplican a todos los procesos por igual, con independencia de
qu recursos use cada uno de ellos. Esta estrategia suele implicar una infrautilizacin de los recursos,
puesto que un proceso, debido a las restricciones establecidas en el sistema, puede verse obligado a
reservar un recurso mucho antes de necesitarlo.
Prediccin (en ingls, se suele usar el trmino avoidance): Esta estrategia evita el interbloqueo
basndose en un conocimiento a priori de qu recursos va a usar cada proceso. Este conocimiento
permite definir algoritmos que aseguren que no se produce un interbloqueo. Como ocurre con las es
trategias de deteccin, a la hora de aplicar esta tcnica, es necesario analizar la repercusin que tiene
la ejecucin del algoritmo de prediccin sobre el rendimiento del sistema. Adems, como sucede con
la prevencin, generalmente provoca una infrautilizacin de los recursos.
Existe una cuarta alternativa que consiste en no realizar ningn tratamiento, o sea, ig n o rar los in ter
bloqueos. Aunque parezca sorprendente a priori, muchos sistemas operativos usan frecuentemente esta estra
tegia de esconder la cabeza debajo del ala. Esta opcin no es tan descabellada si se tiene en cuenta, por un
lado, las restricciones que se han ido identificando a lo largo del captulo que limitan considerablemente el
tratamiento general de los interbloqueos en un sistema real y, por otro, las consecuencias negativas que con
llevan las tcnicas de tratamiento (como la baja utilizacin de los recursos o el coste de los algoritmos de
tratamiento). Tngase en cuenta que ignorar el problema trae como consecuencia que, cuando se produce un
interbloqueo, los procesos implicados seguirn indefinidamente bloqueados y, lo que puede ser ms grave
todava, los recursos involucrados quedarn permanentemente inutilizables. En la seccin 7.9 se analizar
cules pueden ser las repercusiones de esta situacin dependiendo de diversos factores. En las siguientes sec
ciones se estudian en detalle las tres estrategias presentadas: deteccin y recuperacin, prevencin y predic
cin.
7.6.
DETECCIN Y RECUPERACIN DEL INTERBLOQUEO
Esta tcnica de tratamiento de los interbloqueos presenta, como su nombre indica, dos fases:
Fase de deteccin: Debe ejecutarse un algoritmo que determine si el estado actual del sistema est
libre de interbloqueos, y que, en caso de que no lo est, identifique qu procesos estn implicados en
el interbloqueo. Dado que, como se analizar ms adelante, los algoritmos de deteccin pueden tener
una repercusin apreciable sobre el rendimiento del sistema, un aspecto importante es establecer con
qu frecuencia se ejecutar dicho algoritmo. En el caso de que el algoritmo detecte un interbloqueo,
se activar la fase de recuperacin del sistema.
466
Fase de recuperacin: Una vez detectado el interbloqueo, se debe aplicar una accin que lo elimine.
Como se analizar ms adelante, esto conlleva, generalmente, abortar la ejecucin de algunos de los
procesos implicados, liberando de esta forma los recursos que tuvieran asignados. Debe existir, por
tanto, un algoritmo que determine a qu procesos se les aplica esa medida drstica.
7.6.1. Deteccin dei interbloqueo

A partir de la condicin necesaria y suficiente para el interbloqueo basada en el concepto de reduccin que se
present en el apartado anterior, se pueden disear algoritmos que detecten si un sistema est libre de interbloqueos. Se trata simplemente de trasladar dicho concepto a las caractersticas especficas de cada tipo de
representacin del sistema.
Algoritmo de deteccin para una representacin mediante un grafo de recursos
En primer lugar, se va a definir cmo se aplica el concepto de reduccin a la representacin mediante un gra
fo. Dado un grafo de asignacin de recursos, ste se puede reducir por un proceso PAsi los recursos disponi
bles satisfacen sus necesidades (el proceso, por tanto, est desbloqueado).
La reduccin consiste en eliminar las aristas de solicitud que salen del nodo P. ( P i Rj.), puesto que
hay suficientes recursos disponibles, y las de asignacin que llegan a dicho nodo ( R i > P i), ya que se supone
que el proceso devolver todos sus recursos. Como fruto de la reduccin, se obtiene un nuevo grafo donde
podr haber nuevos procesos desbloqueados, gracias a los recursos liberados, a los que se les podr aplicar
una nueva reduccin.
A partir de esta definicin, se puede especificar directamente un algoritmo que detecte si hay un inter
bloqueo en el grafo de asignacin de recursos:
/* secuencia de reduccin. Inicialmente vaca */
S=0;
D={Conjunto de procesos desbloqueados y no incluidos en S};
Mientras (Dl=0) {
/* se puede reducir por cualquier proceso de D: selecciona el primero */
Pi= primer elemento de D;
Reducir grafo por P;
Aadir PAa S y eliminarlo de D;
Determinar qu procesos se desbloquean por la reduccin (sus solicitudes
pueden satisfacerse en el nuevo grafo) y aadirlos a D;
}
Si (S==P)
/* si la secuencia contiene todos los procesos del sistema (P) */
No hay interbloqueo
Sino
Los procesos en el conjunto P-S estn en un interbloqueo
Este algoritmo tiene una complejidad O (p2r), siendo p el nmero de procesos en el sistema y r el nme
ro de recursos. Por un lado, el bucle principal puede ejecutarse una vez por cada proceso (p veces). Por otro,
en cada iteracin del bucle, la operacin que determina qu procesos de desbloquean por la reduccin implica
comparar las solicitudes de recursos de cada proceso que todava no est en la secuencia con los recursos
disponibles en el grafo reducido (del orden de p x r comparaciones).
Como ejemplo, se va a aplicar a continuacin este algoritmo al grafo dibujado en la figura 7.2, lo que
causar las etapas de reduccin que se muestran en las figuras 7.7, 7.8 y 7.9. La representacin formal del
grafo era la siguiente:
.
N = { P I, P 2, P 3 ,R 1( 2 ) ,R 2( 3 ) ,R 3(2 )}
A { R |>Pi, R ]-> P i, R 2 ^P2) P 2 ^Ri> R 2 ^P3j R 2>P3, P i>R2, P ,- R 3, P ,-> R 3}
Interbloqueos
467
Figura 7.7 Grafo de asignacin de recursos despus de la reduccin por />

Cuando se aplica el algoritmo de deteccin a este grafo, el resultado es el siguiente:
1.
2.
Estado inicial: S = 0 y D={P3}

Reduccin del grafo por P3. El grafo reducido residante, representado en la figura 7.7, es:
A={R]Pi, R |>Pj, R 2*P2, P 2^Ri> Pi--*R2> Pi~*R3>P i- *R3}
3. Se aade el proceso a la secuencia de reduccin: S={P3}
4. Como resultado de la reduccin, se desbloquea Pi, ya que estn disponibles todos los recursos que
necesita (2 unidades de R3 y una de R2). D={P!}
5. Reduccin del grafo por Pj. El grafo reducido resultante, representado en la figura 7.8, es:
A={R2>P2, P 2>Ri}
6. Se aade el proceso a la secuencia de reduccin: S={P3, Pi}
7. Como resultado de la reduccin se desbloquea P2. D={P 2}
8. Reduccin del grafo por P2. El grafo queda completamente reducido: A = 0 (vase la figura 7.9).
9. Se aade el proceso a la secuencia de reduccin: S={P3, P h P2}
10. Como no se desbloquea ningn proceso, D est vaco, por lo que termina el bucle.
11. Como S incluye a todos los procesos, el sistema est libre de interbloqueos.
A continuacin, como segundo ejemplo, se aplica el algoritmo de deteccin al grafo de la figura 7.3,
que tena la siguiente representacin formal:
N ={P P2, P3, P4, R i(l), R2(l), R3(l)}
A={Ri>P|, R2>P2, P2 ^Rl>P3-^R2> R3~*P-fi P l- ^ 2}
R1
R2
R3
Figura 7.8 Grafo de asignacin de recursos despus de la reduccin por
468
00
O O O
R2
R3
F ig u ra 7.9 Grafo de asignacin de recursos despus de la reduccin por F.

El resultado es el siguiente:
1.
2.
Estado inicial: S = 0 y D={P4}

Reduccin del grafo por P4. El grafo reducido resultante, representado en la figura 7.10, es:
A = {R i>Pi, R2P , P - ^Ri> P

3.
4.
5.
1 2
^R2j P ^R- }
Se aade el proceso a la secuencia de reduccin: S={P4}

Como no se desbloquea ningn proceso, D est vaco por lo que termina el bucle.
Como S no incluye a todos los procesos, en el sistema hay un interbloqueo que afecta a los proce
sos del sistema que no estn en S: P h P 2 y P 3.
Como se coment previamente, cuando se consideran sistemas con algn tipo de restriccin, se pueden
disear algoritmos de menor complejidad. As, en el caso de un sistema con una sola unidad de cada recurso,
para asegurar que un sistema est libre de interbloqueos, slo es necesario comprobar que no hay un ciclo en
el grafo, dado que en este caso las condiciones de Coffinan son necesarias y suficientes para que exista un
interbloqueo. Por tanto, se puede usar para ello cualquier algoritmo de deteccin de ciclos en un grafo. El
orden de complejidad de este tipo de algoritmos es proporcional al nmero de aristas en el grafo. Como en un
grafo de asignacin de recursos, el nmero de aristas es proporcional a pxr, el algoritmo tiene una compleji
dad de 0(pr).
Algoritmo de deteccin p a ra u n a representacin m atricial
Es relativamente directo trasladar las ideas expuestas para el caso de una representacin mediante un grafo a
una de tipo matricial. Por ello, la exposicin que trata este caso se har de una forma ms sucinta. Por lo que
Figura 7.10 Grafo de asignacin de recursos despus de la reduccin p or P*
Interbloqueos
469
se refiere a la operacin de reduccin aplicada a una representacin matricial, se podra definir de la siguiente
forma: Un sistema se puede reducir por un proceso Pi si los recursos disponibles satisfacen sus necesidades,
es decir, si S [ i ] < D (recuerde que esta notacin compacta equivale a S [ i , j ] < D [ j ] para; = 1,..., r).
La reduccin consiste en devolver los recursos asignados al proceso Pi.:
D = D + A [i]
Una vez hecha esta definicin, se puede especificar un algoritmo de deteccin similar al presentado pa
ra el caso de un grafo y con la misma complejidad (O(p2r)).
S=0;
Repetir {
Buscar Pi tal que S[il S D;
Si Encontrado {
Reducir grafo por Pi D = D + A[i]
Aadir Pi a S;
Continuar = cierto;
}
Sino
Continuar = falso;} Mientras (Continuar)
Si (S==P)
No hay interbloqueo
Si no
Los procesos en el conjunto P-S estn en un interbloqueo
A continuacin, se aplica este algoritmo a los dos ejemplos considerados. En primer lugar, al sistema
mostrado en la figura 7.2, cuya representacin matricial aparece en la figura 7.5. El resultado es el siguiente:
1.
2.
Estado inicial: S = 0
Se puede reducir por P3, ya que S [3] D ( [ 0
0 0 ]< [0
0 2 ] ), dando como resultado:
D = D + A [3] = [0 0 2] + [0 2 0] = [0 2 2]
3.
4.
Se aade el proceso a la secuencia de reduccin: S = { P3} y se pasa a la siguiente iteracin.

Reduccin por Px dado que S [ 1 ] D ( [ 0 1 2 ] < [ 0 2 2 ]), que da como resultado:
5.
6.
Se aade el proceso a la secuencia de reduccin: S = {P 3, Pi} y se pasa a la siguiente iteracin.

Reduccin por P2 dado que S [2] < D ( [ 1 0 0 ] < [ 2 2 2 ]), que da como resultado:
7.
8.
Se aade el proceso a la secuencia de reduccin: S= { P3, Px, P2} y se termina el bucle.

Como S incluye a todos los procesos, el sistema est libre de interbloqueos.
D = D + A [1] = [0 2 2] -t- [2 0 0] = [2 2 2]
D = D + A [2] = [0 1 0 ]
+ [2 2 2] = [2 3 2]
En cuanto al segundo ejemplo, que corresponde con el sistema representado en la figura 7.3, cuya re
presentacin matricial se muestra en la figura 7.6. La aplicacin del algoritmo a este sistema producira el
siguiente resultado:
1.
2.
Estado inicial: S - 0
Se puede reducir por P4, ya que S [4] < D ( [ 0
0 0] < [0 0 0 ]), dando como resultado:
D = D + A [4] = [0 0 1] + [0 0 0] = [0 0 1]
3.
4.
5.
Se aade el proceso a la secuencia de reduccin: S = { P4} y se pasa a la siguiente iteracin.

No hay ningn Pi tal que S [ i ] < D. Termina la ejecucin del bucle.
Como S no incluye a todos los procesos, en el sistema hay un interbloqueo que afecta a los proce
sos del sistema que no estn en s: Pj., P2 y P3.
470
Es conveniente hacer un comentario sobre la implementacin de los algoritmos de deteccin propues

tos. Con independencia de cul sea el modo de representacin utilizado, cuando se intenta averiguar si el es
tado actual est libre de interbloqueos, se le aplica una secuencia de reducciones que modifica las estructuras
de datos que representan el sistema para reflejar las sucesivas reducciones. O sea, se van creando nuevos es
tados hipotticos del sistema. Puesto que el estado real del sistema no debe cambiar, habr que realizar las
modificaciones sobre una copia de trabajo del estado del sistema.
Activacin del algoritmo de deteccin
Una vez seleccionado un algoritmo de deteccin, es necesario decidir cundo se ejecuta el mismo. Evidente
mente, lo ideal sera poder detectar un interbloqueo justo cuando se produce para poder tratarlo inmediata
mente. Tngase en cuenta que, mientras no se arregle el problema, los procesos y recursos involucrados
estarn bloqueados, pudindose, adems, incorporar progresivamente ms procesos al interbloqueo. Sin em
bargo, no hay que olvidar que el algoritmo tiene un coste de ejecucin apreciable y que, por tanto, esta super
visin continua puede ser inabordable.
Volviendo al smil del mantenimiento de los equipos de una empresa, lo idneo sera poder tener una
supervisin continua del funcionamiento de todos los equipos para poder detectar inmediatamente el fallo de
alguno. Sin embargo, esta estrategia puede requerir ms recursos humanos de los que dispone la empresa.
Ante esta situacin, una solucin alternativa sera una comprobacin peridica del buen funcionamiento de
los sistemas. El periodo de comprobacin debera fijarse teniendo en cuenta las estadsticas sobre la frecuen
cia de fallos de cada componente. Adems de esta estrategia peridica, tambin podra activarse la compro
bacin de un equipo cuando se detecta algn sntoma en el sistema global que haga pensar que algn
componente ha fallado. En el tratamiento de los interbloqueos basado en su deteccin se presentan alternati
vas similares:
Se puede realizar una supervisin continua del estado del sistema con respecto a la asignacin de
recursos para comprobar que est libre de interbloqueos. Ntese que un interbloqueo slo puede apa
recer cuando no puede satisfacerse una peticin de un proceso. Por tanto, slo sera necesario ejecu
tar el algoritmo en ese momento. Hay que tener en cuenta tambin que el algoritmo de deteccin
queda simplificado en esta situacin, puesto que, una vez que se detecte que el proceso que realiz la
peticin que activ el algoritmo no est involucrado en un interbloqueo, se puede detener la bsque
da. En consecuencia, en cuanto aparezca dicho proceso en una secuencia de reduccin, el sistema
est libre de interbloqueos. La viabilidad de esta alternativa depender de con qu frecuencia se acti
ve el algoritmo y del tiempo que consuma su ejecucin, que depender del nmero de procesos y re
cursos existentes en el sistema.
Se puede realizar una supervisin peridica. Esta sera la opcin adecuada cuando, dadas las carac
tersticas del sistema, la repercusin sobre el rendimiento del sistema de la ejecucin del algoritmo
por cada peticin insatisfecha fuera intolerable. El valor del periodo debe reflejar un compromiso en
tre dos factores: debe ser suficientemente alto para que el tiempo de ejecucin del algoritmo no afec
te apreciablemente al rendimiento del sistema, pero suficientemente bajo para que sea aceptable el
tiempo que pasa entre que se produce un interbloqueo y su deteccin. Este valor depender de las ca
ractersticas del sistema y de las peticiones que realizan los procesos activos en un momento dado,
siendo, por tanto, difcil de determinar. Ntese que el algoritmo podra tambin activarse cuando se
detecta algn sntoma que pudiera indicar un posible interbloqueo. Por ejemplo, cuando el grado de
utilizacin del procesador bajara de un determinado umbral.
7.6.2. Recuperacin del interbloqueo

Una vez detectado un interbloqueo, es necesario tomar una serie de medidas para eliminarlo, esto es, recupe
rar al sistema del mismo. Para ello, se deberan seleccionar uno o ms de los procesos implicados y quitarles
algunos de los recursos que tienen asignados de forma que se rompa el interbloqueo. Habra que hacer que
los procesos elegidos retrocedan en el tiempo su ejecucin, al menos hasta justo antes de que solicitasen
Interbloqueos
471
dichos recursos. Este viaje hacia atrs en el tiempo es complicado, puesto que implica restaurar el estado
del proceso tal como estaba en ese instante previo. Esta operacin slo sera factible, pero no fcil de implementar, en sistemas que tengan algn mecanismo de puntos de recuperacin, lo que no es habitual en los sis
temas de propsito general (en la aclaracin 7.4, se analiza el uso de esta estrategia en sistemas de gestin de
bases de datos). Dada esta dificultad, lo ms habitual es realizar un retroceso total, abortando directamente
los procesos elegidos, con la consiguiente prdida del trabajo realizado por los mismos.
Aclaracin 7.4. Este tipo de estrategia es adecuada en los sistemas de gestin de bases de datos. En este tipo
de sistemas, las entidades activas son las transacciones y los recursos corresponden con los diversos registros
y tablas de la base de datos, a los que habr que acceder en ocasiones en modo exclusivo, usando un meca
nismo de cerrojos. Con respecto a la deteccin, es ms simple que en un sistema operativo de propsito gene
ral, dado que slo hay un nico tipo de recursos (los cerrojos). En cuanto a la recuperacin del interbloqueo,
gracias al carcter atmico de las transacciones, basta con abortar la transaccin seleccionada y volver arran
carla inmediatamente, sin que el usuario final sea consciente de esta circunstancia. No existe una prdida de
trabajo, slo una sobrecarga tolerable, dada su baja probabilidad, debido a la repeticin de la transaccin.
El algoritmo de recuperacin, por tanto, tomara como punto de partida el conjunto de procesos que
estn implicados en interbloqueos, tal como ha determinado el algoritmo de deteccin, e ira sucesivamente
abortando procesos de este conjunto hasta que los interbloqueos desaparezcan del sistema. Ntese que, des
pus de abortar un proceso, habra que volver a aplicar el algoritmo de deteccin para ver si siguen existiendo
interbloqueos y, en caso afirmativo, qu procesos estn implicados en los mismos.
El criterio a la hora de seleccionar qu procesos del conjunto se abortarn debera intentar minimizar el
coste asociado a la muerte prematura de los mismos. En esta decisin pueden intervenir numerosos factores,
tales como la prioridad de los procesos implicados, el nmero de recursos que tiene asignados cada proceso o
el tiempo que lleva ejecutando cada proceso.
Un ltimo aspecto a destacar es que si se realiza una supervisin continua del sistema (o sea, se aplica
el algoritmo de deteccin siempre que se produce una peticin que no puede satisfacerse), se podra tomar la
decisin de abortar precisamente al proceso que ha realizado la peticin que ha generado el interbloqueo. No
es un mtodo ptimo, ya que este proceso puede tener gran prioridad o llevar mucho tiempo ejecutando, pero
es eficiente, ya que elimina la necesidad de aplicar nuevamente el algoritmo de deteccin.
7.7.
PREVENCIN DEL INTERBLOQUEO
Con la estrategia de prevencin se intenta eliminar el problema de raz, asegurando que nunca se pueden pro
ducir interbloqueos. Dado que, como se analiz previamente, es necesario que se cumplan las cuatro condi
ciones de Coffrnan para que se produzca un interbloqueo, bastara nicamente con asegurar que una de estas
condiciones no se puede satisfacer para eliminar los interbloqueos en el sistema. A continuacin, se analiza
sucesivamente cada una de estas cuatro condiciones para ver si es posible establecer estrategias que aseguren
que no puede cumplirse.
7.7.1. Exclusin mutua

Esta condicin establece que para que se produzca un interbloqueo los recursos implicados en el mismo de
ben ser de uso exclusivo. Para asegurar que no se puede satisfacer esta condicin, habra que conseguir que
todos los recursos del sistema fueran de tipo compartido. Sin embargo, como se coment previamente, esto
no es posible, puesto que hay recursos que son intrnsecamente de carcter exclusivo. Por tanto, esta primera
condicin no permite definir estrategias de prevencin, aunque el uso de tcnicas como el spooling, que se
analizar en la seccin 7.9, que permite que mltiples usuarios compartan un dispositivo de uso exclusivo,
como una impresora, podra considerarse como una forma de romper esta condicin necesaria.
472

tiempo
F igura 7.11 Diagrama de uso de recursos a lo largo del tiempo del programa usado como ejemplo.
7.7.2. Retencin y espera

Esta condicin identifica que para que ocurra un interbloqueo tiene que haber procesos que tengan asignados
recursos pero que estn bloqueados esperando por otros recursos. Una primera estrategia de prevencin, ba
sada en asegurar que no se cumple esta condicin, consistira en hacer que cada programa al principio de su
ejecucin solicitase simultneamente todos los recursos que va a necesitar. De esta forma, se evita el inter
bloqueo, ya que el proceso slo se bloquea esperando recursos al principio, cuando no tiene ninguno asigna
do. Una vez satisfecha la solicitud, el programa ya no se bloquear en espera de recursos, puesto que dispone
de todos los que necesita.
Como ejemplo, supngase un programa que necesita usar cuatro recursos (A, B, C y D) en distintos in
tervalos de tiempo a lo largo de su ejecucin, de acuerdo con el diagrama de la figura 7.11.
Siguiendo esta estrategia de prevencin, el programa debera solicitar todos los recursos al principio,
aunque realmente la mayora de ellos slo los necesite en fases posteriores del programa, como se aprecia a
continuacin:
ti: Solicita(A(B,C,D)
(ti,t2) : slo utiliza A
(t2 ,t3) : utiliza A y B
t3: Libera(A)
(t3 ,t4) : slo utiliza B
(t4 ,t5) : utiliza B y C
t5: Libera(B)
(t5 /ts) : slo utiliza C
t6: Libera(C)
. (t7 ,tB) : slo utiliza D
ta: Libera(D)
Esta estrategia conlleva una tasa muy baja de utilizacin de los recursos. Ntese que, por ejemplo, el
recurso D est reservado desde el instante de tiempo t hasta el t8, aunque realmente slo se usa en el intervalo
de ti hasta tg. Adems, esta solucin retrasa considerablemente el inicio del programa, ya que ste tiene que
Interbloqueos
473
esperar a que todos los recursos estn libres para comenzar, cuando, en realidad, podra comenzar en cuanto
estuviese disponible el recurso A.
Una estrategia ms refinada consistira en permitir que un proceso pueda solicitar un recurso slo si no
tiene ninguno asignado. Con esta segunda alternativa, un programa slo se vera obligado a pedir simult
neamente dos recursos si se solapa en el tiempo el uso de los mismos. En el ejemplo anterior, la solicitud del
recurso D puede realizarse en el momento que realmente se necesita (/y), puesto que dicho recurso no se usa
simultneamente con ningn otro. Sin embargo, el resto de los recursos deben seguir pidindose al principio.
tx: Solicita(A,B,C)
(t1 /t2): slo utiliza A
(t2 ,t3) : utiliza A y B
t3: Libera(A)
(t3 ,t4) : slo utiliza B
(t4 ,t5) : utiliza B y C
t5: Libera(B)
(tS/t6) : slo utiliza C
t6: Libera(C)
t7: solicita(D)
(t7 ,ta) : slo utiliza D
ta: Libera(D)
Aunque esta nueva poltica supone una mejora sobre la anterior, sigue presentando los mismos proble
mas. As, por ejemplo, el recurso C seguir estando desaprovechado en el intervalo de tiempo entre ti y t4.
Obsrvese que, aunque el recurso A y el C no se usan de forma simultnea, se piden a la vez, puesto que el
uso de ambos se solapa con el del recurso B. Se produce, por tanto, un cierre transitivo a la hora de determi
nar qu recursos se pedirn juntos.
7.7.3. Sin expropiacin

La tercera condicin necesaria establece que a un proceso no se le pueden expropiar los recursos que ya tiene
asignados. El proceso liberar sus recursos voluntariamente cuando ya no los necesite. Para romper esta con
dicin, se debe permitir la revocacin involuntaria de recursos. Sin embargo, como ya se discuti a la hora de
clasificar los recursos, no todos los recursos tienen intrnsecamente un carcter expropiable. Por tanto, como
ocurra con la condicin de exclusin mutua, no se puede definir una poltica de prevencin general basada
en esta condicin, ya que existen muchos tipos de recursos a los que no se les puede aplicar la expropiacin.
En el caso hipottico de que todos los recursos fueran expropiables, una posible estrategia consiste en
que, cuando un proceso realiza una peticin que no puede satisfacerse, se le revocan todos los recursos que
tiene asignados. Ntese que, implcitamente, este tratamiento es el que se aplica al uso del procesador. Cuan
do un proceso en ejecucin se bloquea esperando un recurso, se le expropia el procesador hasta que el recur
so est disponible.
Otra alternativa ms agresiva es que, ante una peticin por parte de un proceso de un recurso que est
asignado a otro, se le quite el recurso a su actual poseedor y se le asigne al solicitante. El reemplazo de una
pgina en un sistema con memoria virtual se puede catalogar como una aplicacin de esta estrategia, ya que
el proceso que causa el fallo de pgina le est robando el marco a otro proceso.
Por ltimo, es importante recordar que la expropiacin de recursos conlleva algn tipo de salvaguarda
de informacin de estado del recurso y una posterior restauracin de dicha informacin. Hay que tener en
cuenta que estas operaciones tienen un coste que puede afectar al rendimiento del sistema.
474
7.7.4. Espera circular

La ltima condicin plantea la necesidad de que exista una lista circular de dependencias entre procesos para
que exista el interbloqueo. De manera intuitiva, se ha podido apreciar en los ejemplos planteados hasta ahora
que a esta situacin se llega debido a que los procesos piden los recursos en diferente orden.
Basndose en esa idea, una estrategia de prevencin es el mtodo de las peticiones ordenadas. Esta es
trategia requiere establecer un orden total de los recursos presentes en el sistema y fijar la restriccin de que
un proceso debe pedir los recursos que necesita en orden creciente. Ntese que esta restriccin hace que un
proceso tenga que pedir algunos recursos de forma anticipada.
En el caso del ejemplo de la figura 7.11, si el orden fijado para los recursos es A < B < C < D, el pro
grama podra solicitar los recursos justo en el momento que los necesita (A en t, B en 2, C en t4 y D en t7).
Sin embargo, si el orden establecido es el inverso (D < C < B < A), el programa debera solicitar en el instante
ti, sucesivamente, los recursos D, C, B y A, lo que causara una infrautilizacin de los mismos. Ntese que
slo sera necesario pedir en orden aquellos recursos que se usan de forma solapada (directamente o debido a
un cierre transitivo debido a un tercer recurso). Esto es, un proceso slo podr solicitar recursos cuyo orden
sea mayor que el de los que tiene actualmente asignados. As, en el ejemplo, la solicitud del recurso D puede
realizarse en el momento en que realmente se necesita ( t7).
Un aspecto fundamental de este mtodo es asignar un orden a los recursos de manera que se correspon
da con el orden de uso ms probable por parte de la mayora de los programas.
En el ejercicio 7.16 se plantea al lector demostrar que este mtodo asegura que no se produce la condi
cin de espera circular y, por tanto, evita el interbloqueo.
7.8.
PREDICCIN DEL INTERBLOQUEO
Como se coment al principio del captulo, antes de que en el sistema aparezca un interbloqueo se produce
un punto de no retomo a partir del cual el interbloqueo es inevitable con independencia del orden en el que
realicen sus peticiones los procesos. Retomamos el primer ejemplo planteado en el que dos procesos usan
una cinta (C) y una impresora ( I) siguiendo la siguiente estructura:
Proceso
Solicita(C)
Solicitad)
Uso de los recursos
Libera(I)
Libera(C)
Proceso P2
Solicita(I)
Solicita (C)
Uso de los recursos
Libera(C)
Libera(I)
Si se permite que cada proceso obtenga su primer recurso solicitado, se habr atravesado el umbral que
conduce inevitablemente al interbloqueo. Ntese que en ese instante ninguno de los dos procesos est blo
queado pero, a partir de entonces, sea cual sea la secuencia de ejecucin que se produzca, el interbloqueo es
ineludible. Cmo se podra detectar cuando el sistema se acerca a este punto de no retomo para evitar entrar
en el mismo? La solucin es muy sencilla: slo es necesario conocer el futuro. Si se conociera a priori qu
recursos van a solicitar los procesos durante su ejecucin, se podra controlar la asignacin de recursos a los
procesos de manera que se evite el interbloqueo. En el ejemplo, si despus de asignarle la cinta al primer pro
ceso, se produce la solicitud de la impresora por parte del segundo, no se satisfar esta peticin bloqueando al
segundo proceso, aunque realmente el recurso est libre.
Aunque se trata de un ejemplo muy sencillo, ha permitido apreciar cules son las claves de los algorit
mos de prediccin de interbloqueos: un conocimiento a priori de las necesidades de los procesos y el no con
ceder las peticiones que pueden conducir hacia el interbloqueo, aunque los recursos solicitados estn
disponibles.
Interbloqueos
475
Los algoritmos de prediccin se basarn, por tanto, en evitar que el sistema cruce el punto de no retomo
que conduce al interbloqueo. Para ello, se necesitar conocer a priori las necesidades mximas de recursos
que tiene cada programa. A partir de esta informacin, se deber determinar si el estado del sistema en cada
momento es seguro.
7.8.1. Concepto de estado seguro

Se considera que un determinado estado es seguro si, suponiendo que todos los procesos solicitan en ese
momento sus necesidades mximas, existe al menos un orden secuencial de ejecucin de los procesos tal que
cada proceso pueda obtener sus necesidades mximas. As, para que un estado sea seguro tiene que haber, en
primer lugar, un proceso cuyas necesidades mximas puedan satisfacerse. Cuando, hipotticamente, este pro
ceso terminase de ejecutar, devolvera todos sus recursos (o sea, sus necesidades mximas). Los recursos
disponibles en ese instante podran permitir que se satisficieran las necesidades mximas de al menos un pro
ceso, que terminara liberando sus recursos, lo que a su vez podra hacer que otro proceso obtuviera sus nece
sidades mximas. Repitiendo este proceso, se genera una secuencia de ejecucin de procesos tal que cada uno
de ellos puede obtener sus necesidades mximas. Si esta secuencia incluye todos los procesos del sistema, el
estado es seguro. En caso contrario, es inseguro.
El lector habr podido apreciar que este proceso de anlisis mirando hacia el futuro es similar al usa
do para la reduccin de un sistema en el algoritmo de deteccin de interbloqueos. La nica diferencia es que
en el algoritmo de reduccin se tienen en cuenta slo las peticiones actuales de los procesos, mientras que en
este algoritmo se consideran tambin como peticiones las necesidades mximas de cada proceso. Esta simili
tud permite especificar una segunda definicin del estado seguro:
Un estado es seguro si el estado de asignacin de recursos que resulta al considerar que todos los procesos
realizan en ese instante todas sus posibles peticiones est libre de interbloqueos.
;
Gracias a esta nueva definicin, se puede especificar directamente un algoritmo para determinar si un
estado es seguro: aplicar un algoritmo de deteccin de interbloqueos al estado resultante de considerar que
todos los procesos solicitan sus necesidades bsicas.
Retomando el ejemplo anterior, el estado al que se llega si se permite que cada proceso obtenga su pri
mer recurso solicitado (el primer proceso, la cinta, y el segundo, la impresora) es inseguro, puesto que en ese
momento ninguno de los dos procesos puede satisfacer sus necesidades mximas (el primer proceso no podr
a obtener la impresora, ni el segundo la cinta).
Es importante resaltar que este tipo de algoritmos tiene un carcter conservador, debido a que los da
tos que se poseen a priori sobre el uso de recursos de cada proceso no incluyen informacin sobre la utiliza
cin real de los mismos. Esto puede hacer que se consideren como inseguros estados que realmente nunca
pueden llevar a un interbloqueo. As, por ejemplo, considrese el siguiente ejemplo que tiene una estructura
similar al anterior:
Proceso Pj.
Solicita(C)
Uso del recurso C
Libera(C)
Solicita(I)
Uso del recurso I
Libera(I)
Proceso P 2
Solicita(I)
Solicita(C)
Uso de los recursos
Libera(C)
Libera(I)
En este caso no puede haber nunca interbloqueo, pero, sin embargo, la informacin sobre el uso mxi
mo de recursos por cada proceso es la misma que en el ejemplo anterior. Por tanto, la situacin que corres
ponde con que cada proceso haya obtenido su primer recurso se considerar como un estado inseguro. Se
puede, por tanto, afinnar que una condicin necesaria pero no suficiente para que un sistema evolucione
hacia un interbloqueo es que su estado actual sea inseguro. Los algoritmos de prediccin se basarn en evitar
que el estado del sistema se convierta en inseguro, eliminando de esta forma la posibilidad del interbloqueo.
476
7.8.2. Algoritmos de prediccin

Una vez identificado el concepto de estado seguro, es relativamente directo establecer una estrategia de pre
diccin. Cada vez que un proceso realice una solicitud de recursos que estn disponibles, se calcula provisin
nalmente el nuevo estado del sistema resultante de esa peticin y se aplica el algoritmo para determinar si el
nuevo estado es seguro. Si lo es, se asignan los recursos solicitados haciendo que el estado provisional se
convierta en permanente. En caso de que no lo sea, se bloquea al proceso sin asignarle los recursos, quedan
do, por tanto, el sistema en el estado previo. Dado que el sistema inicialmente est en estado seguro, puesto
que ningn recurso est asignado, este algoritmo asegura que el sistema siempre se encuentra en un estado
seguro, eliminando, por tanto, el interbloqueo.
A continuacin, se plantean algoritmos de prediccin para los dos tipos de representacin considerados:
el grafo de recursos y la representacin matricial. Ntese que no se trata de nuevos algoritmos, puesto que,
como se ha explicado previamente, se aplican los algoritmos de deteccin de interbloqueos ya presentados.
Por ello, la exposicin de los mismos no ser exhaustiva.
Algoritmo p ara una representacin m ediante un grafo de recursos
Adems de las aristas de asignacin y las de solicitud, sera necesario un nuevo tipo de arista que refleje las
necesidades mximas de cada proceso:
Una arista de necesidad entre un proceso Pi y un recurso Rj indica que el proceso puede solicitar
durante su ejecucin una unidad de dicho recurso.
La evolucin de este nuevo tipo de aristas sera la siguiente:
Inicialmente, en la creacin de un proceso Pi, se estableceran aristas de necesidad desde el proceso
a los recursos correspondientes, de manera que queden reflejadas las necesidades mximas requeri
das por el proceso.
En una solicitud, las aristas de necesidad correspondientes se convertiran en aristas de solicitud, si
los recursos correspondientes no estn disponibles, o de asignacin, en caso contrario.
Cuando se produce una liberacin de recursos, las aristas de asignacin correspondientes se trans
forman a su estado inicial, o sea, en aristas de necesidad.
Dado este comportamiento de las aristas de necesidad, se puede apreciar que el nmero total de aristas,
sean del tipo que sean, que hay en cualquier momento entre un proceso y un recurso debe corresponder con
las necesidades mximas del proceso con respecto a ese recurso.
Como se coment previamente, el algoritmo para determinar si un estado es seguro consiste directa
mente en comprobar que no hay interbloqueos en dicho estado, pero teniendo en cuenta las peticiones mxi
mas, o sea, tanto las aristas de solicitud como las de necesidad. Para ello, se pueden usar los algoritmos de
deteccin de interbloqueos para la representacin mediante un grafo ya estudiados previamente.
La estrategia de prediccin consiste, por tanto, en que cuando un proceso realiza una solicitud de recur
sos que estn disponibles, se calcula un nuevo estado provisional, transformando las aristas de necesidad co
rrespondientes en aristas de asignacin, y se aplica el algoritmo para determinar si el nuevo estado es seguro.
Si lo es, se asignan los recursos solicitados haciendo que el estado provisional se convierta en permanente.
En caso contrario, se bloquea al proceso sin asignarle los recursos, restaurando, por tanto, el sistema al estado
previo.
A continuacin, se va a aplicar esta estrategia de prediccin al ejemplo de los dos procesos que usan la
cinta y la impresora. Tngase en cuenta que, dado que se trata de un sistema con una sola unidad de cada tipo
de recurso, bastara con comprobar que no hay un ciclo en el grafo para asegurar que no hay un interbloqueo.
En la figura 7.12 se muestra el estado inicial del sistema, justo cuando se acaban de crear los dos proce
sos. Ntese que en el mismo slo hay aristas de necesidad representando las necesidades mximas, puesto
que todava no se ha realizado ninguna peticin. Evidentemente, este estado inicial es seguro, como lo de
muestra la ausencia de un ciclo en el grafo que representa al mismo.
Supngase que el primer proceso realiza su solicitud de la cinta. Puesto que est disponible, se cons
truir de forma provisional el estado resultante de la asignacin del recurso, lo que queda reflejado en la figu-
Interbloqueos
477
F igura 7.12 Estado inicial del sistema.

ra 7.13. En este instante habra que aplicar el algoritmo de deteccin teniendo en cuenta las aristas de necesi
dad. Como se aprecia en la figura, no hay ciclos, por lo que el estado es seguro y puede hacerse permanente.
Si, a continuacin, el segundo proceso solicita la impresora, al estar disponible, se genera el estado pro
visional representado en la figura 7.14. El grafo resultante de transformar la arista de necesidad en una arista
de asignacin presenta un ciclo, por lo que hay un interbloqueo y el estado es inseguro. Por tanto, no se asig
nara el recurso y se bloqueara al proceso, restaurando el estado previo (el que corresponde con la figura
7.13). Ntese que, como se coment previamente, esta misma situacin se producira tambin en el ejemplo
modificado de los procesos, donde no poda haber interbloqueo.
Algoritmo del banquero
El algoritmo ms conocido de prediccin para una representacin matricial es el del banquero. Su nombre se
debe a que est concebido utilizando como modelo un banquero que presta dinero a sus clientes. Cada cliente
(proceso) tiene asignado un determinado crdito mximo (necesidad mxima del proceso). El banquero tiene
disponible una determinada cantidad de dinero en caja (nmero de unidades del recurso disponible). Los
clientes irn pidiendo y devolviendo dinero (o sea, solicitando y liberando unidades del recurso), de acuerdo
a sus necesidades. El algoritmo del banquero controla las peticiones de los clientes de manera que el sistema
est siempre en un estado seguro. O sea, se asegura que, si en un determinado momento todos los clientes
solicitaran su crdito mximo, al menos uno de ellos satisfara esta peticin, pudiendo, posteriormente, ter
minar su labor y devolver su dinero prestado, lo que permitira a otro cliente obtener sus necesidades, y as
sucesivamente.
Como se puede apreciar, este algoritmo tiene las mismas caractersticas que los algoritmos de predic
cin presentados hasta el momento. La nica diferencia es que utiliza una representacin matricial para mo
delar el sistema. Dijkstra propuso una versin de este algoritmo aplicable slo a un nico tipo de recurso con
mltiples unidades. Habermann lo generaliz para mltiples recursos.
Este algoritmo requiere utilizar, adems de la matriz de solicitud S y la de asignacin A, una nueva ma
triz que contenga las necesidades de los procesos:
Matriz de necesidad N de dimensin p x r . Siendo p el nmero de procesos existentes y r el nmero
de recursos diferentes que hay en el sistema, la componente N [ i , j ] de la matriz especifica cuntas
unidades del recurso j puede necesitar el proceso i. Este valor se corresponde con la diferencia entre
las necesidades mximas del proceso para dicho recurso y el nmero de unidades actualmente asig
nadas. Ntese que, por tanto, en esta matriz.no slo quedan reflejadas las posibles peticiones futuras
de cada proceso solicitando recursos hasta la cantidad mxima, sino tambin las peticiones actuales
que no han podido satisfacerse. Inicialmente, esta matriz contiene las necesidades mximas de cada
proceso.
478
Figura 7.13 Estado del sistema resultante si se acepta la primera peticin.

El procesamiento de las peticiones de solicitud y liberacin de recursos, adems de afectar al vector de
recursos disponibles y a las matrices de asignacin y solicitud, como se mostr en la seccin 7.3.2, modifi
car tambin la matriz de necesidad de la siguiente forma:
Cuando se satisface una solicitud, se restarn las unidades pedidas de cada recurso de la matriz de
necesidad y se sumarn a la matriz de asignacin. Obsrvese que una peticin que no puede satisfa
cerse no altera esta matriz, slo modifica la de solicitud, sumando las unidades correspondientes a la
misma. En el momento que se pueda satisfacer, se alterar la matriz de necesidad.
Cuando se produce una liberacin de recursos, se sustraen de la matriz de asignacin las unidades li
beradas y se aaden a la matriz de necesidad.
Como el algoritmo de prediccin basado en un grafo, el algoritmo del banquero determina si un estado
es seguro comprobando que no hay interbloqueos en dicho estado, pero teniendo en cuenta las peticiones
mximas, en este caso, las representadas por la matriz de necesidad.
Por tanto, el algoritmo es igual que el de deteccin de interbloqueos para la representacin matricial es
tudiado en el apartado 7.6.1, pero usando la matriz de necesidad, en vez de la de solicitud, a la hora de deter
minar si se puede reducir el estado del sistema por un determinado proceso.
Es interesante resaltar que en este algoritmo no se usa la matriz de solicitud para determinar si el estado
es seguro, ya que la matriz de necesidad refleja tanto las peticiones futuras del proceso como las peticiones
actuales que no han podido satisfacerse (usando la terminologa de la representacin mediante un grafo de
recursos, la matriz incluye las aristas de necesidad y las de reserva).
A continuacin, se muestra el algoritmo para determinar si un estado es seguro.
Figura 7.14 Estado del sistema resultante si se acepta la segunda peticin.
Interbloqueos
110
A= 0 1 2
10 0
479
3 0 2
N= 2 2 0
112
Figura 7.15 Estado inicial del sistema.

S= 0 ;
Repetir {
Buscar Pi tal que N[i] < D;
Si Encontrado {
Reducir grafo por Pi: D = D + A[i]
Aadir Pi a S;
Continuar = cierto;
}
Sino
Continuar = falso;
} Mientras (Continuar)
Si (S==P)
El estado es seguro
Sino
El estado no es seguro
Este algoritmo tendr, evidentemente, la misma complejidad (0(p2r)) que la versin que se usaba para
detectar interbloqueos.
Una vez especificado el algoritmo que determina si el estado es seguro, la definicin de la estrategia de
prediccin es casi directa. Cuando un proceso realiza una solicitud de recursos que estn disponibles, se cal
cula un nuevo estado provisional transformando las matrices de necesidad y de asignacin de acuerdo a la
peticin realizada.
Sobre este estado provisional, se aplica el algoritmo para determinar si es seguro. Si lo es, se asignan
los recursos solicitados haciendo que el estado provisional se convierta en permanente. En caso contrario, se
bloquea al proceso sin asignarle los recursos, restaurando, por tanto, el sistema al estado previo.
A continuacin, se va a aplicar esta estrategia de prediccin a un ejemplo. Considrese un sistema con
tres tipos de recursos (R^ R2 y R3) y 3 procesos (P i, P2 y P3). Supngase que se est utilizando el algoritmo
del banquero y que el estado actual del sistema, que se asume como seguro (el ejercicio 7.28 propone dem os
trar que este estado inicial es seg u ro ), es el mostrado en la figura 7.15.
Ntese que no se ha especificado la matriz de solicitud, puesto que no es relevante para el algoritmo.
Observando con detalle los datos del estado actual, se puede obtener informacin adicional sobre el sistema.
Por ejemplo, se puede apreciar que las necesidades mximas de Px con respecto al recurso Rj. son 4 unidades
(N [ 1 ,1 ] +A [ 1 , 1 ] ) , lo que coincide con el nmero total de unidades de dicho recurso que existen en el sis
tema (A [ 1 ,1 ] +A [ 2 , 1 ] + A (3 ,1 ].+ D [1 ]).
Supngase que, estando el sistema en ese estado, llega una peticin de P3 solicitando 1 unidad de R3.
En primer lugar, dado que el recurso implicado en la peticin est disponible, habra que calcular el estado
provisional resultante de satisfacer esta solicitud, que se muestra en la figura 7.16.
A continuacin, habra que comprobar si el nuevo estado es seguro aplicando el algoritmo del banquero
sobre dicho estado.
110
0 12
10 1
3 0 2
N= 2 2 0
111
Figura 7.16 Estado resultante si se acepta la prim era peticin.
480
1 1 0
1 1 2
10 1
3 0 2
N- 1 2 0
1 1 1
F ig u ra 7.17 Estado resultante si se acepta la segunda peticin.

El resultado de aplicar el algoritmo es el siguiente:
1.
2.
Se puede reducir por P3, ya que N[3] < D ([1 1 1]<[2 1 1]), dando como resultado:
3.
4.
Se aade el proceso a la secuencia de reduccin: S= {P3} y se pasa a la siguiente iteracin.

Reduccin por P i, dado que N [ l ] < D ( [3 0 2] < [3 1 2 ] ) , que da como resultado:
5.
6.
Se aade el proceso a la secuencia de reduccin: S = {P3l Pi} y se pasa a la siguiente iteracin.

Reduccin por P2, puesto que N [2] D ( [ 2 2 0 ] < [ 4 2 2 ] ), que da como resultado:
7.
8.
Se aade el proceso a la secuencia de reduccin: S= {P3, p x, P2} y se termina el bucle.

Como S incluye a todos los procesos, el estado del sistema es seguro.
D = D + A [3]
D = D + A [1]
D = D + A [2]
= [2 1 1]
+ [1 o 1] = [3 1 2]
= [3 1 2] + [1 1 0] = [4 2 2]
= [4 2 2]
+ [0 X 2 ]
= [4 3 4]
Por tanto, se aceptara la peticin, consolidando el estado provisional como nuevo estado del sistema.
Supngase que, a continuacin, el proceso P2 solicita 1 unidad de Rx. Puesto que el recurso implicado
est disponible, habra que, en primer lugar, calcular el estado provisional resultante, que sera el mostrado en
la figura 7.17.
Al aplicar al algoritmo que determina si el estado es seguro, el resultado sera el siguiente:
1.
2.
Se puede reducir por P3, ya que N [3 ] < D ( [ 1
D = D + A [3]
3.
4.
5.
= [1 1 1]
1 ]S [1
+ [1 0 1]
1 1 ] ), dando como resultado:

= [2 1 2]
Se aade el proceso a la secuencia de reduccin: S= {P3} y se pasa a la siguiente iteracin.

No hay ningn Pj. tal que N [ i ] < D. Termina la ejecucin del bucle.
Como S no incluye a todos los procesos, el estado del sistema no es seguro.
Por tanto, no se satisfara la peticin, bloqueando el proceso y restaurando el estado anterior del siste
ma.
Sea cual sea el algoritmo de prediccin utilizado, es conveniente resumir algunas de las deficiencias
que presentan este tipo de algoritmos:
Conocimiento de las necesidades mximas de los procesos. Esta informacin no siempre puede co
nocerse a priori y, en caso de poderse, siempre se deber corresponder con el peor caso posible en
cuanto al uso de recursos que puede tener un programa.
o Las necesidades mximas no pueden expresar el uso exacto de los recursos durante la ejecucin de
los programas. Por ello, como se vio en los ejemplos previos, se pueden detectar como inseguros es
tados que realmente no pueden conducir a un interbloqueo, ya que en ellos no hay un uso solapado
de recursos.
infirautilizacin de los recursos. Estos algoritmos pueden denegar la concesin de un recurso aunque
est disponible, producindose el consiguiente desaprovechamiento del mismo.
PLANIFICACIN DEL PROCESADOR

Uno de los principales objetivos del sistema operativo es planificar la utilizacin de los recursos del compu
tador por parte de los procesos activos en el sistema, de manera que se optimice el uso de los mismos, ofre
ciendo un servicio que satisfaga las necesidades de los usuarios. Dado que el principal recurso de un
computador es el procesador, la planificacin de este elemento es un componente clave de cualquier sistema
operativo y es el objeto de este captulo. Se trata de un componente fundamental para el buen funcionamien
to de un sistema, aunque, paradjicamente, su extensin habitual no vas ms all de unos pocos centenares
de lneas de cdigo fuente, frente a las decenas de millones de lneas que puede tener un sistema operativo
actual. Este tema se ha estudiado profusamente desde la aparicin de los primeros sistemas operativos multiprogramados, existiendo una abundante literatura sobre el mismo. Todo ese desarrollo terico, sin embar
go, no es suficiente. Los algoritmos de planificacin presentes en los sistemas operativos de propsito
general son una mezcla de todo este bagaje terico con una serie de ajustes de carcter emprico que consi
guen que el algoritmo funcione aceptablemente en las muy diversas situaciones que pueden presentarse en
un sistema de estas caractersticas. Para abarcar este doble perfil, en este capitulo se realizar, por una
parte, una revisin de los algoritmos de planificacin clsicos propuestos en la bibliografa de este tema,
pero, por otra parte, se estudiarn ejemplos de planificacin de sistema reales. Dada la creciente importan
cia de los multiprocesadores, se estudiarn los aspectos especficos de la planificacin en este tipo de siste
mas, abarcando el amplio espectro que va desde los procesadores con hyperthreading hasta los sistemas
NUMA. Asimismo, se estudiar otro mbito donde la planificacin es esencial y presenta caractersticas
especficas de inters como es el de los sistemas de tiempo real. Todo este contenido se presenta organizado
con la siguiente estructura:
Introduccin.
El problema de la planificacin de recursos.
Caracterizacin de los procesos.
Objetivos de la planificacin.
Niveles de planificacin.
Mecanismos y polticas de planificacin.
Algoritmos de planificacin no expulsivos.
Algoritmos de planificacin expulsivos.
Diseo e implementacin del planificador.
Planificacin en sistemas de tiempo real.
Planificacin de threads.
Planificacin en multiprocesadores.
Estudio de un ejemplo: la planificacin en Linux.
Servicios UNIX y Windows de planificacin.
154
Sistemas Operativos. Una visin aplicada
4.1.
INTRODUCCIN
Antes de la aparicin de la multiprogramacin, la planificacin del procesador era muy sencilla, puesto que a
cada programa se le asignaba el procesador hasta que completaba su ejecucin. Con la tcnica de la multi
programacin, el sistema operativo debe multiplexar a lo largo del tiempo el procesador entre los procesos
existentes, de manera transparente, salvando y restaurando el contenido de los registros del procesador en la
zona del bloque de control del proceso establecida para tal fin. Surge, por tanto, la necesidad de planificar la
asignacin del procesador entre los procesos activos en el sistema.
En los primeros sistemas multiprogramados, los sistemas por lotes, el objetivo principal del planifica
dor era obtener un buen aprovechamiento del procesador, puesto que los computadores eran muy costosos en
esa poca y era necesario sacarles todo el rendimiento posible. Por tanto, todos los algoritmos de planifica
cin iban destinados a tal fin.
Con el advenimiento de los sistemas de tiempo compartido, entraron enjuego muchos otros factores, tal
como el reparto equitativo del procesador entre los usuarios presentes en el sistema, que hicieron ms com
plejo el diseo del algoritmo de planificacin, puesto que requeran equilibrar factores muy diversos, e inclu
so, en algunos casos, contrapuestos.
La enorme difusin de los computadores personales y la revolucin que han supuesto las redes de co
municacin han creado nuevos retos para el planificador. Este tipo de sistemas requiere una gran interactividad y precisa que los tiempos de respuesta que observan los usuarios cuando interaccionan con las
aplicaciones a travs de una interfaz de usuario grfica sean casi instantneos para satisfacer sus expectativas
a la hora de trabajar con el sistema, incluso cuando detrs de esa interaccin existe una transmisin de infor
macin por una red.
La aparicin de los multiprocesadores ha causado tambin un fuerte impacto en el diseo del planifica
dor. Como se estudiar en la seccin 4.12, el planificador debe controlar la asignacin de los procesos a los
diversos procesadores disponibles intentando explotar al mximo el paralelismo del hardware.
Adems del uso del computador en entornos de propsito general, cada vez es ms frecuente su utiliza
cin en entornos donde existen requisitos de tiempo real. Como se analizar en la seccin 4.10, en el caso de
tratarse de sistemas de tiempo real no crtico, pueden afrontarse con sistemas operativos de propsito general,
siempre que en el diseo de los mismos se hayan tenido en cuenta los requisitos que imponen este tipo de
sistemas tanto al planificador como a otras partes del sistema operativo. Los sistemas de tiempo real crticos
requieren sistemas operativos especficos, as como algoritmos de planificacin propios, tal como se anali
zar en dicha seccin.
Es importante resaltar que la presencia de nuevos retos y objetivos para el planificador no conlleva que
desaparezcan los criterios ms tradicionales. Por tanto, como se explicar en la seccin 4.4, un esquema de
planificacin en un sistema actual tiene que intentar satisfacer aspectos tan diversos como lograr un buen
aprovechamiento del procesador, ofreciendo un reparto equitativo del mismo entre los usuarios, proporcio
nando un tiempo de respuesta muy bajo en el uso de aplicaciones interactivas, dando buen soporte a los mul
tiprocesadores, e intentando, dentro de lo posible, satisfacer las necesidades de los sistemas de tiempo real no
crtico. Para afrontar este reto, el diseo de un planificador requiere la aplicacin de todo el bagaje terico
desarrollado en este campo, que incluye una serie de algoritmos clsicos presentados en las secciones 4.7 y
4.8. Sin embargo, tambin es necesario incluir en el algoritmo de planificacin una serie de tcnicas pura
mente empricas para lograr un comportamiento adecuado en los muy diversos escenarios donde se puede
utilizar un sistema operativo de propsito general. Para hacer ms nfasis en este aspecto, tngase en cuenta
que un sistema operativo de estas caractersticas, como Linux, cuyo esquema de planificacin se presentar
en la seccin 4.13, est concebido para su uso en el amplio rango de mquinas que va desde sistemas empo
trados y porttiles hasta grandes multiprocesadores NUMA, tanto para sistemas destinados al trabajo interac
tivo de un usuario como para grandes servidores, as como para operar en todo tipo de entornos (de oficina,
cientficos, de ingeniera, universitarios, empresariales, de tiempo real, etctera). Como podr imaginar el
lector, disear un sistema operativo con tanta versatilidad es una labor compleja y en ella juega un papel muy
importante el planificador.
De todas las consideraciones previas, se deduce que la planificacin de procesos y threads es funda
mental en cualquier sistema operativo. Las entidades ejecutables que existen en el sistema no haran funcio-
Planificacin del procesador
155
Recurso
------->[
cola de espera
fU 6 : U11 U9
Figura 4.1 Planificacin en un sistema con mltiples ejemplares de un recurso.

nar el mismo si no existieran mecanismos y polticas para explotar el procesador. Se puede definir la planifi
cacin como el conjunto de polticas y mecanismos construidos dentro del sistema operativo que gobiernan
la forma de conseguir que los procesos se ejecuten en el procesador. Desde este punto de vista, la planifica
cin est asociada a cuestiones como la colocacin de procesos creados en espera de procesador, la determi
nacin del orden de ejecucin de los procesos, la decisin del momento en que introducir un nuevo proceso
en el sistema y la distribucin de carga si existe ms de un procesador.
Para desarrollar estos temas, a continuacin estudiaremos la caracterizacin de procesos, los objetivos
de la planificacin, los mecanismos y polticas de planificacin, los algoritmos de planificacin que implementan las polticas, y aspectos de planificacin en sistemas avanzados, como tiempo real o multiprocesado
res. Por ltimo, se mostrarn los servicios de planificacin ms habituales en UND y Windows, as como
ejemplos de programacin de sistemas usando estos servicios.
4.2.
EL PROBLEMA DE LA PLANIFICACIN DE RECURSOS
La planificacin de recursos es un problema general que va ms all del campo de los sistemas operativos e,
incluso, de la propia informtica. En su concepcin general, este problema se presenta cuando mltiples
usuarios, sean del tipo que sean, necesitan usar de forma exclusiva un determinado recurso, que puede cons
tar de uno o ms ejemplares, en varias fases a lo largo de su ejecucin. La planificacin determina en cada
instante qu ejemplar se le asigna a cada uno de los usuarios que requiera utilizar el recurso en ese momento.
Se presentan varias posibilidades dependiendo del nmero de ejemplares disponibles:
Si el nmero de usuarios que precisan usar el recurso en ese momento es menor o igual que el nme
ro de ejemplares existentes, la planificacin debe decidir qu ejemplar se asigna a cada usuario. Por
tanto, la planificacin lleva a cabo una multiplexacin espacial de los recursos.
Si hay ms peticiones de uso que ejemplares disponibles, el planificador debe determinar qu usua
rios obtendrn un ejemplar del recurso, y qu ejemplar recibir cada uno, y cules no. Aquellos usua
rios cuya peticin no pueda satisfacerse en ese instante debern aguardar en una cola de espera hasta
que el planificador decida asignarles un ejemplar del recurso. En este caso, se produce una multi
plexacin temporal y espacial de los recursos. En la figura 4.1 se muestra un ejemplo donde hay un
recurso con 4 ejemplares y existen 7 usuarios que necesitan usarlo. La planificacin determina qu
cuatro usuarios obtienen un ejemplar del recurso, y qu ejemplar consigue cada uno, y qu tres usua
rios debn quedarse aguardando en la cola de espera.
En el caso particular de que se trate de un recurso con un nico ejemplar, slo es preciso decidir a
qu usuario asignar ese ejemplar en cada momento. La planificacin realiza una multiplexacin tem
poral del recurso.
Antes de proseguir con el anlisis de este problema general, se plantea un caso hipottico del mismo,
que servir como ejemplo a lo largo del captulo, y que se ir completando progresivamente para ilustrar los
diversos aspectos involucrados en la planificacin. Suponga que un equipo de mdicos de una determinada
especialidad atiende a sus pacientes en una clnica, de manera que cada mdico tiene su propia consulta, pero
tal que cualquier mdico puede atender a un paciente, puesto que, al ser parte del mismo equipo, comparten
los historiales clnicos de los pacientes. En este ejemplo, los usuarios son los pacientes, el recurso es el servi
156
ci de atencin mdica, siendo cada mdico del equipo un ejemplar del mismo, y la sala de espera de la clni
ca, como su nombre indica, hace el papel de cola de espera.
Aunque se analizarn con ms detalle en la seccin 4.4, en este modelo general ya se pueden detectar
qu diversos objetivos debe intentar satisfacer un esquema de planificacin de recursos:
Dado que lo que se pretende es administrar un recurso, uno de los principales objetivos de la planifi
cacin ser optimizar el uso de dicho recurso. En el ejemplo, habr que intentar que, siempre que
haya trabajo pendiente, el equipo mdico est ocupado lo mximo posible.
Hay que minimizar el tiempo gastado por el usuario en la cola de espera, puesto que repercute nega
tivamente en la calidad del servicio recibido. En el caso hipottico planteado, si un paciente tiene que
esperar mucho tiempo en la sala de espera antes de ser atendido, probablemente, no volver a esta
clnica la prxima vez. El malestar ser mayor si ese largo tiempo de espera se ha producido en una
visita en la que el tiempo de consulta requerido es muy breve.
Puesto que hay que dar servicio a mltiples usuarios, la planificacin debe asegurar un reparto equi
tativo del recurso entre los distintos usuarios que precisan su uso. En el ejemplo planteado, el equipo
mdico debera dar un tratamiento de la misma calidad a todos los pacientes.
Generalmente, no todas las peticiones de uso del recurso tendrn el mismo grado de urgencia (la
misma prioridad), por lo que el planificador debera satisfacer las peticiones teniendo en cuenta este
aspecto. En el ejemplo del servicio de atencin mdica, la existencia de distintos grados de urgencia
se explica por s misma.
Un aspecto importante en un sistema de estas caractersticas es si el recurso administrado es expropiable o no, es decir, si es posible interrumpir el uso de un recurso por parte de un usuario para asignrselo a
otro, pudindoselo reasignar posteriormente sin prdida del trabajo ya realizado. Como veremos un poco ms
adelante, y estudiaremos en detalle en la seccin 7.2.1, en el caso de un computador, algunos recursos son
intrnsicamente no expropiables. En el caso de la clnica, se trata de un recurso expropiable: el mdico puede
decidir interrumpir la atencin a un paciente para tratar a otro que presenta un problema urgente. Una vez
tratado el caso urgente, el mdico puede retomar la atencin al primer paciente en el punto donde se qued,
aunque con un cierto trabajo adicional (el paciente ha tenido que pasar antes a la sala espera y ahora volver a
la consulta; el mdico deber retomar el historial clnico de este paciente; etctera). Teniendo en cuenta este
aspecto, se presentan dos alternativas a la hora de realizar la planificacin:
Planificacin no expulsiva. Una vez asignado un ejemplar de un recurso a un usuario, ste lo man
tendr hasta que termine de usarlo. El esquema de planificacin slo se activa cuando un ejemplar
queda libre. Este es el nico esquema factible si el recurso es no expropiable, aunque tambin se
puede usar con recursos expropiables si se considera oportuno. Como se analizar en la seccin 4.7,
este esquema dificulta el reparto equitativo del recurso entre los usuarios y no permite implantar
adecuadamente grados de urgencia en el servicio. En el ejemplo de la clnica, se correspondera con
un esquema donde bajo ninguna circunstancia se interrumpira la atencin a un paciente.
Planificacin expulsiva. Esta alternativa, que slo podr usarse si el recurso es expropiable, puede
reasignar a un usuario un ejemplar de un recurso que est siendo usado por otro usuario cuando las
circunstancias lo propicien, ya sea en aras de un reparto equitativo del recurso o por motivos de gra
dos de urgencia. Adems de cuando se queda un ejemplar del recurso libre, el algoritmo de planifi
cacin de recursos tambin se activar en otras circunstancias, tales como cuando llegada una nueva
peticin de un recurso o cuando el tiempo de uso de un recurso por parte de un usuario llega a un
cierto plazo mximo. En el ejemplo planteado, dado el carcter expropiable de la atencin mdica, se
puede utilizar una estrategia de planificacin de este tipo.
Otro aspecto que ya se puede vislumbrar en este modelo general es la afinidad. En principio, una peti
cin de uso de un recurso por parte de un usuario puede satisfacerse utilizando cualquier ejemplar libre (si
para una peticin debe usarse un determinado ejemplar, realmente no se trata de un recurso con mltiples
ejemplares, sino mltiples recursos con un solo ejemplar cada uno). Sin embargo, en ocasiones, un usuario
puede considerar oportuno restringir qu ejemplares de un recurso pueden utilizarse para satisfacer sus peti
ciones. Esta restriccin establece que el usuario tiene afinidad hacia ese conjunto de ejemplares. El planifica
dor nunca asignar a un usuario un ejemplar que no est incluido dentro del conjunto que define su afinidad,
157
incluso aunque est libre y los de dicho conjunto ocupados. Por ello, denominaremos a esta caracterstica
afinidad estricta. En el ejemplo de la clnica, correspondera a un paciente que slo permite que le atiendan
ciertos mdicos del equipo.
Adems de la afinidad estricta, existe otro tipo de afinidad que denominaremos afin id ad n atu ral. En
este caso, el usuario no establece ninguna restriccin en el uso de los ejemplares. Sin embargo, para cierto
tipo de recursos, puede obtenerse algn beneficio si al usuario se le asigna el mismo ejem plar que la ltima
vez que utiliz el recurso. El ejemplar puede tener memoria de ese usuario, con lo que disminuye el tiempo
de servicio. Se podra decir que el usuario tiene afinidad natural hacia ese ejemplar. En el ejemplo del servi
cio mdico, es preferible que al paciente le atienda el mismo mdico que en la ltima visita, puesto que pro
bablemente recuerde alguna informacin clnica de dicho paciente, agilizndose, por tanto, la consulta.
A continuacin, nos centramos en el caso que nos interesa, es decir, en los recursos de un computador y
en la manera como el sistema operativo los planifica. En este caso, los usuarios son los procesos o threads
presentes en el sistema y, en cuanto a los recursos a planificar, existe una gran variedad, entre la que se pue
den destacar los siguientes recursos:
El procesador. Es el recurso bsico del computador. Puede constar de varios ejemplares si se trata
de un sistema multiprocesador. El planificador controla la asignacin de procesadores a los threads
(o a los procesos, en un sistema que no implemente esta abstraccin) listos para ejecutar y es el obje
to de este captulo. Ntese que la cola de procesos listos se corresponde con la cola de espera de este
recurso, que es de tipo expropiable (basta con salvar y restaurar los registros en el BCP) y en el que
se presenta la propiedad de la afinidad, como se analizar en la seccin 4.12.
L a m em oria. En los sistemas con memoria virtual, tal como se analizar en la seccin 5.5, se produ
ce una multiplexacin espacial y temporal de los marcos de pgina existentes, que se corresponden
con los ejemplares del recurso, entre los procesos activos en el sistema. Las polticas de reparto de
espacio y de reemplazo, que se estudian en dicha seccin, constituyen el esquema de planificacin de
este recurso. Obsrvese que se trata de un recurso expropiable (slo requiere copiar a memoria se
cundaria el contenido del marco expropiado), sobre el que se utiliza una planificacin expulsiva (el
reemplazo de un marco equivale a reasignar un ejemplar de un recurso mientras lo estaba usando un
proceso).
El disco. Los procesos realizan peticiones de acceso al disco que deben planificarse para determinar
en qu orden se van sirviendo. En la seccin 8.5.2 se estudiarn los diversos algoritmos de planifica
cin del disco. En este caso se trata de un recurso compuesto de un nico ejemplar (aunque haya va
rias unidades de disco, un proceso querr usar aqulla que contiene los datos que pretende
manipular), no expropiable (no se puede interrumpir una operacin sobre el disco sin abortarla),
siendo la cola de bloqueo del disco la que corresponde con la cola de espera.
Los m ecanism os de sincronizacin. Cuando un proceso deja libre un mutex que tena cerrado, co
mo se analizar en el captulo 6, o cuando libera un cerrojo asociado a un fichero, como se ver en el
captulo 9, hay que planificar a cul de los procesos que estn esperando usar este recurso, en caso de
que haya alguno, se le asigna dicho recurso. Evidentemente, se trata de un recurso no expropiable,
puesto que en la esencia de estos mecanismos est que el proceso debe mantener el recurso hasta que
lo libere voluntariamente.
En el ejemplo de la clnica tambin es necesario planificar mltiples tipos de recursos. Adems de la
atencin mdica directa, durante la misma pueden requerirse pruebas adicionales (analticas, diagnsticos
basados en imgenes, etctera). La clnica cuenta tambin con estos servicios y en cada uno de ellos aparecen
todos los elementos caractersticos de un sistema de planificacin (usuarios, ejemplares, salas de espera,
carcter expropiable y posible afinidad). De alguna manera, una estancia de un paciente en la clnica sigue la
misma pauta que la evolucin de un proceso durante su ejecucin en el sistema:
Cuando se crea el proceso, se aade a la lista de procesos listos para ejecutar. El paciente que entra
en la clnica pasa a la sala de espera.
En un momento dado, el planificador asignar un procesador al proceso. En cierto instante, el pa
ciente ser atendido por un mdico.
158

El proceso en ejecucin se bloquea a la espera de cierto evento, producindose un cambio de contex
to voluntario, quedndose vinculado a la cola de espera asociada con dicho evento; terminada la es
pera por ese evento, el proceso pasar a la cola de procesos listos para ejecutar. El paciente puede
dejar momentneamente la consulta del mdico, puesto que necesita realizarse unas determinadas
pruebas antes de proseguir, pasando a la sala de espera asociada al servicio que lleva a cabo ese tipo
de pruebas (por ejemplo, la sala de espera de los servicios de radiografas); cuando termine la prue
ba, el paciente se reincorporar a la sala de espera de las consultas mdicas.
El proceso en ejecucin es expulsado del procesador, ya sea por motivos de reparto equitativo del
procesador o por existir un proceso con mayor prioridad, volviendo a la cola de listos para ejecutar.
La consulta al paciente es interrumpida, volviendo ste a la sala de espera y pasando el mdico a
atender a otro paciente.
Antes de empezar en las prximas secciones a estudiar especficamente el problema de la planificacin

del procesador, consideramos que es conveniente explicar por qu motivo en este libro se ha optado por asig
nar un captulo independiente a la planificacin de este recurso, en vez de incluirlo en el captulo de procesos,
mientras que el estudio de la planificacin de otros tipos de recursos, como la memoria o el disco, est englo
bado dentro de captulos ms generales. Realmente, hay varios motivos. Por un lado, se trata del componente
ms importante del sistema y, por tanto, de su buena administracin depende en gran medida el rendimiento
del mismo. Adems, presenta una mayor complejidad que la planificacin de otros recursos, debido, princi
palmente, a la gran diversidad de factores que debe tener en cuenta para conseguir un buen rendimiento en
muy diversas situaciones.
4.3.
CARACTERIZACIN DE LOS PROCESOS
Para proporcionar un buen servicio, sea del tipo que sea, hay que conocer las caractersticas y las necesidades
de los clientes. En el caso de la planificacin de procesos, es evidente que no todos los procesos son iguales y
que, por tanto, es necesario caracterizar el comportamiento y las necesidades de los mismos. Para ello, en
esta seccin se van a distinguir tres factores: el perfil de uso del procesador que presenta el proceso, su grado
de interactividad y su nivel de urgencia.
Perfil de uso del procesador
Un programa est formado por una secuencia de instrucciones entre las que se incluyen llamadas al sistema
para solicitar servicios del sistema operativo. Algunas de estas llamadas implican el uso de un determinado
recurso y causan el bloqueo del proceso mientras se espera por el mismo. Por tanto, la ejecucin de un pro
grama puede verse como una secuencia en la que se va alternando una fase de uso del procesador (denomina
da rfaga de procesador) con una fase de bloqueo asociada al uso de un recurso (denominada,
habitualmente, rfaga de entrada/salida, debido a que en la mayora de los casos se trata de un dispositivo
de entrada/salida). La duracin de las sucesivas rfagas de procesador de un programa es una caracterstica
intrnseca del mismo y es un factor importante a la hora de realizar la planificacin del procesador, pues de
termina la cantidad de tiempo que un proceso usa el procesador cada vez que se le asigna.
Existen programas con rfagas de procesador muy cortas, es decir, que realizan frecuentes llamadas pa
ra operar con dispositivos de entrada/salida u otros recursos bloqueantes del sistema operativo. Se podra
decir que el tiempo total de ejecucin de estos procesos est condicionado en mayor parte por el tiempo de
uso de estos recursos bloqueantes, ms que por el propio uso del procesador. Por ello, se suelen denominar
procesos con un uso intensivo de la E/S, como el que se muestra en la figura 4.2, donde las rfagas de pro
cesador se han marcado con lnea continua y las de entrada/salida con lnea discontinua. En contraposicin,
hay programas que tienen largas rfagas de procesador, usando ocasionalmente recursos bloqueantes. Dado
que el ritmo de ejecucin de estos programas est condicionado principalmente por su uso del procesador, se
les aplica habitualmente el calificativo de procesos con un uso intensivo del procesador, como el que apa
rece en la figura 4.3.
159
Programa
inicioQ;
Repetir
leer(fichero_entr, dato);
/* procesado sencillo /
res=pr(dato);
escribir(fichero_sal, res);
hasta EOF(fichero_entr);
inicio
leer
pr escribir
leer
pr escribir
escribir
fin
fin();
Figura 4.2 Proceso con un uso intensivo de la E/S.

Hay algunos programas que encajan bien en esta dicotoma. Un programa que realiza clculos comple
jos sobre una cantidad relativamente pequea de datos almacenados en un fichero se correspondera con un
proceso con un uso intensivo del procesador, mientras que una aplicacin grfica en la que el usuario selec
ciona operaciones, tal que todas son relativamente simples, responde al perfil de proceso con un uso intensivo
de la entrada/salida. Sin embargo, la mayora de los procesos van cambiando de perfil a lo largo de las distin
tas fases de su ejecucin. As, retomando los ejemplos previos, muchos programas de carcter cientfico re
quieren leer de disco una cantidad muy grande de datos en su fase inicial y escribir en ese mismo dispositivo
unos resultados que ocupan tambin un gran tamao. Por otra parte, hay aplicaciones grficas interactivas
que incluyen algunas operaciones que requieren un uso intensivo del procesador.
El poder prever, hasta cierto punto, el tamao de la prxima rfaga de procesador de un proceso es un
aspecto muy importante, que, de una forma u otra (vase el algoritmo SJF en la seccin 4.7.2), est presente
en los esquemas de planificacin de todos los sistemas operativos. Aunque a lo largo del captulo se explicar
en detalle esta cuestin, a continuacin, se muestra un ejemplo que ilustra su importancia.
Supongamos que se ha quedado libre un procesador y hay dos procesos listos para ejecutar, P y P2, tal
que para P se estima que tendr una rfaga de procesador de 100 unidades de tiempo, mientras que para P2
se prev una rfaga de 10. Analicemos qu valor tendrn los tiempos de espera dependiendo del orden de
asignacin del procesador:
Si ejecuta P en primer lugar, P tendr que esperar 100 unidades de tiempo para ejecutar, obtenin
dose un tiempo de espera medio de 50 unidades de tiempo (el primer proceso no tuvo que esperar).
En caso de que se ejecute primero Pi, P tendr que esperar 10 unidades de tiempo para ejecutar, ob
tenindose un tiempo de espera medio de 5 unidades de tiempo.
Este ejemplo sencillo confirma una idea intuitiva que se cumple en cualquier tipo de servicio: de cara a
minimizar el tiempo de espera, es mejor servir primero las peticiones ms cortas. Explicado de manera in
formal usando el ejemplo de la clnica, alguien que est esperando que se le atienda para una consulta que
dura 100 minutos, no se ver muy afectado por una espera de 10 minutos. Sin embargo, un paciente que re
quiere una consulta de 10 minutos puede considerar intolerable tener que esperar 100.
Programa
inicioQ;
leer(fichero, matriz);
inicio
o
leer
procesar
escribir
fin
i-------------- t-------------------------------------------1-------------- I ------- -o
/* procesado complejo */
procesar(matriz);
escriblr(fichero, matriz);
fin();
Figura 4.3 Proceso con un uso intensivo del procesador.
160
G rado de interactividad
Por grado de interactividad de un programa, nos referimos al nivel de interaccin directa que existe entre el
usuario de la aplicacin y sta misma. Un programa con un alto grado de interactividad va ejecutando las
operaciones que selecciona el usuario mediante dispositivos de entTada tales como el teclado o el ratn. Fren
te a este tipo de programas, existen otros, denominados habitualmente procesos batch, en los que no existe
este dilogo: una vez activado el programa, ste ejecuta sin ninguna interaccin directa con el usuario, leyen
do, normalmente, sus datos de ficheros y dejando los resultados tambin en ficheros. Como ocurra con el
perfil de uso de procesador, en muchos casos, la divisin no es tan drstica, y un programa puede pasar por
fases de mayor o menor interactividad. Tngase en cuenta que un programa con un alto grado de interactivi
dad normalmente tiene un perfil de uso intensivo de la E/S. Sin embargo, la afirmacin contraria no es siem
pre cierta, ya que un proceso no interactivo puede realizar muchas operaciones de entrada/salida sobre
dispositivos que no estn vinculados directamente con el usuario, como son los discos.
De cara a la planificacin, hay que asegurar que un proceso con un alto grado de interactividad respon
de rpidamente a las peticiones del usuario, puesto que, en caso contrario, ste quedara insatisfecho con el
servicio proporcionado por el sistema operativo. Obsrvese que el dar prioridad a los procesos con rfagas
ms cortas, tal como se plante en el apartado anterior, conlleva un beneficio a los procesos interactivos, al
tener stos este tipo de perfil, aunque tambin a otros procesos que no lo son. Por ello, adicionalmente, el
planificador debera otorgar a estos procesos unos beneficios extras. Por ejemplo, algunos planificadores
conceden mayor prioridad a los procesos que estn ejecutando en primer plano o, si se trata de aplicaciones
grficas, cuya ventana tenga el foco activo.
Nivel de urgencia
Es evidente que todos los procesos activos en el sistema no tienen el mismo grado de urgencia. Por un lado,
algunos procesos realizan labores vinculadas con el funcionamiento de ciertas partes del sistema operativo y
son, por tanto, crticos. Dentro de esta categora se encuentran algunos procesos del ncleo, tal como el de
monio de paginacin que se estudia en la seccin 5.5 (tngase en cuenta que no todos los procesos del ncleo
tienen una gran prioridad; el proceso nulo, por ejemplo, tiene prioridad mnima). Tambin existen procesos
del sistema (es decir, procesos en modo usuario, pero arrancados por el sper-usuario) que requieren esa prio
ridad elevada. En cuanto a los usuarios convencionales, aunque no pueden tener un control ilimitado sobre el
grado de prioridad que tienen sus procesos, tambin requieren poder definir distintos niveles de urgencia en
tre sus propios procesos.
Para garantizar el grado de urgencia requerido, el sistema operativo debe asegurar que cuando un pro
ceso urgente se incorpora a la cola de procesos listos, obtiene el uso del procesador inmediatamente.
Un campo donde este aspecto es fundamental es el de los sistemas de tiempo real, donde existen proce
sos que tienen que cumplir unos requisitos estrictos en cuanto a plazos de ejecucin y tiempo de respuesta.
Como se coment previamente y se analizar con detalle en la seccin 4.10, los sistemas operativos de
propsito general actuales intentan dar soporte a este tipo de procesos, aunque sea en entornos de tiempo real
no crtico.
Resumiendo, el planificador debera gestionar distintos niveles de prioridad de servicio permitiendo que
en ellos se puedan plasmar los diversos grados de urgencia que tienen las labores que se llevan a cabo en un
sistema en un momento dado.
Como recapitulacin de esta seccin, se puede destacar que de la propia caracterizacin de los procesos
surgen de forma natural algunos de los requisitos que debe satisfacer un planificador en un sistema operativo
de propsito general. El planificador deber favorecer a los procesos que tengan las siguientes caractersticas:
Procesos con un uso intensivo de la entrada/salida, para minimizar el tiempo medio de espera.
Procesos interactivos, para asegurar que responden rpidamente al usuario.
Procesos urgentes, para garantizar que se ejecutan sin ningn tipo de demora.
4.4.
161
OBJETIVOS DE LA PLANIFICACIN
El objetivo de la planificacin es optimizar el comportamiento del sistema. Ahora bien, el comportamiento de

un sistema informtico es muy complejo, por tanto, el objetivo de la planificacin se deber centrar en la fa
ceta del comportamiento en la que se est interesado. Sin embargo, para poder hacer una evaluacin de obje
tivos es importante tener definidos dos aspectos: parmetros a evaluar y modelo del planificador.
4.4.1. Parmetros de evaluacin del planificador
Para caracterizar el comportamiento de los algoritmos de planificacin se suelen definir dos tipos de parme
tros: de usuario (ya sea de proceso o de thread) y de sistema. Los primeros se refieren al comportamiento del
sistema tal y como lo perciben los usuarios o los procesos. Los segundos se centran principalmente en el uso
eficiente del procesador. Un proceso o thread se puede caracterizar con tres parmetros principales:
Tiempo de ejecucin (Te): Tiempo que tarda en ejecutarse un proceso o thread desde que se crea
hasta que termina totalmente. Incluye todo el tiempo en que el proceso est listo para ejecutar, en
ejecucin y en estado bloqueado (por sincronizacin o entrada/salida).
Tiempo de espera (Tw): Este parmetro define el tiempo que pasa un proceso en la cola de procesos
listos para ejecutar. Si el proceso no se bloquea nunca, es el tiempo que espera el proceso o thread en
estado listo para ejecutar antes de que pase al estado de ejecucin.
Tiem po de respuesta (Ta): Tiempo que pasa entre el momento en que se crea el proceso y se pone
listo para ejecutar y la primera vez que el proceso responde al usuario. Es fundamental en los siste
mas interactivos, ya que un sistema de planificacin se puede configurar para responder muy rpido
al usuario, aunque luego el proceso o thread tenga un tiempo de ejecucin largo.
Desde el punto de vista de la planificacin, un sistema se caracteriza con dos parmetros principales:
Uso del procesador (C): Tiempo en que se ha utilizado el procesador. Normalmente esta medida se
expresa en porcentajes que se definen comparando el tiempo de uso del procesador con el tiempo (T)
desde que se arranc el sistema - Tu / T - , donde Tu es el tiempo til dedicado a procesamiento y se
puede calcular sumando los tiempos en que hay un proceso en estado de ejecucin, exceptuando el
proceso nulo. Este parmetro vara mucho dependiendo de los sistemas. Por ejemplo, un computador
de sobremesa suele usarse menos de un 15%. Sin embargo, un servidor muy cargado puede usarse al
95%. Este parmetro es importante en sistemas de propsito general, pero es mucho ms importante
en sistemas de tiempo real y con calidad de servicio. En estos ltimos casos, siempre debe existir un
porcentaje de uso del procesador que permita crear un proceso o thread, como se ver ms adelante.
Tasa de trab ajo s com pletados (P): Este parmetro indica el nmero de procesos o threads ejecuta
dos completamente por unidad de tiempo. Se puede calcular como la inversa del tiempo medio de
ejecucin (1 / Media(Te)).
Los problemas de planificacin se pueden modelar como un sistema de ecuaciones con restricciones,
donde se trata de maximizar algunos de los parmetros anteriores, los que afectan al uso del sistema, y mini
mizar otros, los que afectan al proceso o thread. Entre los objetivos que se persiguen estn los siguientes:
Optimizar el uso del procesador para conseguir ms eficiencia: max(C).

Minimizar el tiempo de ejecucin medio de un proceso o thread: min(Te).
M i n i m i z a r el tiempo de respuesta medio en uso interactivo: min(Ta).
Minimizar el tiempo de espera medio: min(Tw).
Maximizar el nmero de trabajos por unidad de tiempo: max(P).
Aunque tambin se pueden perseguir objetivos ms complejos y no tan fcilmente modelables, como:
Imparcialidad.
Poltica justa. Realizar un reparto equitativo del procesador.
162
Eficiencia: mantener el procesador ocupado el mayor tiempo posible con procesos de usuario.
Predecibilidad en la ejecucin. Cumplir los plazos de ejecucin de un sistema de tiempo real
Equilibrio en el uso de los recursos.
Minimizar la varianza del tiempo de respuesta.
Reducir el tiempo de cambio entre procesos o threads.
Etctera.
Muchos de estos objetivos son incompatibles entre s, por lo que hay que centrar la atencin en aqul
que sea de mayor inters. Por ejemplo, una planificacin que realice un reparto equitativo del procesador no
conseguir optimizar el uso del mismo. Adems, hay que decir que algunos objetivos estn dirigidos a proce
sos interactivos, mientras que otros lo estn a procesos de tipo batch. Por tanto, para valorar los algoritmos de
planificacin hay que tener en cuenta los beneficios que presenta cada una de las alternativas a analizar y el
tipo de sistema en que se van a usar. Asimismo, no hay que olvidar el tiempo de procesador que se consume
debido al propio algoritmo (tiempo gastado en aadir elementos a las colas, ordenar stas y analizarlas). En
este sentido un algoritmo menos bueno pero muy simple, como el aleatorio, que consume muy poco tiempo
de procesador, puede ser globalmente mejor que otro ms sofisticado, puesto que la ganancia de rendimiento
conseguida puede no compensar el mayor tiempo consumido. Adems de eficiente, el algoritmo de planifica
cin debe ser escalable, es decir, mostrar un buen comportamiento en sistemas donde puede haber decenas de
miles de procesos listos para ejecutar. El objetivo es disear esquemas de planificacin cuyo orden de com
plejidad sea constante y no dependa del nmero de procesos listos.
En general, en los sistemas operativos de propsito general se persiguen los objetivos enunciados arri
ba, es decir, maximizar el uso del procesador (C) y el nmero de procesos ejecutados por unidad de tiempo
(P), al tiempo que se quiere minimizar el tiempo de ejecucin de un proceso, su tiempo de respuesta y de
espera (Te, Tw, Ta). En otros sistemas, como en los servidores interactivos, se suele primar la reduccin del
tiempo de respuesta (Tw), de forma que los clientes tengan la sensacin de que el sistema les atiende rpida
mente y no abandonen el servicio. En los sistemas de trabajo por lotes, se suele tratar de maximizar C y P,
para explotar al mximo el procesador, como veremos ms adelante.
4.4.2. Modelo del planificador

En general, un planificador se puede modelar como un sistema de colas, cuya complejidad aumenta segn el
tipo de planificador y la existencia o no de ms de un procesador.
El caso ms sencillo es aqul en el que el planificador no es expulsivo y no implementa niveles de prio
ridad. Se asume tambin que los procesos no se bloquean. En este caso, el modelo es similar al de la figura
4.4, donde se supone que las llegadas al sistema seguiran una funcin de distribucin de Poisson (el tiempo
entre dos llegadas consecutivas tiene distribucin exponencial). Las llegadas de trabajos listos para ejecutar
se deben a nuevos procesos (lnea continua) y a procesos expulsados del procesador (lnea discontinua). Si no
hay expulsin, este ltimo flujo no existe. Para caracterizar el modelo se tienen en cuenta dos parmetros:
Tasa media de llegada (X), de procesos o threads por unidad de tiempo al sistema. Es decir, nmero
de trabajos que estn listos para ejecutar por unidad de tiempo.
Tiempo medio de servicio (x) del sistema. Es decir, tiempo medio que se tarda en ejecutar los traba
jos que llegan al sistema. La tasa de trabajos completados por unidad de tiempo ser pues P = 1/t.
En este modelo, el uso del procesador por unidad de tiempo cuando el sistema est en rgimen perma
nente, se puede expresar mediante la frmula:
C = A.t
Si k es mayor que P, entonces hay un tiempo de espera en la cola, ya que el sistema no es capaz de pro
cesar los trabajos en cola antes de que llegue uno nuevo. Por tanto, el tiempo medio de ejecucin Te ser
igual a la suma del tiempo medio de espera y del tiempo medio de servicio:
Te = Tw + t
165
servicio y no se rechazan usuarios, como ocurre en sistemas de tiempo real y con calidad de servicio. Ahora
bien, incluso si C es menor que 1, es importante estudiar los algoritmos de planificacin para ver cul es el
tiempo medio de servicio (x) esperado para el sistema.
En el caso de que hubiera bloqueos, observe, que el uso del procesador, sin embargo, no depende del
tiempo de bloqueo de los procesos ni del tiempo de espera en la cola. Slo depende del tiempo que se usa el
propio procesador. Por tanto, C se podra calcular como:
C = X (n a)
Si el sistema tiene mltiples colas segn la prioridad de los procesos, habr una tasa de llegadas Xi,
siendo i la prioridad del proceso. La tasa total de llegadas X = Xi. En este caso se puede afinar ms la eva
luacin y ver hasta qu nivel de prioridad se pueden procesar los trabajos. Si todo va bien, se cumple que C <
1. Ahora bien, si C > 1, se puede calcular la prioridad i a partir de la cual hay inanicin. Asumiendo una dis
tribucin uniforme por nivel de prioridad (Xi = X / p), C se podra calcular como:
C = Xi t, siendo i = 0.. p => C = p (X x/ p) = (X x)
En este caso, se puede calcular el sumatorio de niveles:
Ci = Xi x, i=0..k, tal que C i < 1
El valor k para el que C se hace mayor que 1 indica que a partir de ese nivel de prioridad habr inani
cin si no hace nada en el planificador para proporcionar algn tipo de reparto del procesador distinto de la
prioridad pura. Si hay una distribucin de llegadas uniforme por prioridad, este valor ser:
k (X x /p ) = ( k /p ) (X x ) < 1
Cuando estudiemos los algoritmos de planificacin ms adelante, veremos cmo se comportan frente a
los parmetros anteriores.
4.5.
NIVELES DE PLANIFICACIN
En un sistema operativo, la planificacin sirve fundamentalmente para gestionar el uso del procesador, pero
no slo para eso. Hay tambin otros recursos, como la memoria o los discos, que tambin se ven afectados
por la planificacin. Es por ello necesario tener tres niveles de planificacin, como se muestra en la figura
4.7: a corto plazo, a medio plazo y a largo plazo.
La planificacin a corto plazo (tambin llamado short-term scheduler) se encarga de la gestin ms
directa del procesador. Es responsable de decidir qu proceso de los que estn en la cola de listos para ejecu
tar, y por cunto tiempo, recibe el procesador para ejecutar. Este captulo se centra bsicamente en este nivel
de planificacin.
El planificador a corto plazo se activa cada vez que un suceso ocurrido en el sistema operativo modifica
el estado del mismo. Algunos de estos sucesos son los bloqueos voluntarios del proceso o thread en ejecu
cin, interrupciones, temporizadores de rodaja, llamadas al sistema, seales, activacin de nuevos programas,
desbloqueo de un proceso, etc. En cualquiera de estos casos, es necesario ejecutar el algoritmo de planifica
cin para estimar qu proceso debe ocupar el procesador a continuacin. Si hay un cambio con el proceso
actual, es necesario cambiar los procesos que usan el procesador, salvando el contexto de ejecucin del pro
ceso que ocupaba el procesador.
Debido a la frecuencia con que se activa (alrededor de un centenar de milisegundos en un sistema de
tumo rotatorio), el planificador a corto plazo debe ser rpido y generar poca carga para el procesador, puesto
que es sobrecarga pura en el uso del sistema. A l tiempo que transcurre entre que un proceso o thread pasa al
estado de ejecucin hasta que comienza a ejecutarse, se le denomina latencia del activador (dispatch latency).
Esta latencia es sobrecarga pura del procesador (como veremos en secciones posteriores), por ello debe inten
tar minimizarse.
El planificador a m edio plazo (tambin llamado mid-term scheduler o swapper) es el encargado de
quitar procesos temporalmente de la memoria principal y moverlos al dispositivo de intercambio o de pagi-
166
F igura 4.7 Niveles de planificacin.

nacin (swap). Como se analizar en la seccin 5.5.1, antes de la aparicin de la memoria virtual, se usaba la
tcnica del intercambio (swapping), que permita que en los sistemas del tiempo compartido existieran ms
procesos de los que caben en memoria. Con esta tcnica, cuando no caben en memoria todos los procesos
activos (por ejemplo, debido a que se ha creado uno nuevo), se elige un proceso residente, se le pasa al estado
de suspensin y se copia en swap su imagen en memoria. El criterio de seleccin puede tener en cuenta as
pectos tales como la prioridad del proceso, el tamao de su mapa de memoria, el tiempo que lleva ejecutando
y, principalmente, su estado. Es preferible expulsar procesos que estn bloqueados. Evidentemente, un proce
so expulsado tarde o temprano debe volver a activarse y cargarse en memoria principal. Slo se deberan vol
ver a cargar aquellos procesos que estn listos para ejecutar, que pasarn del estado de listo pero suspendido
al de listo para ejecutar. Esta readmisin en memoria se activar cuando haya espacio de memoria disponible
(por ejemplo, debido a que se ha terminado un proceso) o cuando el proceso lleve un cierto tiempo expulsa
do. Tngase en cuenta que al tratarse de un sistema de tiempo compartido, se debe repartir el procesador en
tre todos los procesos. Por ello, en numerosas ocasiones hay que expulsar un proceso para poder traer de
nuevo a memoria a otro proceso que lleva expulsado un tiempo suficiente.
En los sistemas con memoria virtual puede parecer a priori que no se requiere el uso de esta tcnica de
suspensin, puesto que no es necesario que est residente en memoria el mapa de un proceso para poder eje
cutarlo. Sin embargo, como se estudiar en la seccin 5.5.9, si el grado de multiprogramacin aumenta ms
all de un determinado umbral, se produce el problema de la hiperpaginacin, que hace que el rendimiento
del sistema caiga drsticamente. Para resolver este problema, cuando se detecta que puede producirse esta
situacin, se aplica la misma tcnica que en los sistemas de intercambio, es decir, suspender la ejecucin de
uno o ms procesos, liberando el espacio que ocupan en memoria. Estos procesos volvern al estado de listos
para ejecutar cuando las condiciones del sistema lo permitan o cuando lleven un cierto tiempo en el estado de
suspendido pero listo para ejecutar.
En algunos sistemas operativos, el planificador de medio plazo no slo suspende a procesos cuando hay
un cierto nivel de congestin en la memoria, sino tambin en otras circunstancias. As, por ejemplo, en UNIX
4.4BSD se suspende y expulsa de memoria un proceso cuando lleva ms de 20 segundos bloqueado.
El planificador a medio plazo es el que decide cundo un proceso pasa al estado de suspendido y en qu
momento vuelve al estado de listo. En las secciones ya comentadas del captulo de gestin de memoria se
analiza en ms detalle este nivel de planificacin, que ya no se volver a tratar en este tema.
El planificador a largo plazo (tambin llamado long-tenn scheduler o admission scheduler) se activa
cuando aparecen procesos nuevos y decide qu procesos se admiten en la cola de procesos listos para ejecu
167
tar. Ello significa que controla la admisin de procesos que se ejecutan en el sistema, con tres posibles resul
tados: admitidos, diferidos o denegados. La decisin que adopte depende del grado de multiprogramacin
que se acepte en el sistema. Si se ha llegado al grado mximo, se puede denegar la ejecucin de un nuevo
proceso hasta que quede algn recurso disponible.
Normalmente se ejecuta cuando se crea o termina un proceso, cosa que ocurre con mucha menos fre
cuencia que la planificacin a corto plazo. Por ello, se pueden aplicar algoritmos ms sofisticados y con ma
yor carga computacional, todo ello para conseguir el objetivo de proporcionar al planificador a corto plazo
una mezcla de trabajos que optimice el uso del procesador, juntando procesos intensivos en el uso del proce
sador e intensivos en entrada/salida, aumente el nmero de procesos activos en el sistema, minimice el tiem
po de espera o respuesta, etctera. Tngase en cuenta que este nivel de planificacin se utilizaba en los
sistemas por lotes, por lo que se dispona a priori de informacin sobre el comportamiento del proceso (dura
cin estimada, uso de recursos del programa, etc.) que el usuario deba proporcionar cuando solicitaba la eje
cucin del programa. Esta informacin permite implementar algoritmos como el SJF, que se ver en la
seccin 4.7, pero usando el tiempo total del programa y no el de la prxima rfaga.
En los sistemas operativos de propsito general actuales no existe este nivel como tal, puesto que en
ellos se aceptan todos los procesos, siendo el planificador a medio plazo el encargado de controlar el grado
de multiprogramacin. En cambio, en los sistemas de tiempo real o con calidad de servicio este nivel es muy
importante, como veremos en las secciones dedicadas a este tipo de sistemas.
Estos tres niveles de planificacin tambin se pueden aplicar al ejemplo de la clnica:
Planificacin a corto plazo. La ya comentada al presentar el ejemplo, es decir, la que controla qu
pacientes de la sala de espera reciben atencin mdica en un determinado momento.
Planificacin a medio plazo. Debido al xito de la clnica, el equipo mdico se ha visto obligado a
adquirir una nueva sala de espera mucho mayor, pero ubicada en otro edificio, fuera de la clnica
propiamente dicha. Cuando se produce congestin en las salas de espera de la clnica (recuerde que,
adems de la sala de espera de la consulta, hay salas de espera en los distintos servicios de pruebas
mdicas), se invita a uno o ms pacientes a que pasen a la sala de espera situada en otro edificio, pre
ferentemente a aqullos que estn pendientes de obtener el resultado de una prueba mdica. Cuando
baja el nivel de congestin, se informa de este hecho a los pacientes en la sala de espera externa para
que algunos de ellos, que no estn pendientes del resultado de una prueba mdica, se reincorporen a
la sala de espera de la consulta. Este proceso se correspondera con la planificacin a medio plazo.
Planificacin a largo plazo. El equipo mdico ha pensado en cambiar el modo de organizacin del
servicio mdico. En vez de visitar la clnica directamente, se va a implantar un modulo de peticin
previa, tal que el paciente debe llamar por telfono a la clnica antes de asistir a la misma. El equipo
mdico telefonear al paciente para informarle de cundo puede visitar la clnica. De esta forma, se
puede controlar a priori el nivel de congestin del servicio de atencin mdica. Este modo de opera
cin se correspondera con un planificador a largo plazo.
4.6.
MECANISMOS Y POLTICAS DE PLANIFICACIN
En esta seccin se muestra cmo se pueden plasmar todos los conceptos presentados hasta el momento en un
sistema funcional coherente, con los mecanismos apropiados y las polticas adecuadas para satisfacer las ex
pectativas esperadas del planificador. Para ello, se muestra primero la estructura del planificador y, acto se
guido, los mecanismos y su relacin con las polticas de planificacin.
4.6.1. Estructura del planificador de procesos

La figiua 4.8 muestra la estructura y organizacin de un planificador complejo que incluye todos los niveles
de planificacin descritos anteriormente. Como se puede ver, el planificador de un sistema operativo tiene
172
4.6.4. Polticas de planificacin

En los apartados anteriores hemos visto los mecanismos que permiten implementar y llevar a cabo la planifU
cacin de procesos y threads en un sistema operativo. Con ser importantes, sobre todo en cuanto a gestin d
recursos y a explotacin eficiente del sistema, estos mecanismos no son nada si no acompaan de una polti
ca de planificacin que dicte las normas para planificar. Para comprender esto fcilmente, se puede pensar
en otras reas de actividad, como la poltica fiscal. Los mecanismos de control de la administracin tributaria
existen en muchos pases y pueden ser similares, pero su aplicacin con una u otra poltica puede dar como
resultado que un ciudadano pague un 60% de impuestos o un 0%. Este hecho decide grandes movimientos de
capital y, a veces, tambin de personas.
En un sistema operativo pasa exactamente lo mismo. Partiendo de que existen los mecanismos suficien
tes, hay que decidir si la poltica de planificacin a implementar va a ser:
Expulsiva o no.
Igualitaria o no.
Equitativa o no.
Eficiente o no.
Predecible o no.
La eleccin de unos u otros criterios llevar hacia un comportamiento del sistema completamente dis
tinto, que es el que refleja realmente el criterio de los diseadores o de los que aplican el sistema operativo.
Por ejemplo, un mismo sistema se puede ajustar para favorecer a procesos con un uso intensivo del procesa
dor o de la entrada/salida, aplicar prioridades a distintos procesos o no, admitir a ciertos procesos o no, garan
tizar calidad de servicio o no, etc.
Como en todo sistema poltico, muchos de estos criterios son dependientes entre s y algunos son con
trapuestos, de forma que es imposible optimizar todos de forma simultnea. En el diseo de la poltica de
planificacin es donde se plasman una serie de compromisos entre todos, o algunos, de ellos para conseguir
un determinado comportamiento del sistema. Al final, lo normal en sistemas de propsito general es llegar a
un compromiso que d el mejor comportamiento posible para el conjunto de parmetros a considerar, tenien
do en cuenta todos los tipos de perfiles de procesos posibles en el sistema. Siguiendo con el ejemplo de la
economa, lo normal es que se aplique una poltica mixta que recaude impuestos por tramos, teniendo en
cuenta distintas caractersticas de los contribuyentes. Normalmente, los casos extremos son raros, aunque
pueden existir (piense en Suiza, por ejemplo). Estos casos extremos suelen funcionar slo con sistemas alta
mente especializados y con un perfil muy determinado de trabajos a realizar (por ejemplo, en Suiza, con los
muy ricos). En computacin pueden existir en sistemas dedicados altamente especializados que conocen per
fectamente los procesos que ejecutan. Por ejemplo, una mquina que est calculando el 99% del tiempo del
procesador.
Las polticas de planificacin se implementan mediante algoritmos de planificacin en el ncleo del sis
tema. Existe una amplia variedad de algoritmos de planificacin y de criterios de medida de los mismos. En
este libro los mostraremos siguiendo la distincin clsica entre algoritmos sin expulsin y con expulsin
(tambin llamados apropiativos). A continuacin, se describen los principales algoritmos de cada tipo.
4.7.
ALGORITMOS DE PLANIFICACIN NO EXPULSIVOS
Como se ha explicado previamente, los algoritmos de planificacin no expulsivos se denominan as porque

no quitan el uso del procesador a ningn proceso una vez que se le ha asignado, a no ser que este ceda su uso
voluntariamente o se produzca un evento (como una sincronizacin, una operacin de entrada/salida, etc.)
que libere el procesador. Con este tipo de algoritmos, cuando un proceso o thread adquiere el uso del proce
sador, se ejecuta hasta que termina o cede el procesador voluntariamente. No importa el tiempo que necesite
para ejecutar. Esto significa que en el grafo de planificacin, un proceso nunca vuelve al estado listo una
vez que entra en ejecucin. Solo puede pasar a bloqueado o terminado. Los puntos de activacin del
173
Tabla 4.1 Procesos de ejemplo en FCFS.

Proceso o thread
T0
TI
T2
T3
Instante de llegada
0
10
20
30
Tiempo de procesador (ms)

50
120
20
10
algoritmo de planificacin serian slo los cuatro primeros de los identificados en la seccin 4.6.2, que se co
rresponden con cambios de contexto voluntarios.
Como el lector puede comprender, este tipo de algoritmos no son apropiados para sistemas multiusuario
interactivos, donde lo que interesa es atender simultneamente a varios procesos multiplexando el procesa
dor entre ellos. Este modelo se basa ms en el paradigma de servicio completo y proviene de las operacio
nes clsicas cliente/servidor, como pagar a una cajera en el supermercado u obtener un servicio bancario. En
todos estos servicios, una vez que un proceso o thread se apropia del recurso servidor, lo tiene dedicado ex
clusivamente a l hasta que termina, decide irse voluntariamente u ocurre algo (como por ejemplo, la falta de
precio de un producto en el supermercado) que hace que el sistema lo ponga en el estado de bloqueado. No se
plantea expulsin, por lo que el proceso sigue ejecutndose mientras lo desee.
Existen ms algoritmos de planificacin que los mostrados en este libro, dado que este campo ha sido
objeto de mucha investigacin por su importancia en el comportamiento del sistema operativo. A continua
cin, se estudian slo los principales algoritmos usados con planificacin no expulsiva. Para obtener ms
informacin el lector puede acudir a las referencias bibliogrficas del final del captulo.
4.7.1. Primero en llegar primero en ejecutar (FCFS)

El algoritmo FCFS (First Come First Served) se basa en elegir para pasar a ejecutar el primer proceso listo
para ejecutar, siendo el primero aqul que lleva ms tiempo esperando en la cola de listos. En este caso la
cola de procesos en estado de listo est ordenada de acuerdo al instante en que los procesos pasan a estado de
listo. Los que llevan ms tiempo esperando estn ms cerca de la cabecera.
El algoritmo es sencillo, puesto que basta con elegir el primer proceso de la cola de listos. Adems, la
gestin de la cola de listos es sencilla, ya que slo requiere insertar al final de la cola los procesos que pasan
al estado de listos para ejecutar. Por tanto, la complejidad computacional de este algoritmo de planificacin
es independiente del nmero de procesos que exista en el sistema.
En el ejemplo de la clnica, sera la solucin ms obvia: atender a los pacientes por su orden de llegada
a la sala de espera de la consulta.
Es adecuado para sistemas donde se ejecuten procesos intensivos en el uso del procesador y tal que el
nico objetivo sea obtener el mximo rendimiento del procesador, ya que impone una sobrecarga baja.
Para analizar su comportamiento vamos a estudiar el siguiente ejemplo consistente en 4 procesos cuyas
caractersticas de rfagas de procesador se describen en la tabla 4.1.
La figura 4.9 muestra el cronograma de ejecucin de los trabajos usando el algoritmo FCFS.
Vamos a estudiar a continuacin el comportamiento del algoritmo FCFS respecto a los tres parmetros
anteriores: Te, Tw y Tr.
Tiempo medio de ejecucin: (50 + 160 + 170 + 170) /A = 137,5 ms.
Tiempo medio de espera: (0 + 40 + 150 + 160) / 4 = 87,5 ms.
Tiempo medio de respuesta: Asumiendo que el proceso responde algo en cuanto se activa, el tiempo
medio de respuesta ser igual al tiempo medio de espera, es decir, 87,5 ms.
Este algoritmo es ptimo en el uso del procesador, ya que la carga computacional del algoritmo es muy
poca y no hay operaciones extras debidas al planificador, como cambios de contexto o tratamiento de inte
rrupciones. Sin embargo, tiene un problema: el tiempo de espera puede ser muy largo, ya que depende total
mente de los dos parmetros estudiados anteriormente: tasa de llegada de trabajos y tiempo de procesador
174
T3
T2
T1
T0!
t=0
Ejecucin
Bloqueado
Listo
170
190
20
Tiempo (ms.)
Figura 4.9 Cronograina de ejecucin usando FCFS.

que necesita cada trabajo. Si llegan muchos trabajos o alguno de ellos es muy largo, el comportamiento del
algoritmo es muy malo para aquellos trabajos encolados al final, aunque nunca hay inanicin porque final
mente llegarn a ejecutarse.
El problema anterior se produce porque la ejecucin depende del orden de llegada y esto afecta consi
derablemente tanto al tiempo medio de ejecucin como al tiempo de espera y de respuesta. Qu ocurrira en
el ejemplo anterior si T3 tardara en ejecutarse 120 ms y TI 10 ms? La figura 4.10 muestra el cronograma
correspondiente. Como se puede ver, el tiempo de espera de los procesos se reduce considerablemente:
Tiempo medio de ejecucin: (50 + 50 + 60 + 170) / 4 = 82,5 ms.
Qu ocurre cuando un proceso tiene rfagas de ejecucin de bloqueo debidas a sincronizaciones u ope
raciones de entrada/salida? Cuando termina el bloqueo, vuelve a la cola de listos para ejecutar y se inserta por
el final de la misma. Esto significa que el algoritmo FCFS beneficia a los procesos que requieren mucho pro
cesador, como por ejemplo las multiplicaciones de matrices, pero perjudica a los procesos que interaccionan
con otros procesos o que tienen muchas operaciones de entrada/salida, debido a que el tiempo de espera en la
cola es muy largo.
Para ilustrar un caso con bloqueo, supongamos que en el ejemplo de la tabla 4.1, el trabajo T0 tiene una
rfaga de 10 ms, un bloqueo de 20 ms y una ltima rfaga de 40 ms de procesador. La figura 4.11 muestra el
cronograma de este caso. Observe que el proceso bloqueado T0 pasa ahora a tener un tiempo de ejecucin de
200 ms, 150 ms que antes.
Para ver otro ejemplo, imagine que en el sistema entra un proceso cada 5 ms y que tarda en ejecutarse
20 ms sin bloqueos. Si el primer proceso que ejecuta tiene 5 fases que consisten en una rfaga de procesador
de 10 ms y un bloqueo de 20 ms por una operacin de entrada/salida. Cul sera su comportamiento? Ejecu
tara la primera rfaga y se bloqueara. Durante el bloqueo habran llegado otros 4 procesos que deberan eje
cutar y slo se habra ejecutado uno, luego debera esperar:
Tw = 4*20 - 20 = 60 ms
Empezara a ejecutar de nuevo a los 90 ms, pero durante su espera y ejecucin habran entrado otros 14
Tiempo (ms.)
Figura 4.10 Cronograma de ejecucin usando FCFS con otro orden.
175
Tiempo (ms.)
Figura 4.11 Cronograma de ejecucin usando FCFS con bloqueo.
procesos y se habran ejecutado 5. Cuando se despierte de nuevo, debera esperar 180 ms. Y as sucesivamen
te. Imagine ahora que entrara un proceso de 10 segundos, cul sera el efecto sobre nuestro proceso? Evi
dentemente, se puede apreciar que este algoritmo no es muy conveniente para procesos interactivos o con
muchas operaciones de entrada/salida.
Para ver otro ejemplo, imagine que en el sistema entra un proceso cada 5 ms y que tarda en ejecutarse
20 ms sin bloqueos. Si el primer proceso que ejecuta tiene 5 fases que consisten en una rfaga de procesador
de 10 ms y un bloqueo de 20 ms por una operacin de entrada/salida. Cul sera su comportamiento? Ejecu
tara la primera rfaga y se bloqueara. Durante el bloqueo habran llegado otros 4 procesos que deberan eje
cutar y slo se habra ejecutado uno, luego debera esperar:
Tw - 4*20 - 20 = 60 ms
Empezara a ejecutar de nuevo a los 90 ms, pero durante su espera y ejecucin habran entrado otros 14
procesos y se habran ejecutado 5. Cuando se despierte de nuevo, debera esperar 180 ms. Y as sucesivamen
te. Imagine ahora que entrara un proceso de 10 segundos, cul sera el efecto sobre nuestro proceso? Evi
dentemente, se puede apreciar que este algoritmo no es muy conveniente para procesos interactivos o con
muchas operaciones de entrada/salida.
4.7.2. Primero el trabajo ms corto (SJF)

Este algoritmo trata de resolver el problema del algoritmo FCFS dando prioridad a los trabajos ms cortos,
como su propio nombre indica (SJF, Shortes Job First). La idea es evitar los largos tiempos de espera en los
sistemas interactivos y con entrada/salida. Para ello se ordena la cola de procesos listos para ejecutar de me
nor a mayor tiempo de ejecucin para la siguiente rfaga de procesador. En caso de empate entre tiempos se
ordenan dichos trabajos empatados usando el algoritmo FCFS. La implementacin de este algoritmo ya no es
trivial, como en el caso del FCFS, presentndose distintas alternativas:
Insertar los procesos en la cola de listos en orden FIFO e implementar el planificador de manera que
recorra toda la tabla buscando aquel proceso que tenga una prxima rfaga menor. Esta solucin im
plica que el tiempo de ejecucin del planificador sea proporcional al nmero de procesos listos, por
lo que no es aplicable a grandes sistemas.
Insertar los procesos en la cola en el orden que indica el tamao de su prxima rfaga. Con esta op
cin, la seleccin del proceso es trivial, puesto que se elige el primero de la lista. Sin embargo, la in
sercin en la cola se ralentiza.
Usar mltiples colas, una por cada posible valor de la prxima rfaga. La seleccin del proceso es re
lativamente sencilla: usar el primer proceso de aquella cola con un valor menor del tamao de la
rfaga que no est vaca. Adems, el tiempo requerido para esta eleccin es independiente del nme
ro de procesos que haya en el sistema. En cuanto a la insercin, se agiliza con respecto a la opcin
anterior, puesto que se incluye directamente al final de la lista correspondiente al valor de la rfaga.
176
Tiempo (ms.)
Figura 4.12 Cronograma de ejecucin usando SJF.

En el ejemplo del servicio mdico, cuando llega un paciente a la clnica, se le deberan tomar unos da
tos que permitan estimar la duracin que tendr su atencin, y usar este criterio a la hora de decidir qu pa
ciente debe entrar cuando un mdico se queda libre.
Para analizar su comportamiento vamos a estudiar con este algoritmo el ejemplo anterior, cuyas carac
tersticas de rfagas de procesador se describen en la tabla del algoritmo FCFS (tabla 4.1). La figura 4.12
muestra el cronograma de planificacin de estos trabajos.
Como se puede apreciar a simple vista el cronograma es completamente distinto del FCFS, aunque la
ejecucin del conjunto de rfagas acaba igualmente en el instante 200. Vamos a estudiar a continuacin el
comportamiento del ejemplo con el algoritmo SJF respecto a los tres parmetros anteriores: Te, Tw y Tr:
medio de respuesta ser igual al tiempo medio de espera, es decir, 32,5 ms. Pero si se observa el
comportamiento de los trabajos cortos, este tiempo mejora considerablemente.
Para ilustrar un caso con bloqueo, imagine el mismo ejemplo anterior, pero con todos los procesos lis
tos para ejecutar desde el instante de tiempo 0 y variando el comportamiento del trabajo T0 para que tenga
una rfaga de 10 ms, un bloqueo de 20 ms y una ltima rfaga de 40 ms de procesador. La figura 4.13 mues
tra el cronograma de este caso.
Observe que el proceso bloqueado T0 pasa ahora a tener un tiempo de ejecucin de 80 ms y termina an
tes que el trabajo ms largo T I. Esto se debe a que en el instante t = 40, el trabajo T0 ya ha vuelto del blo
queo y est listo para ejecutar, por lo que el planificador lo elige antes del T I.
La ventaja de este algoritmo frente al FCFS es que minimiza el tiempo de espera para un conjunto de
trabajos que estn listos para ejecutar en el mismo instante, pero a costa de penalizar los trabajos de mayor
tiempo de ejecucin. Tambin puede haber inanicin, ya que, en el caso de que estn continuamente apare
ciendo procesos con tiempo de ejecucin pequeo, un proceso largo puede no llegar a ejecutar. Imagine que
llega cada 5 ms un proceso con tiempo de ejecucin 10 ms y que llega un nuevo proceso en t = 50 ms con
tiempo de ejecucin 100 ms Cundo ejecutara con este algoritmo? La respuesta es nunca. Habra inanicin.
Tiempo (ms.)
Figura 4.13 Cronograma de ejecucin usando SJF con bloqueos.
177
Duracin de la siguiente rfaga de procesador

El principal problema del algoritmo SJF es saber cul es la duracin de la siguiente rfaga de ejecucin que
necesitar un proceso que aparece en la cola de procesos listos para ejecutar.
En los sistemas de tiempo real s se suele conocer la duracin de un proceso en su siguiente activacin,
pero en los sistemas de propsito general no es habitual conocer este valor. Cmo se puede determinar? Hay
dos formas bsicas: permitir que el usuario lo especifique o predecir dicho valor a partir de la historia de las
rfagas de un proceso o thread.
La primera opcin se aplicaba habitualmente en los sistemas por lotes ( batch) donde es habitual que el
usuario los haya ejecutado de forma repetitiva, tenga analizado su comportamiento o sea capaz de estipular
un tiempo de ejecucin estimado para el trabajo. En estos sistemas los trabajos se ordenan basndose en este
tiempo. Cuando empiezan a ejecutar se activa un temporizador con ese tiempo ms un porcentaje extra de
gracia (configurable por el administrador). Si el trabajo no ha terminado de ejecutar en ese tiempo, se termina
su ejecucin de forma forzada.
La forma de prediccin ms sencilla es calcular el valor medio de las rfagas anteriores:
Tn+i =
(1/n)
(t + . . . +
t0
) =
(1/n) tn + ((n-l)/n)
El problema es que este mtodo es costoso de calcular, supone almacenar muchos valores anteriores y
guarda memoria de toda la vida del proceso. Suponga que un proceso ejecuta una primera rfaga de 150 ms y
5 rfagas sucesivas de 10 ms. Cul sera la siguiente rfaga predicha?
t n+i = (1/ 6) (5 * 10 + 150) = 200 / 6 = 33,3 ms.
Sin embargo, debido a la localidad temporal de los procesos y threads, lo lgico sera elegir 10 ms co
mo siguiente rfaga. Este problema se puede aliviar haciendo que la memoria del algoritmo no sea toda la
vida de rfagas del proceso, sino solo una ventana hacia atrs. En este caso, por ejemplo, si se estima una
ventana k = 4, la rfaga predicha sera:
tn +1 = (1/4) (4 * 10) = 40 / 3 = 10 ms
Este mtodo no es muy bueno cuando las rfagas tienen valores cambiantes, ya que asigna el mismo
peso a todos los valores de rfagas pasados. Qu ocurrira si los valores de las cuatro ltimas rfagas fueran
20, 50, 10 y 50? El valor resultante sera:
Ta+i = (1/ 3) (20 + 50 + 10 + 50) = 130 / 3 = 43,3 ms
Puesto que es ms probable que las instancias de rfagas recientes reflejen mejor el comportamiento del
proceso, es muy habitual usar la media exponencial para predecir la siguiente rfaga:
Tn+i =
a t
(1-a)
= a t n + X (1-a)1a t , i = 1 .. n, 0 < a < 1
El valor de a indica el peso que se da a la historia del proceso. Cuanto ms cercano es a 0, menos im
portancia se da a la historia reciente. Si a es 1 o muy cercano a l , ms reducida es la ventana que importa
para predecir la rfaga. La figura 4.14 muestra una comparativa de prediccin con la media aritmtica y tres
medias exponenciales (0,5, 0,25 y 0,75) para el caso mostrado arriba.
El ltimo problema por resolver es asignar la primera rfaga al proceso, ya que no hay historia de eje
cucin del mismo. Hay dos opciones: tener un valor estndar para todos o tener un histrico de rfaga media
en el sistema. Ambas opciones son vlidas, puesto que los algoritmos anteriores se adaptan a rfagas adecua
das finalmente.
4.7.3. Planificacin basada en prioridades

Como se analiz en la seccin 4.3, en un sistema es necesario proporcionar niveles de urgencia, que permitan
a los usuarios establecer los distintos grados de importancia de sus tareas. En los algoritmos anteriores, se
tratan los procesos en la cola de procesos listos en base a caractersticas como el tiempo de llegada, tiempo de
ejecucin, etc. Pero se asume que todos ellos tienen la misma prioridad. Por ejemplo, en SJF si un proceso
178
O
e
V
\w
.\ V \
\\\V
4rafaga
A ..
\
MA
--M E 0
'E 40 ... , \ V _
20
--- -4----1--- ^
0 ------------ 1------V----
i
" i
i
" i.... .....*l
1
ME 0 25
ME 0,75
Rfaga
Figura 4.14 Ejemplo de prediccin de rfaga en SJF.

tiene una rfaga de 10 unidades de tiempo, se planificar antes que uno que tenga 20 u.t. sin ninguna discu
sin.
Sin embargo, en la mayora de los sistemas de colas suele haber modificadores externos que no son
intrnsecos al servicio a prestar y que condicionan la tarea del planificador. En un supermercado, por ejem
plo, puede haber colas para compra rpida, para clientes VIP y para el resto. En muchas empresas tienen dis
tintas categoras de cliente (platino, oro, plata, etctera) y el tiempo de respuesta es ms rpido cuanto mayor
es la categora del cliente.
En los sistemas operativos pasa algo similar: no todos los procesos y hreads son iguales. Hay carac
tersticas, sobretodo el origen de los mismos, que determinan que estn en una u otra cola de servicio. Por
ejemplo, los procesos y hreads del sistema operativo son ms importantes que los de un usuario cualquiera.
Para tratar de acomodar este esquema diverso, se disearon los algoritmos de planificacin basados en priori
dades.
La prio rid ad no es sino un nmero que indica la importancia del trabajo a realizar dentro del sistema.
Este nmero no es asignado por el algoritmo de planificacin, sino que es asignado por el sistema operativo
cuando se crea el trabajo (proceso o thread). El algoritmo de planificacin se limita a usar la prioridad para
tomar decisiones. En caso de que pueda haber mltiples procesos de la misma prioridad, deber usarse otro
algoritmo para decidir cul se elige (podran usarse, por ejemplo, FCFS o SJF). Adems, cada sistema opera
tivo maneja distintos rangos de prioridad. La tabla 4.2 muestra las clases de planificacin y las prioridades
que se asignan a cada una de ellas tanto en el ncleo de Linux como en el de Windows. El concepto de clases
de planificacin se estudiar en la seccin 4.8.4. Como se puede ver, en Linux los procesos normales pueden
tener un rango de -20 a 19, mientras que los procesos de tiempo real, tienen prioridades comprendidas entre 0
y 99, siendo ms prioritarios en ambos casos los valores ms bajos. Tngase en cuenta que los rangos de
prioridades de cada clase son independientes y que los procesos de tiempo real siempre tienen prioridad sobre
los normales. En Windows se pueden manejar prioridades entre 0 y 32 con dos clases de planificacin. En
este caso, la prioridad 32 es la ms alta. Observe que ambos contemplan colas para procesos normales y de
tiempo real con poltica FCFS, pero adems en Linux se contemplan colas para tiempo real con rodaja para
cada proceso. El concepto de rodaja se estudiar en la seccin 4.8.1. Tngase en cuenta que en estos dos sis
temas operativos se implementa un esquema de prioridad expulsivo, que se corresponde con el presentado en
la seccin 4.8.3, que es la versin expulsiva del que se explica en esta seccin.
En el caso del ejemplo del servicio mdico, la prioridad se correspondera con el grado de urgencia del
paciente y se usara para determinar qu paciente pasa a la consulta cuando un mdico se queda libre. Obser
ve que por muy urgente que sea el estado del paciente, esta estrategia no permite interrumpir la consulta de
otro paciente. Recuerde que estamos revisando la versin no expulsiva del algoritmo.
179
T abla 4.2 Niveles de prioridad en el ncleo de Limo: y Windows.

P arm etro
Clases de planificacin
I . Prioridades normales (dinmicas)
2. Prioridades de tiempo real FCFS (fijas)
3. Prioridades de tiempo real con rodaja (fijas)
Orden de importancia de la prioridad
Linux
3
40; de -20 a 19
100; de 0 a 99
100; de 0 a 99
Baja-> Alta
W indows
2
15; de 1 a 15
16; de 16 a 31
AltaBaja
La prioridad de un proceso o thread puede ser esttica o dinmica. Una prioridad esttica no cambia
durante la vida del proceso o thread, independientemente de sus circunstancias de ejecucin, entorno, etc. Su
prioridad se calcula inicialmente cuando se crea el proceso o thread (consulte el captulo 3) y ya no cambia.
Una prioridad se denomina dinm ica si puede cambiar durante la vida del proceso o thread, dependiendo de
sus circunstancias de ejecucin, entorno, etc. Con este tipo de prioridad, es necesario tener algn criterio para
variar la prioridad del proceso. Por ejemplo, en Linux y UNIX la prioridad dinmica slo se aplica a procesos
convencionales (no de tiempo real) y la establece el planificador basndose en la historia del proceso, tenien
do en cuenta la suma del tiempo que ha pasado en la cola ms el nmero de interrupciones de reloj que le
quedan dentro de su rodaja. Adems, existe el mandato n i c e que permite a un proceso cambiar la prioridad
de un proceso.
En cuanto a la implementacin, se presentan las tres mismas alternativas que en el SJF: cola nica en
orden FIFO, cola nica en orden de prioridad o mltiples colas, una por cada prioridad.
Para analizar su comportamiento vamos a estudiar el siguiente ejemplo consistente en 4 procesos cuyas
caractersticas de rfagas de procesador y prioridad se describen en la tabla 4.3.
La figura 4.15 muestra el cronograma de ejecucin de los trabajos usando el algoritmo de prioridad.
Como se puede ver al tratarse de un algoritmo no expulsivo, las prioridades son slo significativas cuando el
procesador queda libre. Por tanto, T2 debe esperar 30 milisegundos hasta que T0 deje voluntariamente el
procesador para poder hacer valer su prioridad. Un proceso de mxima prioridad debe esperar hasta que con
cluya la rfaga del proceso actual para poder obtener el procesador.
Vamos a estudiar a continuacin el comportamiento del algoritmo de prioridad respecto a los tres
parmetros anteriores: Te, Tw y Tr.
Tiempo medio de ejecucin: 50 + 190 + 50 + 50 ) / 4 = 85 ms.
Tiempo medio de espera: (0 + 70 + 30 + 40) / 4 = 35 ms.
medio de respuesta ser similar al tiempo medio de espera, es decir, 35 ms.
Como se puede ver, la planificacin basada en prioridades da buenos resultados en rendimientos me
dios. Sin embargo, tiene un problema: cuando las prioridades son estticas puede surgir el problema de la
inanicin, que implica que un proceso pueda estar esperando indefinidamente sin llegar a ejecutar.
Imagine que en un sistema con tres colas de prioridad llegan los siguientes procesos en el instante ini
cial:
Prioridad 0: (P l, 30), (P2, 40)
Prioridad 1:
Prioridad 3: (P3, 30)
T abla 4.3 Procesos de ejemplo en planificacin con prioridades.
Proceso o thread
T0
TI
T2
T3
In stan te de llegada
0
10
20
30
Tiempo de procesador (ms)

50
120
20
10
P rio rid ad
4
3
1
2
180
E je c u c i n
Bloqueado
m m - o
20T
Tiem po (ms.)
F ig u ra 4.15 Cronograma de ejecucin usando prioridades.

Segn este esquema, P3 debera empezar a ejecutar detrs de P1 y P2 en el instante t = 70. Qu ocurre
si en el instante t = 50 empiezan a llegar continuamente procesos de prioridad 1 del tipo siguiente (Pi, 50)?
En este caso, en el instante t = 50, tendramos los siguientes procesos en las colas de prioridad:
Prioridad 0:
Prioridad 1: (P4, 50) (P5, 50) ... (Pn, 50)
Prioridad 3: (P3, 30)
Cundo se ejecutar el proceso P3? La respuesta es: nunca. Esto ocurrir en los algoritmos de planifi
cacin basados en prioridades si van apareciendo continuamente procesos listos para ejecutar con mayor
prioridad que uno ya existente.
Este problema se puede resolver usando prioridades dinmicas y mecanismos de envejecimiento. Los
mecanismos de envejecimiento se encargan de aumentar paulatinamente la prioridad a los procesos que lle
ven un determinado tiempo esperando a ser ejecutados. Por ejemplo, suponiendo que la mayor prioridad es la
0, un proceso de prioridad 22 que lleve ms de X u.t. esperando (Tw) en estado de listo pasara a prioridad
21; si pasados otros X u.t. siguiese sin ejecutar, pasara a prioridad 20, y as sucesivamente. Una vez que haya
ejecutado, volver a tomar su prioridad normal de 22. De esta forma, se asegura que, finalmente, todos los
procesos se llegan a ejecutar. El tiempo de envejecimiento es un parmetro de configuracin del planificador.
En el programa 4.3 se muestra un algoritmo simplificado del proceso de envejecimiento. Obviamente, un
planificador real optimiza mucho ms las operaciones.
P rogram a 4.3 Ejemplo de algoritmo de envejecimiento de prioridad.
for (i = 2; i <= minPrioridad; i++) {
Pj = colaNivelPrioridad(i).primero;
while (Pj != NULL) {
if (Pj ->Tw > X) {
Pj-prioridad = i - 1;
insertar(Pj , NivelPrioridad(i-1) );
}
Pj = Pj->siguiente;
}
}
4.8.
ALGORITMOS DE PLANIFICACIN EXPULSIVOS
Los algoritmos no expulsivos no son adecuados para realizar la planificacin en un sistema operativo de
propsito general. El algoritmo SJF, a pesar de mejorar el tiempo de espera (y, por tanto, el de respuesta) de
los procesos con respecto al FCFS, no lo hace en un grado suficiente, puesto que, una vez que se le asigna el
181
procesador a un proceso, ste contina hasta que se produce un cambio de contexto voluntario. Los algorit
mos basados en prioridad de carcter no expulsivo, aunque implementan grados de urgencia, no lo hacen de
la forma requerida en un sistema de propsito general, ya que cuando se desbloquea un proceso muy urgente,
debe esperar a que el proceso actual deje voluntariamente el procesador. Adems, los algoritmos no expulsi
vos no proporcionan un buen reparto del procesador. Como el lector puede suponer, los algoritmos expulsi
vos resuelven todas estas deficiencias.
Dos de los algoritmos que se presentan en esta seccin son las versiones expulsivas de dos algoritmos
que se estudiaron en la seccin anterior, concretamente, el algoritmo de planificacin basado en prioridades y
el SJF. Como se coment previamente, se trata de esquemas de planificacin que usan la misma funcin de
planificacin pero que se invoca en distintas situaciones.
4.8.1. Turno rotatorio (round robn)

Este algoritmo requiere una pequea variacin sobre el algoritmo FCFS: cuando se asigna el procesador a un
proceso, se le concede un intervalo de tiempo mximo (denominado habitualmente ro d a ja o cuanto), de
manera que si se cumple ese plazo sin que el proceso haya abandonado voluntariamente el procesador, se
realiza un cambio de contexto involuntario, pasando el proceso al final de la cola de listos para ejecutar, y
cedindose el procesador al primer proceso de la cola de listos, que dispondr de su rodaja. En caso de que el
proceso realice un cambio de contexto voluntario antes de que finalice su rodaja, igualmente, se selecciona el
primer proceso de la cola de listos y se le otorga una rodaja.
Se trata, por consiguiente, de un algoritmo de tipo expulsivo, pero que slo realiza la expulsin en esta
circunstancia, es decir, en el punto 9 de los identificados en la seccin 4.6.2 como puntos de activacin del
algoritmo de planificacin (adems de los cuatro primeros puntos, que son obligatorios). Obsrvese que la
funcin de planificacin es trivial. De hecho, es la misma que en el FCFS, devolviendo simplemente el pri
mero de la cola de listos. Nuevamente, se aprecia como el esquema de planificacin no slo queda condicio
nado por la funcin de planificacin propiamente dicha, que en este caso es la misma, sino tambin por desde
qu puntos se invoca al planificador en cada esquema.
Usando el smil de la clnica, con esta poltica, al comenzar la atencin al paciente, el mdico arrancara
un reloj temporizador para medir la rodaja de tiempo que le corresponde a ese paciente, de manera que si no
termina la consulta en ese tiempo (podra terminar porque ha concluido la visita o porque se requiere algn
tipo de prueba mdica adicional), el mdico pide al paciente que vuelva a la sala de espera, donde pasar a
ocupar la ltima posicin en el orden de atencin, y selecciona a otro paciente teniendo en cuenta aqul que
lleva ms tiempo esperando. Ese cambio de paciente implica una sobrecarga que podra ser intolerable si el
tamao de la rodaja es demasiado pequeo.
La principal virtud de este esquema de planificacin es que proporciona un reparto equitativo del pro
cesador. As, si existen N procesos listos para ejecutar y todos ellos consumen completas sus rodajas, cada
proceso obtendr un porcentaje de 100/N % del tiempo del procesador. Adems, acota el tiempo de espera (y,
por tanto, tambin el de respuesta) de un proceso, puesto que si un proceso que est en la cola de listos tiene
delante a otros N procesos, incluyendo el que est en ejecucin, y el tamao de la rodaja es R, en un tiempo
mximo de NxR el proceso estar ejecutando.
Un aspecto crtico en este esquema es determinar cul debe ser el tamao de la rodaja, puesto que valo
res inapropiados pueden causar problemas de rendimiento:
Un tamao de rodaja demasiado grande conlleva tiempos medios de espera elevados, tendiendo
hacia un comportamiento similar al FCFS.
Un tamao de rodaja demasiado pequeo genera una sobrecarga intolerable. Tngase en cuenta que
el tiempo que se tarda en realizar un cambio de contexto involuntario no es trabajo til en s mismo.
Por tanto, el tamao de la rodaja debe ser varios rdenes de magnitud mayor que el tiempo que re
quiere un cambio de contexto (habitualmente, del orden de milisegundos frente a microsegundos,
respectivamente) para que la sobrecarga asociada al mismo sea tolerable.
182
Figura 4.16 Cronograma de ejecucin usando un algoritmo de tumo rotatorio.

Aunque no hay una frmula mgica para calcular el tamao de la rodaja, pues depende de un gran
nmero de factores, una regla prctica es usar un valor tal que los procesos con un uso intensivo de la entra- t
da/salida no consuman su rodaja la mayora de las veces (es decir, que el tamao habitual de la rfaga de est
tipo de procesos sea inferior al de la rodaja). De esta forma, se evita frecuentemente el cambio de contexto
involuntario. En el caso de Linux, el tamao por defecto de la rodaja es de 100 milisegundos.
Para ilustrar este algoritmo, se utiliza el ejemplo de la tabla 4.1, usado antes con los algoritmos no expulsivos. La figura 4.16 muestra la traza de ejecucin de estos procesos suponiendo una rodaja de 20 milise
gundos. En dicha traza se ha supuesto que, transcurridos 20 milisegundos, la incorporacin de T2 a la cola de
listos se produce justo antes de que se cumpla la rodaja de T0. Por ello, la primera rfaga de T2 se ejecuta
antes que la segunda de T0. Observe que, en cambio, la primera rfaga de T3 tiene que esperar a que se eje
cute la segunda rfaga de T0, puesto que cuando T3 se incluye en la cola de listos, T0 ya ha completado su
primera rfaga y est delante en la cola. Tambin conviene resaltar en el diagrama que cuando un proceso
termina (y, en general, cuando hace un cambio de contexto voluntario) sin consumir su rodaja, comienza jus
to a continuacin una rodaja completa de otro proceso (eso ocurre a los 90 y 120 milisegundos).
A continuacin, se calculan los mismos tiempos que en los algoritmos no expulsivos de la seccin pre
via:
Tiempo medio de respuesta: (0 + 10 + 20 + 50) / 4 = 20 ms.
Aunque se trata de un mero ejemplo que no se puede generalizar, en el resultado del mismo destaca el
aceptable tiempo medio de respuesta obtenido, lo cual era previsible puesto que, como se explic antes, este
algoritmo establece una cota mxima para este valor.
Un aspecto que no define explcitamente el algoritmo de turno rotatorio es qu tamao de rodaja le co
rresponde a un proceso que se bloque despus de consumir parte de su rodaja y que ahora vuelve a ejecutar.
Bsicamente, existen dos opciones: otorgarle slo la parte de la rodaja que no consumi o asignarle una roda
ja completa. La segunda opcin tiene la ventaja de que favorece a los procesos con un uso intensivo de entra
da/salida, que no suelen consumir su rodaja, lo cual es conveniente, como se explic en la seccin 4.3. La
figura 4.17 muestra el cronograma del mismo ejemplo de bloqueo usado previamente en la presentacin del
FCFS (vase la figura 4.11). Dado que transcurridos 30 milisegundos se producen varios eventos simult
neamente, se ha supuesto que primero se produce la llegada de T3, justo a continuacin el desbloqueo de T0,
e inmediatamente el final de la rodaja de T I. Obsrvese que cuando ejecuta T0 despus del desbloqueo, ob
tiene una rodaja completa, puesto que se ha asumido que se usa esta segunda opcin.
Retomando el asunto del tamao de la rodaja, en muchos sistemas operativos es un valor configurable,
que puede ajustarse a las caractersticas del uso que se le va a dar a cada mquina, teniendo valores por de
fecto especficos para cada tipo de entorno de trabajo. As ocurre en Windows, donde, por defecto, el tamao
de la rodaja es de 20 milisegundos en las mquinas cliente y de 120 en los servidores.
En muchos sistemas, se usa un esquema donde el tamao de la rodaja no es constante, ni el mismo para
todos los procesos, sino que cada proceso tiene asociado su propio valor de rodaja (que se almacenar en su
bloque de control de proceso), que, adems, puede variar segn evolucione la ejecucin del proceso. En Li
nux, como se analizar en la seccin 4.13, el valor de la rodaja de un proceso puede variar entre 5 y 800 mili-
183
Tiempo (ms.)
Figura 4.17 Cronograma de ejecucin con bloqueo usando un algoritmo de tumo rotatorio.
segundos, dependiendo de la prioridad y grado de interactividad del proceso, siendo 100 el valor por defecto.
En Windows, todos los procesos tienen la misma rodaja, cuyo valor es configurable, tal como se acaba de
explicar. Sin embargo, cuando un proceso pasa a primer plano (normalmente, porque el usuario ha seleccio
nado la ventana asociada al mismo), se le triplica el valor de su rodaja, para, de esta forma, favorecer su eje
cucin y su interaccin con el usuario. Obsrvese que hacer que un proceso tenga una rodaja ms grande es
una manera alternativa de darle ms importancia frente al uso de la prioridad. Para entender la diferencia en
tre estas dos estrategias, supngase que se le quiere dar ms importancia al proceso P que al Q: dando ms
prioridad a P, djamos que Q slo ejecute cuando P no est listo para ejecutar, mientras que otorgando mayor
rodaja a P, hacemos que este proceso obtenga un mayor porcentaje del uso del procesador, pero Q tambin
podr progresar aunque P no se bloquee. Dependiendo de las caractersticas de los procesos, una opcin pue
de ser mejor que la otra.
Para concluir la revisin de este algoritmo, hay que resaltar que, de una manera u otra, est presente en
todos los esquemas de planificacin utilizados en los sistemas operativos de propsito general, puesto que
asegura un reparto equitativo del procesador. Sus dos puntos dbiles son que no favorece a los procesos con
un uso intensivo de la entrada/salida, que es uno de los objetivos de la planificacin, y que no permite implementar grados de urgencia.
4.8.2. Primero el de menor tiempo restante (SRTF)

Se trata de la versin expulsiva del algoritmo SJF, presentado en la seccin dedicada a los algoritmos no ex
pulsivos. El algoritmo se basa tambin en seleccionar aquel proceso cuya prxima rfaga de procesador tenga
un menor tamao previsto, pero, en este caso, tambin se activa el algoritmo cuando se incorpora un nuevo
proceso a la cola de procesos listos, es decir, en los puntos 5, 6 y 8 identificados en la seccin 4.6.2 (ntese
que, por tanto, el concepto de importancia usado en esa seccin se corresponde con el tamao estimado de la
prxima rfaga). Existe, sin embargo, un pequeo matiz con respecto al SJF: cuando se incorpora un nuevo
proceso a la cola de listos, en vez de comparar los tamaos estimados de las rfagas de dicho proceso y del
que est en ejecucin, es ms razonable descontar de este ltimo valor el tiempo que ya lleva en ejecucin el
proceso que actualmente est usando el procesador. De ese ajuste proviene el nombre del algoritmo primero
el de menor tiempo restante (SRTF, Shortest Remaining Time First), puesto que para comparar se usa el
tiempo estimado que le falta al proceso en ejecucin para completar su rfaga.
Usando el smil del equipo mdico, este esquema implicara aadir al SJF la posibilidad de que cuando
llegue un paciente a la sala de espera, ya sea porque acaba de llegar a la clnica o porque ha terminado una
prueba analtica, pueda expulsar a un paciente que est recibiendo consulta en caso de que su tiempo de con
sulta sea menor que el que todava le queda al otro.
La figura 4.18 muestra el cronograma correspondiente al ejemplo de la tabla 4.1, que se us para anali
zar el algoritmo SJF. Obsrvese como T2 expulsa a T0, puesto que su rfaga prevista es menor que el tiempo
restante de T0 (20 frente a 30). Sin embargo, T3 no puede expulsar a T2, ya que la rfaga prevista de T3 no
es inferior al tiempo restante de T2 (de hecho, son iguales).
184
E je c u c i n
!
Bloqueado
I y / ' i Lsto
80 100 120 140 160 180 200

Tiempo (ms.)
F ig u ra 4.18 Cronograma de ejecucin usando un algoritmo SRTF.
A continuacin, se calculan los mismos tiempos que en los algoritmos no expulsivos de la seccin
via:
pre-

Tiempo medio de respuesta: (0 + 70 + 0 + 10) / 4 = 20 ms.
Analizando estos resultados, se observa que el tiempo de espera es considerablemente mejor que con la
versin no expulsiva. Si se comparan las figuras 4.18 y 4.12, se puede apreciar que la clave est en que, gra
cias a la expulsin, T0 abandona el procesador dejando pasar a T2 y T3. Como ya se ha comentado previa
mente, sin expulsin no es posible obtener buenos tiempos de espera (ni de respuesta).
En la figura 4.19 se muestra el cronograma del ejemplo de ejecucin con bloqueo visto tambin para el
SJF (vase la figura 4.13). Observe que, debido al bloqueo, T0 tiene dos rfagas, la primera de 10 y la segun
da de 40.
Resumiendo, el punto fuerte de este algoritmo es minimizar tiempos de espera, pero no proporciona un
reparto equitativo del procesador, ni implementa grados de urgencia. Por tanto, aunque no se use directamen
te en los sistemas operativos de propsito general, est incluido de una forma u otra en los esquemas de pla
nificacin de los mismos.
4.8.3. Planificacin expulsiva basada en prioridades

La versin no expulsiva de la planificacin basada en prioridades implementa un servicio con distintos nive
les de urgencia de una manera deficiente. Usando el ejemplo de la clnica, se tratara de un servicio mdico
en el que un paciente urgente tiene que esperar hasta que term ine la larga consulta que requiere un paciente
hipocondraco, que, finalmente, slo necesita placebo. Un servicio de urgencias que se precie requiere una
poltica expulsiva.
La planificacin expulsiva basada en prioridades es idntica a la versin expulsiva, excepto en que
tambin se activa el algoritmo de comparacin de prioridades cuando se incorpora un proceso a la lista o
E je c u c i n
s'
Bloqueado
[ L is to
Tiempo (ms.)
Figura 4.19 Cronograma de ejecucin con bloqueo usando un algoritmo SRTF.
185
E je c u c i n
i
Bloqueado
Listo
Tiempo (ms.)
F igura 4.20 Cronograma de ejecucin usando prioridades de carcter expulsivo.

cuando el propio proceso en ejecucin disminuye su prioridad, lo que se corresponde con los puntos de acti
vacin 4, 5, 6, 7 y 8, respectivamente, de los identificados en la seccin 4.6.2.
En el ejemplo del servicio mdico se correspondera con una gestin de los pacientes en la que un pa
ciente urgente siempre expulsa al paciente que est recibiendo la consulta, que vuelve a la sala de espera.
En la figura 4.20 se muestra la traza de ejecucin del mismo ejemplo que se us para la versin no ex
pulsiva del algoritmo. En este caso, T2, que tiene la mxima prioridad, obtiene de forma inmediata el proce
sador cuando llega al sistema, expulsando a T I. A continuacin, se calculan los mismos valores que en los
ejercicios anteriores:
Tiempo medio de respuesta: (0 + 0 + 0 + 10 ) / 4 = 2,5 ms.
Este algoritmo consigue un buen tiempo de respuesta para los procesos urgentes, que expulsarn inme
diatamente a procesos de menor prioridad. Sin embargo, como se explic en la seccin 4.6.2, hay que matizar
esa inmediatez dependiendo de si el ncleo es expulsable o no:
Ncleo no expulsable. El cambio de contexto involuntario debe esperar hasta que se completen to
das las rutinas de interrupcin anidadas, as como la llamada al sistema en curso. Las rutinas de inte
rrupcin son muy cortas (como se ver en el captulo 8, la mayor parte del tratamiento se realiza
fuera de la rutina de interrupcin), pero las llamadas al sistema pueden ser bastante largas. Esto afec
ta negativamente al tiempo de respuesta que, en el peor de los casos, puede ser tan grande como lo
que dura la llamada al sistema ms larga, ms el mximo anidamiento de rutinas de tratamiento de
interrupcin.
Ncleo expulsable. El cambio de contexto involuntario se diferir slo hasta que se completen todas
las rutinas de interrupcin anidadas (vase la aclaracin 4.2 sobre la diferencia entre el nivel de prio
ridad de las interrupciones y la prioridad de los procesos). El tiempo de respuesta mximo queda
acotado slo por la duracin de estas rutinas, que, como se explic previamente, es mucho menor
que la de las llamadas al sistema.
Por lo dems, todos los conceptos explicados para la versin no expulsiva son aplicables a esta versin,
tales como la tcnica del envejecimiento o el carcter dinmico de la prioridad, que suele tener un valor base
que crece o decrece dependiendo de la propia evolucin del proceso. En Windows, por ejemplo, se aumenta
temporalmente la prioridad de un thread en las siguientes situaciones:
Cuando un thread se desbloquea al completarse una operacin de entrada/salida. De esta forma, se
favorece a los threads intensivos en la entrada/salida. El valor del aumento depende del tipo de dis
positivo, siendo mayor para dispositivos vinculados directamente con el usuario, como el teclado y
el ratn, que para los otros dispositivos, como los discos. De esta manera, se favorece ms a los
threads interactivos.
Cuando un thread que estaba esperando en un semforo se desbloquea, tambin recibe un aumento
temporal de su prioridad. Esta estrategia vuelve a favorecer a los threads que consumen menos pro
cesador y tienen rfagas ms cortas.
186

Si el thread que se desbloquea est ejecutando en primer plazo (foreground), recibe un aumento adi
cional, para favorecer a los threads ms interactivos.
Cuando un thread que tiene asociada una ventana se desbloquea debido a operaciones vinculadas
con esa ventana, recibe un incremento de su prioridad, en aras de mejorar el tiempo de respuesta de
las aplicaciones interactivas.
Si un thread en estado de listo para ejecutar no lo ha hecho en los ltimos cuatro segundos, recibe un
incremento temporal de su prioridad, implementndose, de esta forma, la tcnica del envejecimiento
previamente explicada.
Una tcnica interesante que ofrecen algunos sistemas operativos es la cesin de la prioridad. Con esta
tcnica un proceso puede traspasarle a otro parte o toda su prioridad, para favorecer su ejecucin inmediata.
Este mecanismo lo puede usar, por ejemplo, un proceso que ha enviado un mensaje a otro proceso que acta
de servidor solicitando una determinada operacin. El cliente, despus de mandar el mensaje, puede ceder
toda su prioridad al servidor para que ste ejecute con la mayor urgencia posible y Heve a cabo rpidamente
su peticin de servicio.
Recapitulando, hay que resaltar que con este algoritmo se consiguen implementar adecuadamente nive
les de urgencia, pero no proporciona un reparto equitativo del procesador, ni dispensa un mejor trato a los
procesos con un uso intensivo de la entrada/salida, a no ser que la prioridad venga condicionada precisamente
por este factor. Como ha ocurrido en los casos anteriores, un esquema de planificacin real no puede basarse
exclusivamente en este aspecto, pero, por otro lado, tiene que estar incluido en un esquema ms general.
A claracin 4.2. Es conveniente recalcar que no hay ninguna relacin entre las prioridades de los procesos y
los niveles de prioridades de las interrupciones. En un sistema de propsito general un proceso de mxima
prioridad puede ser interrumpido por una interrupcin de mnima prioridad. En un sistema de estas caracters
ticas se considera ms urgente servir una interrupcin, que, al fin y al cabo, es una peticin de servicio urgente por parte de un dispositivo, que ejecutar un proceso de mxima prioridad.
4.8.4. Colas multinivel

Todos los algoritmos analizados hasta el momento aplican a todos los procesos un determinado criterio y
seleccionan para ejecutar aqul (o aqullos si es un multiprocesador) que mejor lo satisfaga. Sin embargo, en
muchas circunstancias es necesario poder distinguir entre distintas clases de procesos, dependiendo de alguna
caracterstica de los mismos, de manera que cada clase se gestiona usando un esquema de planificacin inde
pendiente.
Para entender esta necesidad, piense en los sistemas operativos que proporcionan soporte a los procesos
de tiempo real no crticos. El tratamiento de este tipo de procesos es muy diferente al que se les proporciona a
los procesos convencionales, debido a sus requisitos especficos. Por tanto, el sistema operativo debe conocer
qu procesos pertenecen a esta clase y tratarlos de una forma diferente al resto de los procesos.
El esquema de planificacin de colas multinivel permite distinguir enUe distintas clases (niveles) de
procesos, permitiendo que en cada clase se use un esquema de planificacin especfico. Tngase en cuenta
que previamente habamos visto el uso de mltiples colas de listos para implementar de forma eficiente algo
ritmos como el SJF o los basados en prioridad. Sin embargo, en ese caso, se trataba de una cuestin de implementacin. En este caso, el carcter multinivel est en la esencia del esquema, para poder distinguir
distintas clases de procesos, pudindose incluso implementar como una nica cola de procesos listos (as, en
la versin 2.4 del ncleo de Linux se implementaban clases de procesos usando una nica cola de listos; la
clase a la que perteneca el proceso se inclua como un campo en el BCP).
Usando el ejemplo de la clnica, el equipo mdico podra organizar el servicio de atencin distinguien
do a qu sociedad mdica pertenece cada paciente, utilizando un esquema diferente en cada caso.
El esquema de colas multinivel plantea un modelo general de planificacin que se caracteriza por los
siguientes parmetros:
Nivel 1
Turno rotatorio (R odaja = 50 ms.)
187
Prioridad m xim a
-.-. "''.O: y V -p_:
Nivel 2
Tum o rotatorio (R odaja = 150 ms.)
Prioridad m edia
Nivel 3
Tum o rotatorio (R odaja = 450 ms.)
Prioridad m inim a
F igura 4.21 Esquema de colas multinivel.
El nmero de niveles existentes, es decir, el nmero de clases de procesos que se distinguen. Cada
proceso (o thread, en un sistema que implemente esta entidad) pertenece a una clase durante toda su
ejecucin, a no ser que realice una llamada al sistema solicitando cambiar de clase. Normalmente,
cuando se crea un proceso, pertenecer a la misma clase que el proceso padre y seguir en ella, sino
solicita un cambio de clase.
El algoritmo de planificacin que se utiliza para repartir el procesador entre los procesos de un de
terminado nivel.
El esquema de planificacin que se usa para repartir el procesador entre los distintos niveles.
En la figura 4.21 se muestra un ejemplo con tres niveles, tal que en cada nivel se usa un algoritmo de
tumo rotatorio con distinto tamao de la rodaja. En cuanto al mecanismo de planificacin entre niveles, se
usa un esquema de prioridad tal que slo se ejecutarn procesos de un determinado nivel si en los niveles de
mayor prioridad no hay ningn proceso listo. Tngase en cuenta que se pueden usar otros esquemas de plani
ficacin entre niveles como, por ejemplo, un algoritmo de tumo rotatorio, que establecera qu porcentaje del
tiempo del procesador le corresponde a cada nivel.
En el esquema planteado cada proceso est asociado a un determinado nivel durante toda su ejecucin,
a no ser que pida explcitamente un cambio de clase. Existe, sin embargo, un modelo alternativo, denominado
esquema de colas m ultinivel con realim entacin, donde el sistema operativo puede cambiar de nivel a un
proceso dependiendo de su evolucin. En este nuevo modelo existe un parmetro adicional: la poltica de
cambio de nivel, que establece en qu circunstancias un proceso incluido en un determinado nivel pasa a
formar parte de otro nivel. En la figura 4.22 se muestra un ejemplo de este tipo de esquema. Los parmetros
son los mismos que en el ejemplo anterior, pero se le ha aadido la siguiente poltica de cambio de nivel:
Si un proceso de los niveles 1 2 consume su rodaja cuando ejecuta (es decir, su rfaga es mayor
que su rodaja), se le cambia a un nivel inferior.
Si un proceso de los niveles 2 3 no agota su rodaja cuando ejecuta, se le pasa a un nivel superior.
Figura 4.22 Esquema de colas multinivel con realimentacin.
188
Con esta estrategia, los procesos con un uso intensivo de la entrada/salida, estarn en el nivel 1
otorgndoles la mayor prioridad, mientras que los intensivos en el uso del procesador se situarn en el nivel
3, con la menor prioridad, quedando en el nivel intermedio los procesos con un perfil mixto.
Tanto Linux como Windows usan esquemas de planificacin que gestionan clases de procesos siguien
do un modelo sin realimentacin. El esquema de Linux se analizar en la seccin 4.13. En cuanto a Win
dows, distingue entre dos clases de procesos: procesos de tiempo real y procesos normales. Ambas clases
usan un esquema de prioridad, pero con un tratamiento diferente. La prioridad de los procesos de tiempo real,
que es, evidentemente, mayor que la de los procesos normales, es esttica y no se modifica durante la ejecu
cin del proceso, a menos que ste la cambie explcitamente. En cambio, los procesos normales tienen una
prioridad dinmica, que va cambiando segn evoluciona la ejecucin del proceso. Por simplicidad, para evi
tar tener que almacenar explcitamente la clase a la que pertenece cada proceso, las prioridades se asignan de
forma continua: los valores de prioridad entre el 1 y el 15 se corresponden con procesos normales, mientras
que las prioridades desde la 16 a la 31 son de procesos de tiempo real. Tngase en cuenta que, aunque la prio
ridad de los procesos normales es dinmica, nunca puede crecer ms all de un valor de 15.
4.9.
DISEO E IMPLEMENTACIN DEL PLANIFICADOR
Como se ha podido apreciar en la seccin anterior, cada algoritmo expulsivo satisface algunos de los requisi
tos de la planificacin, pero no cumple con otros. Cmo es entonces un esquema de planificacin real? Qu
algoritmo se utiliza? La respuesta es predecible: uno que sea una mezcla de todos estos algoritmos. Sin em
bargo, queda pendiente la cuestin de saber cmo integrarlos. Esta seccin plantea el diseo de un hipottico
esquema de planificacin que integra todos estos algoritmos tericos, y cuyas caractersticas son similares a
los presentes en los sistemas operativos reales. Adems de revisar aspectos de diseo, tambin se expondrn
algunas consideraciones sobre la implementacin de este esquema. Dado que todava no se han estudiado los
aspectos especficos de la planificacin con threads (seccin 4.11), ni de la planificacin de tiempo real es
tricta (seccin 4.10), as como tampoco se han revisado las tcnicas requeridas para planificar un sistema
multiprocesador (seccin 4.12), se plantea un esquema de planificacin para un sistema de propsito general
destinado a una mquina con un solo procesador y sin threads. Los objetivos que debe satisfacer este planifi
cador son los ya expuestos repetidamente para cualquier planificador de un sistema operativo de propsito
general: favorecer los procesos intensivos en el uso de la entrada/salida, y entre ellos especialmente los inter
activos, ofrecer distintos niveles de urgencia, proporcionar un reparto equitativo del procesador y dar soporte
a sistemas de tiempo real no crtico.
Comenzamos el diseo del planificador con ese ltimo objetivo. Dado que los procesos de tiempo real
tienen unas caractersticas muy distintas de los procesos convencionales, lo ms razonable es disear un pla
nificador que distinga entre dos clases de procesos: los de tiempo real y los normales. Se tratara, por tanto,
de un sistema de colas multinivel sin realimentacin, ya que bajo ninguna circunstancia un proceso normal se
convertir en uno de tiempo real, y viceversa, a no ser que lo pida explcitamente y tenga los permisos nece
sarios para hacerlo. En cuanto al algoritmo de planificacin entre niveles, dado el grado de urgencia de los
procesos de tiempo real, se debe utilizar un algoritmo de prioridad expulsivo, de manera que slo se puedan
ejecutar procesos normales si no hay ningn proceso de tiempo real listo para ejecutar. A continuacin, se
analiza cada uno de los niveles, comenzando por la clase de procesos de tiempo real.
El algoritmo de planificacin del nivel de tiempo real debe ser, evidentemente, un algoritmo de priori
dades expulsivo. El rango de prioridades debera ser lo ms grande posible para facilitar ms precisin a la
hora de fijar los diversos grados de urgencia. La prioridad de cada proceso de tiempo real debera ser esttica,
puesto que es una caracterstica intrnseca del mismo, pudindose cambiar slo por una peticin explcita del
proceso. En cuanto a los procesos con la misma prioridad, se puede usar una estrategia FCFS o una de tumo
rotatorio. En cualquier caso, sera el propio proceso el encargado de establecer cul de las dos estrategias
prefiere y, en caso de que seleccione una poltica de tumo rotatorio, debera fijar el tamao de la rodaja para
ese proceso. Observe que cada proceso usar su propio valor de rodaja, que no debera ser modificado, a me
nos que el proceso lo solicite.
GESTIN DE MEMORIA
La memoria es uno de los recursos ms importantes del computador y, en consecuencia, la parte del sistema
operativo responsable de tratar con este recurso, el gestor de memoria, es un componente bsico del mismo.
Sin embargo, la gestin de memoria no es una labor del sistema operativo nicamente, sino que se realiza
mediante la colaboracin de distintos componentes de muy diversa ndole que se reparten las tareas reque
ridas para llevar a cabo esta labor. Entre estos componentes, adems del propio sistema operativo, estn el
lenguaje de programacin, el compilador, el montador y el hardware de gestin de memoria. Aunque este
capitulo se centra en el sistema operativo, se estudia cmo se integran los diversos componentes para pro
porcionar la funcionalidad requerida. Por otra parte, hay que resaltar que el gestor de memoria es lina de
las partes del sistema operativo que est ms ligada al hardware. Esta estrecha relacin ha hecho que tanto
el hardware como el software de gestin de memoria hayan ido evolucionando juntos. Las necesidades del
sistema operativo han obligado a los diseadores del hardware a incluir nuevos mecanismos que, a su vez,
han posibilitado el uso de nuevos esquemas de gestin de memoria. De hecho, la frontera entre la labor que
realiza el hardware y la que hace el software de gestin de memoria es difusa y ha ido tambin evolucionan
do. El sistema de gestin de memoria ha sufrido grandes cambios segi'm han ido evolucionando los sistemas
operativos. Por ello, en esta presentacin, se ha optado por desarrollar este tema de manera que no slo se
estudie el estado actual del mismo, sino que tambin se pueda conocer su evolucin desde los sistemas ms
primitivos, ya obsoletos, hasta los ms novedosos. Consideramos que este enfoque va a permitir que el lector
entienda mejor qu aportan las caractersticas presentes en los sistemas actuales.
Por lo que se refiere a la organizacin del captulo, en primer lugar, se analizarn aspectos generales
sobre la gestin de memoria, lo que permitir fijar los objetivos del sistema de memoria y establecer un con
texto general para el resto del captulo. Posteriormente, se mostrarn las distintas fases que conlleva la ge
neracin de un ejecutable y se estudiar cmo es el mapa de memoria de un proceso. En las siguientes
secciones se analizar cmo ha sido la evolucin de la gestin de la memoria, desde los sistemas multiprogramados ms primitivos hasta los sistemas actuales basados en la tcnica de memoria virtual. Por ltimo,
se estudiarn algunos de los servicios de gestin de memoria de UNIX y de Windows. El ndice del captulo
es el siguiente:
Introduccin.
Aspectos generales de la gestin de memoria.
Modelo de memoria de un proceso.
Esquemas de gestin de la memoria del sistema.
Memoria virtual.
Servicios de gestin de memoria.
Gestin de memoria
Edificio
:q:
.
111. habitacin
rla..i I.....
:.... i _
s;
Itrg habit ; jhab
219
p
.o
II
|jg.. |
:./3 Iffapartamnto [iS3 |

Edificio
Edificio
F igura 5.1 Tres niveles de planificacin de un espacio urbanizable.
5.2.
ASPECTOS GENERALES DE LA GESTIN DE MEMORIA
En esta seccin se analizarn aspectos generales sobre la gestin de memoria, lo que permitir fijar los obje
tivos del sistema de memoria y establecer un contexto general para el resto del captulo. En primer lugar, se
analizar cules son los niveles de gestin presentes en el sistema de memoria. Acto seguido, se expondrn
las necesidades que tienen los programas con respecto al mismo y cmo el sistema operativo satisface estos
requisitos y los suyos propios. A continuacin, se estudiar el problema general de la asignacin de memoria
dinmica, presente en todos los niveles de gestin, y se mostrar el largo camino de transformaciones que
deben producirse para convertir el acceso simblico que realiza un programa en un acceso real a la memoria.
5.2.1. Niveles de gestin de memoria

El reparto de la memoria entre los procesos existentes es slo uno de los niveles de gestin de memoria en el
sistema. Para entender mejor este aspecto, hagamos un smil con la gestin de un terreno urbanizable donde
se pretenden construir varios edificios. En ese caso, debera existir un plan para repartir el espacio disponible
entre los diversos edificios que se desean construir. Asimismo, para cada edificio, debe haber una estrategia
de reparto del espacio entre los apartamentos incluidos en el mismo. Por ltimo, en cada apartamento, se de
be gestionar cmo se reparte el espacio entre sus diferentes habitaciones. La figura 5.1 muestra un ejemplo
donde existen cinco edificios, dos de los cuales aparecen divididos en cuatro y tres apartamentos, respecti
vamente, mostrndose uno de los apartamentos dividido en tres habitaciones.
De manera similar, en la gestin de la memoria se pueden distinguir tres niveles:
Nivel de procesos. El ya comentado, es decir, el que determina cmo se reparte el espacio de memo
ria entre los procesos existentes. Se trata de un nivel gestionado por el sistema operativo.
Nivel de regiones. Establece cmo se reparte el espacio asignado al proceso entre las regiones del
mismo. Ms adelante, se explicar qu tipo de regiones estn presentes habitualmente en un proceso.
Nuevamente, es un nivel manejado por el sistema operativo.
Nivel de zonas. Como se ver a lo largo del captulo, mientras que la mayora de las regiones tienen
un contenido homogneo (usando el smil planteado, se trata de apartamentos que no estn divididos
en habitaciones), existen algunas, como el heap o la pila, que mantienen en su interior diversas zonas
independientes (habitaciones, siguiendo el ejemplo propuesto). Por tanto, se requiere una estrategia
de gestin que determine cmo se reparte el espacio de la regin entre las distintas zonas englobadas
en la misma. Habitualmente, este nivel est gestionado por el propio lenguaje de programacin, con
cierto soporte del sistema operativo.
220
Este esquema de tres niveles es el ms habitual, pero, como se ver a lo largo del captulo, en alguno %
sistemas de gestin de memoria se fusionan dos de estos niveles (el de procesos y el de regiones), quedando '
slo dos presentes (como se estudiar ms adelante, esta situacin se produce en un sistema basado en see
mentacin). Siguiendo el smil, considere qu ocurrira si un apartamento pudiera estar formado por habita
ciones pertenecientes a distintos edificios. En ese caso, slo habra dos niveles de gestin: cmo se reparte eF
espacio urbanizable entre los edificios y de qu manera se distribuyen las habitaciones de cada apartamento is
entre los distintos edificios.
A lo largo del captulo, se estudiarn estos tres niveles mostrando para cada uno de ellos las distintas
soluciones existentes. Es interesante resaltar que, aunque es muy diferente la forma de gestionar cada nivel
puesto que son intrnsicamente distintos, existen algunas similitudes, ya que, al fin y al cabo, en todos los'
casos se trata de repartir un espacio. No obstante, en cada nivel, las peticiones de reserva de memoria correspondern a eventos totalmente distintos. A continuacin, se analiza qu tipo de operaciones genricas existen
en cada nivel. Esta enumeracin de operaciones genricas, adems de tener inters en s misma, va a permitir
que cuando se presente cada uno de los esquemas de gestin de memoria, se explique ms sistemticamente
su modo de operacin, mostrando cmo se implementan dichas operaciones en el mismo. A cada operacin
le asignamos un nombre para facilitar el hacer referencia a la misma.
Operaciones en el nivel de procesos
En el nivel de procesos se realizan operaciones vinculadas con la gestin del mapa de memoria del proceso.
C rear el m apa de m em oria del proceso {crearjnap). Antes de comenzar la ejecucin de un pro
grama, hay que iniciar su imagen de memoria tomando como base el fichero ejecutable que lo con
tiene. En UNIX se trata del servicio e x e c , mientras que en Windows es C r e a t e P r o c e s s , ya
estudiados en el captulo 3.
E lim inar el m apa de m em oria del proceso {eliminarjnapa). Cuando termina la ejecucin de un
proceso, hay que liberar todos sus recursos, entre los que est su mapa de memoria. En el caso de
UNIX, tambin hay que liberar el mapa actual del proceso en el servicio e x e c , antes de crear el
nuevo mapa basado en el ejecutable especificado.
D uplicar el m apa de m em oria del proceso (duplicar mapa). El servicio f o r k de UNIX crea un
nuevo proceso cuyo mapa de memoria es un duplicado del mapa del padre.
Para completar este nivel, y aunque no tenga que ver directamente con la solicitud y liberacin de espa
cio, falta una operacin genrica adicional asociada al cambio de contexto:
C am biar de m apa de m em oria de proceso (cambiarjnapa). Cuando se produce un cambio de
contexto, habr que activar de alguna forma el nuevo mapa y desactivar el anterior.
Operaciones en el nivel de regiones
En el nivel de regiones, las operaciones estn relacionadas con la gestin de las regiones.
C rear una regin dentro del m apa de un proceso (crear regin). Esta operacin ser activada al
crear el mapa del proceso, para crear las regiones iniciales del mismo. Adems, se utilizar para ir
creando las nuevas regiones que aparezcan segn se va ejecutando el proceso.
E lim inar un a regin del m apa de un proceso (eliminar regin). Al terminar un proceso hay que
eliminar todas sus regiones. Adems, hay regiones que desaparecen durante la ejecucin del proceso.
C am b iar el tam ao de una regin (redimensionar_regin). Algunas regiones, como la pila y el
heap, tienen un tamao dinmico que evoluciona segn lo vaya requiriendo el proceso.
D uplicar un a regin del m apa de un proceso en el m apa de otro (duplicar regin). El duplicado
del mapa asociado al servicio f o r k requiere duplicar cada una de las regiones del proceso padre.
Gestin de memoria
221
Operaciones en el nivel de zonas

Las operaciones identificadas en esta seccin slo son aplicables a las regiones que almacenan internamente
mltiples zonas independientes, como es el caso del heap o de la pila. En este nivel se pueden distinguir las
siguientes operaciones:
R eservar una zona (reservar zona). En el caso del heap y tomando como ejemplo el lenguaje C, se
tratara de la funcin m a l l o c . En C++ y Java, sera.el operador new.
L ib e ra r una zona reservada (liberar zona). En este caso, sera la funcin f r e e del lenguaje C,
mientras que en C++ correspondera a la operacin d e l e t e . En Java la liberacin se realiza de for
ma automtica, mediante un mecanismo de recoleccin de basura.
C am biar el tam ao de una zona reserv ad a (redimensionar zona). La funcin r e a l l o c de C
cumplira esta funcin.
5.2.2. Necesidades de los programas

Dado que el principal objetivo del sistema operativo es proporcionar servicio a las aplicaciones, es necesario
analizar, en primer lugar, qu necesidades tienen los programas con respecto al sistema de memoria para po
der entender la funcionalidad requerida por el mismo. En esta seccin, se presentan aquellas necesidades que
se han considerado ms relevantes. Hay que resaltar que algunas de ellas sern satisfechas por el sistema ope
rativo, mientras que otras quedan normalmente fuera del alcance del mismo, siendo labor de otros componen
tes, como, por ejemplo, el sistema de compilacin. Sin embargo, se considera importante ofrecer una visin
global para entender de una forma integrada cmo funciona la gestin de la memoria. Desde el punto de vista
de la gestin de memoria, un programa necesita:
Tener un espacio lgico propio e independiente.

Estar protegido de otros programas que estn ejecutndose simultneamente.
Compartir memoria con otros procesos para poder comunicarse eficientemente.
Tener soporte para sus distintas regiones.
Tener facilidades para su depuracin.
Poder usar un mapa de memoria muy grande, si lo precisa.
Utilizar distintos tipos de objetos de memoria.
Poder hacer persistentes los datos que as lo requieran.
Desarrollarse de una forma modular.
Poder realizar la carga dinmica de mdulos en tiempo de ejecucin.
Espacios lgicos independientes para los programas
En un sistema operativo multiprogramado de propsito general no se puede conocer a priori la posicin de

memoria que ocupar un programa cuando se cargue en memoria para proceder a su ejecucin, puesto que
depender del estado de ocupacin de la memoria, pudiendo variar en sucesivas ejecuciones del mismo. Por
tanto, dado que el carcter multiprogramado no debe afectar al programa ni al desarrollador del mismo, es
evidente que ni en la fase de programacin, ni en la de compilacin y montaje, debe haber referencias a las
direcciones de memoria reales donde ejecutar el programa. En consecuencia, las referencias a memoria que
aparecen en el cdigo mquina de un programa contenido en un ejecutable correspondern a direcciones de
memoria dentro del mbito del programa (normalmente, en un intervalo desde 0 hasta un cierto valor mxi
mo) y, por tanto, no tendrn ninguna relacin con las direcciones de memoria donde finalmente ejecutar el
programa.
Supngase que el fichero ejecutable mostrado en la figura 5.2, donde se ha utilizado un lenguaje en
samblador hipottico, es el resultado de la compilacin y montaje de un fragmento de un programa escrito en
C que copia el contenido de un vector v i , cuyo tamao es ta m , en otro vector v 2 :
fo r
< i= 0 ; i<tam ,- i+ + )
222 Sistemas operativos. Una visin aplicada

Fichero Ejecutable
Cabecera
LOAD R1. #1000 i;
LOAD R2, #2000
LOAD R3, (1500)
LOAD R4, (R1)
STORE R4,(R2)
INCR1
INCR2
DECR3
JNZ12
........ ..
. '-
F igura 5.2 Fichero ejecutable hipottico.

En ese ejecutable se ha supuesto que la cabecera ocupa 100 bytes, que cada instruccin ocupa 4 y u&
los vectores estn almacenados a partir de la direccin 1000 y de la 2000, respectivamente, estando el tamao
del vector en la 1500. Tngase en cuenta que, tanto en el ejecutable como, posteriormente, en memoria se
almacena realmente cdigo mquina. En esta figura y en las siguientes se ha preferido mostrar un pseudocdigo ensamblador para facilitar la legibilidad de las mismas.
El cdigo mquina de ese programa incluye referencias a direcciones de memoria que se corresponden
tanto con operandos (las direcciones de los vectores y su tamao) como con instrucciones (la etiqueta de la
bifurcacin condicional). Todas ellas estn referidas a un rango de direcciones entre 0 y un cierto valor
mximo.
En el caso de un sistema con monoprogramacin, para ejecutar este programa slo ser necesario car
garlo a partir de la posicin de memoria 0 y pasarle el control al mismo. Ntese que, como se puede apreciar
en la figura 5.3, se est suponiendo que el sistema operativo estar cargado en la parte de la memoria con
direcciones ms altas.
Suponga que se ejecuta ese programa en un sistema con multiprogramacin y se le asigna una zona de
memoria contigua a partir de la direccin 100. Si se realiza una carga directa del programa, las referencias a
memoria del mismo no sern vlidas, ni las correspondientes a los operandos ni a las instrucciones, como se
puede apreciar en la figura 5.4.
Por tanto, en un sistema con multiprogramacin es necesario realizar un proceso de traduccin (reubi
cacin) de las direcciones de memoria a las que hace referencia un programa (direcciones lgicas), tanto
para acceder a sus operandos como para realizar bifurcaciones en la secuencia de ejecucin, de manera que se
correspondan con las direcciones de memoria principal asignadas al mismo (direcciones fsicas).
En el ejemplo planteado anteriormente, habra que traducir todas las direcciones que genera el progra
ma aadindoles un valor de 100. Este proceso de traduccin crea, por tanto, un espacio lgico (o mapa)
independiente para cada proceso. Se trata de una reubicacin en el nivel de procesos.
Memoria
LOAD R1, #1000
LOAD R2. #2000
LOAD R3, (1500)
LOADR4, (R1)
STORE R4, (R2)
INCR1
INCR2
DEC R3
JNZ12
Figura 5.3 Ejecucin del programa en un sistema con monoprogramacin.
-m
fe
i
^
- ;
Gestin de memoria 223

Memoria
-
100
104
108
112
116
120
124
128
132
LOAD R1. #1000

LOAD R2. #2000
LOAD R3, (1500)
LOAD R4, (R1)
STORE R4. (R2)
INCR1
IN CR2
DECR3
JNZ12
S is te m a O perativo
... V 7-
*T
Figura 5.4 Ejecucin errnea del programa en un sistema con multiprogramacin.

Como se estudiar a lo largo del captulo, existen distintas alternativas a la hora de realizar esta reubi
cacin, pudindose llevar a cabo por software (reubicacin software), antes de iniciar la ejecucin del pro
ceso, o por hardware (reubicacin h ardw are), en tiempo de ejecucin. La reubicacin software realiza la
traduccin de las direcciones que contiene el programa en el momento de su carga en memoria. En la reubi
cacin hardware, que es el mtodo habitual en los sistemas operativos actuales, la funcin de traduccin la
lleva a cabo un mdulo especfico del procesador denominado unidad de gestin de memoria (MMU, Memo
ry Management Unit). El sistema operativo deber poder especificar a la MMU del procesador qu funcin
de reubicacin debe aplicar al proceso que est ejecutando en ese momento. Hay que resaltar que, como se
analizar a lo largo del captulo, la reubicacin hardware presenta innumerables ventajas y es la solucin
adoptada en todos los sistemas operativos de propsito general actuales. Sin embargo, hay que tener presente
que conlleva una cierta sobrecarga, tanto en gasto de espacio, debido a que es necesario que est disponible
en tiempo de ejecucin una cierta informacin de traduccin, como en una prdida de eficiencia, por el tiem
po requerido en realizar cada traduccin durante la ejecucin del programa.
La reubicacin define una correspondencia entre un espacio lgico y uno fsico. Un aspecto interesante
en este proceso es qu tamaos mximos tienen estos dos espacios, es decir, cuntos bits componen una di
reccin lgica y cuntos una fsica. Habitualmente, el tamao mximo del espacio lgico es igual al del espa
cio fsico, pero, en algunos sistemas, uno de ellos puede ser mayor.
Proteccin
El uso de la multiprogramacin mejora la eficiencia del sistema al permitir que varios procesos ejecuten de
forma concurrente. Sin embargo, esta simultaneidad abre la posibilidad de que un programa pueda interferir,
ya sea por error o malintencionadamente, en la ejecucin de otro. El desarrollador y el usuario de un progra
ma esperan que el sistema les ofrezca la proteccin y el aislamiento requeridos, impidiendo que otro progra
ma pueda acceder a direcciones de memoria asignadas a su programa. De esta forma, se elimina la
posibilidad de que un proceso pueda acceder a informacin de otro o interferir en su ejecucin causando un
fallo en la misma. El mecanismo de proteccin necesita del apoyo del hardware, puesto que es necesario va
lidar cada una de las direcciones que genera un programa en tiempo de ejecucin.
Como se ver ms adelante, el mecanismo de proteccin est generalmente integrado en el de traduc
cin: el proceso de traduccin debe asegurar que los espacios lgicos de los procesos sean disjuntos entre s.
C om partim iento de m em oria como medio de com unicacin
Como se analizar en el captulo de comunicacin y sincronizacin de procesos, la memoria compartida per
mite una forma de comunicacin muy rpida entre procesos cooperantes. Esta necesidad de compartir es, en
principio, contradictoria con el requisito de proteccin, que requiere que el sistema operativo cree espacios
lgicos independientes y disjuntos para los procesos. Sin embargo, bajo la supervisin y control del sistema
operativo, puede llevarse a cabo sin comprometer la seguridad del sistema. Para ello, el proceso de traduc-

Mapa proceso 1
Figura 5.5 Problemas al compartir una zona en diferentes direcciones del mapa de cada proceso.
cin debe permitir en este caso que direcciones lgicas de dos o ms procesos, posiblemente distintas entre
s, se correspondan con la misma direccin fsica.
La posibilidad de que los procesos compartan una zona de memoria hacindola corresponder a rangos
diferentes de su espacio lgico presenta problemas en determinadas circunstancias. Considere el caso de que
una posicin de memoria de la zona compartida tenga que contener la direccin de otra posicin de dicha
zona (o sea, una referencia), debido a que, por ejemplo, la zona compartida contiene una estructura de lista
basada en punteros. Como se puede apreciar en la figura 5.5, no es posible determinar qu direccin almace
nar en la posicin origen, puesto que cada proceso ve la posicin referenciada en una direccin diferente de
su mapa de memoria. A esta anomala la denominaremos el problem a de las autorreferencias.
Soporte de las regiones del proceso
Como se analizar con ms detalle en secciones posteriores, el mapa de un proceso no es homogneo, sino
que est formado por distintos tipos de regiones con diferentes caractersticas y propiedades. El programa
necesita que el sistema de memoria gestione adecuadamente las caractersticas especficas de cada tipo de
regin. As, por ejemplo, el contenido de la regin que contiene el cdigo del programa normalmente no debe
poder modificarse. Se debera detectar cualquier intento de escritura sobre una direccin incluida en dicha
regin y tratarlo adecuadamente (por ejemplo, enviando una seal al proceso).
Otro aspecto a resaltar es que el mapa del proceso no es esttico. Durante la ejecucin de un programa,
puede variar el tamao de una regin. Tmese como ejemplo el comportamiento dinmico de la regin de
pila del proceso, que crece segn se van realizando llamadas a procedimiento. Asimismo, pueden aparecer
nuevas regiones o eliminarse regiones existentes. As, por ejemplo, cuando se crea un thread, aparecer una
nueva regin que corresponde a la pila del nuevo thread, que desaparecer cuando ste termine. Este carcter
dinmico del mapa de un proceso puede implicar la existencia de zonas dentro del mapa de memoria del pro
ceso que en un determinado momento de su ejecucin no pertenecen a ninguna regin, y que, por tanto, cual
quier acceso a las mismas implica un error de programacin. El gestor de memoria debera detectar cundo se
produce un acceso a las mismas y, como en el caso anterior, tratarlo adecuadamente. Adems, en aras de un
buen aprovechamiento de la memoria, el esquema de gestin de memoria debe evitar reservar memoria para
las zonas del mapa que no estn asignadas al proceso en un determinado instante.
Algunas aplicaciones sofisticadas requieren un nmero muy elevado de regiones. El sistema de memo
ria debera permitirlo. En algunos casos se trata de procesos que necesitan un nmero muy grande de regio
nes, pero tal que stas, adems, son de carcter dinmico, con lo que es necesario asegurar que tienen espacio
entre ellas para crecer sin solaparse. De este tipo de aplicaciones se dice que tienen un espacio de direccio
nes disperso, en el sentido de que las regiones estarn diseminadas por todo el espacio de direcciones del
proceso. El sistema de memoria debe dar soporte a este tipo de aplicaciones intentando minimizar el gasto de
recursos.

Sea cual sea el esquema de gestin de memoria utilizado, ser necesario que el sistema operativo utilice
tipo de estructura de datos que mantenga el estado de la regiones de cada proceso (a esta estructura la
denominaremos tabla de regiones).
a lg n
Facilidades para la depuracin

Uno de los errores de programacin ms frecuentes es el uso de referencias a memoria errneas. Como se
analiz en el punto anterior, en algunos casos puede tratarse de un acceso a una direccin de memoria no
asignada al proceso, mientras que en otros puede deberse a un tipo de acceso que no est permitido dadas las
caractersticas de la regin involucrada. El sistema de memoria debe intentar detectar este tipo de errores lo
antes posible, ya que, cuanto antes se haga, ms fcil ser la depuracin y menor ser la posible repercusin
del error. Algunos errores pueden descubrirse en la fase de compilacin o montaje, lo cual siempre es prefe
rible. Pero en caso de no ser posible en esa fase, se deberan detectar en tiempo de ejecucin, causando que el
programa aborte su ejecucin en ese instante. Normalmente, en ese momento el desarrollador de la aplicacin
utilizar un programa depurador para intentar detectar y corregir el error. Es interesante resaltar que, desde el
punto de vista de la gestin de memoria, el modo de operacin del depurador requiere que ste pueda acceder
directamente al mapa de memoria del proceso que est siendo depurado para consultar y modificar variables,
as como para establecer puntos de ruptura en su ejecucin. Ntese que ese requisito debe de ser incluido
explcitamente en el sistema de gestin de memoria puesto que, en este caso, hay que relajar el nivel de pro
teccin entre procesos.
M apas de m em oria muy grandes p ara los procesos
La continua mejora en las prestaciones de los sistemas informticos ha ido permitiendo su uso para afrontar
problemas cada vez ms complejos. Algunas de estas aplicaciones tienen unos requisitos de memoria muy
elevados para llevar a cabo su labor de manera eficiente. Es necesario, por tanto, que el sistema operativo
ponga a disposicin de estos programas toda la memoria disponible. Por tanto, el tamao del espacio lgico
ofrecido a un proceso debe poder ser tan grande como el del espacio fsico disponible, o incluso mayor. Con
respecto a este ltimo aspecto, dado que en cada momento el proceso slo usa una parte relativamente pe
quea de su mapa, como consecuencia de la propiedad de la proximidad de referencias presente en todo pro
grama, tal como se estudi en el primer captulo, es factible, de forma eficiente, poder hacer creer a los
procesos que disponen de ms memoria de la que realmente existe, usando la tcnica de la m em oria virtual,
que se estudiar en la parte final del captulo.
Esta necesidad puede parecer innecesaria dado el espectacular abaratamiento de la memoria y la consi
guiente disponibilidad generalizada de equipos con memorias apreciablemente grandes. Sin embargo, a pesar
de ello, la necesidad de memoria por parte de las aplicaciones es insaciable. A la memoria le ocurre lo mismo
que a los armarios: cunto ms grandes son, ms cosas metemos dentro de ellos, y siempre estn llenos. La
disponibilidad de ms memoria permite a los programadores obtener beneficio del avance tecnolgico, pudiendo incluir caractersticas ms avanzadas en sus aplicaciones o incluso tratar problemas que hasta enton
ces se consideraban inabordables.
Diversos tipos de objetos de m em oria
Como establece el modelo de von Neumann, un programa necesita tener asignada una zona de memoria para
almacenar en ella los datos que utiliza durante su ejecucin. Sin embargo, no todos los datos que utiliza la
aplicacin tienen las mismas caractersticas. Por un lado, hay datos de tipo constante que no deberan de ser
modificados por ninguna sentencia del programa. Por otro lado, dependiendo del tipo de uso previsto para
cada dato, se presentan distintas alternativas en cuanto al tiempo de vida del mismo:
Datos estticos. Se trata de datos que existen durante toda la ejecucin del programa. Al inicio de la
ejecucin del programa se conoce cuntos datos de este tipo existen y se les habilita el espacio de
almacenamiento requerido, que se mantendr durante toda la ejecucin del programa.
Datos dinm icos asociados a la ejecucin de una funcin. La vida de este tipo de datos est aso
ciada a la activacin de una funcin, crendose en la invocacin de la misma y destruyndose cuan
do sta termina.

Datos dinmicos controlados por el program a. Se trata de datos dinmicos, pero cuyo tiempo de
vida no est vinculado a la activacin de una funcin, sino bajo el control directo del programa, que
crear los datos cuando los necesite. El espacio asociado a los datos se liberar cuando ya no sea ne
cesario. Este tipo de datos se almacena habitualmente en una regin denominada heap.
Existe un tipo de datos adicional, las variables globales de thread, que quedan fuera de esta exposicin
(aunque no se volvern a tratar en el resto del capitulo, se recomienda al lector interesado en este tema con
sultar la aclaracin 5.2).
A claracin 5.2. En algunas ocasiones, puede ser conveniente disponer de una variable global, accesible des
de cualquier parte de un programa, pero tal que cada thread tenga implcitamente su propia copia de la mis
ma. De esta forma, cuando un thread lee esta variable, accede de forma implcita a su propia copiaj
obteniendo, por tanto, el ltimo valor almacenado por ese mismo thread en esa variable. Un ejemplo de la
utilidad de este mecanismo se presenta en la implementacin de la variable e r r n o de UNIX, que almacena
el cdigo de error asociado a la ltima llamada al sistema que caus un fallo. En un sistema con threads, lo
razonable es que cada uno tenga su propia copia de esta variable, lo cual se puede conseguir fcilmente de
clarndola como variable global de thread. En algunos compiladores, esto se conseguira con una declaracin
como la siguiente:
int __thread e r m o ;
Hay que resaltar que el sistema operativo no se encarga de proporcionar directamente los diversos tipos
de objetos de memoria, siendo sta una labor del lenguaje de programacin. Sin embargo, consideramos que
es necesario conocerlos para entender de qu manera estn asociados con los diversos tipos de regiones pre
sentes en un proceso.
P ersistencia de datos
Las aplicaciones necesitan poder almacenar datos de forma persistente, de manera que pervivan cuando ter
mine su ejecucin e incluso cuando se apague su computador. Como el lector conoce sobradamente, este re
quisito se satisface mediante el uso de ficheros que se almacenan en dispositivos de almacenamiento no
voltiles. Como se estudiar en el captulo dedicado al sistema de ficheros, ste ofrece una coleccin de fun
ciones que permite almacenar y recuperar informacin del programa en ficheros. Sin embargo, este modo de
operacin requiere que el programador incluya explcitamente en su cdigo llamadas al sistema de ficheros.
Un modo alternativo, que puede ser ms conveniente para muchas aplicaciones, es uno en el que, una vez
marcados ciertos datos como persistentes, no sea necesario invocar funciones del sistema de ficheros. En su
lugar, el programa accede a esos datos como al resto de las variables, realizndose de forma automtica su
salvaguarda y recuperacin del almacenamiento no voltil. La mayora de los sistemas operativos actuales
ofrecen este tipo de acceso alternativo a los datos persistentes dentro de los servicios proporcionados por el
sistema de gestin de memoria, usando, como se analizar al final del captulo, la tcnica de la proyeccin de
ficheros.
D esarrollo m odular
Cuando se afronta el desarrollo de una aplicacin de una cierta envergadura, es conveniente hacerlo de una
manera modular. Observe que intencionadamente no se va a definir con precisin a qu nos referimos con el
trmino mdulo, resaltando nicamente que se trata de una unidad de compilacin independiente, y obviando
cualquier otro aspecto que no sea pertinente para esta presentacin El desarrollo modular permite programar
y compilar cada mdulo de una manera independiente, y luego integrar todos los mdulos requeridos con
formando el programa ejecutable. Esta tcnica facilita el desarrollo incremental y fomenta la reutilizacin del
software. Es importante resaltar que durante la fase de compilacin de un mdulo no se conoce con qu otros
mdulos se integrar para formar un ejecutable. Por tanto, en el cdigo objeto resultante de la compilacin de
un mdulo se incluirn referencias a direcciones de memoria dentro del mbito del mdulo (normalmente,
entre 0 y un valor mximo). Aprciese que vuelve a requerirse un proceso de traduccin (reubicacin). Sin

embargo, en este caso, se trata de una reubicacin de mdulos. Hay que hacer notar que, en la mayora de
los sistemas, el sistema operativo no participa en el soporte de este desarrollo modular, sino que es labor ex
clusiva del sistema de compilacin y montaje, tratndose, por tanto, de una reubicacin software. Sin embar
go, consideramos que es necesario entender de qu manera se lleva a cabo para conocer mejor cmo es el
proceso global del sistema de gestin de memoria.
Carga dinmica de mdulos
Un nmero creciente de aplicaciones requiere poder aadir nueva funcionalidad sin necesidad de volver a
compilarlas, enlazarlas, o incluso, sin tener que volver a arrancarlas. En este esquema se basan mecanismos
tan conocidos como los plugins que estn presentes en numerosas aplicaciones de uso muy frecuente, como,
por ejemplo, los navegadores web. El sistema de memoria tiene que proporcionar esta funcionalidad a las
aplicaciones. Como se ver ms adelante, esta necesidad se satisface mediante la tcnica del montaje explci
to de bibliotecas dinmicas.
5.2.3. O bjetivos del sistema de gestin de memoria

Adems de satisfacer las necesidades de los procesos, tal como se han planteado en la seccin anterior (al
menos aqullas que incumben directamente al sistema operativo), el gestor de memoria debe cumplir otros
dos objetivos. Por un lado, debe satisfacer los requisitos planteados por el propio sistema operativo, en cuan
to a su uso de memoria. Por otro lado, en su faceta de controlador de recursos, debe realizar una gestin efi
ciente y correcta de los distintos tipos de memoria presentes en el computador. Centrndose en estas dos
facetas, el sistema operativo debe:
Tener un espacio lgico propio.

Estar protegido de los programas que estn ejecutndose.
Usar la tcnica de compartir memoria para poder optimizar el uso de la misma.
Tener soporte para sus distintas regiones.
Satisfacer adecuadamente las propias necesidades de memoria del sistema operativo.
Poder realizar carga dinmica de cdigo del sistema operativo en tiempo de ejecucin.
Lograr un buen aprovechamiento de la memoria.
Gestionar eficiente y coherentemente la jerarqua de memoria.
Dar soporte a los sistemas multiprocesador en cuanto a sus necesidades de memoria.
E spacio lgico propio para el sistem a operativo
A pesar de sus peculiaridades, el sistema operativo es al fin y al cabo un programa ms. Por tanto, se plantea
si es necesario un proceso de reubicacin de las direcciones contenidas en el fichero ejecutable del sistema
operativo, como ocurre con el resto de los programas. En este caso, en principio, no sera estrictamente nece
saria la traduccin, ya que el sistema operativo puede compilarse de manera que utilice un determinado rango
de direcciones (por ejemplo, desde 0 hasta un valor mximo) y cargarse justo en ese rango (al principio de la
memoria, en caso de que se haya compilado en un rango que comienza por 0), eliminando la necesidad de la
reubicacin. De cualquier manera, el uso de una funcin de traduccin puede ser conveniente, puesto que
proporciona ms flexibilidad. Para entender esto, considere qu ocurrira, en caso de que no hubiera reubica
cin, si el sistema operativo estuviera compilado para usar un cierto rango de direcciones y este rango no
estuviera disponible debido a que, por ejemplo, correspondiera a memoria ROM. En este caso, no sera posi
ble la ejecucin del sistema operativo. El uso de la reubicacin tambin en el sistema operativo proporciona
un grado de flexibilidad que permite cargarlo en cualquier rango de direcciones, creando un mapa propio
para el mismo.
Como ocurre con la reubicacin de procesos, la solucin usada para el sistema operativo es una reubi
cacin hardware, es decir, las direcciones generadas por el cdigo del sistema operativo son traducidas en
tiempo de ejecucin por la MMU. Esta circunstancia plantea un problema del tipo huevo o gallina (qu fue
antes?): el sistema operativo es el encargado de indicar a la MMU cul debe ser la funcin de traduccin que

aplica a las direcciones, pero, por otra parte, no puede hacerlo, ya que, para que el sistema operativo pueda
ejecutar correctamente esta informacin debe estar presente. En la mayora de los sistemas, este problema se
resuelve gracias a que el procesador comienza su ejecucin con la funcin de traduccin desactivada, por lo
que todas las direcciones que genera inicialmente el sistema operativo llegan a la memoria sin alteracin. El
cdigo inicial del sistema operativo est preparado para funcionar correctamente sin reubicacin. Como parte
del proceso de iniciacin del sistema operativo, ste confecciona su propia informacin de reubicacin y se la
comunica a la MMU, activando el proceso de traduccin en ese momento. Como podr imaginar el lector, el
cdigo de esta fase tiene que tener en cuenta esa transicin. Tngase en cuenta que en una instruccin justo
antes de la activacin de la MMU, una determinada direccin de memoria corresponde a esa misma direccin
en memoria fsica, mientras que ese mismo valor, justo despus de la activacin de la funcin de traduccin
pasa por un proceso de reubicacin antes de llegar a la memoria.
Hay que resaltar que el sistema operativo no slo requiere utilizar su mapa, sino que necesita acceder a
toda la memoria del sistema. Es importante resaltar que, adems de poder acceder a la memoria fsica, el sis
tema operativo necesita ver el espacio lgico de cada proceso. Para aclarar esta afirmacin, considere un
sistema donde la reubicacin se realiza en tiempo de ejecucin (reubicacin hardware). Suponga que en este
sistema un proceso realiza una llamada al sistema en la que pasa como parmetro la direccin donde est
almacenada una cadena de caracteres que representa el nombre de un fichero. Ntese que se tratar de una
direccin lgica dentro del mapa del proceso y que, por tanto, en tiempo de ejecucin, esa direccin se de
ber transformar usando la funcin de traduccin asociada al proceso para poder acceder a dicha cadena.
Proteccin del sistem a operativo
Adems de proteger a los programas entre s, el sistema operativo debe protegerse a s mismo de los accesos
que realizan los programas en ejecucin para evitar que, voluntaria o involuntariamente, puedan interferir en
el correcto funcionamiento del mismo. Todos los usuarios que han trabajado en un sistema que no cumple
este requisito de proteccin, como, por ejemplo, MS-DOS, han experimentado cmo el error de un programa
puede provocar que todo el sistema se colapse durante su ejecucin, al producirse una alteracin imprevista
del cdigo o de las estructuras de datos del sistema operativo.
Tngase en cuenta que en el caso de un sistema que use un procesador con mapa de memoria y E/S
comn, el propio mecanismo de proteccin permite impedir que los procesos accedan directamente a los dis
positivos de E/S, haciendo simplemente que las direcciones de los dispositivos no formen parte del mapa de
ningn proceso.
C om partim iento de m em oria p a ra optim izar su uso
Adems de proporcionar una forma de comunicacin muy rpida entre procesos cooperantes, el comparti
miento de memoria permite al sistema operativo un mejor aprovechamiento de la memoria disponible,
haciendo que, cuando se estn ejecutando mltiples activaciones del mismo programa (por ejemplo, el intr
prete de mandatos) o de una biblioteca, los procesos correspondientes compartan el cdigo. Para aumentar el
grado de compartimiento en el sistema, tanto el sistema de compilacin como el propio sistema operativo,
deberan evitar modificar en tiempo de ejecucin el cdigo de ejecutables y bibliotecas cargados en memoria,
puesto que esto impedira el compartimiento de los mismos.
Las zonas de datos de un programa o de una biblioteca no pueden compartirse, puesto que cada proceso
requiere su copia privada. Sin embargo, su contenido inicial es idntico. Dado que no todos los datos de un
programa o de una biblioteca se modifican durante su ejecucin, sera interesante diferir la generacin de una
copia privada de un dato para un proceso hasta que ste lo modifique. De esta forma, todas las activaciones
de un mismo programa, y todos los usos simultneos de una biblioteca, compartiran inicialmente las zonas
de datos, crendose copias privadas para un proceso, pero slo de aquellos datos modificados por el mismo.
Esta optimizacin ser efectiva si los programas no modifican todos sus datos durante su ejecucin, lo cual es
frecuente, dado que habr algunas variables que slo se modificarn si se cumplen ciertas condiciones.
Esa misma estrategia de copia diferida se puede usar en la operacin de duplicar una regin asociada a
la llamada f o r k . En este caso, la copia diferida es especialmente eficiente, puesto que, la mayora de las
veces, el proceso hijo prcticamente no modifica su mapa de memoria, ya que realiza inmediatamente una
llamada a e x e c , que crea un nuevo mapa destruyendo el previo. E} uso de una estrategia de copia diferida

puede lograr una implementacin eficiente de la llamada f o r k , que tradicionalmente siempre se ha conside
rado una llamada costosa en cuanto a su tiempo de ejecucin. Como se analizar en la seccin dedicada a la
memoria virtual, la tcnica del copy-on-write servir para este propsito.
Cuando mltiples procesos comparten una regin, ya sea de forma explcita o implcita, el sistema ope
rativo debe controlar en qu momento la regin deja de ser usada para poder liberarla. Para ello, se suele uti
lizar un contador de referencias, que mantiene la cuenta del nmero de veces que est siendo usada la
regin compartida.
Como ocurra con el uso del compartimiento de memoria como mecanismo de comunicacin, se pre
senta tambin en este caso el problem a de las autorreferencias. Si los procesos comparten una zona de
memoria hacindola corresponder a rangos diferentes de su espacio lgico, existen problemas si en la zona
compartida se incluye una direccin de la propia zona. En el caso del cdigo, considere qu ocurrir si una
posicin de la zona contiene una instruccin de bifurcacin a otra posicin de la misma.
Soporte de las regiones del sistem a operativo
Al igual que ocurre con los procesos de usuario, el mapa de memoria del propio sistema operativo, como
programa que es, tambin est organizado en regiones. El sistema de memoria debera dar soporte a las re
giones del sistema operativo. As, se detectara inmediatamente un error en el cdigo del sistema operativo,
lo que facilitara su depuracin a la gente encargada de esta ardua labor. La deteccin del error debera de
detener inmediatamente la ejecucin del sistema operativo y mostrar un volcado de la informacin del siste
ma.
Gestin de m em oria acorde con las necesidades del propio sistem a operativo
A lo largo del captulo se irn conociendo las necesidades especficas del propio sistema operativo en cuanto
a su uso de la memoria, aunque en esta seccin se pueden anticipar algunos aspectos generales. En primer
lugar, hay que reiterar que el sistema operativo es un programa y, por tanto, usar estructuras de datos simila
res a cualquier otro programa. Tradicionalmente, era habitual que muchas de las estructuras de datos del sis
tema operativo fueran de carcter esttico (tales como la tabla de procesos o la de ficheros abiertos). Sin
embargo, la tendencia general ha sido sustituirlas por estructuras reservadas de forma dinmica.
Esa tendencia responde a la estrategia general de intentar mejorar el uso de la memoria por parte del
sistema operativo y de conseguir un nico punto de agotamiento de la memoria. Si se utiliza una estructura
esttica, sta tendr que definirse con un tamao mximo. Si el tamao elegido es demasiado grande, se es
tar desperdiciando memoria, puesto que el espacio sobrante se malgasta, mientras que en caso de que el ta
mao seleccionado sea demasiado pequeo, se producir un error por falta de espacio, aunque realmente
haya memoria libre en el sistema. La reserva dinmica permite usar la cantidad de memoria que realmente se
requiere, asegurando, adems, que, mientras haya memoria en el sistema, se podr asignar espacio a cual
quiera de las estructuras de carcter dinmico (nico punto de agotamiento del espacio de memoria). El pre
cio que hay que pagar es la sobrecarga asociada a una gestin dinmica de la memoria, como se analizar a lo
largo del captulo.
C arg a dinm ica de cdigo del sistem a operativo
Tradicionalmente, los sistemas operativos estaban formados por un nico fichero ejecutable de tamao con
siderable, que contena toda la funcionalidad requerida para controlar el uso del computador, incluso ms all
de la estrictamente necesaria (por ejemplo, manejadores de dispositivos de los que no se dispona, al menos
por el momento). Aadir una nueva funcionalidad implicaba generar una nueva versin del sistema operativo
y arrancar el sistema usando esa versin. En los sistemas actuales, se posibilita la carga en tiempo de ejecu
cin de mdulos de cdigo del sistema operativo.
Esta posibilidad permite crear un ejecutable del sistema operativo que incluya justo la mnima funcio
nalidad requerida y traspasar a mdulos el resto de la funcionalidad. Adems de ser una solucin ms flexi
ble, esta estrategia facilita la implementacin de tcnicas sofisticadas como el hot-plugging de dispositivos,
que permite, estando el sistema arrancado, conectar un nuevo dispositivo al equipo, producindose automti

camente la carga del mdulo software que lo gestiona. La tcnica que se utiliza para este propsito es similar
a la que usa para cargar en tiempo de ejecucin mdulos de aplicaciones de usuario.
Buen aprovecham iento de la memoria
El gestor de memoria debe, evidentemente, aprovechar al mximo el recurso que gestiona. Lo ideal es que
toda posicin de memoria se utilice para almacenar alguna informacin de utilidad, ya sea de los procesos o
del propio sistema operativo. Sin embargo, esto no es as. Por un lado, se produce un desperdicio inherente a
la propia gestin, que habr que intentar minimizar, al que se denomina fragm entacin, y que ser estudiado
en detalle ms adelante. Por otro lado, la propia gestin de memoria requiere un gasto en espacio de almace
namiento para que el sistema operativo almacene las estructuras de datos implicadas en dicha gestin. As,
ser necesario guardar la tabla de regiones y la informacin de traduccin asociada a cada proceso, en caso
de usar reubicacin hardware, as como una estructura que refleje qu partes de la memoria permanecen li
bres y cules estn ocupadas. Dado que el almacenamiento de estas estructuras resta espacio de memoria para
los procesos, es importante asegurar que su consumo se mantiene en unos trminos razonables.
Otro aspecto que conviene resaltar, aunque pueda parecer obvio, es que el gestor de memoria siempre
debe recuperar un determinado espacio de memoria cuando el proceso o el mdulo del sistema operativo que
lo usaba ya no lo necesite, asegurando que no queda espacio de memoria inutilizable (a este problema se le
suele denominar goteras en la memoria).
Un mejor aprovechamiento de la memoria permite tener ms procesos activos en el sistema, es decir, un
mayor grado de multiprogramacin. Como se analiz en captulos anteriores, el grado de multiprogramacin
del sistema influye directamente en el porcentaje de utilizacin del procesador y, por tanto, en el rendimiento
del sistema. Adems, un mayor grado de multiprogramacin implica que puede existir un mayor nmero de
usuarios trabajando simultneamente en el sistema.
Para optimizar el rendimiento, la mayora de los sistemas operativos no slo intentan aprovechar la
memoria existente lo mejor posible, sino que, adems, utilizan la tcnica de la m em oria virtual presentada
en el primer captulo, y que se estudiar al final de ste. Con esta tcnica, el grado de multiprogramacin
puede aumentar considerablemente, ya que no es preciso que todo el mapa de memoria del proceso tenga que
residir en memoria principal para poder ejecutarse, sino que se ir trayendo de la memoria secundaria bajo
demanda. Tngase en cuenta que el incremento del grado de multiprogramacin no puede ser ilimitado pues
to que, como ya se analiz en el primer captulo, cuando se supera un determinado umbral, el rendimiento del
sistema decae drsticamente.
Gestin eficiente y coherente de la jerarq u a de m emoria
El sistema operativo gestiona la jerarqua de memoria presente en el computador. Como se explic en el pri
mer captulo del libro, para obtener un rendimiento eficiente de esta jerarqua hay que intentar que la infor
macin que se est usando en un determinado momento est almacenada en los niveles ms rpidos de la
jerarqua. Esta labor la lleva a cabo el hardware en el nivel de memoria cach (o el compilador, en el caso del
nivel de los registros del procesador), pero el sistema operativo es el que se encargar de realizarla en el nivel
de memoria virtual.
Aunque el nivel de memoria cach est controlado por el hardware y, en la mayora de los procesado
res, es prcticamente transparente al sistema operativo, ste puede gestionar el espacio de memoria de mane
ra que se obtenga un mayor provecho de la cach, como se ver ms adelante.
En cuanto a la coherencia, como se estudi en el primer captulo del libro, una jerarqua de memoria
presenta mltiples problemas de coherencia (entre dos niveles adyacentes, entre dos mdulos de memoria del
mismo nivel, y otros que aparecern a lo largo de este captulo). Algunos de ellos los soluciona directamente
el hardware. Sin embargo, hay otros que debe resolver el sistema operativo.
Soporte m ultiprocesador
En caso de un sistema multiprocesador, la jerarqua de memoria se complica al existir mltiples componentes
en varios niveles de la jerarqua. Cada procesador posee su propia cach y su propia unidad de gestin de
memoria, aumentando los problemas de coherencia. Como se coment en el apartado anterior, el hardware va

a resolver algunos de los problemas de coherencia presentes en la jerarqua de memoria del sistema multipro
cesador, pero, como se estudiar ms adelante, ciertos problemas los deber afrontar el sistema operativo.
Un aspecto importante en un multiprocesador es evitar que haya algn tipo de congestin (cuellos de
botella) en el manejo de alguna estructura de datos que requiera un acceso sincronizado, puesto que repercute
considerablemente en el rendimiento del sistema. Por lo que se refiere al gestor de memoria, su modo de ope
racin debe evitar que se produzcan este tipo de cuellos de botella en el sistema.
En cuanto a los multiprocesadores de tipo NUMA, para obtener un buen rendimiento en este tipo de ar
quitecturas, el sistema operativo debe asignar memoria a los procesos intentando que las operaciones sobre la
memoria por parte de un proceso se realicen sobre la parte de la memoria a la que puede acceder ms rpi
damente.
5.2.4. Problema general de la asignacin de memoria

Anteriormente, se han identificado tres niveles en la gestin de memoria: el nivel de procesos (asignacin de
memoria a cada proceso), el nivel de regiones (asignacin de memoria a cada regin de un proceso) y el nivel
de zonas (asignacin de memoria a las distintas zonas englobadas en una regin, en caso de que la regin las
tenga). Es evidente que se trata de niveles muy diferentes entre s, en los que entran en juego factores radi
calmente distintos. Sin embargo, en esencia, hay un punto en comn en todos ellos: el reparto de un determi
nado espacio de almacenamiento entre las distintas peticiones que necesitan usarlo.
Este problema general asume que las peticiones de reserva requieren un espacio de almacenamiento
contiguo. Sin embargo, como analizaremos ms adelante, cuando se usan esquemas de asignacin que no
requieren esta contigidad (reubicacin no lineal), como ocurre con la paginacin, no es aplicable directa
mente este problema, ni lo son las soluciones que se presentan a continuacin, o, al menos, se simplifican
apreciablemente.
En esta seccin se estudia este problema de forma general, de manera que las consideraciones que se
realicen puedan aplicarse a los tres niveles en el resto del captulo. Se estudian distintas soluciones a este
problema y, cuando en secciones posteriores, se presenten los distintos niveles de gestin de memoria, se
analizar cul es la solucin ms adecuada en cada caso.
Asimismo, hay que resaltar que este problema general se presenta en otros mbitos del sistema operati
vo, como la gestin del espacio de disco cuando se usa una estrategia de asignacin contigua de bloques a los
ficheros, e incluso fuera del mbito de la informtica. De hecho, para ilustrar esta seccin, utilizaremos el
ejemplo hipottico de una gran nave (el espacio de almacenamiento a repartir) destinada al alquiler de apar
tamentos a medida (las peticiones de espacio que hay que satisfacer). Se tratara de una nave que puede ser
compartimentada, usando paredes flotantes, en habitculos de distintas dimensiones. Reconocemos que es un
ejemplo un poco forzado y que, probablemente, el avispado lector habr imaginado alguno ms realista. Le
animamos a que use su propio ejemplo en la explicacin que sigue.
Planteam iento del problem a
Comencemos definiendo el problema general de la asignacin dinmica de memoria estableciendo sus prin
cipales caractersticas.
Existe un espacio de almacenamiento de N bytes (metros cuadrados en el ejemplo planteado).
Se producen de forma dinmica peticiones de reserva de memoria de diversos tamaos (en el ejem
plo, solicitudes de alquiler de un nmero determinado de metros cuadrados).
Cuando ya no se necesita un determinado espacio, ste se libera (se cancela el alquiler liberando el
espacio). En algunas versiones del problema slo se puede liberar todo el espacio asociado a una re
serva, mientras que en otras tambin puede liberarse slo parte del mismo. En cualquier caso, el pro
blema es bsicamente equivalente, ya que liberar parte de una reserva simplemente genera un
espacio libre y una zona reservada ms pequea (o dos zonas en caso de que se haya liberado espacio
en mitad de la reserva inicial).
r .w .o
F ig u ra 5.6 Solucin basada en compactacin.

Puede existir un tamao de reserva mnimo. En el caso de la memoria, debido a las restricciones de
alineamiento (vase la aclaracin 5.3) presentes en la mayora de los procesadores, puede ser necesa
rio que el tamao de las peticiones sea mltiplo de un determinado tamao (normalmente, 4 bytes,
aunque en algunos sistemas puede ser 8 bytes) para asegurar que no se produce este tipo de proble
mas. En caso de que el tamao solicitado no sea mltiplo de ese valor mnimo, debe redondearse por
exceso para que lo sea. Como se analizar ms adelante, en ciertas situaciones, por motivos de orga
nizacin del espacio de memoria, pueden existir otros tamaos mnimos (como, puede ser el tamao
de una pgina).
Hay que aclarar en este punto que hay una solucin directa a este problema basada en la compactacin:
cada vez que se libere un determinado espacio, se copia todo el espacio reservado a continuacin, trasladn
dolo de manera que no se genere ningn hueco, dejando todo el espacio libre compactado al final de la zona
que se gestiona. En la figura 5.6 se puede apreciar este proceso, mostrando cmo evoluciona el espacio ges
tionado cuando se libera la segunda reserva. Con esta estrategia, la reserva de espacio es sencilla, ya que bas
ta con usar directamente la parte requerida del hueco que est al final del espacio gestionado. Esta solucin
tiene dos problemas graves, que desaconsejan su uso. Por un lado, el coste de copiar la informacin cada vez
que se libera un espacio reservado (al usuario de un apartamento no le va a resultar cmodo tener que mover
se cada vez que se va un vecino). Por otro lado, como se aprecia en la figura, si existe alguna referencia a un
dato almacenado en un bloque reservado y ste se mueve de sitio, como ocurre con esta estrategia, la referen
cia deja de ser vlida. En consecuencia, este tipo de solucin slo ser aplicable si las caractersticas de la
zona permiten tolerar los dos problemas identificados, lo que no suele ser habitual, pero no constituye una
solucin general a este problema, que ser lo que se afronte a continuacin.
A claracin 5.3. Por razones de eficiencia, en la mayora de los procesadores, cada objeto debe almacenarse
en una direccin de memoria que sea mltiplo del tamao del objeto (restriccin de alineam iento). En gene
ral, el programador no debe de ocuparse de este aspecto, ya que el compilador se encarga de situar cada va
riable en una direccin que cumpla las restricciones de alineamiento correspondientes. Las restricciones de
alineamiento no slo afectan a variables individuales, sino tambin a los diversos campos de las estructuras
de datos compuestas, lo que hace que una estructura de datos pueda ocupar ms espacio del requerido direc
tamente por sus campos, puesto que las restricciones de alineamiento pueden forzar la presencia de espacio
sin usar entre los mismos.
Las soluciones generales no usan compactacin. Por tanto, segn va evolucionando el sistema y se van
produciendo peticiones de reserva y de liberacin, en la memoria van quedando una sucesin de zonas libres
(huecos) y zonas ocupadas (bloques). Para conocer el estado de la memoria en cada instante, bastar con
saber la direccin de comienzo y el tamao de cada bloque y de cada hueco presentes en un momento dado.
Volviendo al smil planteado, es necesario almacenar en algn sitio qu apartamentos estn alquilados y qu
zonas estn libres.
U na estrategia de gestin se caracteriza por el tipo de estructura de datos que se utiliza para almacenar
el estado de la memoria y por el algoritmo que se usa para buscar un hueco que satisfaga una determinada

V
7 '- '
bW
Blo qi
; Bloqi
- i. ,- - '
?;
......
e.
B lo qi
F igura 5.7 El problema de la fragmentacin externa.

peticin. Antes de analizar estos dos aspectos, es importante resaltar los dos objetivos que se deben intentar
satisfacer a la hora de disear una estrategia de gestin de memoria: por un lado, que haya un buen aprove
chamiento de la memoria y, por otro lado, que el algoritmo sea eficiente.
Con respecto al aprovechamiento del espacio de almacenamiento, lo mejor sera que todo el espacio
disponible se dedicase a satisfacer las necesidades de los solicitantes. Sin embargo, debido a la propia din
mica de la gestin de la memoria, esto no es as:
Por un lado, la propia informacin sobre el estado de la memoria, necesaria para realizar su gestin,
ocupa un cierto espacio de almacenamiento.
Por otro lado, segn evoluciona el espacio de almacenamiento, van quedando fragmentos inutilizables. Este problema, como ya dijimos antes, se denomina fragm entacin.
La fragmentacin es un aspecto clave en la gestin de memoria y uno de los objetivos de cualquier es
quema es intentar minimizarla. Este problema se presenta en dos modalidades:
Fragm entacin externa. En el proceso de asignar y liberar espacio, se pueden producir huecos muy
pequeos entre los bloques. El espacio de estos huecos de tamao reducido se desperdicia, ya que no
se puede usar para satisfacer ninguna solicitud. En un cierto instante, la cantidad total de espacio li
bre puede ser claramente suficiente para satisfacer una determinada peticin. Sin embargo, debido a
la fragmentacin externa, la peticin no puede ser cumplida. En la figura 5.7, se puede observar que
hay un espacio total libre de 60 bytes, pero, sin embargo, debido a la fragmentacin externa, slo se
pueden satisfacer peticiones de un tamao de 20 bytes. Usando el smil planteado, la fragmentacin
externa correspondera a una situacin en la que queda una zona libre entre dos apartamentos, pero
que es tan pequea que no sirve para ser alquilada.
Fragm entacin in tern a. Algunas estrategias de gestin asignan a una solicitud de reserva un espa
cio mayor que el pedido. El fragmento no utilizado no se transforma en un hueco, sino que se man
tiene con el resto del bloque. En el ejemplo, se le asignara un apartamento de mayores dimensiones
que las requeridas.
Hay que resaltar que el tipo de fragmentacin asociado a un determinado esquema de gestin de memo
ria es un aspecto clave del mismo. Para incidir ms en las diferencias entre ambos tipos de fragmentacin,
considrense las dos opciones que existen cuando una reserva usa un hueco mayor de lo requerido. Si se opta
por generar un hueco con el espacio sobrante (fragmentacin externa), en caso de que no se use ese hueco
mientras se mantiene la reserva, cuando sta se libere, se volver a obtener el hueco original. Por tanto, se ha
incurrido en la sobrecarga de la generacin y compactacin de hueco sin sacarle ningn provecho. En caso
contrario, es decir, si no se genera hueco con el espacio sobrante (fragmentacin interna), se pierde la posibi
lidad de usarlo para satisfacer otras peticiones. Si este sobrante es muy pequeo, parece ms razonable no
generar hueco, dado que es improbable que se pueda usar (aunque podra ocurrir que s se usase al compac
tarse con un nuevo hueco adyacente surgido mientras se mantiene la reserva inicial), eliminando la sobrecar
ga asociada. Para evitar este problema, es habitual que en muchos esquemas de gestin de memoria no se
genere ningn hueco en caso de que el tamao de ste no supere un determinado umbral.
234
Figura 5.8 Fragmentacin extenia versus interna.

En la figura 5.8, se muestra cmo se satisfara una peticin de 70 bytes usando un hueco de 80 bytes: en
la parte superior derecha se ilustra qu ocurre si se asigna slo el espacio requerido (fragmentacin externa),
generando un hueco pequeo, mientras que en la parte inferior derecha se aprecia lo que sucede si se asigna
el hueco completo (fragmentacin interna), dejando el espacio sin usar dentro del bloque, que en la figura
aparece con un sombreado menos intenso.
En cuanto a la eficiencia, hay que tener en cuenta dos aspectos:
El tiempo de bsqueda de un hueco que satisfaga una determinada solicitud. Se buscarn algoritmos
que minimicen este tiempo de bsqueda.
El tiempo que conlleva el mantenimiento de la informacin del estado de la memoria. Cuando se
asigna un hueco para satisfacer una peticin, entre otras operaciones, hay que generar un hueco con
el espacio sobrante, en caso de que exista. De manera similar, cuando se libera un bloque, hay que
realizar una serie de operaciones de compactacin con los huecos adyacentes, en el caso de que los
haya. Todas estas operaciones tienen asociada una sobrecarga apreciable que hay que intentar mini
mizar. En el ejemplo planteado, correspondera a todo el trabajo relacionado con la instalacin y la
eliminacin de las paredes flotantes segn se van reservando y liberando apartamentos.
A lgoritm o de asignacin de espacio
Cuando se produce una solicitud de reserva de espacio, hay que seleccionar qu hueco utilizar entre los exis
tentes en ese instante. Existen cuatro estrategias bsicas:
E l m ejor ajuste (best fit). Se elige el hueco ms pequeo que satisfaga la peticin. A priori, puede
parecer la mejor solucin. Sin embargo, tiene algunos inconvenientes. Por un lado, se pueden gene
rar huecos muy pequeos, lo que puede favorecer la fragmentacin externa. Por otro lado, la selec
cin del mejor hueco exige comprobar cada uno de ellos, lo que alarga considerablemente la
bsqueda, o requiere mantenerlos ordenados por tamao, lo que complica las operaciones de mante
nimiento de la informacin de estado.
El peor ajuste (worst fit). Se elige el hueco ms grande. Con ello se pretende que no se generen
huecos pequeos. Sin embargo, sigue siendo necesario recorrer toda la lista de huecos o mantenerla
ordenada por tamao. Las pruebas empricas muestran que es una estrategia de poca utilidad. Entre
otros problemas, tiende a hacer que desaparezcan los huecos grandes, que se necesitarn para servir
peticiones de gran tamao.
El p rim ero que ajuste (first fit). Aunque pueda parecer sorprendente a priori, sta suele ser la mejor
poltica en muchas situaciones. Es eficiente, ya que basta con encontrar una zona libre de tamao su
ficiente, y proporciona un aprovechamiento de la memoria aceptable.
Gestin de memoria
235
El prxim o que ajuste (next fit). Se trata de una pequea variacin del first fit, tal que cada vez que
se realiza una nueva bsqueda se consideran primero los huecos que no se analizaron en la bsqueda
previa, y se usa el primero de ellos que encaje. De esta forma, se va rotando entre los huecos dispo
nibles a la hora de satisfacer las peticiones sucesivas. Esta estrategia distribuye de manera ms uni
forme las reservas a lo largo de la memoria, lo que puede ser beneficioso en ciertos problemas de
gestin de memoria.
Gestin de la inform acin de estado
Para poder gestionar el espacio de almacenamiento en cuestin, es necesario mantener informacin sobre el
estado del mismo, identificando los bloques y huecos existentes, y organizando la informacin de estos lti
mos en algn tipo de estructura de datos que permita un uso eficiente, tanto en las operaciones de reserva
como de liberacin.
Un primer aspecto a tener en cuenta es dnde se almacena esta informacin de estado, presentndose
dos posibilidades: usar alguna zona de memoria ajena al espacio de almacenamiento que se est gestionando
(en el ejemplo planteado, supngase que se utiliza un mueble archivador para guardar la informacin sobre
los apartamentos alquilados y el espacio libre disponible, y que este mueble est almacenado en una estancia
externa a la nave) o utilizar el espacio de cada bloque y cada hueco para almacenar su informacin (en el
ejemplo, la informacin sobre cada apartamento ocupado y cada espacio libre se guarda en la propia zona,
ocupando parte del espacio de la misma). Ntese que si se usa la opcin del almacenamiento interno, el espa
cio asignado a una peticin debe ser mayor que el solicitado para poder incluir la informacin del estado del
mismo, aunque, por otro lado, si se trata de un hueco, la informacin de estado no consume un espacio til. A
lo largo del captulo, se presentan esquemas de ambos tipos.
Con independencia de si se almacena la informacin de estado interna o externamente, existen mlti
ples alternativas a la hora de elegir qu estructura de datos se va a utilizar para mantener el conjunto de hue
cos disponibles en cada momento. A continuacin, se analizan las tres opciones ms habituales: lista nica,
mltiples listas y mapas de bits.
La solucin ms usada consiste en enlazar los huecos disponibles en una nica lista (si la informacin
de estado se almacena externamente, ms que de huecos, se trata de una lista de nodos tal que cada nodo con
tiene informacin de un hueco; tambin se requerira en este caso una lista de bloques). Habitualmente, se
trata de una lista doblemente encadenada y ordenada. Existen mltiples criterios a la hora de ordenar la lista,
entre los que se encuentran los siguientes: por la direccin de comienzo de cada hueco, el ms habitual ya
que facilita la gestin, por el tamao de los huecos, que sera apropiado para una poltica del mejor ajuste, en
orden LIFO (ltimo hueco generado es el primero usado), que puede generar un mejor uso de la cach. Ini
cialmente, toda la memoria disponible formar un nico hueco. Para satisfacer una peticin* hay que recorrer
la lista buscando el hueco adecuado de acuerdo con el algoritmo de asignacin de espacio usado,, que podr
ser cualquiera de los cuatro algoritmos presentados anteriormente. Si se genera un espacio sobrante, se in
cluir en la lista en la posicin que le corresponda segn el orden establecido. Cuando se libere un bloque, se
crear un hueco con ese espacio, compactndolo con los huecos adyacentes, en caso de que los haya. Como
se puede apreciar, esta estrategia sufre de fragmentacin extema. Este esquema ofrece un tiempo de bsque
da de un hueco proporcional al tamao de la lista de huecos. Por otro lado, en caso de usarse en un sistema
multiprocesador, la bsqueda en la lista nica puede convertirse en un cuello de botella al requerir un acceso
sincronizado.
En la figura 5.9 se muestra un ejemplo del uso de este esquema con una poltica del prximo que ajuste,
un almacenamiento interno de la informacin de estado y una lista circular unidireccional ordenada por las
direcciones de comienzo de los huecos. En los primeros cuatro bytes de cada bloque y de cada hueco, se al
macena su tamao en bytes, excluyendo esos cuatro bytes. En el caso de los huecos, en los 4 siguientes bytes
se almacena el puntero que hace referencia al siguiente hueco de la lista. Para implementar la poltica del
prximo que ajuste, se mantiene un puntero {prximo) que indica cul es el siguiente hueco a considerar a la
hora de satisfacer una peticin. En la parte superior de la figura se muestra el estado de una zona de 64 bytes
(se trata de un ejemplo a pequea escala) que tiene dos huecos (dibujados en blanco) de 12 bytes y dos blo
ques (dibujados como sombreados) de 20 y 4 bytes, respectivamente. Suponga que en esta situacin se pro-
236

Prximo
F ig u ra 5.9 Ejemplo de uso de un esquema basado en una nica lista.

duce una solicitud de 4 bytes. En la parte inferior de la figura se muestra cmo queda la memoria despus de
servir esta peticin.
Para mejorar el tiempo de bsqueda y el comportamiento en un sistema multiprocesador de la solucin
basada en una nica lista, una alternativa es usar mltiples listas, de manera que cada lista mantenga huecos
de un determinado tamao o, para reducir el nmero de listas, de un intervalo de tamaos. Este esquema
complica la lgica de gestin, pero puede agilizar la bsqueda al dirigirse directamente a la lista con los hue
cos del tamao adecuado, permitiendo, adems, mayor paralelismo en caso de usar un multiprocesador. Por
lo dems, el modo de operacin es similar al uso de una sola lista. Inicialmente, todo el espacio formar un
nico hueco en la lista de tamao mximo. Ante una solicitud de memoria, se busca un hueco adecuado en la
lista cuyo intervalo incluya al tamao solicitado, utilizando cualquiera de los cuatro algoritmos de asignacin
de espacio. En caso de haberlo, se usa para satisfacer la peticin y, si hay espacio sobrante, se genera un hue
co que se incluir en la lista acorde con su tamao (hay fragmentacin externa). Si no encuentra un hueco
vlido en la lista que corresponde, ya sea porque est vaca o porque ninguno de los huecos incluidos tiene un
tamao suficiente, se busca en la lista del siguiente tamao, y as sucesivamente hasta que se pueda encontrar
un hueco vlido para satisfacer la peticin. Al liberar un bloque, hay que comprobar si el hueco resultante
puede compactarse con los huecos adyacentes, en caso de que los haya, que podrn pertenecer a distintas
listas. Despus de la posible compactacin, se incluir en la lista pertinente.
En la figura 5.10 se muestra un ejemplo de este esquema aplicado a una zona de 64 bytes utilizando lis
tas de huecos de tres intervalos: huecos con un tamao menor o igual que 16; huecos con un tamao mayor
que 16 y menor o igual que 32; y huecos con un tamao mayor que 32 bytes hasta el mximo valor posible.
Inicialmente, como muestra la parte superior de la figura, todo el espacio est libre y forma un hueco en la
lista de mayor tamao. En los primeros cuatro bytes de cada bloque y de cada hueco, se almacena su tamao
en bytes, excluyendo esos cuatro bytes. Por tanto, el espacio til mximo en los huecos de cada lista es de 12,
28 y 60, respectivamente. En el caso de los huecos, en los 4 siguientes bytes se almacena el puntero que hace
referencia al siguiente hueco de la lista. La parte central de la figura muestra qu sucede cuando se sirve una
peticin de 36 bytes. Para servir esta peticin se buscara en la lista que corresponde al tamao pedido, en
este caso sera la de los huecos de mayor tamao. Dado que hay un hueco adecuado en esta lista, se le asigna
generando un hueco de un tamao til de 20 bytes, que se inserta en la lista correspondiente, como se puede
apreciar en la figura. En la parte inferior de la figura, se muestra cul sera el estado resultante despus de
satisfacer una peticin de 8 bytes. En este caso, la lista correspondiente, la de los huecos ms pequeos, est
vaca, por lo que hay que buscar sucesivamente en las siguientes listas. En el ejemplo planteado, hay un hue
co apropiado en la lista siguiente, que ser asignado, generndose un hueco de un tamao til de 8 bytes, que
se inserta en la lista correspondiente, como puede verse en la figura.
El esquema analizado se puede catalogar como de mltiples listas con huecos de tam ao variable.
Sin embargo, dentro del uso de mltiples listas, hay otras alternativas que usan huecos de tamao fijo. Se
trata de esquemas con un grado elevado de fragmentacin interna, pero muy eficientes, ya que eliminan, o
Gestin de memoria
237
F igura 5.10 Ejemplo de uso de un esquema basado en mltiples listas.

reducen considerablemente, la sobrecarga asociada a la generacin y compactacin de huecos. Sern de utili
dad cuando se intente primar la eficiencia sobre el aprovechamiento de espacio o cuando se conozca a priori
que el tamao habitual de las peticiones encaja con el asignado a las listas. A continuacin, se presentan dos
esquemas de este tipo, que son de inters puesto que a ellos se har referencia a lo largo del captulo.
El p rim e r esquema se puede denominar m ltiples listas con particiones estticas. A diferencia del es
quema anterior, en este caso, ante una solicitud de reserva, se consulta la lista del tamao correspondiente y
se usa el primer hueco de la misma, pero asignndolo completo (hay, por tanto, fragmentacin interna).
Cuando no hay un hueco en la lista que corresponde, se busca un hueco sucesivamente en las listas de los
siguientes niveles y se usa, pero sin generar un hueco sobrante, retomndolo a la misma lista cuando se libe
re. Inicialmente, el espacio estar dividido en varios huecos de cada uno de los tamaos existentes, a criterio
del administrador de ese espacio. En esta solucin, un determinado hueco pasar de estar libre a ocupado y
viceversa, pero siempre mantendr su tamao y estar asociado a la misma lista. Usando el smil del alquiler
de apartamentos, tendramos una estrategia en la que la nave est dividida a priori en apartamentos de distin
tos tamaos, que se mantendrn as todo el tiempo, ocupndose y liberndose segn se vayan solicitando. El
principal mrito de este esquema es su sencillez y eficiencia, ya que elimina la sobrecarga asociada a la gene
racin y compactacin de huecos, pero con el coste de una elevada fragmentacin interna al tener que usar a
veces huecos de listas que no corresponden con el tamao solicitado. En el peor de los casos, puede ser nece
sario utilizar un hueco del mximo tamao para satisfacer una peticin de tamao mnimo. Puede ser una
opcin interesante en situaciones en las que prime la eficiencia frente al aprovechamiento del espacio. Asi
mismo, puede resultar conveniente en escenarios donde el tamao de las solicitudes de memoria se distribuye
normalmente en ciertos intervalos habituales, ya que, en ese caso, se pueden establecer los tamaos de las
listas de acuerdo con dichos valores.
En la figura 5.11 se muestra un ejemplo de este esquema aplicado a una zona de 64 bytes utilizando lis
tas de huecos de tamao 8 y 16 bytes. Inicialmente, se establece que hay dos huecos de 8 bytes y dos de 16.
En los primeros cuatro bytes de cada bloque se almacena su tamao en bytes, excluyendo esos cuatro bytes,
; .V;
4
SI M
:S?y r/i':
V jv
'P r
i'
4
'
.fe
' <
Figura 5.11 Ejemplo de uso de un esquema de mltiples listas con particiones estticas.
por lo que, realmente, las listas tienen un tamao til de 4 y 12 bytes, respectivamente. En cuanto a los hue
cos, no es necesario almacenar su tamao al ser ste fijo. Slo se precisa guardar en los primeros cuatro bytes
el puntero que hace referencia al siguiente hueco de la lista de ese tamao. El estado de partida de la figura,
que corresponde con la parte superior, representa una situacin en la que se han reservado dos bloques de
tamao 4 y uno de tamao 8, que se ha redondeado a 12 para encajar en el tamao de una de las listas, provo
cando una fragmentacin interna de 4 bytes, que en la figura se representa con un sombreado de menor inten
sidad. En la parte inferior de la figura, se muestra cul sera el estado resultante despus de satisfacer tres
peticiones adicionales de 4 bytes. Como puede apreciarse, al agotarse los huecos del tamao adecuado, se ha
usado uno de tamao 16, provocando una fragmentacin interna de 8 bytes, nuevamente mostrada en la figu
ra con un sombreado de menor intensidad.
El segundo esquema de este tipo se denomina sistem a buddy binario (hay otro algoritmo buddy basado
en la secuencia de nmeros de Fibonacci, que queda fuera de esta exposicin). Este esquema intenta reducir
el nivel de fragmentacin interna presente en el anterior, permitiendo que se generen huecos con el espacio
sobrante cuando se usa un hueco de una lista de mayor tamao que el requerido, pero manteniendo ciertas
restricciones que aseguran que el nivel de sobrecarga asociado a la gestin de los huecos sea muy limitado.
En este esquema la lista de tamaos sigue una secuencia de potencias de 2, desde un tamao mnimo de 2M
hasta uno mximo de 2N (siendo N>M). Cuando se produce una solicitud, el tamao de las peticiones se re
dondea por exceso al ms cercano. Como ocurra en la solucin previa, si hay un hueco en la lista del tamao
correspondiente, se asigna completo, producindose fragmentacin interna, y si no lo hay, se busca un hueco
sucesivamente en las listas de los siguientes niveles, y se usa. La diferencia es que en este caso s se genera
un hueco con el espacio sobrante y, adems, que cuando el bloque se libere, se intentar compactar con los
posibles huecos adyacentes. Sin embargo, esta gestin de huecos se realiza con unas ciertas restricciones, que
reducen sensiblemente su complejidad.
A continuacin, se explica brevemente el modo de operacin de este algoritmo mostrando cmo se lle
van a cabo las operaciones de reserva y de liberacin de espacio:
Inicialmente, toda la zona de memoria est, evidentemente, libre y, por tanto, estar incluida como
huecos en la lista correspondiente al tamao mximo (2N).
Cuando llega una peticin y no hay huecos libres en la lista que corresponde (tamao 2P), se busca
en la lista siguiente (tamao 2P+I).
Si hay un hueco en esa lista, se rompe en dos partes: el fragmento de direccin ms baja (al que lla
maremos parte inferior) se usa para satisfacer la peticin, mientras que el otro fragmento (al que de
nominaremos parte superior), se incluye en la lista pertinente (la de tamao igual a 2P). En caso de
que no lo haya, se busca en la siguiente lista (tamao 2P+3).

Si se encuentra un hueco en esa lista, que tendr un tamao que es cuatro veces el necesitado, se
rompe en dos: la parte superior se incluye en la lista correspondiente a su tamao (tamao 2P+I),
mientras que la inferior se rompe, a su vez, en dos, usndose la parte inferior para satisfacer la solici
tud e incluyendo la parte superior de esta parte inferior en la lista de huecos adecuada (tamao 2P).
Dicho de otra manera, el primer cuarto del hueco se usa para la peticin, el segundo cuarto se con
vierte en un hueco de tamao 2P y los dos ltimos cuartos (la segunda mitad) se mantienen unidos
como un hueco de tamao 2P+1.
En caso de no encontrar hueco en la lista de tamao 2/>+, se pasara a la siguiente, donde, si hay hue
co, se usara su primera octava parte, generndose tres huecos: uno del tamao de una octava parte
del hueco, otro de la cuarta parte y un ltimo de la mitad de tamao. En caso de no haberlo, se pasar
a a la siguiente lista, y as sucesivamente hasta encontrar un hueco.
Cuando se libera un hueco, se intenta realizar una compactacin, pero no con las dos partes adyacen
tes. Si el nuevo hueco corresponde a una parte inferior, slo se comprobar si est libre la parte supe
rior correspondiente, para, si es as, llevar a cabo la compactacin. En cambio, en caso de que el
nuevo hueco sea una parte superior, nicamente se comprobar el estado de la parte inferior corres
pondiente para una posible compactacin. Ntese que, aunque haya dos huecos contiguos, slo se
compactarn si son las dos partes de un hueco de nivel superior, es decir, que lo que se hace en este
caso es fundir dos huecos que provienen de la divisin en dos partes de un hueco de nivel superior
que se us para satisfacer una determinada solicitud.
Si se produce compactacin, se genera un nuevo hueco de nivel superior, que podr ser la parte supe
rior o inferior de un hueco del siguiente nivel. Por tanto, se repetir el intento de compactacin com
probando el estado de la parte complementaria (inferior o superior, respectivamente), y as
repetidamente en los sucesivos niveles, hasta que no haya compactacin.
Es interesante resaltar que este esquema distingue entre los huecos contiguos que se pueden fusionar (si
son la parte inferior y superior de un hueco del siguiente nivel) y los que no (si son la parte superior e inferior
de distintos huecos del siguiente nivel), y esto es lo que da nombre al algoritmo, puesto que se puede consi
derar que los huecos que s se pueden fusionar son amiguetes (buddy).
Para entender por qu motivo este esquema es muy eficiente y tiene una sobrecarga asociada a la ges
tin de los huecos muy baja, hay que tener en cuenta que el uso de potencias de dos como tamaos de las
listas, as como la forma de partir los huecos y el permitir que slo se fusionen los amiguetes, garantiza que
todos los huecos generados tienen un tamao que coincide exactamente con una de las listas existentes. Asi
mismo, hay que resaltar que, dada la direccin de comienzo de un hueco (o mejor dicho, su desplazamiento
desde el inicio de la zona de memoria gestionada), el clculo de cul es el amigete, necesario para com
probar si hay que realizar una compactacin, es trivial. As, si se toma como ejemplo una lista de tamao 64
(26), las direcciones de comienzo, expresadas como el desplazamiento desde el inicio de la zona, de los cua
tro posibles primeros huecos sern:
Primero 0..00000000; Segundo 0..01000000; Tercero 0..10000000; Cuarto 0..11000000
Si nos fijamos en las direcciones, podemos apreciar que dos huecos amiguetes, como el primero y el
segundo, o el tercero y el cuarto, se diferencian en el bit sexto (considerando el bit de menor peso como el bit
0), que es justo la posicin correspondiente al tamao de la lista. Por tanto, bastar con invertir ese bit en la
direccin de comienzo de un hueco para encontrar a su amigete.
Este esquema presenta un nivel de fragmentacin interna considerable, aunque mucho menor que el de
particiones fijas. Con este esquema, en el peor de los casos, se desperdicia un espacio ligeramente menor que
el tamao de los huecos de la lista anterior a la usada. Ese peor caso, correspondera a una peticin que tenga
justamente un tamao que exceda ligeramente el valor de una potencia de 2. Esa peticin no podra usar la
lista correspondiente a esa potencia, sino que utilizara la siguiente, que es el doble de grande, malgastndose,
por tanto, casi la mitad del hueco asignado. As, por ejemplo, a una peticin de tamao 36 se le asignara un
hueco de tamao 64 desperdicindose 28 bytes, que es un valor ligeramente inferior que el tamao de los
huecos de la lista anterior, es decir, 32 bytes.
En la figura 5.12 se muestra un ejemplo de este esquema, aplicado a una zona de 64 bytes, utilizando
listas de huecos de tamao 8, 16 y 32 bytes. Como ocurra en la solucin anterior, en los primeros cuatro by-
240
iU
F ig u ra 5.12 Ejemplo de uso del sistema buddy binario.

tes de cada bloque se almacena su tamao en bytes, excluyendo esos cuatro bytes, por lo que, realmente, las
listas tienen un tamao til de 4, 12 y 28 bytes, respectivamente. Por lo que se refiere a los huecos, slo se
necesita guardar en los primeros cuatro bytes el puntero que hace referencia al siguiente hueco de la lista de
ese tamao. La parte superior de la figura representa el estado inicial de la zona, con dos huecos de 32 bytes.
La parte intermedia ilustra el estado del sistema despus de satisfacerse una peticin de 4 bytes, que ocupar
un espacio real de 8 bytes. Ntese que, dado que no hay huecos en las listas de 8 ni de 16, hay que usar uno
de la lista de 32, rompindolo en tres partes: la primera parte de tamao 8 se usa para satisfacer la peticin; la
segunda parte de tamao 8 se convierte en un nuevo hueco que se inserta en la lista correspondiente; la terce
ra parte de tamao 16 se transforma en un nuevo hueco que se incorpora en la lista de ese tamao. A conti
nuacin, suponga que se produce una peticin de 10 bytes, que, redondeando por exceso, corresponde a la
lista de tamao 16, en la que hay un hueco disponible. Se le asignar completo, como se muestra en la parte
inferior de la figura, producindose fragmentacin interna, que en la figura se muestra con un sombreado
menos intenso. Si, acto seguido, se libera este bloque, se volver a la situacin reflejada en la parte interme
dia de la figura, sin producirse compactacin entre huecos al no ser amiguetes. Por ltimo, si, a continua
cin, se libera el bloque reservado inicialmente, se producir una doble compactacin (primero, una fusin de
los huecos de tamao 8 en uno de 16, y luego del hueco resultante de esa primera compactacin con el hueco
de 16 ya existente), volviendo al estado inicial mostrado en la parte superior de la figura.
La figura 5.13 muestra los posibles huecos del ejemplo correspondiente a la figura 5.12 como un rbol
binario (lo cual es lgico, al tratarse de un sistema buddy binario). En la figura se puede volver a apreciar
cmo las direcciones relativas de comienzo de dos huecos amiguetes slo se diferencian en un bit. Tam
bin se aprecia claramente qu relacin tiene que haber entre dos huecos contiguos para que se puedan fusio
nar: deben ser hijos del mismo nodo padre en el rbol.
II
Gestin de memoria
241
Huecos de tamaa 32
looooool lioooool
Huecos de tamao 16
joooooo! loiooool 1100*0001 liiooool

looooool looioool loiooool loiioool lioooool [ooool liiooool [iiioool
Huecos de tamao 8
Figura 5.13 Arbol binario correspondiente al ejemplo de la figura 5.12.

Resumiendo, se trata de un esquema eficiente, pero con un nivel de fragmentacin interna apreciable
(en promedio, la mitad del hueco asignado se desperdiciara), aunque considerablemente menor que en el
esquema de particiones fijas. Ms adelante, veremos ejemplos reales del uso de este esquema.
La ltima solucin planteada son los m apas de bits. Se trata de una estructura de datos en la que cada
bit refleja si est libre u ocupado (por ejemplo, con los valores 0 y 1, respectivamente) el elemento de memo
ria cuyo estado representa. Normalmente, esta estructura se almacenar de forma extema. La gestin de soli
citudes es bastante sencilla usando este esquema. Para satisfacer una peticin de un determinado tamao, se
buscar en el mapa una secuencia de ceros suficientemente grande, usando cualquiera de los cuatro algorit
mos de asignacin de espacio presentados anteriormente. Al liberar un bloque, se marcarn como ceros los
bits correspondientes, producindose de forma automtica la compactacin.
El problema de esta solucin es que la informacin de control puede consumir un espacio significati
vamente mayor que el usado en las soluciones basadas en listas. Obsrvese que si cada bit del m apa represen
ta el estado de una unidad de espacio, suponiendo que el tamao mnimo fuera 4 bytes, la informacin de
estado de los huecos consumira aproximadamente un 3% del espacio disponible. Adems, habra que alma
cenar externamente una lista de bloques, que describiera dnde comienza cada bloque y qu tamao tiene.
Sin embargo, hay que resaltar que si el tamao mnimo es suficientemente grande (por ejemplo, una pgina),
puede resultar una solucin aceptable.
En la figura 5.14 se muestra el uso de un mapa de bits para controlar el estado de una zona de 256 by
tes, de manera que cada bit controla el estado de una unidad mnima de asignacin de 4 bytes. En la zona hay
un bloque de 96 bytes y dos huecos de 64 y 96 bytes, respectivamente. Como se puede observar, se trata de
un esquema con almacenamiento extemo de la informacin de estado. En el ejemplo, para mantener el estado
de una zona de 256 bytes se han usado 8 bytes. Si se hubiera usado una nica lista con almacenamiento de
estado interno, se habran gastado 4 bytes, correspondientes a la cabecera del bloque. Obsrvese que en ese
caso el bloque tendra un tamao de 92 bytes, en vez de 96, debido a dicha cabecera.
Hay que resaltar que, por limitaciones de espacio, hay numerosos aspectos del problema general de la
asignacin de memoria que no se han tratado en esta seccin, puesto que se podra dedicar todo un captulo a
estudiarlo. De todas formas, a continuacin, se comenta uno de estos aspectos, por considerarlo de especial
inters: la com pactacin diferida. Para minimizar la sobrecarga asociada a la generacin y compactacin de
huecos en los esquemas basados en una o ms listas, cuando se produce un nuevo hueco, se puede diferir su
posible compactacin un cierto intervalo de tiempo. As, se facilita la reutilizacin directa del hueco y se
pueden compactar mltiples huecos simultneamente, lo que puede implementarse de manera ms eficiente.
Para entender la mejora, suponga que la secuencia de operaciones solicitadas consiste en reservar un espacio
de un cierto tamao, luego liberarlo, a continuacin volver a pedirlo y, despus, liberarlo, y as de forma re
petida. La compactacin diferida eliminar la sobrecarga de generacin y liberacin de huecos ante un patrn
de peticiones de estas caractersticas.
. .. .
OOOOOOOOOOOOOOOOllllllllllllllllllllllllOOOOOOOOOOOOOOOOOOOOOOOG
Figura 5.14 Ejemplo de uso de un esquema de mapa de bits.
242
Para terminar esta seccin, se expone una consideracin sobre los niveles mltiples de gestin de me
moria. Retomando el ejemplo planteado del alquiler de apartamentos, supngase que una persona que ha al
quilado un apartamento se plantea, a su vez, compartimentarlo en habitaciones y alquilarlas a terceros. Se
tratada de una situacin en la que existiran dos niveles de gestin de memoria. En cada uno de ellos, se
podra usar un esquema distinto. Por ejemplo, el propietario de la nave podra realizar una asignacin din
mica similar al esquema de lista nica, mientras que el que pretende realquilar su apartamento podra hacer
una particin esttica de habitaciones. Es interesante resaltar cmo cambia la visin sobre el estado de una
zona dependiendo desde qu nivel se contemple. As, una habitacin de un apartamento que no ha sido real
quilada est libre para la persona que tiene alquilado el apartamento, pero, sin embargo, est ocupada desde
el punto de vista del propietario de la nave, como parte del apartamento que es. Esta consideracin se puede
aplicar a cualquier sistema donde existan mltiples niveles de gestin de memoria.
5.2.5. El largo camino del acceso sim blico al real

El cdigo de un programa hace referencia a variables (miembros de datos, en terminologa de programacin
orientada a objetos) y a funciones (mtodos, en dicha terminologa). Por otro lado, en tiempo de ejecucin el
programa genera accesos a memoria usando las direcciones pertinentes. Una de las funciones principales del
sistema de gestin de memoria es realizar este proceso de traduccin desde el acceso simblico hasta el real.
En esta seccin se intenta caracterizar dicho proceso, introduciendo una notacin original para modelarlo, de
manera que sirva como un marco de referencia para clasificar los diversos esquemas de gestin de memoria
que se estudiarn a lo largo del captulo. Pedimos un poco de paciencia al lector, ya que es bastante probable
que en una primera toma de contacto con esta seccin no alcance a entender completamente la utilidad de
esta notacin y que, incluso, le resulte engorrosa. Sin embargo, creemos que merece la pena porque va a faci
litar la comprensin del resto del captulo, permitiendo entender mejor en qu se diferencian las distintas es
trategias de gestin de memoria.
A priori, puede parecer que este proceso de traduccin es bastante directo: el sistema de compilacin
(compilador y montador) asigna una direccin de memoria a cada smbolo, y asunto resuelto. Sin embargo,
como se analiza a continuacin, el proceso es algo ms complejo y el camino de transformacin es algo ms
largo y tortuoso.
Consideremos un determinado programa compuesto de varios mdulos de cdigo escrito en un lenguaje
de alto nivel. Prestemos atencin a un determinado mdulo en el que se incluye una referencia a un smbolo S
(variable o funcin), que normalmente consistir en un identificador alfanumrico que lo distingue de manera
nica. Ahora supongamos que un proceso P est ejecutando ese programa, concretamente, la instruccin que
contiene esa referencia en el cdigo fuente original. En tiempo de ejecucin, la memoria fsica recibir una
direccin D/, pero, cmo se ha llegado a este valor desde el acceso original?
[P,
s]
[Df ]
La primera etapa de este proceso es la resolucin de smbolos, que determina en qu mdulo M est
definido el smbolo referenciado (S), as como con qu direccin D m dentro del contexto del mdulo se co
rresponde (generalmente, los smbolos definidos en un mdulo tendrn asignadas direcciones entre 0 y un
valor mximo).
[p, s ]
-> [p, M, Dm]
Esta etapa de resolucin ser igual en todos los esquemas de gestin de memoria: el compilador, si el
smbolo est definido en el mismo mdulo, o el montador, en caso de estar definido en otro mdulo, se en
cargarn de la misma, excepto si hay montaje dinmico (vase la seccin 5.3.3), donde la resolucin se reali
za en tiempo de ejecucin. Terminada esta fase, falta todava el resto del proceso de traduccin:
[P, M, D] -
[D]
En esa expresin se puede apreciar que se trata de una transformacin de un espacio tridimensional (la
direccin Dm corresponde al mbito del mdulo M, que, dado que puede haber mltiples activaciones del
Gestin de memoria
243
Espacio destino 1
Espacio origen '
600
Espacio destino 2
Espacio origen 2
100
F igura 5.15 Ejemplos de reubicacin lineal y no lineal.

mismo programa ejecutndose simultneamente, est englobado en el contexto del proceso P) en uno unidi
mensional (la memoria).
Esta transformacin de aplanamiento dimensional va a conllevar varias etapas que se aplicarn en las
distintas fases por las que pasa un programa desde su creacin hasta su ejecucin (compilacin, montaje, car
ga y ejecucin, que se analizarn con mayor profundidad ms adelante). Sin embargo, dependiendo de cmo
sea la solucin elegida, el reparto de las etapas de transformacin entre las fases de procesamiento del pro
grama puede ser diferente. En esta seccin se identifican las etapas del proceso de transformacin y en el
resto del captulo, por cada esquema de gestin de memoria presentado, se explicar en qu fase se lleva a
cabo cada una de las etapas identificadas.
Las etapas de transformacin estn basadas en el concepto de reubicacin, comentado anteriormente.
La reubicacin es una funcin que transforma (traduce) un conjunto de direcciones contiguas situadas en un
espacio origen en otro conjunto de direcciones englobadas en un espacio destino, donde pueden ser contiguas
(reubicacin lineal) o no (reubicacin no lineal).
Reubicacin(D) - D'
En algunos casos, la funcin de reubicacin puede ser slo aplicable a un subconjunto de las direccio
nes del espacio origen, generando un error -cuando se utiliza con una direccin que no pertenece al subcon
junto de direcciones vlidas (como veremos adelante, esta circunstancia ser til para proporcionar un
soporte adecuado a las regiones de un proceso):
Reubicacin(D) > D' kj Error
La funcin de reubicacin puede ser tan sencilla como sumar a toda direccin un determinado despla
zamiento, lo que hara que en el espacio destino las direcciones se mantuvieran contiguas (reubicacin line
al), o mucho ms compleja, sin mantener la contigidad (reubicacin no lineal), pudiendo requerir para poder
ser aplicada una tabla de correspondencias entre valores de entrada y de salida, como ocurre con la pagina
cin, que se estudiar ms adelante. A pesar de su mayor complejidad, la reubicacin no lineal presenta ven
tajas en ciertas situaciones, ya que favorece un mejor aprovechamiento de la memoria al no requerir
contigidad en el espacio destino (como se ver ms adelante, esto es especialmente beneficioso en el nivel
de procesos). En la figura 5.15 se muestran dos ejemplos de funciones de reubicacin: la funcin aplicada al
primer espacio origen es de carcter lineal y se tratara de un simple desplazamiento de 100 unidades, mien
tras que la utilizada en el segundo espacio origen es no lineal.
Ese tipo de reubicacin, a la que denominaremos reubicacin simple, hace corresponder un nico es
pacio origen con un espacio destino. Sin embargo, para realizar el aplanamiento de la direccin, es necesario
establecer una correspondencia entre mltiples espacios origen y un destino, de forma que la funcin de
transformacin no slo dependa de la direccin D, sino tambin del espacio origen (es decir, del contexto C)
donde est definida, dando como resultado una direccin D independiente de ese contexto:
Reubicacin(C,
D)
>
D'
244

o
Espacio origen 1
Espacio destino
600
400
Figura 5.16 Ejemplo de reubicacin basada en contexto.

La transformacin provoca que desaparezca la informacin de contexto, produciendo un aplanamiento
del espacio de direcciones. A este tipo de reubicacin la denominaremos reubicacin basada en contexto.
En la figura 5.16 se muestra cmo se reubican dos espacios origen dentro de un espacio destino usando trans
formaciones lineales. Para realizar un aplanamiento de mltiples dimensiones ser necesario aplicar una se
cuencia de reubicaciones basada en contexto. La figura 5.17 muestra un aplanamiento de dos dimensiones,
usando primero una reubicacin basada en contexto de tipo lineal y, a continuacin, una de tipo no lineal.
En el caso que nos ocupa en esta seccin, se trata de una direccin tridimensional, una direccin especi
ficada en el mbito de un cierto mdulo que ejecuta en el contexto de un determinado proceso, que hay que
transformar en unidimensional. Este espacio tridimensional est vinculado con la existencia de mltiples ni
veles de gestin de memoria, concretamente, con los niveles de procesos y de regiones (el nivel de zonas no
est presente en todas las regiones y, normalmente, no lo gestiona el sistema operativo), presentados al prin
cipio del captulo. Usando el smil planteado del terreno urbanizable con edificios y apartamentos, se trata de
transformar una referencia a un determinado punto espacial situado en un cierto apartamento de un determi
nado edificio, expresada como sus coordenadas dentro de dicho apartamento, en una referencia dentro del
espacio urbanizable global. Podra ser algo como, por ejemplo, convertir la referencia al punto que est a 1
metro de la pared oeste y a 2 metros de la pared sur dentro del apartamento 3 del edificio 5 en una referencia
que indique que el punto est a 50 metros del linde oeste del terreno y a 200 metros del lmite sur del mismo.
Obsrvese que este ejemplo de proceso de transformacin pasara por un punto intermedio donde la referen
cia estara especificada en el contexto del edificio que la contiene (el punto que est a 5 metros de la pared
oeste y a 7 metros de la pared sur de la fachada del edificio 4). La figura 5.18 muestra estas dos fases en el
ejemplo del terreno urbanizable. Tngase en cuenta que en este ejemplo todas las reubicaciones son lineales,
ya que se supone, razonablemente, que un apartamento ocupa un espacio contiguo dentro de un edificio y que
el edificio se extiende por una zona contigua dentro del terreno. .
En el prrafo anterior hemos usado intencionadamente de forma ambigua los trminos mdulo y regin.
Qu relacin hay entre ambos trminos? El mdulo representa una unidad de compilacin independiente
gestionada por el sistema de compilacin. La regin se corresponde con una parte individualizada del mapa
de memoria de un proceso que es gestionada por el sistema operativo. Conceptualmente, cada mdulo podra
constituir una regin del proceso. Sin embargo, como se ver ms adelante, para optimizar el uso de recursos
por parte del sistema operativo, es habitual que se agrupen varios mdulos del programa en cada regin, jun
tando aqullos que tengan las mismas caractersticas (por ejemplo, la regin de cdigo contendr la agrupa
cin del cdigo de los distintos mdulos). Por tanto, podra considerarse que hay un nuevo nivel de gestin
de memoria: el nivel de mdulos. Sin embargo, dado que conceptualmente no representa un nivel de abstrac
cin diferente, sino que es una cuestin meramente organizativa, se ha preferido mantener la propuesta de
tres niveles presentada al principio del captulo.
La agrupacin de mdulos en regiones requiere una reubicacin basada en contexto (reubicacin de
mdulos), que asociar cada mdulo M con la parte de la regin R donde se incluir. Esta reubicacin suele
basarse en un simple desplazamiento lineal que provoca que la direccin Dm se transforme en Dr:
[P, M, D J - [P, R, Dr ]
Gestin de memoria
245
F ig u ra 5.17 Ejemplo de una secuencia de dos reubicaciones basadas en contexto.

Esta operacin puede apreciarse grficamente revisando nuevamente la figura 5.16, interpretando los
espacios origen como mdulos y el espacio destino como la regin donde se incluyen estos mdulos. Esta
etapa vuelve a ser igual en todos los esquemas de gestin de memoria, encargndose de ella el montador. Sin
embargo, las etapas que se presentarn a continuacin, pueden realizarse en distintas fases del procesamiento
del programa (montaje, carga o ejecucin), dependiendo de cul sea el esquema de gestin de memoria utili
zado.
Para convertir el espacio tridimensional en unidimensional, se requerirn dos reubicaciones basadas en
contexto sucesivas, tal que la primera elimina el contexto de la regin (reubicacin de regiones) y la segun
da el del proceso (reubicacin de procesos):
[P, R, Dr ]
[P, Dp]
[D]
En la primera etapa, se convierte la direccin D r, definida en el mbito de la regin R, que ejecuta en el

contexto del proceso P, en la direccin Dp dentro del contexto de dicho proceso. En la siguiente etapa se
transforma la direccin Dp del proceso en la direccin de memoria Df. Revisando la figura 5.17, se puede
apreciar esta operacin interpretando el dibujo como dos procesos con un par de regiones cada uno. En el
smil del terreno urbanizable, la primera transformacin hara que una referencia a un punto dentro de un
apartamento se convirtiera en una a un punto dentro del edificio correspondiente, mientras que la segunda
etapa situara la referencia dentro del contexto de todo el terreno urbanizable.
Recuerde que, como se coment al presentar los niveles de gestin de memoria, en algunos esquemas
de gestin de memoria el nivel de procesos y de regiones estn fusionados (as ocurre, como se ver ms ade
lante, en un sistema basado en segmentacin). En ese caso, las dos operaciones de aplanamiento se llevan a
cabo en la misma etapa (se tratara de una doble reubicacin basada en contexto).
[p, R, Dr ] -> [Df]
246

Edificio
Edificio
Edificio
1 U
Edificio
Terreno
Edificio
Edificio
Edificio
Edificio
Edificio
Figura 5.18 Ejemplo de transformacin de una referencia geogrfica.

Recapitulando, el camino que va desde el acceso simblico al real requiere una primera etapa de reso
lucin, seguida por tres etapas de reubicacin basada en contexto (de mdulos, de regiones y de procesos).
[P, S] -> [P, M, Dm] - [P, R, Dr]
[Df ]
[P, Dp]
En la mayora de los esquemas de gestin de memoria este es el camino de transformacin completo,

distinguindose entre s por la fase en la que est integrada cada etapa del proceso de transformacin. Sin
embargo, en algunos sistemas (como se ver ms adelante, esto ocurre con los sistemas de segmentacin pa
ginada global y con los que usan un espacio de direcciones nico), ese camino no completa el proceso de
transformacin, puesto que no se corresponde directamente con el espacio fsico, sino con un espacio lgico
global (en vez de una direccin fsica Df se tratara de una direccin en un espacio lgico global Dg). Es nece
saria, por tanto, otra etapa final de transformacin en la que se produce una reubicacin de la direccin sin
existir ningn contexto asociado (una reubicacin simple), a la que podemos denominar reubicacin global.
[Dg]
> [Df]
En consecuencia, el camino de transformacin resultante en este caso sena el siguiente:

[P ,
S]
[P ,
M,
D J
-> [ P ,
R,
Dr ]
[P ,
Dp] - [Dg]
->
[Df]
O bien, en caso de fusin de niveles:

[P ,
S]
[ P ( M,
DJ
[P( R, DJ
[D J
[Df]
Para terminar esta seccin, y aunque pequemos de ser un poco reiterativos, volvemos a aconsejar al lec
tor que no se desanime si no ha comprendido totalmente el sentido y la utilidad de esta notacin. Estamos
convencidos de que, segn vaya aplicndose a la hora de clasificar las distintas tcnicas de gestin de memo
ria, el lector llegar a entenderla y apreciarla.
5.3.
MODELO DE MEMORIA DE UN PROCESO
Esta seccin se centra en todos los aspectos relacionados con la gestin del mapa de memoria de un proceso
y las regiones incluidas en el mismo, abarcando todo el espectro que va desde la generacin del cdigo ejecu
table del programa hasta la propia ejecucin del mismo. Por tanto, los conceptos presentados en esta seccin
se corresponden directamente con lo que hemos identificado anteriormente como el nivel de regiones (y tam
bin con el de zonas, puesto que se analizar cmo se implementan aquellas regiones que engloban zonas
independientes, concretamente, la pila y el heap).
En primer lugar, se analizar cmo se implementan los distintos tipos de objetos de memoria requeridos
por los programas y cul es su correspondencia con el mapa de memoria del proceso, haciendo especial nfa
sis en la gestin de los datos de carcter dinmico. Acto seguido, dado que el mapa inicial de un proceso est
muy vinculado con el fichero que contiene el programa ejecutable asociado al mismo, se estudiar cmo es el
ciclo de vida de un programa, desde que se tiene escrito su cdigo fuente hasta su activacin y ejecucin,
pasando anteriormente por las fases de compilacin y montaje. Como parte de este estudio, se mostrar cmo
316
Tabla 5.1 Comparativa de los esquemas de gestin de la memoria del sistema.

E sq u em a de gestin
Registros lmite
Registro base y lmite
Segmentacin
Paginacin
Seg. paginada global
Seg. paginada local
SASOS
Resolucin/R.mdulos
Compilador/montador
Compilador/montador
Compilador/montador
Compilador/montador
Compilador/montador
Compilador/montador
Compilador/montador
R. regiones
R. procesos
Montador
Cargador
Montador
MMU
MMU (seg)
Montador
| MMU (pg)
MMU (seg)
MMU (seg)
MMU (pg)
Montador
Cargador
R. global
MMU (pg)
MMU (pg)
A claracin 5.7. En algunas arquitecturas, las direcciones que se usan para acceder a memoria (llamadas ca
pabilities), adems de la referencia a la posicin de memoria propiamente dicha, incluyen uno o ms bits de
informacin de proteccin, que, entre otras cosas, identifican que se trata de una direccin de acceso a memo
ria. El aspecto interesante de las capabilities es que slo se pueden modificar estando en modo privilegiado:
Por tanto, slo en dicho modo se pueden generar direcciones vlidas de acceso a memoria. Un proceso podr
usar las posiciones de memoria que le ha asignado el sistema operativo, puesto que ste le ha proporcionado
las capabilities requeridas para acceder a las mismas. Sin embargo, no podr acceder a otras direcciones,
puesto que la unidad de control del procesador asegura que una capability slo se puede modificar en modo
privilegiado. El mecanismo de capabilities asegura la proteccin requerida, permitiendo usar direcciones
fsicas directamente, lo que elimina el problema de las autorreferencias. La reubicacin necesaria se puede
realizar por software. El nico problema de este mecanismo, que ha limitado considerablemente su impacto,
es que requiere un procesador con una arquitectura muy especfica.__________________
x
Para terminar esta seccin, se plantea la tabla 5.1, que sirve de recapitulacin de la misma y muestra
una comparativa de los distintos esquemas de gestin de memoria estudiados, mostrando cmo se llevan a
cabo las distintas etapas identificadas en la seccin 5.2.5.
5.5.
M EM O RIA V IR TU A L
En prcticamente todos los sistemas operativos de propsito general actuales se usa la tcnica de memoria
virtual. Hasta el momento, por motivos pedaggicos, se han presentado los diversos esquemas de memoria
sin apenas hacer referencia a esta tcnica. En esta seccin se estudiar esta tcnica mostrando cmo se integra
con estos esquemas de gestin de memoria. En el primer captulo ya se presentaron los fundamentos de la
memoria virtual, explicando aspectos tales como la jerarqua de memoria o la proximidad de referencias, por
lo que no se volver a incidir en los mismos. Como se apreciar a lo largo de esta seccin, la memoria virtual
resuelve dos de los objetivos del sistema de memoria identificados al principio del captulo: ejecutar ms
procesos de los que caben en la memoria principal, y ejecutar un proceso cuyo mapa no cabe en la memoria.
Antes de la aparicin de la memoria virtual, esas dos necesidades ya existan y se intentaban resolver de la
mejor manera posible, teniendo en cuenta la tecnologa presente por entonces. Esta seccin, por tanto, co
m enzar presentando las tcnicas de intercambio y de overlays como precedentes de la memoria virtual. A
continuacin, se analizarn las diversas polticas de administracin de la memoria virtual, especialmente, las
estrategias de reemplazo y las polticas de reparto de la memoria entre los procesos.
5.5.1. Intercambio
Como se coment previamente, la tcnica del intercambio (swapping) signific en su momento una manera
de perm itir que en los sistemas del tiempo compartido existieran ms procesos de los que caben en memoria.
Gestin de memoria
317
Se puede considerar que se trata de un mecanismo antecesor de la memoria virtual. En este apartado se pre
sentarn de forma breve los fundamentos de esta tcnica.
El intercambio se basa en utilizar un disco o parte de un disco como respaldo de la memoria principal.
Esta zona de almacenamiento se denomina dispositivo de swap. Cuando no caben en memoria todos los pro
cesos activos (por ejemplo, debido a que se ha creado uno nuevo), se elige un proceso residente y se copia en
swap su imagen en memoria. El criterio de seleccin puede tener en cuenta aspectos tales como la prioridad
del proceso, el tamao de su mapa de memoria, el tiempo que lleva ejecutando y, principalmente, su estado.
Es preferible expulsar (swap out) procesos que estn bloqueados. Cuando se expulsa un proceso, no es nece
sario copiar toda su imagen al dispositivo de swap. Los huecos en el mapa no es preciso copiarlos, ya que su
contenido es intrascendente. Tampoco se tiene que copiar el cdigo, puesto que se puede volver a recuperar
directamente del ejecutable.
Evidentemente, un proceso expulsado tarde o temprano debe volver a activarse y cargarse en memoria
principal (swap in). Slo se deberan volver a cargar aquellos procesos que estn listos para ejecutar. Esta
readmisin en memoria se activar cuando haya espacio de memoria disponible (por ejemplo, debido a que
se ha terminado un proceso) o cuando el proceso lleve un cierto tiempo expulsado. Tngase en cuenta que al
tratarse de un sistema de tiempo compartido, se debe repartir el procesador entre todos los procesos. Por ello,
en numerosas ocasiones hay que expulsar un proceso para poder traer de nuevo a memoria a otro proceso que
lleva expulsado un tiempo suficiente.
La estrategia que decide cundo expulsar un proceso a swap y cundo reincorporarlo a memoria se co
rresponde con la planificacin a medio plazo presentada en el captulo 4.
En cuanto al dispositivo de swap, hay dos alternativas en la asignacin de espacio:
Con preasignacin: Al crear el proceso ya se reserva espacio de swap suficiente para albergarlo. Si
el proceso nunca se expulsa, se desperdicia el espacio asignado.
Sin preasignacin. Slo se reserva espacio de swap cuando se expulsa el proceso. Puede haber pro
blemas si se intenta expulsar un proceso a swap para traer a otro proceso y no hay espacio en el dis
positivo.
Un ltimo aspecto a tener en cuenta es que no debera expulsarse un proceso mientras se estn realizan
do operaciones de entrada/salida por DMA vinculadas a su imagen de memoria, ya que provocara que el
dispositivo accediera al mapa de otro proceso.
5.5.2. Overlays
En los tiempos en los que todava no se haba propuesto la tcnica de memoria virtual y las memorias tenan
una capacidad limitada, se presentaba con cierta frecuencia el problema de que un determinado programa no
cupiera en memoria. Para resolver dentro de lo posible este problema, se ide la tcnica de los overlays. Se
trataba de un esquema que no era transparente al programador, puesto que ste tena que determinar si ciertos
mdulos de su programa no requeran estar simultneamente en memoria en tiempo de ejecucin y que, por
tanto, podran usar la misma zona de memoria en distintas fases de ejecucin del programa. El programador
usaba un lenguaje de definicin de overlays para notificar al montador esta informacin. El montador gene
raba un fichero ejecutable en el que inclua automticamente cdigo para cargar y descargar los mdulos del
programa. En la llamada desde un mdulo a una funcin definida en otro mdulo, el montador inclua cdigo
que comprobaba si el mdulo destino estaba ya cargado en memoria. En caso de no estarlo, el cdigo inclui
do por el montador cargaba ese mdulo, usando para ello, si es necesario, el espacio ocupado por otro mdu
lo cuya presencia no se requiere segn indica la informacin suministrada al montador.
5.5.3. Fundamento de la memoria virtual

Como se estudi en el primer captulo, la memoria en un sistema est organizada como una jerarqua de nive
les de almacenamiento entre los que se mueve la informacin dependiendo de las necesidades de los procesos

en un determinado instante. La tcnica de memoria virtual se ocupa de la transferencia de informacin entre
la memoria principal y la secundaria. La memoria secundaria est normalmente soportada en un disco (o par
ticin). Dado que, como se ver ms adelante, la memoria virtual se implementa sobre un esquema de pagi
nacin, este dispositivo se denomina dispositivo de paginacin. Tambin se usa el trmino dispositivo de
swap. Aunque este trmino proviene de la tcnica del intercambio, por tradicin se usa frecuentemente y se
utilizar indistintamente en esta exposicin. En cualquier caso, hay que resaltar que la memoria secundaria
no slo est formada por el dispositivo de paginacin, sino que tambin forma parte de la misma el sistema
de ficheros. Tngase en cuenta que, como se analizar en esta seccin, al ser expulsadas, algunas pginas se
transferirn al dispositivo de paginacin, mientras que otras lo harn al sistema de ficheros.
Es importante recordar en este punto que, como se explic en el primer captulo, el buen rendimiento
del sistema de memoria virtual est basado en que los procesos presentan la propiedad de proxim idad de
referencias. Esta propiedad permite que un proceso genere muy pocos fallos aunque tenga en memoria prin
cipal slo una parte de su imagen de memoria (conjunto residente). El objetivo del sistema de memoria vir
tual es intentar que la informacin que est usando un proceso en un determinado momento (conjunto de
trabajo) est residente en memoria principal, es decir, que el conjunto residente del proceso contenga su con
junto de trabajo. Algunos beneficios del uso de memoria virtual son los siguientes:
Se produce un aumento del grado de multiprogramacin al no ser necesario que todo el mapa de
memoria de un proceso est en memoria principal para poder ejecutarlo. Este aumento implica una
mejora en el rendimiento del sistema. Sin embargo, como se analiz en el segundo captulo, si el
grado de multiprogramacin se hace demasiado alto, el nmero de fallos de pgina se dispara y el
rendimiento del sistema baja drsticamente. Esta situacin se denomina hiperpaginacin y se estu
diar ms adelante.
Se pueden ejecutar programas ms grandes que la memoria principal disponible.
Hay que resaltar que el objetivo de la memoria virtual no es acelerar la ejecucin de un programa. En
algunos casos, puede hacerlo, especialmente, en situaciones donde el proceso no accede a todo su cdigo o a
todos sus datos durante su ejecucin, no siendo necesario, por tanto, leerlos del ejecutable. Sin embargo, en
otras ocasiones, puede incluso ralentizar la ejecucin, debido a la sobrecarga asociada a las transferencias
entre la memoria principal y la secundaria. Esto hace que esta tcnica no sea apropiada para sistemas de
tiempo real, adems de por hacer que sea poco predecible el comportamiento de los procesos.
Como se ha analizado en los apartados anteriores, la memoria virtual se construye generalmente sobre
un esquema de paginacin, ya sea paginacin simple o segmentacin paginada. Por tanto, las unidades de
informacin que se transfieren entre la memoria principal y la secundaria son pginas. Las transferencias
desde la memoria secundaria hacia la principal se realizan normalmente bajo demanda (paginacin por de
manda). Cuando un proceso necesita acceder a una pgina que no est en memoria principal (a lo que se
denomina fallo de pgina), el sistema operativo se encarga de transferirla desde la memoria secundaria. Si al
intentar traer la pgina desde memoria secundaria, se detecta que no hay espacio en la memoria principal (no
hay marcos libres), ser necesario expulsar una pgina de la memoria principal y transferirla a la secundaria.
Por tanto, las transferencias desde la memoria principal hacia la secundaria se realizan normalmente por ex
pulsin. El algoritmo para elegir qu pgina debe ser expulsada se denomina algoritmo de reemplazo y se
analizar ms adelante.
Dado que se est usando la paginacin para construir un esquema de memoria virtual, se puede usar in
distintamente el trmino de direccin lgica y el de direccin virtual para referirse a las direcciones que
genera un programa.
Para construir un esquema de memoria virtual sobre un procesador que ofrezca paginacin, se utiliza el
bit de la entrada de la tabla de pginas que indica si la pgina es vlida. Estarn marcadas como invlidas
todas las entradas correspondientes a las pginas que no estn residentes en memoria principal en ese instan
te. Dado que se utiliza el bit validez para marcar la ausencia de una pgina y este mismo bit tambin se usa
para indicar que una pgina es realmente invlida (una pgina que corresponde a un hueco en el mapa), es
necesario que el sistema operativo almacene informacin asociada a la pgina para distinguir entre esos dos
casos. En caso de que la pgina sea vlida pero no residente, el sistema operativo tambin deber guardar
informacin de en qu bloque de la memoria secundaria est almacenada la pgina. De esta forma, cuando se
Gestin de memoria
319
F igura 5.67 Ciclo de vida de una pgina de una regin compartida con soporte.
produzca un acceso a una de estas pginas, se producir una excepcin (fallo de pgina) que activar al sis
tema operativo, que ser el encargado de traerla desde la memoria secundaria.
5.5.4. Ciclo de vida de una pgina

Antes de anazar los distintos aspectos vinculados con la memoria virtual, es conveniente analizar cmo evo
luciona una pgina en un sistema con memoria virtual, dependiendo de a qu tipo de regin pertenece, fijn
dose en dos caractersticas de la misma: si es privada o compartida y si tiene soporte o es annima.
Pgina de una regin com partida con soporte en un fichero. Cada vez que se produzca un fallo al
acceder a esta pgina por no estar presente en memoria principal, habr que leerla del fichero que la
contiene. Por otra parte, al ser expulsada estando modificada, habr que volverla a escribir en el fi
chero, puesto que los cambios sobre una regin compartida deben revertir al fichero. La figura 5.67
muestra cmo es la evolucin de este tipo de pginas.
Pgina de una regin p riv ad a con soporte en un fichero. Mientras no se modifique la pgina, es
tar vinculada al soporte y todos los fallos se servirn leyendo del fichero. En cuanto se modifique
una vez, queda desvinculada del soporte original, y al ser expulsada, se escribir en swap. Los fallos
posteriores se servirn de swap, y las expulsiones que encuentren la pgina modificada la escribirn
en swap. Esta es la esencia de una regin privada: los cambios sobre la misma no afectan al soporte
original. Para entender la utilidad de este modo de operacin, recuerde que se utiliza con la regin de
datos con valor inicial de un programa o de una biblioteca dinmica. Despus de acceder a una va
riable global con valor inicial para modificarla, cuando sea expulsada la pgina que la contiene, no
podemos volver a escribirla en el fichero ejecutable, puesto que estaramos cambiando el propio pro
grama. La figura 5.68 muestra la evolucin de una pgina de estas caractersticas.
P gina de una regin annim a, ya sea p riv ad a o com partida. Por motivos de seguridad, cuando
se accede por primera vez a una pgina de este tipo, se rellena con ceros el marco de pgina usado
para la misma, no requiriendo un acceso a disco. Si la pgina se expulsa sin ser modificada (lo cual
es bastante improbable puesto que, al no tener un valor inicial, lo ms habitual es que el primer acce
so sea de escritura), no es necesario escribirla en el disco. El siguiente fallo volver a rellenar el mar
co elegido con ceros. En cuanto se modifique una vez la pgina, al ser expulsada, se escribir en
swap. Los fallos posteriores se servirn de swap y las expulsiones que encuentren la pgina modifi
cada la escribirn en swap. Recuerde que la regin de datos sin valor inicial de un programa o de una
biblioteca dinmica son de este tipo, teniendo, adems, carcter privado. Tambin entra en esta cate
gora una zona de memoria compartida que no est basada en un fichero. La figura 5.69 muestra la
evolucin de una pgina de este tipo.
5.5.5. Polticas de adm inistracin de la memoria virtual

Como se analiz en el primer captulo, el modo de interaccin entre dos niveles de la jerarqua queda defini
do por un conjunto de polticas que establecen de qu forma se realizan las transferencias entre ambos. En el
+

X
D
S
Ld#f,0I&
^"6c#
,'*-IN,'&), S
"$&
D
0
? G
C A-? D ?Lj = CED

"T#4/i2,g# 30/#)/
Cb
? = JIDj
"T&]+FL#),0I&u/hSF(2#)JI(2&
= AXr JJC D D
C
uG
/0BU/POF(S)I-S#4/<
D ;>; Cb
&
/0BuH#4/*QF,FI-#),
=#),0L&)"{+F(*Q
,.'&)"T#g#
c&
/X
(
F^2"'&ESE#
F"
% IN(nF+k'&),DE#49b*P&)+kFI (n0/ H*-IN"2F(+/0IN/F*QFL&4/

.#f( Ld#f,0I&+H&),*-I I-#)(&ESE& &)"&)BcL(*P&),+"T&+2,'#0H#),IV)( SUi"$#4/62,g# 30/#)/=2,.QH&f,g&ES#4/\H&),'&/0B
XB IV)( &)Bc+F(*P&)(2S#iSJ0/*P&id&f(F,'&+"T&4/;2,.0/F*P&I-#f(0/\S"e/0IN/F*QFL&a
I(*QF, .&)+kFI# O&),g&I^2"TL(*P&), "$&=JBU"$*-I 2,g#3D),g& I-Vf(a

".&ESE#),xBO'SUA#Bc,0,FIN,!@BO
(2#t'WfIK/*P&MBU(2&mO&),F*-IIV)(+&ES BH&SE&=@BCF(iF/RI(O/F*P&)(2*Qb/XF(BOF(2*-,g&A"{IPkF,'àmR/ (*P#)(3
F/ BO&)(2SE#
/X2BO.SdI(Cw# .&),d&)" Cb
? = JIDj
CEDFA = H&),'&v@BCJw4&IPJBc(2&=H&),*-I I-V)(za6;" I(*QF,. &)+kFI&ESE#f,\(#
0/tLy4/=@BCBU(+2,'#30/#vSF" % a !a Bc<E&4/=*P&),.'&4/ FBU(SE&)+F(*P&)"0/t/#)(*
YxBO&)(2S#A/^S I-SM&ESf\I-*-I,;Bc(G\BCFw#2,'# 3F/#!H#),xO&),F*QMS"42"$&f(CI
'&

%
F"

%
F"
I#)(2&),2,'#30/#4/H&f,g&i,.*-IN,'&),F"$#)/\S6Ld#f,0I&a

I#)(2&),2,'#30/#4/H&f,g&iI(.#),QH#),'&),F"$#4/J&L+FL#),FI-&Ua

0/F*-I#)(2&),t<G&4/0ITD)(2&),"x0/PO& I#GSU6I(*QF, .&)+kFI#a

Ie,' 3#),gS&)L#4/tF"2*QFL&=,.XF,.F(*Qt&="$&2"T&)(CI

%

.&I-Vf(SUF")2,'#30/&ESE#),09b(2#4/!SE&)L#4/ BOF(2*P&\@BO

.&SE#),&++'S)I#t"$& `#a
+*
F"eI(*QF, .&)+kFI&ESE#f,=,.'&)"{I `&G"$&+L&)<E#),;H&),*Q\S="$&4/=*P&f,''&)/SF"H2"T&)(CI
I-V)(nSF"`2,'#30/#6w*-IL&^/k'&)/&=F(L/F" I#)(2&f,&@BO"N"T#4/@BO!F(LBc(dd#fL(*P#tSE&ESE#

,g#00/#4/6&\I(.#),QH#),'&),09m(*-,'
"T#4/J/F" I-#)(&ESE#4/nF/ .
#.DUF,i"T#4/+S++F(2#),M,0I#),FI-SE&S # 0/PCF,g&f( /0B 30/#)/L"TF(2*P#4/a *-,g&.#f(O/0IS
,'&IV)(
F/="Z*-IF^H#G@BCH
&)(LCF,0L&)(z ISE#F( +FL#),FI-&)92BO0/ O#XS),-&G#Bc,0,FI,=@BOJF"{ITD)I F/FL#4/
.#fd# w *-Id&& BU( 2,'#3 0/#h@BCi&. &k'& Sd/,LIN( . #),QH#),'&ESE#L2,'#XS)B I(2SE# Sn0/*P&vL&)(,g& Bc(
*-,'&4/0IPDE#iI(C(0
0/&),FI#a
&^/F"
3&
0/*Py)(G/0BU/PO(2S)ISE#4/^<J@BCt# B`H&)(LH&),*-I I#)(F/M&ES BH&ES&4/mO&),g&d"$#4/
BH&f(*P#
(
& *P#),.0/=*P&)"0/

;"
'SE&ES

SF"m2,'# 30/#
.#),QH#),'&ESE#)9+/

&]/XF,
I(
*-IF(zF(
BCF(*P&
F(
w&),FI-#4/
5r*-IF^H#tH&4/&ESE#vF(+FL#),FI-&L/ BU(2S&),0I&F?9j/0BJ,0I#),FI-SE&S49;* àaNa
K; K
" 1
IV)(
&]"T&u/F"
.#fd#+/FB
)$
!%)+ ! "

d#f(CI*P#f,S2,'# 30/#
BCF(*-,'&
/X(
!#&

! %%) &
c(CI .#v0/="T&
#
#),FL&GLy4/t/0I^2"T\SADU0/F*-IV)( S+FL#),FI-&Ua
S)IwXI-SfI-SE&u/FIN^2"F+F(*Q
F(
S#4/
3#)(*-ITD)BH&)/a
y),.'&4/
O,0L&)((*QF+F(*Q& "$&H&),*QSF"/FIK/*QFL& #0O,g&f*-Iw#
@BCSXk.
(2&
S
F""T&4/
F/F*P&),v,.0/FI-S(*Q
Z&G+FL#),FI&
0/*Py
&4/0ITD)(2&ES&
F(
+FL#),FI&
;"R,'0/*P#hSi"T&+FL#),0I&
/&)/0ITD)(2&),'y
&"$#)/A2,g# 3
0/#)/S(2#)JIN(&ESE#4/i*-,'&)(O/FI*P#f,0I#4/39
BH&)"0/A/#f( . &),DE&ESE#)/A<i-Bc*P&ES#4/=SABc(2#i(vBU(#iF( ,'0/Q2BC0/F*P&G&J"T&4/tVf,gS(0/=SF"zBU/0BO&),0I#a
YxBO&)(2SE# Bc( ,g#00/#
*-,'&)(O/FI*P#),FI#
c& j(&)" I X&SE#49d"/0IN/F*QFL&]#0OF,'&f*-Iw# S`k..&),DE&), #f*-,'#O&),g&
X
B IV)(a
5Qd#f(CI*P#f,Q?Ea
"T#4/
Yb#fd#
(2#L/,=&4/
.#)+F(2*Pyk'&)L#4/\&f(*QF,FI-#),F+F(*Q09R&f" j(2&)"{I X&),ABc(+,g#00/#*-,'&)(O/FI*P#f,0I#d/X 3&),-D&),gy #f*-,g#

% a !a1/J&)/D)Bc,'&),gy
Sd@BCLF"C2,'#3
0/# @BC\w&&i/XF,3&),-D&ESE# 3&k.GF( +FL#),0I&a
2,'#0H#f, I#)(2&GBc( +F(O/&'SJF,F,g#),Xa
(CBCFw#Uat;"
&
? G
C A-? D~j ?*j = CED ; D =
CEJC -DFA>D
.$
XkI-SE#i&+@BCt/V)"T#c&UkF,gy+Bc(d2,'#30/#n&J"$&Lw4 9j(2#\/=&02"{I 3&L(CI(UD c(v+.&f(CIK/FL#iS;2,'#f*Q

I-V)(nF(*-,.12,'#3 0/#4/a % Ie@BC!0/ (0 0/&),FI&6Bc(2&R2,'#f*Q I-Vf( 3#)(+,.0/PC*P#J&A"T&;H&),*-II-Vf(iS0/*-IN(2&SE&
&f"H2,'#02I# % a !a^[ (+.
&)(IK/Fd#i/FIN^2"J0/t/0I-*-BO&),=&)" % a !abF( BU(& `#)(2&nS=+FL#),FI-&nS"$&),'&ESE&
3#)L#uSn/V)"T# " *-Bc,'&a % IN( Lk.&),-D# F/F*Q *-I H#uS0/F*-,'&f*QD)I&u(2# 0/JBc< 'WfIkF" &)" INÔ'SfIN,
L#XSfI 3
&),<& *-BO&)"{I `&),LF" % a !a y4/ c &kI*-BO&)"0//#)( "T&4/\* (CI 3 &4/Lk.&4/&ES&4/dF( F" = ? C G
= ]
D/.
D 5P/0I,0w4MH&),'& SU*Q *P&),+" JI*Q0/r?i< F(u"$#)/ C
G A-? ;>= "
?JJC 5/Gk'&4/& F( &4/# I-&f,+& . &ES&
O&)"$&UkF,g&nF(
"$&LLd#f,0I&dBc(
kFI-*mS;2,'#f*Q
IV)(f?EaR/*P#4/M+3 &)(CIN/0L#4/A(3 0/FI*P&f( S6Bc(2&+&f*Q( IV)(
H&),gS m&),'à
'&
&
'&
/,
#)^H&),*-I-SE#]S\2,g#3D),g&fd&)/n< S&f*P#4/ F( +FL#),FI-&uF( Bc(

3
SUFLy4/39d/X #k*-IPF(Bc(2& k'&g& BH*-IN"{I X&IV)( S"T& YZ7\[ 2BC0/*P#
@BO/
S0/&F2,g#fw4c&
BH&)(SE#]" c(CI. #G,g#00/# @BC 0/F*Py]F( F";/FIK/*QFL& XBH*P&]#FOF,'&I#)(0/
SUG % 9=<hBc(2&uL&)"T& BH*-I" I X&
I-V)( S "T&uLd#f,0I&v2BOF/F*P# @BC /S0/&02,'#)w4 c & "T&uLd#f,0I&
3#)^2,'(2S)ISE&(*-,'d"$& @BCdBH*-IN"{I X& ",g#0 0/#*-,'&)(O/0I-*P#),FI-#<v" m
(2&)"jSJ"T&n+FL#),FI-& S0/*-IN(2&SE&
O&),g&i"T#4/;2,'#3
0/#4/a
6#h*-IPF(JB
(*P#),F(2#
S
H#
L#)(CI-*P#),
/(*-I-S#uF" BU/#

c(CI .#a
0
S. O. (monitor)
Area de procesos
transitorios
max
760G"2 : x

" 2 1

) &()+!
A,8E("76)EV"!H$"L='!'&D4"("7='
) 5
/$
c&3F,RH#4/FIkF"6"$&JJBc"{*-I 2,'#.D),'&)L&IV)(+H&4/&AH#),6S)IwXIS)IN,M"T&J+FL#),0I& K/FI 3&+S)IN/PH#

&ESE&\Bc(2&\S"T&4/ BO&)"0/ 2BC'S!/,!&4/0ITD)(2&ES&&\S)I F,.F(*QF/ 2,g# 30/#)/a
.
7#),\*P&f(*P#
F"
= DFA A>?~jWr
C ;>= = Dj@DFJC 0/F*Pyn"{I\I-*P&ESE#=O#),+F"1( U+F,'# SJ,'DfI-#)(z0/iF(
@BOF/F* SfINwXIS)ISE&M"T&MLd#f,0I&a6Yb&SE&MBU(&tS0/*P&4/R,.D)I#)(0/#mH&),*-I
I-#f(0/39 BO&)(2S#t"T&6 B I-V)(
[1(2&
#),Fd&+S
(IkF"MF(iw4&),0I&4/xH&),*-I I-#f(0/39
SUF"H2,'#.D),'&)L&@BC,'0/FI-SU\(
F""T&4/=*QF,F\I(2&49m@BC'SE&" IPkF,. O&),g&=O#XSF,&f"Tk.,-DE&f,J&n#f*-,'#a
($
.Vfd#i< BOy)(2S#L/#)( ,'.&ESE&4/6<LL#XSfI 3&ESE&4/6"T&4/;H&),*-I I-#)(z0/39;F"cO&),F*-II#)(2&

JIPF(*P#GS="$&++FL#),FI-&t2BC'S=/,\0/F*PyE*-I .
#n#nS)I(2y)JI.#a
;(

FBc( IV)(S

+
= AXr JJC D D
? G
C A-? D ?Lj = CED
D =
EC JC Dj C ?L
? G

CEJ

S6"$&)/jH&),*-II-#f(0/0/Hc& FBOF,'&GSA"
C&4/;SU0/P2B0/S!0/*P#am "U( c+F,'#6S H&f,F*-II#)(0/ <t"c*P&)L& #
SJ"$&4/\JIK/Fd&)/39F/JS*Q,0JI(2&ESE#vSfBU,'&)(*QiF"C,g#0
0/#StD(F,'&IV)( SUF" /FIK/*QFL&49*QF(CIPF(2SE# (
BCF(*P&"T& 3&0H&ISE&ESdSU"T&=Ld#f,0I& N /0I. &SfIK/QH#)(CIPkF"09 F"UDf,g&ES#\SUJBc"{*-I 2,'#.D),'&)L& IV)( S0/X'&ESE#
<vF" *P&)L& 2#n* 2I 3#S\"T#4/2,'#3
F/#4/L@BC\/#UkF,'+S)Ic #i/0IN/F*Qd&Gw4&)(u&i/,dX BH*P&ESE#)/a 6#),FL&)"
+F(*Q c&k,gy)(=H&),*-II-#f(0/xO'@BC 2&)/39 L.S)I-&f(2&4/<^D),'&)(2SF/1O&),g&H#`SF,MX
BH*P&),AS)I XF,.F(*Q0/!*-I H#4/
S 2,'#3
0/#4/a
(-
;"H&),*-I I-#f(2&)JI(*P#i0/*Pyf*-I .#LI^2"{I .&i@BCt"T&LS)IwXIN/0IV)(

(.&A<A@BO"$&4/
H&),*-I I-#)(z0/ @BC'SE&f(
(-
[1(2&
)-

w4 @BOG"T&4/tO&),F*-I I#)(0/
c&)(]/0ISE#
S j(I-SE&)/39=F"j/FIK/*QFL&#FOF,'&f*-INw4#

( 3F/0I-*P&vD)BO&),gS&),
.#)L#d"{Ik,'=#+F(vBU/#492H&),'&M,g#0OV4/0I-*P#4/6St&4/FI$D)(&IV)(a;;"eF/F*P&ESE#i&*-BO&)"
<v"T#4/+&f*-,FIkBc*P#4/+S+"T&4/MH&),*-I
I-#)(z0/G0/F*Pyf( & +F(CBOSE# ,'3 #02I"$&ES#4/F(]Bc(2& 0/F*-,FB X *-BU,'& SGSE&f*P#4/
S(2#)JIN(&ESE&
D > D
A-? A>? G J = C ; JC A>? D G ; D =
CEJC -? G u
w aYb&ESE&=O&),F*-I IV)( /JSU0/
,FIPk.jH#),!/0BGSfIN,. IV)( SU. #)JI X#d#dk'&4/X09O#),/FBi*P&)L& 2#<=/0BG0/*P&ESE#a\YxBO&)(2SE#Bc(2&!H&),*-I I-Vf(
0/*Pyf*-I.& 0/GB/&ESE&/V)"$#
/iL#XS)I .
&),'yu" . &f!O# SvF/F*P&ESE#Ua Yb#)L# . #)+F(*PyUk'&)L#4/v&)(*QF,FI-#f,
+F(*QF9="$#)/Gw&f"$#),.0/
SF",.0/*P#uS
&)^H#)/G/XvS j
.
(CIPF,g#f( F( "$&uS j
(I IV)( S"T&4/H&),*-I I-#)(z0/39
L&)(*Q(CI(2SE#4/XtI(2&)"$*QF,'&kF"0/.
#)( F"cO&4/#nSF"1*-IF^H#Ua
2IN/F*P&dSUM/0Bv0/*P&ESE#49b*P&)"
(-
0K
N Particin Direc. Base
0
0K
1
100 K
2
400 K
3
500 K
4
750 K
5
900 K
Tamao
100 K
300 K
100 K
250 K
150 K
100 K

100 K
Estado
Asignada
Libre
Asignada
Asignada
Asignada
Libre
400 K
Pi
500 K
Pj
750 K
Pk
900 K
1000 K
P760G"2 : x } N"8"!g"!'&=#76$;=#7JE( "!RE&K$@)7=#7E(!'&

,.'&ES#L#&*-INw4&ESE#49mF"O/FIK/*QFL&#0CF,g&E*-INw#\I(*QF(2*P&
&4/FI$Df(2&),F"TBU(2& H&),*-I I-V)(GS+FL#),FI&A" IPkF,.!SU*P&)L& 2#t/0B
IPF(*Q . #)(O/FBU"$*P&)(2SE#="T&4/(*-,g&SE&4/&t"T&
7
ba;( F" 3&4/#GS\F(.#)(2*-,g&),=BU(2&AH&),*-I I-V)( &ES BH&ES#49F" 3 &)^H#3 #),0,.0/QH#)(2S)IPF(*QJ&f"ZF/F*P&ESE#
SGS)Ic&LH&f,F*-IIV)(
F/Ld&f, .&SE#
.#)L# % <"z2,'#3 0/# 0/. &),DE&ES#hF( "$&LH&),*-I I-Vf(
.#f,0,.0/PO#)(2S)IPF(*QXa7 BO0/*P#L@BC6F("T&67 (2#J&0O&),' 3 \@BUI F (BH*-IN"{I X&"$&!O&),F*-I IV)(O9x/F,'yLF"E2,g#F2I-#
2,'#3F/#
F"j@BO=D)BO&),gSU+@BCAH&),*-I
IV)( *-IPF(L&4/0ITD)(2&ES& F(]"Z76Yâ!YxBH&)(SE# F"2,'#3 0/# j
(2&)"{I `&
#+/\SF/ .&),DE&
S)IN(y)JI .&fL(*Q09 F"C2,'#3
0/#nBc*-I"{I `&),gyi"T&GIN(#),FL& IV)( SF"7tY H&),'&GL&), 3 &),\S
(CBCFw#i"T&AO&),F*-IIV)(
#)L#
.
a
(-
YxBO&)(2S#6Bc(2,g# 30/#d(2#6,.0/FI-S(*Q^w&J&t/XF,
I""$&+*Q'#),-&!"T&i0/*-,g&E*QD)I&GSU=&4/FI$Df(2&IV)(
@BO=/X;2BC'SE&&)/0ITD)(2&),=@B c
&0 F,a
R2"T&)(*Q'&f(SE#4/R2,'#kF"FL&4/=S*-,'y4/=S=F/F*P&J/XF(
Bc(2&tH&),*-I IV)(O9j<L/0Ib(2#
c&)<L(IN(UDfBU(2&6H&f,F*-IIV)(
S

? G
C A-? D~j ?*j = CED ; D =
CEJC -DFA>D
BO&)(*P#

"{IPkF,'F/39+"T&
&)/0ITD)(2&IV)(JBO'SUt,.'&)"{I `&),0/SMw&),FI&4/ML&)(zF,g&)/a Z&4/MLy4/.#)JBc(0/A/#f(* = G
.
v5l&)" D#),0I-*-L#
SUF"c2,FIN+F,=&ESUBO&ESE#F?G<
? G
.
5r&)" DE#),FI*-L#GSF"eLy4/=&ES BH&SE#F?fa!;"H2,FIN+F, 3 &4/#+/\k'&4/&F(
(.#)(*-,'&),nBc(2&iH&),*-II-Vf(
SE#)(2Sv*-I(
.&kI-SE&]F" 2,g# 30/#)9=Bc*-I"{I `&)(2SE#Bc(2& c(CI. & . #f"$&au;( F"
/XD)Bc(2SE#
.&)/#+/J0/ .#.Dd&@BO"N"T&=H&),*-I I-V)( @BCBU(&+w) Bc*-I"{I `&ESE&GSX\"Z+F(2#),\F/PH& I-#i"{IkF,.09
F/LSUI,39/X 3#.DGSGF(*-,.+*P#`SE&4/d"$&)/!H&f,F*-II#)(0/+&ES
BH&SE&4/39M"$& Ly4/Ô'@BC 2&an;( F"2,FIN+F,
&f" DE#f,0I-*-L#u&0,g#)w)c&)L#4/+#f,
F" 2,'#30/&ESE#),LH#),'@BC(2# ,'3
#),0,.F,.FL#4/ *P#XSE&u"$& 7 9t/0I(2#
@BO H&),'&),.FL#4/ BO&)(2SE#nF(.#f(*-,'d#)/ABc(2&GF(*-,'&ESE&G&ES
BO&ESE&Ua;( "z/D)Bc(2SE# . &4/#L,.. #f,0,.FL#4/
*P#`SE&6"T&A7
IN(2*QF(*P&)(2S#\F( .
#)(*-,'&),^&E@BOF""T&\&S BO&ESE&\< 3 #)(n (CIL#6S0/QOF,'S)I I-#dS!+FL#),FI-&)9
&F2,g#fw4c&f(2SE#+#f,R"T&t+FL#),FI-&)9UCF,g#MDE&4/*P&)(*P#=*-IF^H#S 2,'#3
F/&ESE#f,MF(n(. #)(*-,'&),"T&A+#),a
;(
&
"T&

H#)" -*-I .&
S
&4/FI$D)(& IV)(O9d/0B`H#)(IF(SE#
@BC 'WfIK/*QF(
H&),*-I I-#f(0/
)-
!"$#
^&BCF,'SE#d&)"20/@BOd&2,.0/XF(*P&ESE#J&)(2*QF,0I#),F+F(*Q09Z/FIz"N"DE&Bc(t2,'#30/# .#)(GBU(&6( 30/0ISE&ES

SUJ+FL#),FI-&vSUp o 9!F"j&)" DE#),FI*-L# m
,3/* m
*9!0/ 3 #.DF,'y"$&\H&),*-I IV)(u" IPkF,.LSL> oEo 9!S0/&02,'#)w4
c&)(2SE# :> o a;7#),vF" 3 #)(*-,'&),0I#49\F"&)" DE#),FI*-L# k30/F* m
*0/ . #.DF,'y "$&iO&),F*-I IV)( "{Ik,' Sv8 oEo 9
SU0/&0,g#)w)c
&)(SE#G/#f"$&)+F(2*Q=> o a
)$
)$

,''&I-Vf(#d&d&E@BC
#.&4/FI-#)(z0/39+F"mD0/*P#),v(2#n2BC'S
/&E*-IK/&0
F,"$&)/
;"cDF/F*P#),tSM+FL#),FI-&dSUXk.6&)/0ITD)(2&),^Ld#f,0I&d&\"$#)/j2,'# 30/#4/6SM(CBCFw&
""T#4/@BOv/
S0/ .&),DE&),'#)(

S)I(2y)JI .&)+F(*QXa

;(
BH&f(2SE#
C*-I I-#)(z0/6,'.&)" I X&SE&4/a;/F*P&4/# 3&4/0I#)(0/t/#)(
A>D G D G ; D =
CEJC -? G ? G
C = ? G ; ? = ? ;>= JI? G ?*
= D
? ? G A-?Lj@D G CEDFA
= D A>? ;( 0/*Q.&4/#49j" % a a FJI*Q^Bc(nL(O/&gXAStF,F,'#),a &6/#)"{B IV)(\H&)/&!H#),^,'.S)I
j(CI,t"$&)/ H&),*-I I#)(F/\#6H#),=,.'S)IN/ 2&),J"O2,'#.D),'&)L&H&),'&@BC,'.S)B .&"T#4/6,.'@BCF,FINJIPF(*P#4/
&
.-
/*
S=+FL#),0I&a
A>D G3 D G ; D =
CEJC ? G ? G
OD G C DFA>D G % d0/QOF,'& H&4/F*P&@BC+" &)" D)Bc(2&H&f,F*-IIV)(

2BC'SE&t/F, &)"$#'&ES#aJ[1(2&^/#)"{B I-Vf(G0/j/&.&),&MBU(t2,g# 30/#
@BC+0/*P&k'&
(h+FL#),0I&H&f,g&
S&),Bc(2&O&),F*-I
IV)( /FB IF(2*QF+F(*Q6Df,g&)(S^2,'#)w# .&)(2SE#
BU(+2,'#kF"FL&S6/F"
I-V)(]Stw *-IL&i<iS\S0/ . &),DE&S)I(2y)JI 3 &GSUF"ZJIK/FL#+&GS)IK/ . #a
@BC'S" IPkF,.;<t"2,'# 30/#\(*-,g&f(*Q

#

rP-D G ; D =
CEJC -? G ? G
C = ? Gf ; ? = -Cb

/F,=Bc*-I" I X&SE&4/F(h0/F*Q.&4/#a
+*
r D A>? ? D G ? G G r JCE?*

?Lj@?L
?

Z&4/R/#)"{B I-#f(0/&)(*QF,FI-#f,0+F(*Qx2,'#02BC0/F*P&4/65l&02"T& X&)JIPF(*P#A<6SF/ .&),DE&\S)I(2y)JI 3&F?`9c2BC'SF(
]!g"!R$"E)!'='=#7JE(-QeG&/='E,/$@)7"
&0O&ISE&ES\S H#)(zF,!F(LwXITDE#),
.
I#)(0/091CF,g#(2#+/V)"T# 0,.F(*QJ&iI(*-,'#)JIK/FI-#)(z0/
SU#f*-,'#4/62,'#3F/#4/
F(
F"!0/QH&I#hSvS)IN,. I-#)(&)JIF(2*P#uS" % a ;9!/FIN(2#
@BO
&ESE&G,g#0 0/#]SXk.
3
F/F*P&), ,g#f*QPD)I-S# 0,.F(*Q\&+IN(*-,'#)JIN/0I#)(0/6S\#f*-,'#4/ 2,'#3
0/#4/a
Z&AI(*QD),FISE&ES=SU;BU(L/0IN/F*QFL&AJBc"{*-I 2,'#.D),'&)L&ESE#\SQOF(S!SUR/0B
"x&)IN/0"T&)JI(*P#iSU"$#4/JS)IK/*-IN(2*P#4/0/PH& I-#)/JS\S)I,'
S="T&62,g#E*Q
IV)(uS="T&iLd#f,0I&G(Bc(/0IN/F*QFL&GSE&ESE#)9R*-I(2S\&0/F*P&),
I&ESE#6H#),JF"z/#0O#),F*Q H&),gS m&),'JSfIK/QH#)(CIPkF"Xa
Z&iIN^2"F+F(*P& I-Vf(
/,
(2#),FLL(*Q=IN( ;BCF(
bW)IN/F*QF(

w&),FI#4/t
&
*P#XSE#4/S2,'#f*Q I-Vf(
D G DFA ?* = ? C G
= G D G ? k j C
?
*P&),vF" & 30/#]&GH#4/0II#)(0/SG+FL#),FI-&
dy)/n&)""$y
SUF" " JI*Qn&4/FI$Df(2&ESE#iO#),
.$

Yb#)(h0/F*P#)/=,'PD)IK/*-,g#)/" NJI-*QA/X2,'*QF(2SdSU*Q
F"m/FIK/*QFL&
@
+
= AXr JJC D D
? G
C A-? D ?Lj = CED
Reg. Base
SI
<= Registro
lmite
CPU
NO
max
Violacin de la
proteccin
Memoria
,
760G"2 : x [!<"!<$"E)!'='=#7JE(-N@E&2E"8!#(!#07&)/N@E&!HQe 6,/76)!

#0OF,'&f*-Iw#

&vBU(v2,'#.D),'&)L&@BOd/i0/F*Py Bc*P&f(2SE#aiR/F*P#4/\,'PD)IK/*-,g#)/L" JI*Q\<
.&SE&62,g# 30/#
&)" L& 0F(2&ESE#)/\F( F"7tY
S
D G DFA ?* J "

D G
F/F*Q
k.&4/G0/F*Pyf(
)$
.&4/#G*QF(2S),.FL#4/6Bc(2#4/6,.D)IN/F*-,'#4/.#f*P&iI( XF,0I#),t<3#f*P&+/0BÒ
,0I#),09RS6*P&f"ZL&)(F,'&n@BO="T&nS)IN,.
I-V)( DUF(F,'&ESE&c &nSJF( . #)(*-,'&),0/dF(*-,.\S)Ic&4/ .#E*P&4/a
;(
k
? G A>? ;-= "
?BJIJC
.&),DE&LF(++FL#),FI&49e/!&4/0ITD)(2&\F"Ow&)"T#),

&n/0Bn7
a1;( . &ES&v& 3 F/#&
Ld#f,0I&
/+w&)"{I-S&
"T&,.,'F( I-&
3#)^H&),'&)(2SE# " 7 SUF"z2,'#3 0/# . #)( "mw&)"T#),iSUi"$#4/
kF<f*Q0/S2,'#f*Q IV)( S"xkF"T#X@BCd& 3.S)I-S#49R<+/0I (2#
.#)I( ISF( / 2,'#XS)B 3 \Bc( F,0,'#),Xa
SJ*P#XSE#)/"T#4/JkFI-*/\S!,g#f*Q
BH&)(2*P#
YxBO&)(2S#6Bc(t2,'#.D),'&)L&=/
IV)(
SU\"$#)/JkF"T#X@BC0/+@BO+# B`H&
3#)^H&),*-I IV)(O9+/L2BC'SF( ,'0/XF,Fw&),h&)" D)BU(&4/LH&f,F*-II#)(0/dO&),g& F"N"T#a

&
DF/F*-IV)(iSF/F*P&4/ H&),*-I
I#)(F/0/ . #)^2"&R2BC0/ H&)<6@BO /&)"$*P&),0/;"T#4/;L .&)(CIN/0L#4/S 2,'#f*Q I-Vf(O9
JIPF(*-,'&4/
@BCh&f"^,.0/F*P#
S+2,'#3
F/#4/ /X"TF/ SXk3 (PDE&), F"6& 3 F/#a [ (&]/#)"{B I-Vf( 0/ @BOuF"
/FIK/*QFL&+#0O,g&f*-Iw#i,.D)IN/F*-,.J@B
2,'#3 F/#4/BO'SUF(h& 3 'SUF,J&+"T&4/;H&),*-I I#)(F/ 3 #)^H&),*-IkF"0/ j/0Ix/
F^2"'&\Bc(
0/@BCFL&LStk<)*QF/^Sj2,'#f*Q
IV)( F( . &ESE& . &fLkI-#dS3 #)(*Q'Wf*P#)9jF"/0IN/F*QFL&J#0O,g&f*-Iw#
S`k.\L#XS)I .
&),\"T&4/ "T&)w40/LS\*P#XSE#)/="$#)/JkF"T#X@BC0/dSULd#f,0I&S"T&=H&),*-I IV)( . #f!O&),F*-ISE&O&),g&
&4/FI$Df(2&),F"$#4/
&f";7
S"!(CBCFw#
,g#0
0/# 5P/0IF /F*Q*-IPF( & 0 0/#F?Ea *-,'&u/#f" B IV)( 0/S&), @BO
#
BU,F,g&F"xSU0/0w #n<@BCLF"1/0IN/F*QFL&#0O,g&f*-Iw# . #)^2,FBOXk3+@BC/XJ*-,g&E*P&S\Bc(2&G,'F,.F( I-&v"TD&)"
5l&L+FL#),FI-&
#)^H&f,F*-ISE&F?L<L"T&i,'.&)" I3 "e\IN/0L#nF("$&i,FBc*-I(2&GS6/F,FwXI I-#nS"1S0/Fw- #Ua
.
(
&]"$&
&
E(=#6G&7E(!'&
#

0/=Bc(2&vS"T&4/\d&f(F,'&4/.#)^H&f,g&f*-I
w&)+F(*Q=Ly4/A/0I^2"TF/6SUt/#0H#),*P&),6JBc"{*-I 2,'#.D),'&)L&IV)(a
Z&dD0/*-I-Vf(uk'&4/&SE&
;"

H&),*-I I-#f(2&)JI(*P#
SE#)(2Sd"$&
.&),DE&

F(u"CH&f,F*-I I#)(2&)JIPF(*P#v0/*Pyf*-I 3#

0/F*Pyf*-I .#
S
+FL#),FI&
F/vI-SEVf('#
SUd*-,'&k'&g#F/!2,.'S Ik"T09M<G/0BU/
F(
&E@BCF""$#)/

F(*P#),F(2#4/F/F*Pyf*-I .#4/
.&f,g&X*QF, N/F*-I.&4/ .#f(2#ISE&4/v5$ZaN .#)(*-,'#)"
S2,g# 30/#)/Q?fa
.#f(Cw4F(CIPF(*QF/Sh0/*Q*-I O# SLH&),*-I I-#)(&)JIF(2*P#]wXI(F( SE&ES#4/dH#),"T&

'W)IPkFI" ISE&ES+<L"T&iIN(3 &0H& ISE&ESSU=&ES&0*P&),0/J&+"$#)/ 3&)+kFI-#)/@BOd"e/0IN/F*QFL&+(3F/0I-*P&a
Z#4/vL&)<E#),.0/
IN(
I(

? G
C A-? D~j ?*j = CED ; D =
CEJC -DFA>D

($
($
I H&)"0/A2,'#kF"FL&4/nF/J"T& = D j ?*

DFJC 9M@BCL/+,. ;F,.n&v"T& IN( .&0H&
ISE&ESSF" % a aeH&f,g&&4/0ITD)(2&f,!O#), I-#)(z0/iSJ+FL#),FI& @BC+(2# 0/*Py)(h/FI(2SE#BU/&SE&4/a+;(
wXI,F*-BOShSvF/F*P&hS j
(CI I-Vf(2BO.SvSE&f,3/X = D j ?*
DFJC CZ
? = -D 9=@BC 0/vF" SU0/&0,g#
w4H&)JIF(2*P#
S\+FL#),FI&vSF(*-,'#vSJBU(2&\H&),*-I
IV)(O9SXkFISE# &G"$&vSfI XF,.F(I&vSJ*P&fd& 2#
F(*-,.+"$&dH&),*-I
I-V)( <"m#kX*P# ,'0/FI-SUF(*QnF( F""$& M< = D j ?*
DFJC ?H
? = D 9t@BO+/X
,' ;
F,.&)";SU0/&0,g#)w)c &)JIPF(*P#uS+Ld#f,0I& F(*-,.=H&),*-I I-#)(z0/39tSXkFISE#h& "T&SfIK/QOF,0/0IV)(
St0/QH&
I#d"{Ik,'6( y),'.&4/AS)IN/ 3 #)(*-I(CBH&)/a;;(\H&),*-I BU"T&),09jF( ". &)/#LS"fH&),*-I I-#f(2&)JI(*P#
0/F*PyE*-I .
#)9m"$& F,g&XDfL(*P& IV)( IN(2*QF,0(&d/FBXH#f(BU(D),'&)( IN( . #)(Cw4(CI(*QXa
[
(2#S+"T#4/M2,0I(
&

/-

/-

*P&fd& 2#iSUt"T&LL&)<E#),
I#)(0/+F(uF" *P&)L& 2#SU\"$#)/
.#)( 0/F*-,FB *-BU,'&4/ S SE&f*P#4/v@BC
Yb#)(dO&),F*-I I#)(2&)JIPF(*P#n0/F*PyE*-I .#)9m(CI(UD c(L2,'# 3F/#=2BC'Sd'W 3'SF,LF"
(-
H&),*-I I-V)(]SBU(h/0IN/F*QFL&SE&ES#49&F2" I .&)(SE#H#),J*P&)(*P#G,.0/*-,0I

;" 2,'#kF"FL&
/Xv&XDf,g&)w4&
BO&)(2S# /v*-,g&Uk'&g&

,.3F(uSfIN(2yf\I.&)+F(2*Q09".#)L#6H#),J!"$#+"$&)/ 2IN"T&4/Xa
2,'#.D),'&)L&4/a
( c+F,g#
;"R*Q(F,+Bc(

C#
SH&),*-I I#)(F/+" IJI*P&

&

!
"
#
$%
$
&
'
( #)

*
! %
Y{!'=#)8"!R$;\#S788"!'&2$"c.!'=2_@,/7!#(C)e$OEM!Yb!'=#)8"!HYZ20,8!#(*)2E=#7JE(-76(C)!#(@
F/&02,'#)w4 c&)JIPF(*P# SUi"$&+FL#),FI-&LH#f,nX*P#hSUi"$&

1DfBU,'& Ua r?fa

F,'&XD)+F(*P& I-V)(iIN(2*QF,0(&
F,g&`D)+F(*P& IV)(
!"$#
5,+CF,
<LH#),
X#Ua
c&)JIPF(*P#!H#f,^ *P#JS
P760G"2 : # x
+*
D),'&ESE#hSiJBc"{*-I 2,'#.D),'&)L& IV)(
*P#JS1 ,gS)ISE&J#=SU0/&0,g#)w)
!"$# m
F"
".&ESE#),\&.#f,F*P#62"T&
*P&)(*P#+,'.S)B IN,"$&X *-IwXISE&ESSF"O2"$&f(CI
I &),3/X+@BOL/0I""DE&
BU(&JO*-I IV)(
.#f(X0Bc(*P#a
S
o
<f&
(2#J2BO.Sn&f*QF(2SUF,3/X
c&kFIPF(2S#8
oo
'WE*QF,0(&
"{Ik,'0/
(
-
A C - j CEJ
D =
C JBC .- Dj CE? *
(-
I H&)"xS="$&4/ O&),F*-II#)(0/ &4/0/SU*QF,F\I(2&),dF" *P&)L& #iS="T&4/6JIK/FL&4/;H&),'&

*-II#)(0/+S #),Fd&S)I(2y)JI.
&LH&),'& &ESE&0*P&f,3/Xi& "T&4/L(3F/0ISE&ES0/S .&ESE&L2,'#3F/#/#)" II-*P&)(*QXa
YxBO&)(2S#=Bc(\2,'#3
0/# j
(&)" I X&J#d0/MSU0/ . &f,-DE&SE#+S)I(2y)JI.&)+F(*QASUFwXBCF" w)t"T&\+FL#),0I&aR;"cDF/F*P#),
SU^Ld#f,0I&=/0ITD)BUI,'y
,'.&)(2SE#J<J&4/0ITD)(2&f(2SE#H&),*-I I-#)(z0/MS^+FL#),FI-&J&"T#4/b2,'#3 0/#4/!/#)"{I I-*P&)(*QF/
H&4/F*P&&3&k'&), . #)( "$&n+FL#),FI&S)IK/QH#)(CIPkF"09#vkFI(u&)" . &)( `&),d"zD),'&ESE#dy`W)INL#SJ\Bc"$*-I 2,'#.D),'&
L&
I-V)(tOF,F\I-*-ISE#L5T2BOF/ "T&4/!0/F*-,FB *-BU,'&4/^S!SE&f*P#4/S0/*-IN(&ESE&4/&)" . #)(*-,'#)"SJBU"$*-I ,g#.Df,g&)L& I-V)(
/XH
&)(h&XDE#f*P&ES#49". #)L#6H#),-F^2"T#i"$& . #f"$&nSA7tY0/ /r?fa
"H2,'#kF"FL&=2,0I(
JI(CI\I X&f,!"T&
F,g&`D)+F(*P& IV)(IN(2*QF,0(&a R/F*Q 2,'#kF"FL&AH#`S), &+/F,=&f" IwXI&ESE#+SU j(CIPF(2SE#+"T&4/mO&),
%*
($
+ -*
=
AXr JJC
D D
-
? G
C
-
A-? D ?Lj = CED
Libres
TODA LA
MEMORIA
LIBRE
(UN HUECO)
800 k
100 k
Asignacin
Libres
LIBRE
700 K
100 k
Asignacin
800 k
Libres
LIBRE 100 k
300 k
100 k
300 k
LIBRE
400 k
Termina
el primero
LIBRE 400 k
Libres
Asignacin
50 k
50 k
LIBRE 50 k
300 k
Libres
50 k
LIBRE 50 k
300 k
350 k
Asignacin
350 k
LIBRE 400 k
760G"2 : Sx

Libres
LIBRE 50 k
Y{!'=#)8"!H$O\#S7D8"!'&2$"i.!'=_@,/7!#(C)e$OEV!Y{!'=#)/"!RYZ20,8!#(*)2E=#7JE( !)S)!#(@
I#)(2&)JIPF(*P# F( 0/F*Qi*-I H# SUGF/@BCFL&4/GSAH&),*-II-#f(2&)JI(*P#F/L\Bc</XF(I"N"T#an;"

2,FIL,AH&4/#
F/+"$# .
&)"{I `&),+Bc( y),'.& .#)(*-ITD)BO& Si+FL#),FI-& "{IkF,.nSG*P&)L& #vITD)BO&)";# L&)<E#),iS
"T&G,'.@BO,0ISE&\O#),d"O2,'#3
0/# F(2*-,g&)(2*QXa % I F/F*Qdy),.'&n"{IPkF,'+0/JF(3#)(*-,'&ESE#49^F" /0IN/F*QFL&#0O,g&f*-Iw#
#k*-IF(z=S0/F*Qy),.'&i"$&AH&),*-I
I-V)( S6*P&)L& 2#i.WE& *P#nS)I *P&ESE#tH#),A"T&4/t(3 F/0ISE&ES0/SUF"c2,'#30/#a
;" ,'0/*P#S+FL#),FI-&@BC=/#UkF,'+0/\SFw`BOF"$*P#
#fd#G+FL#),FI&G" IPkF,.H&),'& 0BH*-Bc,g&4/J&4/0ITD)(2& I-#)(z0/a
.
&dO&),F*-I
IV)( 0/ ,''&SE& I(*-,'#XS)B I(2SE#/FB k'&4/X09=*P&)L& 2# <h0/F*P&SE#hF( Bc(2&v7 L#XS)I . &SE&a
R/*P&MIN(#),FL&
IV)(L@BC'SE&t,.D)IN/F*-,'&ESE&=*P&)+kFI F (iF(GF"f7tYMa;(dBc(2&tS0/ . &),DE&\S)IN(y)JI . &)92/X;,'.&)" I X&
Bc(
k.#),0,'&ESE#SU6"T&nF(*-,'&ESE&
#),F,'F/PH#)(S)I(*QJ*P&)(*P#nF( "T&\7 3 #)L#n(h"7tYMa
.
" 0Bc(
(-
(-
(-

L#XS)I .&ES&6SE#)(2SUR/*P#)L&M(2#f*P&6S "$&4/
,'.&ESE&4/A<JSUM"$&)/A&4/FI$D)(&ESE&4/ x<!H#),6#f*-,'&^H&),*QMBc(2&J"{IK/*P&dSM+FL#),FI-&d" IPkF,.Xa XkI-SE#
&G@BCJS)IN(y)JI .
&fL(*QF/F*P&i" IN/F*P&+w&), &49b/6/0BCF"IN^2"F+F(*P&f, .#)L#iBU(2&+"{IK/*P&GF("$& `&ESE&a
&4/ 0/*-,0B *-Bc,g&)/ (z 30/&),0I&4/;/#)(tH#),;BU(L"T&ESE#t"$&7

+*
H&f,F*-I I#)(0/
Yb#f(

0/F*P&
0/*-,0B *-Bc,g&
H&f,F*-I I#)(2&)JIPF(*P#
.#fd#
/0I(]BU/&f,a
"T&

L&)(,g&
,.'&IV)(
SE&f*P#)/Gw&fd#)/v& w4F,

3#)L#
FBU( I-#f(2&]"mD0/F*P#f,
S+FL#),FI&
.#)(

#)(]*P#`SE& "$& +FL#),0I& SfIK/QH#)(CIPkF"AO&),g&
3
3#)L#v"{Ik,'09^d&f, .yf(2SE#4/XL"T&4/+F(*-,'&ESE&4/iF(]"T&i7
&
"{IK/*P&
SG+FL#),FI-&"{Ik,'
#)(*-IPF(GBc(2& c(CI.&uF(2*-,g&ES&a H&f,F*-I,nSUv0/F*Q
.
SABc(2&^H&f,F*-IIV)(n7
SUt*P&)L& 2#67
*P&fd& 2#\/t"N"Fw&i& .
&k.#iSt"$&J/0ITD)BUIPF(*Q
SfIN(2yf\I .#aG;"

&4/FI$Df(2& IV)(]SfIN(2yf\I .&
2Bc(*P#49
S
@BO.SE&)(2SE#
/FIK/*QFL&n/LI(CI I-&)"{I X&
S "$&f,g&ES&
(-
/-
? G
C
-
A-? D~j ?*j = CED ; D =

CEJC
- DFA>D
100K

400K
500K
0K
N Par. Dir. Base Tamao Estado
0
0K
100K Asig.
1
2
400K
100K Asig.
3
500K
250K Asig.
4
750K
150K Asig.
5
6
7
-
Cabeza

900K
300K

750K
900K

"!
1000K
0K
0
0K
100K Asig.
1
280K
120K Asig
2
400K
100K Asig.
3
500K
250K Asig.
4
750K
150K Asig.
5
6
7
-
100K
280K
#%$&('*)+ ,
798;:8
400K
500K
Cabeza
#-$.&/'*)0+ ,213+54)6$
900K
180K
<=
<>+
<@?
750K
900K
<>A
B
CEDFDG
1000K
0K
0
0K
100K Asig.
1
280K
120K Asig
2
400K
100K Asig.
3
4
750K
150K Asig.
5
6
7
-
100K
280K
HJIKML3NPO Q
V"WX%W
YPZ
400K
500K
Y3O
750K
900K
Y3[
Cabeza
HJI.KL3NRO QSFOTNUI
500K
180K
900K
250K
\
]_^9â`
1000K
"bdcefg 3 hi3j ek.lmbonPkg
pqbormk*stnvurmwaryxtz*e.rmp{g|ur~}wg
kb l@gPlmboPkgPxgPunrmk}g
fsbolmbonPkg
pqbormk*stnvu3b&%
k
pqbolyn

M
"
+ -*
=
A JJC
-
D D
? G
C
.#)(2*-,g&),^(+"T&t"{IK/*P&6SLd#f,0I&t"{Ik,'BU(Gy),'.&="{IPkF,' *P&)"C@BC

I (2#'W)IN/F*Q=(CITD)BU(&GF"x&)" D#),0I-*-L# j
(2&)"{I `& . #f(Bc(hF,0,'#),Xa
8EaM;(
%
(- ($
(-
(-
A-? D ? = CED
(-
(-
*P&)L& 2# M7
*P&)L& 2#a
.&f" Bc"T& *P&)L& # -7 *P&)L& #a % I F/ +F(#),#tITD)BH&f"O@BO IPF,F*P&.#)(C/F*P&)(*Q
Y19m(*P#)(3
F/6/&4/0IT D)(2&G*P#XS&+"T&t H&),*-I IV)( &J7R9RS*P&)"eL&)(,g&n@BC

7
7 *Pk'&)&)L/& # k'&) / *P &)L& 2#

% I
F/6d&f<f#f,=@BOnY
7
k'&)/ \
5 k'&4/ ?
*P&)L& 2#
%
:ca
(-
.#)(2*-,g&),=F(
(-
>UaM;(
"$&7
<+*P&)L& 2#G&\7
D)IN/F*-,'&),J"Z(
_2a
(-
uBc(2&GF(*-,'&ESE&J/FIN( &)/0ITD)(2&),A<+0/F*P&UkF"T 3F,6"T#4/ .&)^H#4/=k'&4/X=&=7

.#)L#F"x0/*P&ESE#n&i&)/0ITD)(2&ESE#Ua
/-
*P&fd& 2#49R&4/
cL,g#nSJF(*-,'&ESE&nS="T&\7

SF"H2,'# 3F/#v&4/# I&ESE#F(
k.&4/

/0BG76Y
â
I#)(2&),tBc(yf,''&iSA+FL#),FI&
(F"H&4/#G8EaA0/jO#4/0IPkF"tBH*-IN"{I X&),Mw&),FI-#)/A&)" DE#),FI*-L#4/mH&),'&d/XF"
"{Ik,'
C = G

>

?IH

>
;-= C@? =
? G ?@DFA-D ;
? LG D = CED -*
? ? G C >CE? -*
?
? G ? DFA-D ;
? ;"x&)" D#),0I-*-L#S
= G

-
0Bc(I#)(2&iITD)BO&)" &f"ZwXIN/F*P#vF( F"b0/@BCFL&vS
H&),*-I
I#)(2&f\IPF(*P#LF/F*Pyf*-I.#a ;"e&)" DE#),FI*-L#dS - ?IH

-
FBU(I-#)(&49bk'y)/0I.&)+F(*Q09jITD)BO&)"@BO
F"
= G

-
3 #)(n"$&t/&)"{w4'SE&S\SU^@BO^&6"T& c #),'&S,.'&)"{I `&),Bc(2&k U/@BO'S&J(2#!I `&SU0/S
F" .
#f\IPF( `#vS"T&G" IN/F*P&i/FIN(#G@BO\"T&i/0ITD)BcI(*QLk U/@BC'SE& . #)(2*-IN(CBO&&=H&),*-I,\S\"T& c"{*-IL&
@BOG/vF( .
#)(*-,'Va \
v0/*P& L&)(F,'& /GI(*QF(2*P&hFwXI-*P&),.WE&)JIN(&),nkF"T#X@BC0/\O'@BO #4/@BO
/0BCF"T(
#)(3 F(2*-,g&),0/L&)"ZI(CI I-#iS="$&+" IN/F*P& . #)L# . #)(C/ BCF( I-& S=&)/0ITD)(2& I#)(F/ 2,'wXI-&)/a
3
%*

*
)-
( "8
? G

>

( 8
)-
($
= G

>

? ; ? = G ? DFA>D ;
? ;( .#)(*-,'&LS"+#),M@BC^/XA&ESE&0*QF9j0/*Qt&)" DE#
,0I-*-L#0/ .
#.DjH&f,g&J&4/FI$D)(&),!F"OL&)<E#),!kF"$#`@BO^"{IPkF,'à % I(*QF(*P&\SM0/F*P&=L&)(F,'&6JI(CI\I X&f,
"$&L'WfIK/*QF(
I&LSmC'@BC 2#4/ BC. #4/F("T&\+FL#),0I&!2,'#XS)B ISE#4/RH#),6F"z&f(*QF,FI-#),A&)" DE#),FI*-L#a
)-
)-
(GF"4H&4/#t:JSF"&)" DE#),FI*-L#^DF(F,'&)"2&f(*QF,FI-#),F+F(*Q^'W02BC0/F*P#)9bF"4H&f,gy)+*-,'#GY
,.'&I-V)( SU C'@BC
I^2I-SfIN,A"T&
)$
-?@? = G ? DFA-D ;
? R/*QJ&)" D#),0I-*-L#i\I(CIJI `&d"T& .&)(*-ISE&ESS=+
d#f,0I&S0/&02,'#)w4H&ESE&aJ7#),LF" .#)(*-,'&),FI-#
0/Ly4/="F(*P#)9&ESUFLy4/JS^2,g#`S)B IN,Ô'@BO #4/
BO .#4/=I(O/0B IPF(*QF/ H&),'& FBH*-BU,'&4/&4/FI$D)(&I#)(0/Xa
*
&dBH*-IN"{I X& IV)(
BO .#4/JF(
"T&L+FL#),FI&a
F"1F/@BCFL&nSH&),*-I
I#)(2&f\IPF(
(2#v/62,'#XS)B 3 F,'&XD)+F(*P&I-V)(
'Wf*QF,F(2&
BO&)(2S#"$& /FBUL& Si"T#4/+*P&)L& 2#4/

c(L,g#00/#49ZOF,'#n"O
c #nS=@BO=(2#J/'&)(
S6"$&++FL#),0I&iF/DUF(F,'&)"{L(*Q+#f,6(

*P#S)I(2y)JI 3#@BO0/*Pyf*-I .#a

I(*QF,F(2&49M(2#
2#4/
w&=&6IN(2*QF(*P&),
(
c&Uk.F,
#k0/F*P&f(*Q62BC'S
"zH&),*-I I-#)(&)JIF(2*P#SfIN(2yf\I .#
0,'&XD)+F(*P& I-Vf(
(-
BC. #)/6" IPkF,.0/0/^/FB " I(*Q;O&),g& . #)(2*QF(F,=&)" D

.#f(*-I$DfBH#4/ I!I-S /0BL&4/FI$D)(&IV)(am7#),*P&)(*P#49e"T& c(CI 3&t/&)" ISE&RBO'SU/XF, w#)"{w4F,^&A/0I-*-BH&),&)" D)Bc(2&4/
#
*P#XSE&4/d"T&4/!O&),F*-I
I#)(0/iF(uBU( 'Wf*-,.FL# SL"$&vLd#f,0I&< &4/ .#)+kFI(2&),d"T#4/d&`D)B0XF,'#4/GF(]BU(&
D),'&)( y),.'&n"{IPkF,'à
F/F*Q.
#)( 3 Q*P# SR0Bc(*P&),*P#XSE&G"T&GLd#f,0I&i" IPkF,.LF( BU(U BO3 #+D),'&)(2S=/X"T
S(2#)JIN(& J
; DFJ
DFJC ! - a
St"$#)/
? G
C!
-
A-? D ? = CED ; D =

CEJC
- DFA>D
0K
100K
S.O
Px
220K
320K
Pi
Pk
470K
1000K
bdcefg 3 h 3j2nPpq}gPlmsgPlmboPk
#
!
"#$ %'&()*+")) , *- "#.0/tk001.#02")43&5!.) !
.#Pk04
k00
.
&( 26
7.) '80. "0
Ua9.% :"#/;.<
- "$
" 7=0!
"0 & '6
7>?6 @.!&A2
5 B*C!
"#$ +D=
@. &5
@.%>2E(2 0FE#.G'
!.
# 8#.=&Ck0"0:"CH @.C'8#.0 6#.
*I J( (/K(0")
+&*F6
.J.#Pa
9LM#.3&50! 7L
y@.<?'0") N

- $ 7 . C
"I.#&( "O
P6 4H 7!
"#$ +,P k0"=0Q&A
R")
STH U=0!
"#$ aV9L &( H3&*0" .
@/OH
W*7=0!
"0 S#.
@.0
. X0
0
BDB 60Ly@.Y0Z.0[.E0! 1*XkT.
#(
"0 "T")&Ok0 \:2yO a^];
"T 2
10W 63&50>H
@.
.0[.E0! @.Y3&5 " 8_Y&A A ")( ,` "= "a X S"0O& k b >2 y % @/2
B. .0&(0Q #', "
( "0 $
2 %0F
4 >2 y % 8
a
#
@.C#.3&( .CL'"a
E $ QD&.

"
40U0 8 @.
4Z " $
2 O0F
4 >2y %
.
cO&AD.0:%>H "#.G 8 @.
d; "
2 %$F
40.0Py
a
2nPk.lmwde.xbonPk.ryx
9L2 "

' %$02
Y > %
7")3&A0")d*0e%[.0
A ")(,` "+3&(40' "
2 %$F
2y
#.0Py6
Ua;];
"G 2
@/NH 4 ")0 + + " 70.
,` "Xa
^f %0g:%>2 # ") -? =0F c>FE0"02
a
+ -*
=
A JJC!
-
D D
? G
C!
-
A-? D ? = CED
8
F") "#$
40A "
2 %$F
+#.
@/`
-6 !H ==0!
"0 2&(I.0"I @.0H? ' 66 4 &A
*5
I2")
? ") ! a
Py
Z& ") @02 0F " $

2 O0F
d > %
T#.OH 0 $6 6Y
-" H
" 2"a
8 ) $
O0F
.&*D6
@.4")3&("#>%$02
@.7*4=0!
"#$ =2&5)0^: ")!F "#.7 &A") FE+.0&V &%$

Gw
];
"
F") @/0A "0$
2 %0F
! > %
")3&A0")%* &A2 ! D6
"
F 0:g$6 6D&A2
@.
?
"#!
@.J@.
2
.O?#.0$ UG=0!
"0
# # ") -? =0F 1)RE0"02 I2&5)C.0&-

'0"I&A+2"a
0 G502 g *P 26

c&AQ$ (
d
H
- $
9L "
2 %$F
% : %
G.-&A>, *- "
0 63&(0>
@. 0F
"#2
.6
2 "$?6 !<") ($
)
%0. :2")0 9NR [.E0d!
-0
@. 0"0
@.
0>2 2
O
@.M "
' %$02
@.

""!$#%!&

'(*),+-(/. 0214365 7,.
8 2 O! '0") !<") & >"C0 ! (-2

O=) $
= &*2 =0! 26 * =0!
"0 !#.J :9-:"J0 #.
O >" $

'#.!C&A *5
G2")
80.
Y;H
-3&(#.!3&5 2&5)6 Q.-0"C
66
@.0; ") @.%C=0!
($
"0 Y2

FH?& c9.
0.=H
3&5
(.0&*D+ G ? @? -< DFJBC ! -= # .-$? =0F ^ 0
2")
#
" $
2 4"0*& 0 $ B > % !D=.
N.0 66 @.
"0 .I*Z'"a
E $ QD!&*.

"$6

# @.;F 6#.ZH8? 8 @.8/e

<.$?!F
@.8/ .

"0! 66
@. 0=0
G* ") 6 & $ 70 2")
? ") ! @/
- ?"#&P 2
&AF
@.JH
.I00=0F
.I")0 $
2 6
@.I? =0FE#
@.G6
. D=H
@. P H?
@.
")$
$6
@.
\
"a
.%2"a
8#.
.=2&5)W.0" .#& 6
@.c0W&A2
@.7.-$? =0F
@.=2")
#2$
@.c) 6
@.!( "a
0>
@.
# @.T :"

#.c0 H
@.4.#:.0E .+.-$? =0F 6
@.T$0 0 6
. 8

'02E#.>S0;2
0"Y0
.-$? =0F
XD 0J#.E2H 1*- %0F
F"a
0.$? =02
@? &( 26
S
@.c *=0")
@.QY.? =0F
@.
A 2"a
D6 $ %
@.2
0"#.=O.-$? =0F
.BTDd.#&*.!#.'H +*P %$F
@.%")0 :9
@.+F"a
c0 .-$?($
=0F
Y#.0 X NF6
.8/;H .6
.
(
'0FE0.!*&A2 :" $ C
9->"0&( M$0F X
"0!
A5
7
-6
.O
@.0=02
@.*0F")
0`#.E $
*! >") $
'#.+%&*T2"a
8#.
9.0 T:" $
9->"& <0;.-$? =0F
X 80
" X.0" 8
* 9@0"$6 0 H S >") $ [.0 X)3&A: 9 0FEQ S")D 9 #.Y
? A ! 5:.#!
dG"a 6& E
? &( 2
C. .
, ?&*2 "$?6 = &*O2")
80.
%.-$? =0F 6
@/02.#:.0E0! %
#(0") :9
>FE02
@ .0H?2 "!=0!
"0 =( "a QH
@.=.$? =02
@.=.0&*%>5[."a 6
@.F8 . 2
c&*c "0$
2 %0F
YH8? 8
@/
.0:%>H "O > %
@/L&*2 G( "0$ . ") 66 C2&5)%.0" ") 66 % ") T &. "G @.G 8#.06 #.
66 7.$?!F
%( "0 &AH " # @G
. ) . A
E5
&A"a FE ") H O " $ 2BdD 0
!( -'
A #.E( 6
70c0 !- &AH
+ 8 "?H B= &A7.? =0F
"$?6 66
@/`.
T"$? :.0") 66
.Gc0
< D 0"K D A>? A-? G J = C ; <I = ? G
A>? G J = C ; <I = A-? G ? ? -<I" F
P6
@.C
@.O*#. "0 '
"#. 8

"#! BHJ
- <IG ML ON

A>? G ? @?
0 I`.-$? =0F

@. 2&5)L.0>&( "#. ")$?[."a
@.
I0=0!
"0 J8 2 0H G.? =0F
@.
02 +*P 66 0X")$?[."a
@.I2&(=.0"=")-0"0$ 66 c%&ADT"P#2$6 =0FE # T.#&A c YH Q) @.-+DT
L ? ?
- < DFJC!
D
C - DFJBC !

-
8
") $
B0 >OEZ2&* 80"#.G.0:%&Ag ) =0FE; ") ?6 ' "I$ (

9LX0 .
c=3&(!.!E0*?6 1%& A
@.O.$?!F
@.8/2
Y#.%") +*-
' 0!&*. "O"$? :.0")
@.+ 0
7.#&B0H9 6

.0E O%!
-
Y3&5!H 0 %.$? =02
@.%..#& B=0!
"0 f ! :.
'
*J&AY"$? :.0")
) @.-C*J = 0H 4J.$?!F
@. A
f B!3&5G 02&*2 + =H + 0 2 0 6 6
3&(40M A!"a
cO.-$? =0F
.= ') 6
!
"=022")
? ") ! '&()*9@ "#$ "! 2g !FE#/;.&.
&AX")? [."a
1+
*?>&(Q4 c 0 Q+.? =0F
@. A
# f B +
"#! >+.0 A .#/$ Bc#.=&A2
:" $ U? @/ 2"0:=0")
+.I.-

2"0&( d.#Z0 A=0")
7I.$? =02
4.O#.G$?6 ,/ #.C >"#/.0
.
# f f eH
7#.#/Z0F
8#.C.O( -2 6*O
f =. A .
f BP/N"#.#&AH 26
7 @. eH 702"a 6
VH H Q9L.T00=0F
B4 0 c.+#/IDQ = ":"d0;#.E2H1 *- %0F
c.-d
0'4
:" $ [.0 8 #
@. 9
"#.O%#.
@.C6
@.J"$? :.0")
@.I.-C ,! 82 Q
0 0QU2] ?
C#.Q0N2&*2
V 9-:.0 X0 f '&/O 1.? =0F $ b0.c#.0 ,=0FE &*2 9 0"8.0W*
Q=0!
"0$ 4 "
2 66 S > % 8 =0FE#/8
^ Ag 2#. ) @.-#.7DQ >%>E#. # B=0!
"#$ 10.
.#? 2 66 40
"0! =Z "
'#. 9 "0 00.8/` '"#> -0")$ 4#.G3&5O 6 =.$? =02
>2 : 9-$ &( .- B .#? 2 X&A2 *U #.+ "
#. # @. ) .#.QDV :%E#. QH
.Y.-$? =0F
@.
50"0E' 0FE#.% &A2")
8#.
76 66
.
d? &( "a 66
@.O0YH f SD+0 2] ?b0A2")
8#.
d 3&5
50"0E' 8
9L 2")

; -? 66
;
"ZH J.$?!F $ 70F#.( $
C >")
'#.;&*I2"a
8#.
%#. 0?6 @.
@.#$
2 6
G
"O g 802 %0F
+Dd 80.
T + @. f # d @.#? 2 Q 6 7 :"
9P:"& ("))3&*0"J<6
@. 80.
@.< G=0!
"0 >Z&*2 O GH f = ") CH O @.#? 2 9->"0&( 2 [.0 /
D7&A2 7.$? &A26 ! "a #)0"d T O
.#X=0!
"#$ :.# *#.) 6 49.*>"8/ .-") & 8
K A
4J
) 26 d - : 9
d % 6 8 2
@.0 0J.
g& = @. <
"J&A>, *- "<&A2
@. &( F
@.
"$? :.0")
@.+6
2C? & "a6 "!H .=F"a 6 @.=!H Y 0 T&*. 6 @.
@.O" 0FE!FE#/
SH
c3&5.-
") & 8O +"a 02 *P $
Nmero de segmento
Tamao
0
D
1
500
2
C
3
S
Mdulo de carga
Tipo
Datos
Pila
Cdigo
Cdigo
bdcefg 3 hjv>u3ewonqurl@g

fc*g
9 'H
A 5+ " ? &A"a B2>
8 2 !")-0"0$ d ! <( H 0"a

40 .-$? =0F
d0.0 d0 (
@.#$

")
4 *0 .-$? =0F

Y#.0 TQH C(
@.#$

6"a 7 4 0 .$? =02
2")D
9
8 d&*' !>FE0"0"#&P $ B f '&(
")3&5!)R8=0 ! (-2

g
ftug
ftr ur%}ftnPstrylylmboPk|e.xtnqlynPpq}g
fsboun
#
"#! d 2")
E B@.I2 &A") ( "a 4.0[.E0! @.CG.-$? =0F
@.!#.G 73&5C.% #(
D6 T0

@. "$? :.0")
@. ) @.- DO >%>EL9LK#.
+J >" $
2 %0F
!$? <&AO2"a
8#.
d#. N5$6
(
"<
P6 @. @. 02"a 6 @. <.#& f ?e

!R8E'
J ") =0 @.
!.-$? =0F
@.
"$6
@.8/e
+ -< = I

A JJC!
-
D KD
? G< C!
-
A-? K D ? I = CED
0
(DATOS)
d-1
0
20000
(PILA)
(COMUN)
499
0
(CDIGO)
c-1
0
(COMN)
20100
ssub2
40000
(PILA)
40500
(CODIGO)
75000
(DATOS)
Max
Memoria
100
s-1
Mapa de Segmentos
bdcefg 3 h 4 jg

}g urrmcp rmk*stnx
.-E ") $ !H

@.= :.0>F
@.!#.( $
@.+4 >")
'#.d#. A Y")0.( "

26
Y.? =0F
@.
-0")FE#.%0 ")) .OC=0!
"0 7 :. &AF @.8/` 5 @.% FE0"0
"0=0FE)R02&(0.0 @. ") +.#:.0E0! @.

Q .#? 2 $ Q > % 8 .
02, #.O 0 Q0B#.E
FE)R6

&;")
)$
$
&5#. U#.J <2")

E UF"a
40 0.
4C :"
' %$02
43&(Z2&5)C! '
9ZB @.
7 C2")
E $ C9 T:2g > S0
#E'
cO.-$? =0F
>
!
@/
"O&*d'"a
# #.

? =0FE0/ A 0 "
C
.-$? =0F
.< 6
. DO >(.0"0&
'#.8/ .N2&5) :$?6 " % N5>"Z.? =0

@. .
E &A"a =
O* &A") a#. "0>&A"a /"
d
& 4) @. ")
2")
) ".#K&A2 %
#(0") $
#.+
c'
8
"#" Q
9L" &A2g:%0F
@.++
@.+") A
@.Td 8 0.
1S
@.!.0[.E0! @..? =0F @.
#. Y
2
"0 ,=0FEd .
$ 66
8
^0 "a ` ")T4"a & ^d >") $
'#. 2 8 =0FE#/

@. 0 >. 3&( :2 4
@.") A
@. * 8 #.
+#. d: ,&A
@.<0dH
.#. "# '
"#. *;.-$? =0F
.
&*") FEdH U .#? 2 $ d&*2 Q:" $ (/0L
QT 8 #.
1*#.) 6
1#.
2")
) 6

F"a
I

@.+0"
@.dd 8 #.
B0N.$? =02
B0 &5#.0$ ? & H3&A0"=>FE0F
-9 $
$ c2")
- & 8

O"#.0&*H 66
O&A2 # .
" H C"-0") $ ! C!
"#$ %3&(G#.0 2")
8 #. 26
8 7E0" # 0"
= 5[.0!
!`2")
E (/L3&5<.0&(0I 0 "8 0"OTH f /N#.J4) . 66
40 J @9 #.I]L"a
6E
$ 8 >, - 26
#.E%
-
72
4.- 2&5)+ 8 0"4 7&*Q.-$? =0F

B&*1 *=0")
*O5:@9 0
=02
"G3&(% 3&( 0K.-$? =0F
7* 8 - ?6
73&5O0.0 !
@.O & 2

($
($
/,
.$
L ? ?
- < DFJC!
D
C - DFJBC !

-
Violacin tamao
segmento
Dir. Lgica (3,100)
20100
<= s
Base
Tamao
75000
40000
500
40500
20000
SDT
bdcefg 3 h R j tx z>e.rmp{gqur%ryxtsboPk ur rmp nPfbg ! Pg xUgPunqrmk rmcp rmk*sgPlmboPk
0
1
2
3
4
Base
Tamao
1400
1000
6300
400
4300
400
3200
1100
4700
1000
Tabla de Segmentos
bdcefg 3 h j g

wg{ur xtrmcp rmk*stnx} rmfstrmk.rylmbormk*strJg
w
rmpq}won
#
)R 0>,$6 6 DdH :g 6T0e&*.

"
c#. XF")!
@.% "$? &A=0F
@.@. 0&50" $
E0.+ D9
"+=H .-$? =0F E #
@.+

@.
"$6
@.8/J #.
!
P H?
cDc6
.8/ .

'
"#! g=0FE

6
@.%0c.? =0F
@.J.-E ") 66
@.ID4) 66
.; ") 70:
@.8 .-$? =0F

$
( "0$6
d 8G.0"G @.0H?2 66
@/
"I=) $
4GH @.C 02"a
02 6 @. f / !
@.C#.( $
@.OO >") $
'#.
9P:"& #.C*G
P6
@.I
@.L2"a
8#.
.%3&5%#.0 U &
"0 *P 66
@.G +" ")0 H
@.
# =.? =0F $ 1#.J@.# =0FE%&*2 @9 "8.0 UG +!

"#$ I " $
2 6
Q * H $
2#.I")? [."a
. ) @.-CD! >%>E
9Lg:%>2 # ") -? =0F c>FE0"02

^f
#
"0 70 "):%0F
7 > %
+*I
@. .? =0F
@.
]L")
E $ UD=&.

( "0$6

0. "0"a
:
C]Z"a
?"a ! c
P &* "#/ Y"a 29 # .+!H T.? =0F $ (/H
&( N2 &A") $
C
=0FE+2
@.
2 & 8 cH Q N570F$6 60.+=02
"#.7I2")
? ") ! Q"0H
2 66 @.
H8? 8 =0FE
+ -< = I
A JJC!
-
D KD
? G< C!
-
A-? K D ? I = CED
8 2 17 @.T#.H9@0F @ . 9-0'c6 6 4

"7 7
@.# 0>,$6 61
(/ '&(#.
13&(
(("#%:"C3&(O&A42")
8#.
:.(
*?6 7 9@ "#$ @.;( "0$
'#.#/ @.%#."a 6E$? $ @.%3&5C.0&*"$?0
") =
- $ .
c@.
2 @.
0@.J !") 6 & $ UIH @.I >") $

'#.9->"& #.G =H @. [.0 .J I.0"<.
0
" 66
J
"
A ") ` "#.( ( ") 7H9- "G&A2 =") & S0U0 A
d ) 26 dG !=0!
"0$
(,
9L
F

U&A^.$? =02
d2&5)T.-0"dG .? ") 2*Y3&(TH U=0!
"#$ :.# B :.(
5 0
! (-2
=GPR :!
dG
@. .$? =02
@.") C2")
00! @.;( "a 4") "I +H8? 8 7% >")
'#.
0c#."#& &A"a @.GG6
@.J $0"
! /-2
@/
!
! "0 ##.%&ADG? "a 2#.L9L.0 @. A Y
.0"I>20=0F 66 .G 9 "#$
@.J.? =0F
@.
""!$#%!
J1E),5 .%14365 7 .
9L62"0: 62")
00! =*H @.<")?
'#. 9 "0 #.#/#.8/
!

.9-:.0
@/MH #") -? =0F c)R($
E0"02 # ( -? >2 $ Y#. &AY#.3&( +Z?#. <=0!
"0 %3&5G0g>O>2 C
@. ")3&50"#>%$F
@.
I 4 .#? 2 $ QG=0!
"#$ :.#
F ? &( @/
( -? >2 $ =2"a

0
"
2 4&*' ") =.E "a 1F")G 9P[.0 3&50K&.0& "#$
4$0 G
=0!
"0 =D 40!
"0$ [.0 8 Z9LK&.0& "#$
")%3&(G !=0!
"0 d#.J&AQ#.E $

F ? &(
43&(
A5 =0FE
2$0 %.0&42"a
8? "a 79L1") g$6 6 .#&42")
? ") ! Y.40&(02"a Q :.50"8.
%(
"!
=0!
"0 =g 0"#/L3&(O 6G
.Z2&(

FE'0"O
6"a
@.Z'"a
?"a ! @.
@.0 !FE4 =0!

"#$ :.# Y.-T0&50F") B 9-$ $6 U0 &*V *=0")
UG(
"
#.d
! '

O02
%>2 66
. D = J IG A>? ; C - D \.#&9@ 0/e'#.( $
< :"
#. 9->"& #.
I&A='"a
# #.
T#. d
P9 $6
d0 0
-3&5#.OC ! 2

!> ! 66
@. ;
C- D G
(-
(-
9Z'= 8 5:.#!

40. %&AD%.#>2 ><
F") "J&AY *=0")
.0& "$FEG*J! "
@.GZ -? >2 !.#>
&*. " "a c 0"$?6 "! @. -? >2 @.")3&50"#$6 @. (
"+022")
8#.
# T") 6 & $ @.! >")
'#.
@.
$ d
6 G -? >2 9->"0&( K.0&% -?:2 [.0 8 ;]L&5#.0
d3&5CH .Z -? >2 @.J.-C .#? 2 Y.E( "a 6 ($
=0FE0/L
@.% -0"0FE#.%! " 8
@.= -?:2 Y @.#? 2 6
@.% 7&*d'"a
##.
Y2
B=0.0 "
2 H? &(
@.
0c=0!
"0 :.# =' 80. "0 !FE
9 .0[.E0! @.L -? >2 66

.GH +=0!
"0 d#.C @.0H?2 66 70 26 #.CO ! (-'

=: ! 66 @.
Z
P? :' @.Y9L` ! (-2
+&AY -? >2 9-0'd*E0"0O>2 6
=
"=&A
&AF
Q
"#.43&5=.
"0 P"
2:5&( $ 49L f & ? & "a6 Q0Z#.0 6
Y 6 &A2
c!H
@.! "
@.+ -?:2

"I=) $
7C&* ! # dC=0!
"0$ :.# @/Z0 &( (2&5)O.0"#.0"0& -&*") 66
8
!
4&*2 4 E0H
#. @/L3&5O02
O>2 "0!
@
. < D 0"K D A-? K D ; D A>? ? I = C D N
?e 6 Q0F") 66 U+
#. "0Y0Z0.0 66
#
9
f &L/<*4&*X! "
U
P ? :' 0U=0!
"0 :.# I]
"O F
@/Z&*2
^$'%&AU ! (-2

7+0F") 66 @.3&5=#.
$0F
4 A=0")
4*I! "
@.C*Z6-? >2 70Y&Ac.#:.0E0! 46 66

2 # .T0Z A!"a
U*d! "
@.TG - ?:2 / #.+ #( $6 6S4 =
0!
"#$ [.0 8
>(.0 H 6 D # .Y0; ! (-2
1d 46-? >2 G
"#! g=0FE#/O F
8
!
.
Q(
E0$ @.
L ? ?
- < DFJC!
D

C - DFJBC !
F
-
FE0") @.7*O) @.-/I"#.#&AH 26

=&A A!"a
B 0 ^0FE0")
CY#.0
"0! Y. >,
8
*9@0"#.#$ Y*<&*' :" YH8? 8 = O&A2 :.# <.(2&5#.#/e 2E<&*' (% ") "$?6 " &A
'"a
##.
7C !( -'
.#/L0 f & * @.0H?2 "Jc "
.C; -? >2 +, 0"#.G 3&(

02
26
8/`&A2 0&* Q3&(*H9-&50 9 &AQ")0.#&Ag 6
0FE0")
T
E05$6
7C")6
2*) "
"
R8#.
S0
$02Ed.0 U :9-[.0c2"a
P & #7&A "#.0
1 [.:2
c* 80")
S9.J
"T0.
@/G3&54.0J0
'"a
##.
2
#.%&AU%&*H 'H
FE0")
YM /-2
76-? >2 @/0 *H>
7 "
c 6-? >2 Y#. "P
( " g=0FEO#. #2")D
9@ A 66
9.0
d#.J
=3&5I.
2
#

!
= D @? -< DFJC! - A>? ; C - D /
3&(G2
d 4I.0"I&A @.
I "0 &AH "% #") -? =02 $ :FE"#2 4 =5 9 0 ; -?:2
9L!.0[.E0! @.
G -? >2 $ (/ H G"a 6& * >" $
'#. . :H9 O 8 )

d G D &(6 C*
&A2 O 0 @.0H?2 $ d: ! 66 < D 0"K D3A-? K @D ; D3A-? ; C - D G N 2.0 G.-
(."#&AD
\$ (
"$?6 ^*02"a
8#.
U "a #.0 0 80"U
"#"#.(
20 W02")QH @.U >") $
'#.
9P:"& #.YDB @. [.0 . G DB&A2 02"a 6 0^]
"! -? >2 9->"0&( I0\0e2")
80.
9L
9@ H
"Y 66 F"a 6 V#.c0 A=0")
S*T! "
V P? :' X B!
"#$ :.# S6
2
8
"#"#.E
2 0FE -? >2
9-:"&( #. 8
H
66
9 'H
A 5+ " ? &A"a
B>
N pgina
0
1
2
3
Marco de pgina
1
4
3
7
PMT
N Marco pgina

];
"I F
A D!&*'
#
0
1
2
3
4
5
6
7
Pgina 0
Pgina 2
Pgina 1
Pgina 3
Memoria
Fsica
LIBRE
ASIGNADA
LIBRE
ASIGNADA
ASIGNADA
LIBRE
LIBRE
ASIGNADA
MMT
Pgina0
Pgina 1
Pgina 2
Pgina3
Memoria
Lgica
bdcefg 3 h j tx z>e.rmp{gqur%sg

wgPx-rmk }g
cbdkgPlmboPk
Y
"I.#:.0E0! =D= F @.]

!
I2")
8#.
@.O - 9
.
9@0
$6 6^0J ?6
"0>!
V7?*#.0$ \c S=0!
"0 0W&A #.3&( ^= P? :' $
9 02 "PY*E0"0O>2 6 O
"% @9 H
6 8
X3&(.%.) # +*=08
F") "! " 8
@.=<6-? >2
g 0")0.=9L.
"+0:
c3&(.=
! "P 8
!
c#."#& &A"a +6
. "a Y =?#.X!
@.O! "
@.
*Z6- ? >2 !g 0 ")0.G&*' !g[. 45H - 66
1*
1*
5
3 &5 6 #.( $

Q:" $
'0.U & J*c&*S'"a
##.
Q2&5)Q.0"c%&*DS:0"0$
"c
-R:!
;(0"0O$6
@/( ")# ") +*-
' 0 8
(.0"0&A:" 8 66 I]
d F @.02"a 6 @.
!
-?:2 .
E*?6 702")
80.
T0 &5#.0$ ;9L.0
!.G:H9 "
d )
8
&* A ")(,` "#.5$ , *- 6
>

. ?
C G< = I K C < ?OA>? K D < D K D A-? K D ; D6A-? ;

A!"a
d; -?:2 9->"& G
.I g
4 NF6
70c O]

C - D G
F0'Q0
+ -< = I

. ?
C G< = I
:" @.%G O]

A JJC!
-
D KD
? G< C!
D G ?A-? K D < D "K D A-? K D ; D A>? ;
A-? K D ? I = CED

C - D G #2&AF S
#
@. 9 H
"#. #.
@."$? :.0")
@.L.
4 N5$6
@.;0=0
I 8 "? G0P2")
8#.
IDI g! 80' 66
@.
0 Q0'] ?_*0A2")
8#.
A
Y + D@&(6 40 "a/,` ")0/`H
.<.0[.E0! @. '8#.0> Q
@.G 8#.
@.
c=0!
"0 >T&A2
U QH ] \D
")
U U >" $ :.# U0 &(#. OT#. ! '0") c.
2&5)+") & >"71&A 0Z
c* 26 = =0!
"0$ 8 2
"#! c+"#.
9@0"7#.0E

!L2")
00! @.I0.<>F")
- & :" &AT5&5H 9
A ")( ,` "#/L#.J >"8/N&A2 5)3&5) -2 +=0!
"#$ !G H
9@H
6 ;( "a O g! 802 ";&*=.#*&
&AF
%; @. 0F") 66 @.;
@.Z&. 66 @.0+H G 0 C* P? :' @.8/
# ;/ 3&(
8
F0'N "#.J *=0")
@.<*N -? >2 @
. 9->"& #.<DJ.#&*
.
"0"#.
2 0FE#.< *=0")
@.
Z -?:2 d6
2GH .6 -? >2 @.O0 &5#.0$ B#. ,! 82 66 @.Oc =!
"#$ :.#
9Z #.3&50! ?0 0"a 0 &*
' %$02
4#.C0.#? &*0FE >
CPU
Direccin
Lgica
Direccin
Fsica
Memoria
Fsica
bdcefg 3 h j tx z>e.rmp{gqur ek.lmbonPkg

pqbormk*stn|ur%wg cRryxsboPk ur%p rmp nPfbg gPxgPun rmk }g
cbdkgPlmboPk
9ZO?0 0"a / .# #.05 ! (-2

O &*2 ; -?:2 / &*' C >" $ 7? Q9-$'R#2"#. 6
"
&Ad *=0")
N P? :'
%/ DO&*T#.E2 +*- %0F
f 2 ! (-2
%
&A2 P? :' +#
. Y&A5$6 6#.#/0F
##.<
@. / 0>>.J =0'
"N5#.
=:' 8 c0K#.E2H 1*- %0F
@/eD

@.J")0.0 FE0.O0 A=0"a
d; P? :' CO#. =! 0"a =.-Z'&()*H9- "I + :9-:.#$
9 02
f ) 70 .#? &A$02E#.3&50! dGH +=0!

"0 A +5" ? &A"a B>
8 . '6
c&*^ ! (-2
UC -? >2 U Y 0") @.7DY&A2 =0!
"0$ :.# U*
d H "a @.#/G
>"$ ?
"0")#.E
2*B X Y P? :' SDV#.'H+ *P %$F

:") 2
0 B] /
.-=
0.0H" 9 3&5+H -? >2 Y0.0 Q0 0N! "
<6 -? >2
+]
"! F
H c >") $ VH8? 8

"#"#.(
2< GH C :" [.0 8
"C0%:.#!
J!
-6
J/ G >") $ dH?
A -?:2
D+#.E2H1 *- %0F

B 8
"#"#.E
2! + >" $ [.0

`DH 4 >") $ H?

A -? >2

+D4#.'H+ *P %$F
HB!
"0")0.
'O 4:" $ [.0 8

g
ftu2g
ftr ur }ftnPstrylylmboPk|e.xtnqlynPpq}g
fsboun
2 ")
E $ Y.Z?6 "a 2 *P =0% P? :' $ =? ") $ @.J O =)R[.E0$ !0'"$? :.0")
:%E <
/L3&5O.%&. C ") TE "D4") A +*- "O>FE02
@.O 8#.
@.= d=0!
"#$ 4@.O H T%H
@.
L ? ?
- < DFJC!
N pgina
0
1
2
3
D
C - DFJBC !
Marco de pgina
5
6
1
2
PMT
N Marco pgina

-
0
4 I, J, K, L
8 M, N, O, P
12
16
20 A, B, C, D
24 E, F, G, H
28
Memoria
Fsica
Libre
Asignada
Asignada
Libre
Libre
Asignada
Asignada
Libre
MMT
0 A, B, C, D
4 E, F, G, H
8 I, J, K, L
12 M, N, O, P
Memoria
Lgica
bdcefg 3 h # j x z*e.rmp{gqur%sg

wgPxur }g
cbdkgPlmboPk }g
fg rmw r rmpq}won
>OE#. ?6 #.O0(2"a

8#.
9.
@.J")$?[."a
@.C >%>E .;2&5)0 9 "#$ "#/ (0")
!.
+") ) '6
70
!
-
!! #."a

&Z") 7! 0"a YJ9@"H C'"a

E $ C9-$'!6 6 C
"% T @.
$ $ S 0>.%= 8#.
dH .
F"a 6 @.Td Y] 2.
@. Y#.0 "+.
#
" 66
.G
" "a/,` ") <.N2&5#.dH
.O0>.d*
8#.
G2&(0c.0"IJ.H
= &*") 7
$0Y.Z2&5)G0"C
4#. "0 0:"#/N&
") @.
"#! @.IC 8#.

&Z")
4
-6
d HE0"02 :9
7 2")
E d @. G
"I @. D9@#.;2")
E $ 9L+2"0> 2
/
! (2-
S &*' 76-? >2 X 8
"#"#.E
2"
0 ! (-2
SQ0
-3&5=2")
E$? $6
Y(
"T&A2

A5 D9@ 9.0
("#%EQ3&5cH . -? >2 @.
"0")0.
' $FE#.U S&* A5
Y2")
8#.
c2&5)6
.-0" [.E(0"#. 6 @. "a 29 #.!% d=0!
"0 <.
$ 26
TH
.G0>.%H
.%0"
@.+! 8#.

@. D 9@0.c!2")
E 5/40< 8#.
B&A2 P? :' S 66 T2&5)Y.-0" "#.0"0>*? $6
& 26
1.
8#. "#$

9 &*.

( "0$6
T* -? >2 @.#.G) .0 FEO.0:>H
T .#:.0E0! @.
U&*' ?#.0$ B%!.$
L
!
"0$ -? >2 66 8 2 A5 8
#2$ ! &*2 < -? >2
( "0$6 '&()*<." >,=02EJ @.#? 2 6
d F
@.%#.E $
@. >") $
'#.
!
4.-#.- 5 73&5 8 66 T @.0H?2 $ 1#.O:H9 6 T )
(
" =) $
&A2 0F") 66 8
" =07 O 0 !02! # %N -?:2 .<062"a
8#.
40 &5#.0$ (/
-0"0FE#.Z2")
80.
@.;'&()*0UE0'0"O -0"0FE#.%0" A
@.%O 8#.
T =H I -?:2
"0$6
# -? >2 $ Q#.

6 ,=02E ?#.
2 66
"C0 f
? ") ! 66
"#.
&
($
.0$0'6
") (.( ")FE; ")
@.`'"a
# J -? >2 B0g>O>2 J2"P =0FEC # ") -? =0F URE0"02
# d @.0H? ' $ YDd#. @.#? 2 UG=0!

"0 d0c.#:.0E .( -? >2 66
@.G.
;) @. FEG.#>
2#.%! '0") T3&5% !?#.1!#. @. 0 &A$

'#.O:&*"0")+0Q%&*DC

@.<2")
8#.
@.%.#&%$
20=0F "0
.
# &>, *- dL J=0!

"0 :.# 2&5) "#.#&AH "Z.0"L%&*DG g 8
J P? :' $ &( 2
0 ! (-'
+G 6-? >2 7#.I%&*D 5)3&5)-2

];
"O
F") "0
@/`.C$' # ") -? =0F Q*L P ? :'
+ -< = I
A JJC!
-
D KD
? G< C!
-
A-? K D ? I = CED
0@.#/:. f 20"a*T%& A

X0
X0 H ?#. @. 0 @.Y ! # S -? >2 @.
A g! 802 O0F
B2
9L(2")
80.
c% @.#? 2 B
O0$U") & # = 4 d%> dM A
7 26 T*OH 4=0!
"0$
00c.I'##.# 4&* A "a(,` ")% 6 $

2 A

@ %

# " B

G=0!
"0$ 9P:"& #. &AY#.3&(0! !*?*#.0$ =0!
"0 %6
2 .H
C&A2 "EJ0K#.
Y >") $

'#. 9P:"& 7&AB2"a
8#.
S"#.0FE2&( #.0 " ")) ,=0FE 0 =0!
"0 :.#
9.%>"8/Z 4!
"#$ 9->"0&( F(0"0OEO T & S '"a
##.
@. "$?6 6
@. ( " g=0FEC];
"
2
@/ .#&A +
@.4#.E $
@.4*d :"
#. 9->"& #.7=H
@. '"a
##.
@.T :9
@.70X&*S.#:. $
E0!;
9-:"&( / 2&(YR 8)" #( $6 6Xd Q=0!
"0$ :.# 1 [.E
5 04.0$02"Y3&(T
=0!
"0 :.# =.) 4.0& "$FE0=0FEG? "a 2 "a !?& ")6 "%&A2 26 d
:5>! d0N#.
C >") $

'#.
66 I2")
8#.
T : 9

2
-6
O#.0
O#.Z:H9 6
G 8 )
C! FE0502
G04 ,! 82 %$F
J.-&A26 "0$
I&A2 >! -?0d0
#.E $
* >")
'#.9->"0&(
2
cO&A72")
8#.
@/ D7"a D626
d.- $
'0.! 7H d=0!
"0$
2"0> ; Q=) $6 B3&(7.
'8#.0> 6 @. @.T:.#$
'#.T 3& 7.T"a *#/&6 26
UDU6 2
&*0 "0H U#.!"#.E
(. 0 >,$6 6Q f
@.+ :#.++ 4?#.0$ = Y!
"#$ -9 :"&( e.

?'0") ,=02E "a (. ")02E#.< '"a
?"a ! 6
";
9Z 2")
? ") ! 66
" $'H C>,&*.#$ 7 :.
'0"
&A2 4=0!
"0 d! D6
"O T3&5=U") ,$6 6Y :.
#/;*#. "? 26
@.-+*OH "$?6 Y*O:2E0F "
3&5I.#&*.Z2")
? ") ! @.O3&5E 1Y&A2 +=0!
"#$ =,>%> 6
& #
# 8 # $6 6 % &A " 2")

80.
@.O3&(#. + "$ ,=02E "$?6 66
@.#/ 0.9@0F
@.
4*#.
0A'&*F
d 9-:.0 40 f ' & >
8 S2")
8#.
c2&5)1#.0 " "$?6 6
^0 &A #.E $
c ! (-'
V ">") "0
9L.0
2&5)
. 0"!&*. 6
= ") c") & :"d 0") -? =0F ^RE0"02 Y.#>1 8#.06 U 0$ "70L
")0
2H 5 " 66
I ") +H d & $ 1;2")
8#.
@.
# F 6 =#.

&*. 66
O
"%&*72"a
8 #.
6 6
C2&5)9 "0$ "%&*") FE%.#& ")0.#$0
S0=0!

"0$ ?e
!
"#.#&AH 66
@/=0 f &M2&5)c 80") "YH S & %2")
8#.
@.
:
" FE0.I .#? 2
0.IG . =0!
"0$ !")
""! "!&
) & 026

Y T=0!
"0 T")
&P 6 =
"
@. ' "a
##.
@.+")#.0*0FE#.#/ 0 ? ") 66
!%&*H $
2"a
8? "a 42&(C: ")!F "#.0 #.E $
9 8 FE ") d :9 "CG .'"a
##.
@.

. 365,. 1E+ 5(/. 0F) ( 0 5 7 . ( 1 +-(/+ 51520%1

# O!
"#$J 9->"0&( 2&( .-0" >20=0F 66
!
%&A2 =)RE(.#$ Y H J?0.0$ Y<=0!
"0$
P? :' 66 X
B.$? =02 66 b];
" F
@/%H S") 6 & $ c >") $
'#.Q9->"0&( #.c X >")
'#.
[.0 8 @.7#.d>H
9@ 66 B )
7
"d=) $
B*7 0 @.Td! #( BO -? >2 @.T
+
"d=) $
B*7 0 @.
#. "# '
"#. d.$? =02
@. # B -0") $ 9-0'Y6 66 d
")3&5%(
"
#. 0 #.( $
1
>" $
'#.0B & 4'&()*01#.0 "G &.-0FE#.%GH ==0!
"#$ J2"#>
GESTIN DE FICHEROS Y
DIRECTORIOS
En este captulo se presentan los conceptos relacionados con ficheros y directorios. El captulo tiene tres
objetivos bsicos: mostrar al lector dichos conceptos desde el punto de vista de usuario, los servicios que da
el sistema operativo y los aspectos de diseo de los sistemas de ficheros y del servidor de ficheros. De esta
forma, se pueden adaptar los contenidos del tema a distintos niveles de conocimiento.
Desde el punto de vista de los usuarios y las aplicaciones, los ficheros y directorios son los elementos
centrales del sistema. Cualquier usuario genera y usa informacin a travs de las aplicaciones que ejecuta
en el sistema. En todos los sistemas operativos de propsito general, las aplicaciones y sus datos se almace
nan en ficheros no voltiles, lo que permite su posterior reutilizacin. Por ello, un objetivo fundamental de
cualquier libro de sistemas operativos suele ser la dedicada a la gestin de archivos y directorios, tanto en
lo que concierne a la visin externa y al uso de los mismos mediante los servicios del sistema, como en lo
que concierne a la visin interna del sistema y a los aspectos de diseo de estos elementos.
Para alcanzar este objetivo el planteamiento que se va a realizar en este captulo es plantear el pro
blema inicialmente los aspectos externos de ficheros y directorios, con las distintas visiones que de estos
elementos deben tener los usuarios, para continuar profundizando en los aspectos internos de descripcin de
ficheros y directorios, las estructuras que los representan y su situacin en los dispositivos de almacena
miento usando sistemas de ficheros. Al final del capitulo se mostrarn ejemplos prcticos de programacin
de sistemas en UNIX y en Windows.
Para desarrollar el tema, el capitulo se estructura en los siguientes grandes apartados:
Visin de usuario del sistema de ficheros.

Ficheros.
Directorios.
Sistemas de ficheros.
El servidor de ficheros.
Servicios de ficheros y directorios.
574
9.1.
VISIN DE USUARIO DEL SISTEMA DE FICHEROS
Desde el punto de vista de los usuarios y las aplicaciones, los ficheros y directorios son los elementos centra
les del sistema. Cualquier usuario genera y usa informacin a travs de las aplicaciones que ejecuta en el sis
tema. En todos los sistemas operativos de propsito general, las aplicaciones y sus datos se almacenan en
ficheros no voltiles, lo que permite su posterior reutilizacin. La visin que los usuarios tienen del sistema
de ficheros es muy distinta de la que tiene el sistema operativo en el mbito interno. Como se muestra en la
figura 9.1, los usuarios ven los ficheros como un conjunto de informacin estructurada segn sus necesidades
o las de sus aplicaciones, mientras que el sistema operativo los contempla como conjuntos de datos estructu
rados segn sus necesidades de almacenamiento y representacin. Adems, puede darse la circunstancia de
que distintos usuarios vean un mismo fichero de forma distinta. Un fichero de empleados, por ejemplo, puede
tratarse como un conjunto de registros indexados o como un fichero de texto sin ninguna estructura. Cuando
en un sistema existen mltiples ficheros, es necesario dotar al usuario de algn mecanismo para estructurar el
acceso a los mismos. Estos mecanismos son los directorios, agrupaciones lgicas de ficheros que siguen cri
terios definidos por sus creadores o manipuladores. Para facilitar el manejo de los ficheros, casi todos los
sistemas de directorios permiten usar nombres-lgicos, que, en general, son muy distintos de los descriptores
fsicos que usa internamente el sistema operativo. Cualquiera que sea la visin lgica de sus ficheros, para
los usuarios su caracterstica principal es que no estn ligados al ciclo de vida de una aplicacin en particular.
Un fichero y un directorio tienen su propio ciclo de vida. Para gestionar estos objetos, todos los sistemas ope
rativos de propsito general incluyen servicios de ficheros v directorios, iunto con programas de utilidad que
facilitan el uso de sus servicios.
El servidor de ficheros es la parte del sistema operativo que se ocupa de facilitar el manejo de los dis
positivos perifricos, ofreciendo una visin lgica simplificada de los mismos en forma de ficheros. Mediante
esta visin lgica se ofrece a los usuarios un mecanismo de abstraccin que oculta todos los detalles relacio
nados con el almacenamiento y distribucin de la informacin en los dispositivos perifricos, as como el
funcionamiento de los mismos. Para ello se encarga de la organizacin, almacenamiento, recuperacin, ges
tin de nombres, coutilizacin y proteccin de los ficheros de un sistema.
9.2.
FICHEROS
Las aplicaciones de un computador necesitan almacenar informacin en soporte permanente, tal como discos
o cintas. Dicha informacin, cuyo tamao puede variar desde unos pocos bytes hasta Terabytes, puede tener
accesos concurrentes desde varios procesos. Adems, dicha informacin tiene su ciclo de vida que normal
mente no est ligado a una nica aplicacin.
Figura 9.1 Visin lgica y fsica de un fichero.
Gestin de ficheros y directorios
575
En esta seccin se va a estudiar la visin externa del sistema de ficheros. Para ello, se mostrar el con
cepto de fichero, la gestin de nombres de ficheros, las estructuras de fichero posibles, las semnticas de ac
ceso, las semnticas de coutilizacin y los servicios que proporcionan los sistemas operativos para gestionar
ficheros.
9.2.1. Concepto de fichero

Todos los sistemas operativos proporcionan una unidad de almacenamiento lgico, que oculta los detalles del
sistema fsico de almacenamiento, denominada fichero. Un fichero es una unidad de almacenamiento lgico
no voltil que agrupa un conjunto de informacin relacionada entre si bajo un mismo nombre. Desde el pun
to de vista del usuario, el fichero es la nica forma de gestionar el almacenamiento secundario, por lo que es
importante en un sistema operativo definir cmo se nombran los ficheros, qu operaciones hay disponibles
sobre los ficheros, cmo perciben los usuarios los ficheros, etctera Internamente, todos los sistemas opera
tivos dedican una parte de sus funciones, agrupada en el sistem a de ficheros, a gestionar los ficheros. En este
componente del sistema operativo se define cmo se estructuran los ficheros, cmo se identifican, cmo se
implementan, acceden, protegen, etctera
Desde el punto de vista del usuario, el sistema de ficheros es la parte ms visible del sistema operativo
ya que a travs de l accede a los programas y los datos almacenados en ficheros de distinto tipo (cdigo
fuente, programas objeto, bibliotecas, programas ejecutables, texto ASCII, etctera) agrupados en directorios.
Para el usuario, los ficheros son contenedores de informacin de un tipo definido por su creador, aunque to
dos ellos se pueden agrupar en dos grandes clases: ficheros A SC II y ficheros binarios. Los ficheros ASCII,
formados por lneas de texto, pueden ser editados o impresos directamente, cosa que no suele ocurrir con
ficheros binarios que suelen almacenar ficheros ejecutables, objetos y datos no textuales. En el sistema opera
tivo UNIX existe un tipo peculiar de ficheros, denominado ficheros especiales , que permiten m odelar cual
quier dispositivo de E/S como un fichero ms del sistema. Los ficheros especiales pueden serlo de caracteres
a r a modelar terminales, impresoras, etctera) o de bloques (para modelar discos y cintas).
Desde el punto de vista del sistema operativo, un fichero se caracteriza por tener una serie de atributos.
Dichos atributos varan de unos sistemas operativos a otros, pero habitualmente incluyen los siguientes:
N om bre: identificador del fichero en formato comprensible para el usuario. Definido por su creador.
Identificador nico: en el mbito interno, el sistema operativo no usa el nombre para identificar a
los ficheros, sino un identificador nico fijado con criterios internos del sistema operativo. Este identificador suele ser un nmero y habitualmente es desconocido por los usuarios.
Tipo de fichero: til en aquellos sistemas operativos que soportan tipos de ficheros en el mbito in
terno. En algunos casos el tipo de fichero se identifica por el denominado nmero mgico, una eti
queta del sistema operativo que le permite distinguir entre distintos formatos de almacenamiento de
ficheros.
M apa del fichero: formado normalmente por apuntadores a los dispositivos, y a los bloques dentro
de estos, que albergan el fichero. Esta informacin se utiliza para localizar el dispositivo y los blo
ques donde se almacena la informacin que contiene el fichero.
Proteccin: informacin de control de acceso que define quin puede hacer qu sobre el fichero, la
palabra clave para acceder al fichero, el dueo del fichero.o su creador, entre otros datos.
Tam ao del fichero: nmero de bytes en el fichero, mximo tamao posible para el fichero, etctera
Inform acin tem poral: tiempo de creacin, de ltimo acceso, de ltima actualizacin, etctera. Esta
informacin es muy til para gestionar, monitorizar y proteger los sistemas de ficheros.
Inform acin de control del fichero: que indica si es un fichero escondido, de sistema, normal o di
rectorio, cerrojos, etctera.
576

Tipo de archivo y Proteccin
Nmero de Nombres
Propietario
Grupo del Propietario
Tamao
instante de creacin
Cabecera
Atributos
instante de la ltima modificacin

Puntero a bloque de dalos 0
Puntero a bloque de datos 1
Atributos
Tamao KB
Puntero a bloque de datos 9

Puntero indirecto simple
Puntero indirecto doble
Puntero indirecto triple
Entrada ris
directorio de MS-DOS
Nodo-i de UNIX
Nombre
Seguridad
Datos
Vclusters
de WINDOWS-NT
....
Figura 9.2 Distintas formas de representar un fichero.
;>:
El sistema operativo debe proporcionar, al menos, una estructura de fichero genrico que d soporte a
todos los tipos de ficheros mencionados anteriormente, un mecanismo de nombrado, facilidades para prote
ger los ficheros y un conjunto de servicios que permita explotar el almacenamiento secundario y el sistema
de E/S de forma sencilla y eficiente. Dicha estructura debe incluir los atributos deseados para cada fichero,
especificando cules son visibles y cules estn ocultos a los usuarios. La figura 9.2 muestra tres formas de
describir un fichero: nodo-i de UNIX, registro de MFT en Windows y entrada de directorio de MS-DOS.
Todas ellas sirven como mapas para acceder a la informacin del fichero en los dispositivos de almacena
miento.
El nodo-i de UNIX contiene informacin acerca del propietario del fichero, de su grupo, del modo de
proteccin aplicable al fichero, del nmero de enlaces al fichero, de valores de fechas de creacin y actuali
zacin, el tamao del fichero y el tipo del mismo. Adems, incluye un mapa del fichero mediante apuntado
res a bloques de dispositivo que contienen datos del fichero. A travs del mapa de bloques del nodo-i se
puede acceder a cualquiera de sus bloques con un nmero muy pequeo de accesos a disco.
Cuando se abre un fichero, su nodo-i se trae a memoria. En este proceso, se incrementa la informacin
del nodo-i almacenada en el disco con datos referentes al uso dinmico del mismo, tales como el dispositivo
en que est almacenado y el nmero de veces que el fichero ha sido abierto por los procesos que lo estn
usando.
El registro de M F T de Windows describe el fichero mediante los siguientes atributos: cabecera, in
formacin estndar, descriptor de seguridad, nombre de fichero y datos (vase figura 9.2). A diferencia del
nodo-i de UNIX, un registro de Windows permite almacenar hasta 1,5 Kbytes de datos del fichero en el pro
pio registro, de forma que cualquier fichero menor de ese tamao debera caber en el registro. Si el fichero es
mayor, dentro del registro se almacena informacin del mapa fsico del fichero incluyendo punteros a grupos
de bloques de datos ( Vclusters), cada uno de los cuales incluye a su vez datos y punteros a los siguientes
grupos de bloques. Cuando se abre el fichero, se trae el registro a memoria. Si es pequeo, ya se tienen los
datos del fichero. Si es grande hay que acceder al disco para traer bloques sucesivos. Es interesante resaltar
que en este sistema todos los accesos a disco proporcionan datos del fichero, cosa que no pasa en UNIX,
donde algunos accesos son slo para leer informacin de control.
En el caso de MS-DOS, la representacin del fichero es bastante ms sencilla debido principalmente a
que es un sistema operativo monoproceso y monousuario. En este caso, la informacin de proteccin no exis
te y se limita a unos atributos mnimos que permiten ocultar el fichero o ponerlo como de slo lectura. El
nombre se incluye dentro de la descripcin, as como los atributos bsicos y el tamao del fichero en Kbytes.
Adems, se especifica la posicin del inicio del fichero en la tabla FAT (file allocation table), donde se al
macena el mapa fsico del fichero.
577
9.2.2. Tipos de ficheros

Los tipos de ficheros que reconoce un sistema operativo se han ido simplificando cada vez ms, hasta llegar a
modelos generales que permiten a las aplicaciones superponer sobre ellos cualquier estructura particular. En
general, un sistema operativo convencional distingue cuatro tipos de ficheros: ficheros normales o regulares,
directorios, ficheros especiales y enlaces. En Linux y UNIX se puede averiguar de qu tipo es un fichero
usando el mandato f i l e . En Windows se pueden mirar las propiedades del fichero.
Los ficheros norm ales o regulares son los usados para almacenar datos de todo tipo. Pueden incluir
informacin alfanumrica o binaria. Todos los ficheros que manejan las aplicaciones son regulares, aunque
tengan distintos atributos, son de este tipo para el sistema operativo. Por ejemplo, si se ejecuta un mandato
f i l e sobre un fichero de datos, denominado d a t o s en el ejemplo, se obtiene:
#file datos
datos: data
Si se ejecuta sobre un fichero de texto generado por un editor, denominado h i j o en el ejemplo, se ob

tiene:
#file hijo
hijo: ASCII text
Si se ejecuta sobre una imagen, denominada sf 25. gif en el ejemplo, se obtiene:

#file sf25.gif
sf25.gif: GIF image data, versin 89a, 1495 x 663
(Observe que ambos se reconocen como data).

Todos los sistemas operativos deben reconocer al menos un tipo de fichero regular: sus propios fiche
ros ejecutables. As, si se ejecuta el mandato f i l e sobre un fichero binario ejecutable, que en el ejemplo se
denomina b u sq u e d a, se obtiene lo siguiente:
#file busqueda
busqueda: ELF 32-bit LSB executable, Intel 80386, versin 1 (SYSV),
dynamically linked (uses shared libs), not stripped
La estructura de un fichero ejecutable est ntimamente ligada a la forma de gestionar la memoria y la

E/S en un sistema operativo. En algunos sistemas, como VMS, los ficheros ejecutables se reconocen por su
extensin. En otros, como en UNIX, porque as se indica en el nmero mgico que identifica el tipo de fiche
ro.
Aunque existen distintos formatos de ficheros ejecutables, como el ELF, la figura 9.3 muestra un ejem
plo simplificado de estructura de un fichero ejecutable en el sistema operativo UNIX. Como puede verse, el
sistema operativo espera que dicho formato incluya, al menos, cinco secciones: cabecera, texto, datos, infor
macin de carga y tabla de smbolos. Dentro de la cabecera est la informacin necesaria para que el sistema
operativo pueda interpretar la estructura del ejecutable y encontrar cada uno de sus elementos (nmero mgi
co, tamao de las otras secciones, opciones de ejecucin, etctera). Cada sistema operativo usa un nmero
mgico caracterstico para reconocer sus ejecutables.
Como se ver en la seccin 9.3 con ms detalle, los directorios son un tipo de fichero especial para el
sistema operativo porque la informacin que contienen es un conjunto de estructuras de tipo directorio que
son inherentes al propio sistema operativo. Adems, desde el punto de vista de integridad estos ficheros son
ms importantes para el sistema que los de datos, por lo que se gestionan a nivel interno del sistema operativo
de forma ms exigente.
578

N m e ro m gico
C a b ecera
prim aria
C a b e c er a de
se c c i n 1
C a b e c er a de
s e c c i n n
S e c ci n 1
N m e ro de secciones
Tam a o segm ento texto
Tipo de seccin,
tam ao de la seccin
direccin virtual______
Tam a o seg m e nto datos
Tipo de seccin,
tam ao de la seccin
direccin virtual______
Tam ao tab la d e sm bolos
Cdigo
S e c ci n 2
Datos con
valor inicial
S e c c i n n
Datos con
valor inicial
T am a o datos sin valor

inicial
Valor inicial d e registros

D ireccin inicial
O pciones
Inform acin
de carga
Tabla de
sm bolos
O tra
inform acin
Figura 9.3 Estructura de un fichero ejecutable en UNIX.

Si se ejecuta el mandato f i l e sobre un directorio, que en el ejemplo se denomina soluciones, se obtie
ne lo siguiente:
# f i l e s o lu c io n e s
s o lu c io n e s : d ir e c to r y
Un tipo de fichero significativo para el sistema operativo son los denominados ficheros especiales. Es
tos ficheros permiten representar cualquier dispositivo como un fichero y fueron una innovacin importante
en UNIX en los aos 70. Existen dos tipos de ficheros especiales, de bloques y de caracteres, en correspon
dencia con los tipos de dispositivo existentes. La gran ventaja de estos ficheros es que permiten leer y escribir
los dispositivos exactamente como se leen y se escriben los ficheros ordinarios, siendo el sistema operativo
capaz de traducir las operaciones de ficheros a su equivalente del hardware correspondiente. Este tipo de ma
nejo de informacin tiene una ventaja importante: puesto que el sistema operativo trata todo como si fuese un
fichero, no es necesario aprender las particularidades del hardware de la computadora. Si se ejecuta un man
dato f i l e sobre este dispositivo, denominado IpO , se obtiene:
# f i l e IpO
Ip O : c h a r a c t e r s p e c i a l
(6 /0 )
El ltimo tipo de fichero considerado son los enlaces. Como se ver ms adelante, los enlaces no son
ficheros reales, sino representaciones de otros ficheros. Tienen limitaciones importantes en ciertos casos y
exigen tambin una gestin especial por parte del sistema operativo. Si se ejecuta el mandato f i l e sobre un
fichero h i j o l , que es un enlace del h i j o del ejemplo anterior, se obtiene:
# f ile h ijo l
h i j o l : sy m b o lic l i n k t o h i j o
579
9.2.3. Nombres de ficheros

Todo objeto del sistema operativo debe tener un nom bre o descrip to r nico para que el sistema operativo y
sus usuarios puedan localizar dicho objeto y trabajar con l. En el caso de objetos internos al sistema operati
vo, ste les asigna un identificador de tipo numrico que no trasciende al exterior. Sin embargo, los ficheros
son especiales en cuanto que son creados y manipulados de forma extema al sistema operativo por los usua
rios, por lo que no parece ms adecuado asignar un nombre que tenga significado lgico para la visin del
usuario.
En esta seccin se comentan los aspectos relativos al nombrado de ficheros, tanto desde el punto de vis
ta lgico como del interno del sistema operativo, as como la posibilidad de usar varios nombres lgicos para
designar a un mismo fichero.
Nombres lgicos de fichero (de usuario o externos)
Una de las caractersticas principales de un sistema operativo, de cara a los usuarios, es la forma en que se
nombran los ficheros. Todo objeto fichero debe tener un nombre a travs del que se pueda acceder a l de
forma inequvoca. Por ello, todos los sistemas operativos proporcionan mecanismos de nombrado que perm i
ten asignar un nombre a un fichero en el momento de su creacin. Este nombre acompaar al objeto m ien
tras exista y le identificar de forma nica.
El tipo de nombres que se usan para los ficheros vara de un sistema operativo a otro. Sin embargo, y
para ser ms amigables con los usuarios, todos ellos permiten asignar a los ficheros lom bres formados por
combinaciones de caracteres alfanumricos y algunos caracteres especiales. La longitud de los nombres pue
de ser variable. Por ejemplo, MS-DOS permite nombres con una longitud mxima de 8 caracteres, mientras
UNIX permite nombres de hasta~4Q?5~'caracteres. Asimismo, algunos sistemas operativos, como MS-DOS o
Windows, no distinguen entre maysculas v minsculas, mientras otros, como UNIX, s lo hacen. Por las
razones anteriores, un nombre de fichero como c a t a l i n a p e r e z no sera vlido en MS-DOS pero s en
UNIX y los nombres c a t a l i n a y c a t a l i n a denominaran el mismo fichero en MS-DOS pero a dos fiche
ros distintos en UNIX.
Muchos sistemas operativos permiten aadir una o ms extensiones al nomhre de un fichero. Dichas
extensiones se suelen separar del nombre con un punto (ejemplo . t x t ) y sirven para indicar al sistema ope
rativo, a las aplicaciones, o a los usuarios, caractersticas del contenido del fichero . Las extensiones de los
ficheros tienen formato y significado muy distinto para cada sistema operativo. En MS-DOS, por ejemplo, un
fichero slo pueden tener una extensin y sta debe ser una etiqueta de tres letras como mximo. En UNIX y
Windows, un_fichero puede tener cualquier nmero de extensiones y de cualquier tamao. La figura 9.4
muestra algunase las~xtensiones ms habituales en los nombres de ficheros, tales como p d f , p s o d v i para
ficheros ASCII en formato visible o imprimible, z i p para ficheros comprimidos, c o cp p para cdigo fuente
en C y C++ respectivamente, htm o h tm l para hipertexto, etctera Como se puede ver, Windows asocia a
cada tipo de fichero el icono de la aplicacin que lo puede manejar (si conoce el tipo de fichero y la aplica
cin).
Habitualmente, las extensiones son significativas slo para las aplicaciones de usuario, pero existen ca
sos en que el sistema operativo reconoce, y da soporte especfico, a distintos tipos de ficheros segn sus ex
tensiones. Ambas aproximaciones tienen sus ventajas e inconvenientes:
Si el sistema operativo reconoce tipos de ficheros, puede proporcionar utilidades especficas y muy op
timizadas para los mismos. Sin embargo, el diseo del sistema se complica mucho.
Si no los reconoce, las aplicaciones deben programar las utilidades especficas para manejar su tipo de
ficheros. Pero el diseo interno del sistema operativo es mucho ms sencillo.
Un ejemplo de la primera opcin fue el sistema operativo TOPS-20, que proporcionaba distintos tipos
de ficheros en su mbito interno y ejecutaba operaciones de forma automtica dependiendo del tipo de fiche
ro. Por ejemplo, si se modificaba un fichero con cdigo fuente Pascal, y extensin .p a s , el sistema operati
vo recompilaba automticamente la aplicacin creando una nueva versin de la misma.

Name >:
5ize 1 Type
fS^Mv Pictures
r i My Webs
Rie Folder
Rie Folder
GD pstr-inf J iles
M .fvwmrc
& cartacas.tex
F l cata99.ps
[w] control, bib
fg[ faxing.log
[ S flg 3 -l.tif
Iwlfiq3-7.cdr
pstr-inf. doc
13 KB
1 KB
193 KB
16 KB
1 Modified
07/09/2000 11:36
06/09/2000 11:57
Hie Folder
14/09/2000 16:21
FVWMRC Rie
COREL Texture
06/05/1999 13:00
06/05/1999 17:55
PS Rie
06/05/1999 17:55
BIB File
06/05/1999 17:55
Text Document
06/05/1999 17:55
27 KB
Corel PHOTO-PAIN...
CDR File
22/08/2000 11:59
03/05/2000 18:27
53 KB
Microsoft Word Doc...
14/09/2000 16:21
4 KB
734 KB
1 KB
Microsoft HTML Doc...
14/09/2000 9:51
^ r e m a in .zip
0 KB
WinZip File
30/05/2000 12:34
'
Q d Sample.jpg
10 KB
Corel PHOTO-PAIN...
05/09/2000 17:08
3 KB
Application
CPP Rie
07/09/2000 13:10
11/07/2000 15:30
ji
2 KB
C File
14/07/2000 12:52
ADB File
Microsoft Power Poi,..
24/02/2000 9:49
24/07/1998 8:15
10 KB
Microsoft HTML Doc...
22/12/1999 11:28
4.110 KB
Adobe Acrobat Doc...
07/04/1999 11:11
pstr-inf .htm
@3 winamp265.exe
N cmutex.cpp
fl secobject.c
adasmspkg. adb
PpDem o.ppt
vol3 tc 04 .htm l
2.112 KB
13 KB
345 KB
'
'
un
F igura 9.4 Extensiones frecuentes en los nombres de fichero.

La segunda opcin tiene un exponente claro en UNIX, sistema operativo para el que las extensiones del
nombre no son significativas, aunque s lo sean para las aplicaciones externas. Por ello, UNIX no almacena
entre los atributos de un fichero ninguna informacin acerca del tipo del mismo, ya que este sistema operati
vo proporciona un nico tipo de fichero cuyo modelo se basa en una tira secuencial de bytes. Unicamente
distingue algunos formatos, como los ficheros ejecutables, porque en el propio fichero existe una cabecera
donde se indica el tipo del mismo mediante un nmero, al que se denomina nm ero mgico. Por supuesto;
esta caracterstica est totalmente oculta al usuario. Por ejemplo, un compilador de lenguaje C puede necesi
tar nombres de ficheros con la extensin . c y la aplicacin co m p ress puede necesitar nombres con la exten
sin . z. Sin embargo, desde el punto de vista del sistema operativo no existe ninguna diferencia entre ambos
ficheros. Windows tampoco es sensible a las extensiones de ficheros, pero sobre l existen aplicaciones del
sistema (como el explorador) que permiten asociar dichas extensiones con la ejecucin de aplicaciones. De
esta forma, cuando se activa un fichero con el ratn, se lanza automticamente la aplicacin que permite tra
bajar con ese tipo de ficheros.
Nombres de ficheros estndar
Hasta la introduccin del sistema operativo UNIX, cuando un proceso tena que usar dispositivos deba reali
zar operaciones muy complicadas, generalmente distintas a las de los ficheros. Debido a ello, cuando un p r
grama se construa para un dispositivo no poda usarse para otro, a no ser que se creara una nueva versin
adaptada. Con UNIX se introdujo la filosofa de poder usar los dispositivos como un fichero cualquiera, cu
yos nombres estn incluidos en el directorio /d e v , con lo que se unificaron las operaciones de entrada/salida
(ver el captulo anterior. Adems de estas ideas, UNIX introdujo otras derivadas de la experiencia obtenida
de MULTICS, siendo una de las principales la asignacin por defecto a cada proceso creado de tres descrip:
tores estndares de fichero:
s t d i n : descriptor de la entrada estndar para el proceso. Como se muestra en la figura 9.5, est aso
ciado por defecto al teclado (/d e v /k b d ).
Gestin de ficheros y directorios 581

s t d o u t : descriptor de la salida estndar para el proceso. Como se muestra en la figura 9.5, est aso
ciado por defecto a la pantalla ( / d e v / t t y ) .
s t d e r r : descriptor de la salida estndar para los errores del proceso. Como se muestra en la figura
9.5, est asociado por defecto a la pantalla ( / d e v / t t y ) .
Estos descriptores indican los lugares por defecto desde donde se leen los datos de trabajo y hacia
donde se envan los resultados y los errores, respectivamente. Cuando se crea un proceso, el sistema operati
vo abre estos dispositivos y les asigna los nombres estndares. Una gran ventaja de estos descriptores que se
pueden redireccionar mediante mandatos o mediante programas para cambiar el lugar de donde se leen los
datos, donde se envan los resultados y donde se envan los errores, respectivamente. As, tanto en UNIX
como en Windows, el smbolo > permite cambiar los dispositivos asociados a los nombres estndar para usar
otros dispositivos, ficheros, etctera Por ejemplo, el mandato c a t :
#cat
Lee lo que se escribe por el teclado y lo reproduce en pantalla, incluyendo posibles errores. Sin embar
go, el mandato:
#cat
<
h ijo
>
/d e v /lp
Lee el contenido del fichero h i j o y lo muestra la impresora, cambiando los dispositivos asociados a los
nombres estndar como se muestra en la figura 9.5 (b). Observe que la salida de errores no se ha cambiado.
Este mecanismo permite crear mandatos ms complejos a partir de mdulos bsicos basados en los descripto
res estndar y est actualmente presente en todos los sistemas operativos.
En la seccin 9.3 se muestra un programa de ejemplo para asociar los nombres estndar a dispositivos
distintos usando llamadas al sistema operativo UNIX.
Nombres internos (del sistema de ficheros) de un fichero
Los nombres lgicos de usuario no significan nada para el sistema de ficheros. Cunado se crea un fichero en
un dispositivo o volumen, el sistema operativo le asigna un identificador interno nico que es el que realmen
te se utiliza en todas las operaciones del sistema operativo. Estos descriptores internos son tanto en UNIX
/LINUX como en Windows nm eros enteros que identifican la posicin o ndice de los metadatos del fiche
ro dentro del dispositivo fsico o lgico de almacenamiento en el que est el fichero.
En LINUX por ejemplo, el dispositivo se identifica mediante dos nmeros: primario (m ajor) para el ti
po de dispositivo y secundario (m inor) para el dispositivo en s. Por tanto un fichero se identificar dentro
de un computador mediante un identificador resultante de unir esos dos nmeros y el nmero del nodo-i del
fichero dentro del dispositivo. En Windows, los dispositivos de almacenamiento se gestionan mediante
volmenes, que tienen un identificador numrico asignado, por lo que los ficheros se identifican mediante el
descriptor del volum en y el descriptor del MFT dentro del volumen. Este esquema se puede extender a sis
temas distribuidos sin ms que usar la direccin IP del sistema antes de los descriptores anteriores.
Cmo se relacionan los nombres lgicos, o de usuario, con los internos, o del sistema operativo? Pues
Figura 9.5 Cambio de dispositivo asociado a los nombres estndar.
582
se relacionan a travs de los directorios. Los directorios, que se explican a continuacin, no son sino formas
de enlazar nombres con nmeros, o representaciones simblicas con el descriptor real del objeto. Son idnti
cos a una gua de telfonos que asigna a cada usuario un nmero de telfonos.
Qu descriptores internos tienen los nombres estndar? No tienen ninguno a priori. Se les asigna el del
dispositivo con el que se relacionan en cada momento.
Aclracin 9.1 EL nombr interno de un fichero es nico y pervive mientras exista el fichero. No se di
confundir con el descriptor de fichero que reciben los usuarios cuando abren un fichero, como se: puede
servar en la seccin en la que se describe ms adelante el cico de vida de un fichero.
~
Nombrado mltiple de un fichero: enlaces

En algunos sistemas operativos, como los de tipo UNIX, se permite que un fichero pueda tener varios nom
bres, aunque todos ellos representen al mismo objeto fichero final, es decir hagan referencia al mismo nom
bre interno. As, un usuario puede ver el fichero con identificador interno 234 8765 mediante el nombre
h i j o , mientras otro lo ve mediante el nombre s o b r in o , pero el sistema operativo sabe de alguna forma que
ambos nombres denominan al mismo objeto.
Esta es una forma muy habitual de compartir ficheros en UNIX, para lo que se suele crear un enlace al
fichero compartido. Existen dos tipos de enlaces:
Fsico. Un apuntador a otro fichero o subdirectorio, cuya entrada de directorio tiene el mismo des
criptor de fichero (en UNIX, el nodo-i) que el fichero enlazado. Ambos nombres apuntan al mismo
objeto fichero. Resolver cualquiera de los nombres de sus enlaces nos devuelve el propio descriptor
del fichero. Una restriccin importante es que solo se pueden establecer enlaces fsicos entre ficheros
que estn en el mismo sistema de ficheros, por lo que no se puede realizar enlaces entres sistemas de
ficheros distintos o simados en distintos volmenes de almacenamiento.
Simblico. Se crea un un nuevo fichero cuyo contenido es el nombre del fichero enlazado. Resolver
el nombre del enlace simblico no da el descriptor del destino, sino el descriptor del fichero en el
que est el nombre del destino. Para acceder al destino, hay que abrir el fichero del enlace, leer el
nombre del destino y resolverlo de nuevo. Su acceso es ms ineficiente, porque hay que resolver dos
nombres (enlace y fichero), pero son mucho ms generales. Estos enlaces simblicos se introdujeron
con el sistema operativo UNIX BSD y se popularizaron mucho con el sistema de ficheros de red
NFS (NetWork File System).
El sistema operativo necesita tener constancia de los enlaces fsicos que tiene un fichero para realizar
las acciones adecuadas en la creacin y borrado del fichero (como se ver ms adelante). Para ello, se cuenta
en UNIX con un atributo en el descriptor del fichero (nodo-i) denominado contador de enlaces. Cuando se
crea un enlace a un fichero, se incrementa en el nodo-i del fichero un contador de enlaces fsicos. Cuando se
rompe el enlace, se decrementa dicho contador. Solo se puede borrar un fichero cuando su contador de enla
ces es cero.
La figura 9.6 (a) muestra el caso en que s o b r in o es un enlace fsico a h i j o . Como se puede ver ambos
apuntan al mismo descriptor de fichero, es decir fsicamente al mismo fichero (cuyo contador de enlaces es
2). Sin embargo, en el caso (b) s o b r in o es un enlace simblico a h i j o por lo que tiene su propio descriptor
de fichero, dentro del cual se encuentra el nombre del fichero al que apunta. Por tanto, no apunta directamen
te al descriptor de fichero de h i j o .
9.2.4. Estructura de un fichero

Los ficheros pueden estructurarse de formas distintas, tanto en el mbito de usuario como del sistema opera
tivo. Desde el punto de vista del sistema operativo, algunos ficheros (com o los ejecutables o las bibliotecas
dinmicas) deben tener una cierta estructura para que su informacin pueda ser interpretada. Desde el punto J
de vista del usuario, la informacin de un fichero puede estructurarse como una lista de caracteres, un con-
585
hay delante de ellos. Imagine que tiene un fichero de clientes ordenado por orden alfabtico y quiere buscar a
Juan y a Pepe. Deber leer todos los nombres y ver si son ellos. Con el mtodo ISAM, existe un fichero de
ndice que le dice, por ejemplo, donde empiezan los clientes cuyo nombre comienza por A , por B, etctera
Para leer los datos de Juan puede ir directamente a la posicin del ndice para la J y luego comparar los datos
para buscar Juan dentro de ese bloque. Observe que, en cualquier caso, es necesario leer los datos hasta
Juan!
Con la llegada de los dispositivos de acceso directo (como los discos magnticos) surgi la forma de
acceso directo, o aleatorio, a un fichero. El fichero se considera como un conjunto de registros, cada uno de
los cuales puede ser un byte. Se puede acceder al mismo desordenadamente moviendo el apuntador de acce
so al fichero a uno u otro registro. Esta forma de acceso se basa en un modelo de fichero almacenado en dis
co, ya que se asume que el dispositivo se puede mover aleatoriamente entre los distintos bloques que
componen el fichero. Para proporcionar este mtodo de acceso a las aplicaciones, los sistemas operativos
incluyen llamadas del sistema de ficheros con las que se puede modificar la posicin dentro del fichero (se
ek) o en las que se puede especificar el nmero de registro o bloque a leer o escribir, normalmente relativos
al principio del fichero. El sistema operativo relaciona estos nmeros relativos con nmeros absolutos en los
dispositivos fsicos de almacenamiento. Por ejemplo, para acceder primero a los datos de Juan y Miguel igual
que antes, la secuencia de instrucciones a ejecutar es la siguiente:
Seek alumno 34
Read
/* Autoincrementa el puntero tras la lectura*/
Seek alumno 16
Read
/* Autoincrementa el puntero tras la lectura*/
Este mtodo de acceso es fundamental para la implementacin de muchas aplicaciones. Las bases de
datos, por ejemplo, usan fundamentalmente ficheros de este tipo. Imagine que tiene la lista de clientes ante
rior en un dispositivo que permite acceso directo. En lugar de leer los datos hasta Juan basta con leer la posi
cin en el ndice y saltar hasta dicha posicin. Actualmente, todos los sistemas operativos usan esta forma de
acceso, mediante la cual se puede tambin acceder secuencialmente al fichero de forma muy sencilla. Igual
mente, sobre sistemas de acceso directo se pueden construir fcilmente otros mtodos de acceso como los de
ndice, registros de tamao fijo o variable, etctera (Prestaciones 9.1).
Prestaciones 9.1 Seleccionar adecuadamente la forma de acceso a un fichero influye mucho en el rendimien
to de las operaciones sobre ficheros. Por ejemplo, usar accesos secuenciales en una base de datos cuyas ope
raciones se hacen en el mbito de los registros sera psimo. Sin embargo, usar accesos secuenciales para
copiar un fichero sobre otro seria ptimo.__________________________
9.3.
DIRECTORIOS
Un sistema de ficheros puede ser muy grande. Para poder acceder a los ficheros con facilidad, todos los sis
temas operativos proporcionan formas de organizar los nombres de ficheros mediante directorios. Un direc
torio puede almacenar otros atributos de los ficheros tales como ubicacin, propietario, etctera dependiendo
de cmo haya sido diseado. Habitualmente, los directorios se implementan como ficheros, pero se tratan de
forma especial y existen servicios especiales del sistema operativo para su manipulacin.
En esta seccin se va a estudiar el concepto de directorio, las estructuras de directorios ms comunes,
su relacin con los nombres de fichero y las formas ms frecuentes de construir las jerarquas de directorios.
586
9.3.1. Concepto de directorio

Un directorio es un objeto que relaciona de forma um'voca el nombre de usuario de un fichero y el descrip
tor interno del mismo usado por el sistema operativo. Los directorios sirven para organizar y proporcionar
informacin acerca de la estructuracin de los ficheros en los sistemas de ficheros. Para evitar ambigedades
un mismo nombre no puede identificar nunca a dos ficheros distintos, aunque varios nombres se pueden refe
rir al mismo fichero.
Habitualmente, un directorio contiene tantas entradas como ficheros son accesibles a travs de l, sien
do la funcin principal de los directorios presentar una visin lgica simple al usuario, escondiendo los deta
lles de implementacin del sistema de directorios.
Un ejemplo de visin lgica del esquema de directorios de Windows, en este caso un esquema jerrqui
co, puede verse en la figura 9.9, donde los ficheros se representan mediante iconos grficos y los directorios
se representan mediante carpetas. Esta representacin permite visualizar grficamente la estructura de los
directorios a travs de aplicaciones del sistema, en este caso Microsoft Explorer, y generalmente algunos
detalles o atributos de los objetos incluidos en el directorio. Adems, permiten visualizar con preferencia
ciertos tipos de ficheros, como ejecutables o ficheros de procesadores de textos, y asociarlos con aplicaciones
que se ejecutan de forma automtica cuando se pulsa con el ratn sobre dichos ficheros.
Cuando se abre un fichero, el sistema operativo busca en el sistema de directorios hasta que encuentra
la entrada correspondiente al nombre del fichero. A partir de dicha entrada, el sistema operativo obtiene el
identificador interno del fichero y, posiblemente, algunos de los atributos del mismo. Esta informacin per
mite pasar del nombre de usuario al objeto fichero que maneja el sistema operativo. Todas las referencias
posteriores al fichero se resuelven a travs de su descriptor (nodo-i, registro MFT, etctera). En la seccin
9.3 se describe con ms detalle las distintas alternativas existentes en los sistemas operativos actuales para
definir e implementar los directorios y las entradas que describen a un fichero.
9.3.2. Estructuras de directorio

Independientemente de cmo se defina la entrada de un directorio, es necesario organizar todas las entradas
de directorio para poder manejar los ficheros existentes en un sistema de almacenamiento de forma sencilla y
ftrtttvo
ddn
Vtr
rf* tu
Evortto tJerrafttort**
Carpetas
B O ACER(O)
a
ArtNv de programa
& ejBOOtT
ffl C3 Corel
S
eygwin
f
ffl
j JJ
Ayuda
|(5
Qfc
Nombre
x
g l ^ GUIDE
GUIDE
ONLINE
F**idoc
-j
ED bome
tD fe
Dsbn
S > u*
f**l D30TEMP
3 Documento and SetUngs
3 &EUMENTS
(B j Ghortgum
ffl m
ffl ea V306
a llocAfcwor/
ffl C ) SY5TNFO
ffl 3 TCMP
EB 5 twnf
S G WINDOWS
O ACERDATAfD:)
9 ^ UnidadDVD/CD-RW(E:)
a
DMco extrabto (F:)
i-
U>;
Figura 9.9 Visin lgica de los directorios en Windows.
X. o m a |
Tamafia I Tipo
1KB Icono
10.929 KB Adobe Aoobafc Doc...
1KB Imagen de mapa da...
Carpet da arttVvos
j /Hrcha do modHcadn 1
16/03/20019:11
06/02/2003 11:53
25/08/1997 16| 17
26/09/2001 I7i 10
587
eficiente. La forma de estructurar dichas entradas vara de unos sistemas a otros dependiendo de las necesi
dades de cada sistema.
En sistemas operativos antiguos, como CP/M, se usaron estructuras de directorio de nivel nico y di
rectorios con dos niveles (figura 9.10). En la primera, existe un nico directorio que contiene todas las en
tradas de ficheros. Es fcil de entender e implementar, pero asignar nombre a un fichero nuevo no es fcil por
la dificultad de recordar todos los nombres o la imposibilidad de ver los de otros usuarios. En CP/M, para
evitar este problema, el nmero mximo de ficheros que poda haber en un sistema de ficheros estaba signifi
cativamente limitado. Esto reduce el problema de gestin de nombres, pero limita el nmero de ficheros en
un dispositivo de almacenamiento.
Con el crecimiento de la capacidad de los dispositivos de almacenamiento, se resolvi el problema an
terior extendiendo la estructura a un directorio de dos niveles, donde cada usuario dispona de su propio di
rectorio, reduciendo as una parte de la confusin inherente a los directorios de nivel nico. Cuando se daba
de alta un nuevo usuario en el sistema, las utilidades de administracin del sistema operativo creaban el di
rectorio para los ficheros del usuario con un nombre fijado con criterios internos al sistema.
Cuando el usuario entraba al sistema, se le pona dentro de su directorio. Para acceder a sus ficheros
poda hacer dos cosas: especificar slo el nombre del fichero relativo a su directorio (por ejemplo, c la v e s ) o
especificar el nombre completo del fichero incluyendo dispositivo, directorio del usuario y nombre de fiche
ro (por ejemplo, C: \ m ig u el\ cla v es). Esta estructura mejoraba la seguridad al aislar a los usuarios, pero
no se evitaba otros problemas, tales como la gestin de nombres propios de un usuario, la imposibilidad de
agrupar los ficheros de un mismo usuario con distintos criterios o el uso compartido de ficheros. Suponga
mos, por ejemplo, que un alumno tiene varios ficheros de prcticas. Todos ellos estaran bajo el mismo direc
torio, pero no podra agrupar los de las prcticas de sistemas operativos o las de arquitectura de
computadores. Suponga ahora que la prctica se lleva a cabo por un grupo de tres alumnos. Cmo pueden
compartir los ficheros de la misma? Con esta estructura sera necesario copiar los ficheros en los directorios
de todos ellos, con el peligro consiguiente de incoherencias entre las distintas copias, o crear un nuevo usua
rio (por ejemplo, g r u p o -1 ) e introducir en su directorio los ficheros compartidos. Esta solucin se adopt
para permitir que todos los usuarios vieran las utilidades del sistema operativo sin tener que hacer mltiples
copias: crear un usuario especial, denominado sistem a , en cuyo directorio se incluan dichas utilidades con
permisos de lectura y ejecucin para todos los usuarios.
[c a rta |
["*1
mapa.glfj
lista.txt j
[J
D ire c to rio
Archivos
programa.o j
!"']
(A ) Nivel n ico
mi9uel I -
elvlfa i
i
datosi lista.c; |
D ire cto rio

del u s u a rio "'
Archivos
| mail
-I-
D ire cto rio ,

d el u su a rio
1
1 | test | agenda 1
i claves j
i
i
Iista.c
_T_
.
I
D ire cto rio

d e l u su a rio
"
Archivos
1claves
Imo.O j
-T_
Archivos
(B )
Figura 9.10 Estructuras de directorio de uno y dos niveles.
D o s n iv eles
588
A medida que la capacidad de los dispositivos se fue incrementando, fue tambin creciendo el nmero
de ficheros almacenados por los usuarios en el sistema de ficheros. Con lo que el problema de la complejidad
de la asignacin de nombres, paliado por la estructura de dos niveles, volvi a aparecer a nivel de usuario.
Fue pues necesario generalizar la estructura de dos niveles para obtener una estructura jerrquica ms general
que permitiera a los usuarios ordenar sus ficheros con criterios lgicos en sus propios subdirectorios, sin de
pender de las limitaciones de los niveles de la estructura de directorios, lo que llev a la estructura de rbol.
Una estructura de rbol (figura 9.11) representa todos los directorios y subdirectorios del sistema partiendo
de un directorio raz, existiendo un camino nico (path) que atraviesa el rbol desde la raz hasta un fichero
determinado. Los nodos del rbol son directorios que contiene un conjunto de subdirectorios o ficheros. Las
hojas del rbol son siempre ficheros. Normalmente, cada usuario tiene su propio directorio home a partir del
cual se cuelgan sus subdirectorios y ficheros y en el que le sita el sistema operativo cuando entra a su cuen
ta. Este directorio lo decide el administrador, o los procesos de creacin de nuevos usuarios, cuando el usua
rio se da de alta en el sistema y est almacenado junto con otros datos del usuario en una base de datos o
fichero del sistema operativo. En el caso de UNIX, por ejemplo, el fichero /e t c /p a s s w o r d contiene una
lnea por usuario del sistema, similar a la siguiente:
miguel:* Miguel:/users/miguel:/etc/bin
Donde el directorio home es /u s e r s /m ig u e l. MS-DOS y Windows tienen registros de usuarios que
tambin definen el directorio home.
Los usuarios pueden subir y bajar por el rbol de directorios, mediante servicios del sistema operativo,
siempre que tengan los permisos adecuados. Por ello, tanto el propio usuario como el sistema operativo de
ben conocer dnde estn en cada instante. Para solventar este problema se defini el concepto de directorio
de trabajo, que es el directorio en el que un usuario se encuentra en un instante determinado. Para crear o
borrar un fichero o directorio, se puede indicar su nombre relativo al directorio de trabajo o completo desde
la raz a las utilidades del sistema que llevan a cabo estas operaciones. Un problema interesante con este tipo
de estructura es cmo borrar un directorio no vaco. Hay dos soluciones posibles:
Un directorio no se borra si no est vaco. Si tiene ficheros o subdirectorios, el usuario debe borrarlos
previamente. Esta es la solucin adoptada habitualmente en las llamadas a los sistemas operativos.
Un directorio, y todo el subrbol de directorios que cuelga de l, es borrado, aunque el subrbol no
est vaco. Esta solucin existe en UNIX y Windows, aunque no como llamada al sistema sino como
mandato de usuario. Para evitar que un usuario borre ficheros por error se solicita una confirmacin
del usuario, va opcin en el mandato UNIX o confirmacin en un men grfico en Windows. Si la
respuesta es afirmativa, se borra todo el subrbol recursivamente.
La estructura de rbol es muy general, pero no proporciona los servicios requeridos en algunos entor-
Figura 9.11 Estiuctura de rbol jerrquico.
589
nos. Por ejemplo, puede ser interesante que varios programadores que trabajan en el mismo proyecto com
partan ficheros o subdirectorios llegando a los mismos por sus respectivos directorios de usuario para no te
ner problemas de seguridad y proteccin. Esta forma de acceso no existe en la estructura de rbol porque
exige que a un fichero se llegue con nico nombre. El modelo descrito, sin embargo, rompe la relacin uno a
uno entre el nombre y el fichero, al requerir que un mismo fichero se pueda acceder a travs de varios cami
nos. Este problema puede resolverse generalizando la estructura del rbol de directorio para convertirla en un
grafo acclico (figura 9.12) en el cual el mismo fichero o subdirectorio puede estar en dos directorios distin
tos, estableciendo una relacin unvoca nombre-fichero.
La existencia de enlaces desde varios nombres al mismo fichero introduce dos problemas en este tipo
de estructura de directorio. Primero, existen varios nombres para el mismo fichero. Si se quiere recorrer todo
el rbol es importante evitar los bucles. (Advertencia 9.1). Segundo, el borrado de ficheros se complica, ya
que un mismo fichero puede ser borrado por varios caminos. Es necesario pues determinar cuando se puede
borrar el fichero. En UNIX, el fichero no se borra hasta que no existe ninguna referencia al mismo, lo que
significa que el valor del contador de enlaces es cero. Para ello, cuando se borra un fichero, se borra la entra
da de directorio que referencia al fichero y se decrementa su contador de enlaces. Slo en el caso de que el
contador de enlaces sea cero y de que nadie tenga abierto el fichero se borra el fichero realmente y se liberan
sus recursos.
Advertencia 9.1 Es importante evitar la existencia de bucles en el rbol de directorios. Dichos bucles origi
nan dos problemas: no permiten recorrer el rbol de directorios completo y pueden hacer que una operacin
de traduccin de nombre no acabe nunca.__________________ ._________________________ ____________ ______
Para evitar los problemas anteriores, algunos sistemas operativos, como MS-DOS, no permiten la exis
tencia de directorios compartidos o enlaces. En el caso de UNIX, existen limitaciones para que no se puedan
establecer enlaces hacia arriba en el rbol de directorios, evitando as la formacin de bucles.
Dado el gran tamao de los dispositivos de almacenamiento actuales y la necesidad de clasificar la in
formacin de formas variadas, existen actualmente varias propuestas para incrementar la potencia de las es
tructuras de directorios que se basan en la idea de los directorios dinmicos o relacinales. La idea que hay
detrs de esta nueva tendencia es sencilla. Se trata de permitir al usuario aadir a los objetos de almacena
miento atributos propios que, aadidos a los del sistema, permitan clasificarlos y recuperarlos de forma ms
rpida. Hay varias propuestas de este estilo, como el nuevo WinFS de Microsoft y los proyectos Storage y
Medusa de Gnome. La figura 9.13 muestra un ejemplo de etiquetado con atributos en WinFS, donde el usua
rio puede aadir al objeto informacin relacionada con su tema, categora, palabras clave, plantilla, comenta
rios de fechas de creacin y modificacin, etctera
Figura 9.12 Estructura de grafo acclico.
590
View - Favorites
Tools
Search
is?-Folder:
Last M inutes
Share
Author Raquel Mell

brochure, flyer}
Microsoft Word document
Author
Figura 9.13 Etiquetado de un objeto de almacenamiento con atributos.

Esta informacin se introduce en una base de datos relacional sobre la que se pueden hacer consultas
para localizar los ficheros por distintos criterios. El resultado son los denominados directorios dinmicos %
donde ya no existe una estructura determinada y fija de directorio, sino que los ficheros se pueden ver como
agrupaciones dinmicas y sin estructura, pudiendo existir un fichero en directorios o buzones distintos. Para
hacer frente a este tipo de directorios, es necesario extender la interfaz de llamadas al sistema para permitir ^
hacer consultas de tipo base datos al sistema de ficheros.
9.4.
NOMBRES JERRQUICOS
La especificacin del nombre de un fichero en un rbol de directorios, o en un grafo acclico, toma siempre
como referencia el directorio raz (/ en UNIX, \ en MS-DOS). A partir de este directorio, es necesario viajar
por los sucesivos subdirectorios hasta encontrar el fichero deseado. Para ello, el sistema operativo debe cono
cer el nombre completo del fichero a partir del directorio raz. Hay dos posibles formas de obtener dicho
nombre:
Que el usuario especifique el nombre completo del fichero, denominado nombre absoluto.
Que el usuario especifique el nombre de forma relativa, denominado nombre relativo, a algn subdirectorio del rbol de directorios.
El nombre absoluto de un fichero proporciona todo el camino a travs del rbol de directorios desde
la raz hasta el fichero. Por ejemplo, en UNIX, un nombre absoluto de uno de los ficheros existentes en la
figura 9.11 sera /u s e r s /m i g u e l /c l a v e s . Este nombre indica al sistema de ficheros que a partir del direc
torio raz (/) se debe atravesar el directorio u s e r s y, dentro de este ltimo, el subdirectorio m igu el para lle
gar al fichero
c la v e s .
En MS-DOS,
dicho nombre
absoluto
se representara como /
C :\ u se rs\ m ig u e l\ cla v e s. Un nombre absoluto es autocontenido, en el sentido de que proporciona al
sistema de ficheros toda la informacin necesaria para llegar al fichero, sin que tenga que suponer o aadir
ninguna informacin de entorno del proceso o interna al sistema operativo. Algunas aplicaciones necesitan
este tipo de nombres para asegurar que sus programas funcionan independientemente del lugar del rbol de
directorios en que estn simados. Por ejemplo, un compilador de lenguaje C, en una mquina que ejecuta el
sistema operativo UNIX, necesita saber que los ficheros con definiciones de macros y tipos de datos estn en
el directorio /u s r / i n c l u d e . Es necesario especificar el nombre absoluto porque no es posible saber en que
directorio del rbol instalar cada usuario el compilador.
Puesto que la profundidad del rbol de directorios puede ser muy grande, resultara muy incomodo te
ner que especificar constantemente nombres absolutos de ficheros. Adems, algunas aplicaciones usan direc
torios relativos a su situacin para almacenar ficheros. Es por ello que la mayora de los sistemas operativos
modernos permiten definir nombres relativos, es decir nombres de fichero que slo especifica una porcin
591
el nombre absoluto a partir de un determinado subdirectorio del rbol de nombres. Por ejemplo, m i
g u e l/c la v e s . Los nombres relativos no se pueden interpretar si no se conoce el directorio del rbol a partir
el que empiezan, para ello existe un directorio de trabajo, o actual, a partir del cual se interpretan siempre
los nombre relativos. Por ejemplo, si el directorio de trabajo es /u s r y se especifica el nombre relativo m i
g u e l/c la v e s se obtendr un error. Pero si el directorio de trabajo es /u s e r s , la interpretacin del nombre
relativo ser correcta. Es responsabilidad del usuario colocarse en el directorio de trabajo adecuado antes de
usar nombres relativos al mismo. El sistema operativo o el intrprete de mandatos almacenan el directorio de
trabajo actual de cada proceso en su BCP como parte de su entorno. Suele existir una variable de entorno
asociada (PWD en el caso de UNIX y Linux) que se modifica cada vez que se cambia el directorio de trabajo
del proceso. Puesto que el sistema operativo solo trabaja en realidad con nombres absolutos, cuando se espe
cifica un nombre relativo, el sistema operativo o el intrprete de mandatos concatenan el valor de la variable
del directorio de trabajo con el del nombre relativo para obtener el nombre absoluto, es decir:
nombre a b s o lu t o = d i r e c t o r i o de t r a b a j o + nombre r e l a t i v o
Antes de interpretar dicho nombre o usarlo en llamadas al sistema. En secciones posteriores se mos
trarn algunas optimizaciones de este proceso.
Muchos sistemas operativos con directorios jerrquicos tienen dos entradas especiales, . y . . , en
cada directorio para referirse a s mismos y a su directorio padre en la jerarqua. Estas entradas especiales son
muy tiles para especificar posiciones relativas al directorio actual y para viajar por el rbol. Por ejemplo, si
el directorio actual es /u s e r s /m ig u e l, el mandato UNIX:
# ls
../
Mostrar las entradas de directorio de su padre en el rbol, es decir del directorio u s e r s . Pero el man
dato UNIX:
#cp / u s r / i n c l u d e / s t d i o . h
Copiar el fichero s t d i o .h al directorio actual, es decir m igu el.
Las entradas especiales son muy importantes en la gestin e interpretacin de nombres de ficheros y di
rectorios, ya que permiten navegar hacia arriba y hacia abajo por los nombres. Esto es as tambin para los
sistemas de ficheros montados, como veremos en secciones posteriores de este captulo que se dedican al
diseo del sistema de nombres.
9.4.1. Construccin de la jerarqua de nombres

Una de las decisiones ms importantes de diseo de un sistema operativo, que acaba siendo visible al usuario,
es ofrecer, o no, un rbol nico de nombres para todo el sistema, independientemente de los dispositivos fsi
cos o lgicos en que estos estn almacenados los directorios. En MS-DOS y en Windows, el rbol de directo
rios es nico por dispositivo lgico, pero el usuario debe conocer los nombres de dispositivo (C :, H:,
etctera) cuando quiere cambiar de uno a otro. Esa es la razn por la que la especificacin en Windows de un
nombre completo, tal como C :\ m ig u e l\ te x to , exige especificar el nombre de dispositivo. En todos los
sistemas operativos derivados de UNIX, la existencia de un rbol de directorios nico es un principio de
diseo fundamental. Para que ello sea posible, el sistema debe ocultar la existencia de los dispositivos al
usuario, que debe poder cambiar de uno a otro de forma transparente sin ms que usar nombres lgicos. Por
ejemplo, suponga que en la figura 9.12 el directorio raz estuviera en el dispositivo /d e v /h d a l (C: en Win
dows) y que los usuarios ( /u s e r s ) estuvieran en el dispositivo /d e v /h d a 3 (D: en Windows). Si se quiere
acceder al fichero /u s e r s /m i g u e l / t e x t o s , en UNIX bastara con especificar dicho nombre. Sin embargo,
en Windows sera necesario especificar D: \ m ig u e l\ te x to s.
Para ofrecer una imagen nica del sistema, el sistema operativo debe ofrecer servicios que permitan
asociar, y desasociar, unos sistemas con otros de forma transparente en un rbol de nombres nico. Adems,
las utilidades de interpretacin de nombres deben ser capaces de saltar de un sistema de ficheros a otro sin
que sea aparente en ningn momento el nombre del dispositivo fsico o lgico que almacena el sistema de
592
ficheros. Las dos llamadas al sistema de UNIX que realizan estas operaciones son mount y umount. La operacin de montado permite conectar un sistema de ficheros, almacenado en un volumen o particin, a una
entrada de directorio del rbol de directorios existente. A partir de dicha operacin, el sistema de ficheros en
el nuevo dispositivo aparece como un subrbol del rbol de directorios, sin que exista diferencia con el resto M
del mismo. Sus ficheros y directorios son accesibles a travs del nombre lgico. Por ejemplo, para montar
/ d ev/hda3 de forma que se construya un rbol de directorios como el de la figura 9.12, se ejecutara el si- '^
guente mandato:
#mount /dev/hda3 /users
Desmontar (umount) un sistema de ficheros es sencillo. Por ejemplo, para desconectar el dispositivo
/dev/hda3 montado en el directorio /users del sistema de ficheros raz, bastara con ejecutar el mandato:
ttumount /users
Si no se est usando ningn fichero o directorio del sistema de ficheros existente en /d e v /h d a 3 , el sistema operativo lo desconecta. A partir de ese instante, el subrbol de directorios del dispositivo no aparecer
en la jerarqua de directorios y sus datos no estarn accesibles.
Las operaciones anteriores tienen varias ventajas:
iM
Ofrecen una imagen nica del sistema.

Ocultan el tipo de dispositivo que est montado sobre un directorio.
Facilitan la interpretacin de nombres que incluyen varios sistemas de ficheros.
Permiten conectar sistemas de ficheros incluso remotamente por la red.
Sin embargo, tambin tienen inconvenientes:
Complican la traduccin de nombres lgicos de ficheros.

Dan problemas cuando se quiere establecer un enlace fsico entre dos ficheros. Debido a estos pro
blemas, en UNIX slo se puede establecer un enlace fsico entre dos ficheros que se encuentran en el
mismo sistema de ficheros. Nunca de un fichero a otro existente en un sistema de ficheros distinto.
La seccin 9.10 se dedica al servidor de ficheros y en ella se explica con ms detalle cmo se implementan las operaciones anteriores.
9.5.
FICHEROS COMPARTIDOS
Los procesos y los usuarios comparten ficheros con distintos motivos: sincronizacin, repositorios de datos
compartidos, almacenes de operaciones temporales, etctera Este hecho genera dos problemas bsicos que el
sistema operativo debe afrontar: qu prevalece cuando dos o ms procesos escriben simultneamente sobre
un fichero y cmo se pueden proteger ficheros para evitar que dos o ms procesos modifiquen informacin
simultneamente. El primer problema se resuelve definiendo e implementando una semntica de comparti
cin, el segundo se puede resolver dotando a los usuarios con un mecanismo de bloqueos totales o parciales
sobre ficheros.
9.5.1. Semnticas de coutilizacin

El uso de cualquiera de las formas de acceso anteriores no resuelve el problema del uso concurrente de un
fichero, sobre todo en el caso de que al acceder a l alguno de los procesos est modificando la informacin
existente en dicho fichero. En situaciones de coutilizacin de un fichero, las acciones de un proceso pueden
afectar a la visin que los otros tienen de los datos o a los resultados de su aplicacin. La semntica de coutilizacin especifica qu ocurre cuando varios procesos acceden de forma simultnea al mismo fichero y
especifican el momento en el que las modificaciones que realiza un proceso sobre un fichero pueden ser ob-
595
Los bloqueos parciales se activan mediante un cerrojo en el que se indica el inicio y el final de la re
gin de fichero bloqueada. En UNIX no existe ninguna llamada al sistema, pero se pueden implementar me
diante la llamada f c n t l y la estructura de datos f lo c k :
stru ct flo c k {
sh ort
l_ ty p e ;
sh ort
l_w h en ce;
o ff_ t
l_ s ta r t;
o ff_ t
l_ le n ;
p id _ t
l_ p id ;
/*
/*
/*
/*
/*
F_RDLCK, F_WRLCK, o F_UNLCK */

SEEK_SET, SEEK_CUR, o SEEK_END */
Puntero al inicio de la regin bloqueada */
longitud del segmento */
Id. Del proceso propietario del cerrojo */
};
Los tipos de bloqueos incluyen: lectura f _ rdlck , escritura f_ wrlck y liberacin FJUNLCK. Por ejem
plo, las sentencias siguientes ponen un cerrojo de escritura sobre una regin del fichero de notas, regin que
incluye a los alumnos comprendidos entre el 3 y el 10.
# in c lu d e < f c n t l .h >
s tru ct flo c k c e r r o jo ;
fd * open ( "n o ta s _ a lu m n o s ", 0_RDWR);
f l o c k . l _ t y p e = F_WRLCK;
flo c k .l_ w h e n c e = SEEK_SET;
f l o c k . l _ S t a r t = 3 * s i z e o f ( s t r u c t a lu m n o);
f l o c k . l _ l e n = 7 * s i z e o f ( s t r u c t a lu m n o);
f lo c k . l_ p id = g e t p id O ;
f c n t l ( f d , F_SETLK, c e rr o jo ) ;
En la seccin de servicios UNIX y Windows se explican estas llamadas con ms detalle y se muestran
programas de ejemplo. La figura 9.14 muestra el efecto de usar cerrojos compartidos y exclusivos sobre un
fichero. Como se puede ver, si hay un bloqueo exclusivo, sucesivos intentos de poner otro bloqueo devuelven
error hasta que se libera el bloqueo exclusivo.
Debido al potencial de todos los mecanismos de bloqueo para crear interbloqueos o para dejar recursos
bloqueados, como se vio en el captulo 7, en general estas llamadas para bloquear el fichero solo son reco
mendaciones (advisory) para el sistema operativo y para los dems usuarios. Cualquier proceso puede abrir
un fichero sobre el que tenga permisos sin comprobar la existencia de bloqueos y leer o escribir de l. Tam
bin puede decidir escribir o leer sobre el fichero aunque no est en posesin del cerrojo del bloqueo.
9.6.
CICLO DE VID A DE UN FICHERO
Los dispositivos de almacenamiento secundario no son voltiles, es decir, no pierden su contenido cuando la
computadora deja de tener fluido elctrico (como le ocurre a la memoria RAM). Por ello, el ciclo de vida de
un fichero no est ligado al de ningn proceso, ni siquiera est ligado al ciclo de vida del proceso que lo
crea. Los ficheros se crean y permanecen en el dispositivo de almacenamiento hasta que alguien los destruye
borrndolos (como en discos o cintas) o destruyendo el dispositivo (com o en los DVD que no se pueden reescribir ni borrar).
Los ficheros tienen su propio ciclo de vida, de forma similar a un libro que tiene un ciclo de vida distin
to al del autor que lo escribi. As puede haber libros inmortales como El Quijote y otros (cm o ste?) que
duren menos que no trasciendan el ciclo de vida de sus autores. De forma similar un proceso puede crear y
destruir varios ficheros durante su vida (por ejemplo, los ficheros temporales que usa el sistema operativo) y
puede crear ficheros cuya vida sea mucha ms larga que la del proceso (por ejemplo, un fichero de resultados
de una simulacin o un registro de entradas al sistema operativo).
Cada uno de estos ficheros tiene su nombre lgico y su nombre interno, pero cm o se relacionan stos
con los procesos cuando quieren trabajar con un fichero? Pues asignando al proceso un descriptor de fichero
596
cuando abre un fichero para trabajar con l. Pero qu descriptor se asigna al proceso? Existen dos respues
tas a esta pregunta:
Asociar el descriptor del nombre interno. Esta solucin podra ser vlida si en cada instante solo
un proceso trabajara con un fichero. Sin embargo, como ya hemos visto, varios procesos pueden
abrir un fichero simultneamente y trabajar con l. En ese caso, todos estaran manipulado el des
criptor del fichero, lo que creara problemas de concurrencia. Adems de ello, cada proceso podra
estar trabajando en una zona distinta del fichero. Cmo sabra el fichero qu informacin es relativa
a un proceso si todos usaran el descriptor interno? Quin llevara el control de la posicin (despla
zamiento) de trabajo de cada proceso dentro del fichero?
Asociar un descriptor temporal asociado al nombre interno. Con esta solucin cada proceso tie
ne una tabla o lista de descriptores de ficheros abiertos por el proceso. Asociada a esta tabla puede
tener la posicin de trabajo en cada fichero, lo que resolvera los problemas anteriores. Es la solucin
elegida habitualmente en los sistemas operativos. Qu tipo de descriptor de fichero abierto se usa?
Depende del sistema operativo. Windows asocia al proceso una lista de objetos fichero que incluye
el identificador del objeto fichero devuelto por el sistema operativo cuando se abre un fichero.
LIMJX asocia a cada proceso una tabla de descriptores de ficheros abiertos y devuelve al usuario la
posicin de la tabla donde se encuentra el descriptor asociado. Como se ver ms adelante, la solu
cin real es un poco ms compleja debido a un cierto tipo de comparticin de ficheros.
La figura 9.15 muestra el ciclo de vida de un fichero. El fichero vive desde que el proceso PO lo crea,
con el nombre h i j o , hasta que el proceso P3 lo borra. Todos los procesos realizan sesiones de entra
da/salida con el fichero y van obteniendo descriptores para del fichero que son vlidos exclusivamente para
esa sesin de trabajo. Observe que incluso el mismo proceso, Pl, puede obtener distintos descriptores de fi
chero para distintas sesiones de trabajo.
En la seccin 9.12, dedicada al diseo, se describen las estructuras de datos que usa el sistema operativo
para almacenar cada tipo de descriptores, aunque del descriptor de sesin de trabajo ya se coment en el cap
tulo 3, dedicado a los procesos.
9.7.
DEL USUARIO A LOS DISPOSITIVOS
Los conceptos anteriores se proporcionan a los usuarios en forma de bibliotecas (ver figura 9.16) con las que
construyen sus aplicaciones. Algunas de estas bibliotecas son especiales (por ejemplo la l i b e o la s t d li b
en sistemas Linux) porque son las que realizan las llamadas al sistema. Estas bibliotecas son proporcionadas
habitualmente por los fabricantes o programadores del sistema operativo. De entre los mecanismos de entra
da/salida que proporcionan las bibliotecas los usuarios usan especialmente dos: los flujos (streams) y los me
canismos estndares del sistema operativo. La biblioteca de flujos proporciona optimizaciones sobre las
operaciones estndar. Por ejemplo, si se accede un fichero byte a byte, usar las operaciones estndares es
muy lento porque hay que realizar muchas llamadas al sistema y operaciones de disco. Con la biblioteca de
flujos se lee un bloque completo del fichero a un buffer de memoria y se sirven los bytes directamente al
usuario desde este bloque.
Una vez realizada una llamada al sistema, se entra en el sistema operativo. La llamada al sistema filtra
los parmetros de la operacin solicitada, comprueba que sean correctos y solicita el servicio al servidor de
ficheros o al de directorios, los componentes del sistema operativo que gestionan objetos fichero y directorio.
En la seccin 9.2 se describen las llamadas al sistema operativo utilizadas en UNDC (UNDC/Linux) y en Win
dows (Windows) y se muestran ejemplo de cmo realizar programas que usan dichas llamadas.
597
d e s c rip to r Interno = (2,3,78)
Nombre a rchivo = " h ijo
PO
abrir
cerrar
abrir
cerrar
P2
brir
P3
Figura 9.15 Ciclo de vida de unfichero: duracin y sesiones de trabajo.
La funcin principal de los servidores de ficheros y de directorios es adaptar las peticiones lgicas de
los usuarios a la representacin fsica de los objetos almacenada en los dispositivos, para lo que llevan a cabo
una serie de transformaciones de datos y operaciones. Otra funcin de estos componentes es proporcionar un
espacio de almacenamiento lgico que permita ofrecer una gestin ms sofisticada a nivel de bloques de los
dispositivos de entrada/salida de almacenamiento secundario, para lo que crean distintos tipos de estructuras
denominadas sistemas de ficheros.
Las cuatro funciones principales del sistema operativo en cuanto al almacenamiento son: ser capaz de
gestionar con eficacia los recursos, conecta la imagen lgica del fichero con la fsica, proporcionar sistemas
de nombrado lgico de ficheros y proteger los datos de los usuarios. En las secciones siguientes se muestran
Figura 9.16 Componentes de la entrada/salida con ficheros.
598
los aspectos de diseo fundamentales relacionados con el servidor de ficheros y con los sistemas de ficheros.
9.7.1. Proyecciones lgica y fsica del fichero

Para poder acceder a los datos de un fichero, sea del tipo que sea, siempre es necesario solventar el mismo
problema: pasar de los bytes que maneja el usuario a los bloques del dispositivo donde se almacenan los da
tos. Para ello es necesario hacer dos proyecciones:
1. Bytes a bloques lgicos del fichero.
2. Bloques lgicos del fichero a bloques fsicos del dispositivo.
En la primera proyeccin no interviene nada ms que el byte al que se quiere acceder y el tamao de
bloque del fichero. En la segunda proyeccin, como ya hemos visto en los ejemplos anteriores, es muy rele
vante la estructura de almacenamiento del fichero. La forma de calcular el bloque es tan sencilla como hacer
la divisin entera de la posicin de fichero por el tamao del bloque (asumiendo que el bloque 0 existe). Es
decir:
Num. Bloque = posicin / Tamao bloque
En la segunda proyeccin, denominada proyeccin fsica, es determinante conocer la estructura de al
macenamiento del fichero. Existen distintas formas de almacenar un fichero en un dispositivo, como se ver a
continuacin, pero, independientemente de ellas, hay que saber pasar del nmero del bloque lgico del fiche
ro al nmero de bloque fsico del dispositivo que le corresponde.
La figura 9.17 muestra el flujo de operaciones en un fichero debido a una llamada read , as como las
operaciones necesarias para generar dicho flujo. El usuario ve un vector de bytes, que son colectivamente
descritos mediante un descriptor de fichero, un apuntador de posicin en el fichero y el nmero de bytes a
leer. Los datos a leer pueden no estar alineados con el principio de un bloque lgico y el nmero de bytes
pedidos puede no ser mltiplo del tamao de bloque lgico. Cuando el sistema operativo virtual recibe la
peticin de lectura, calcula los bloques lgicos del fichero asociados con el trozo de fichero pedido, teniendo
en cuenta que si no estn alineados a principio y fin de bloque, se deben elegir los dos bloques cuyos frag
mentos estn afectados por la operacin. Como puede verse en la figura, es habitual que slo se necesite un
fragmento del bloque inicial y final de la peticin. Sin embargo, puesto que el sistema de ficheros trabaja con
bloques, es necesario leer ambos bloques completos.
Aqu terminara la proyeccin de byte a bloque lgico. Una vez calculados los bloques lgicos, es nece
sario calcular los bloques fsicos de dispositivo asociados con ellos y a continuacin se solicitan los bloques
al manejador de disco. Aqu termina la proyeccin fsica. Una vez terminada la operacin de lectura, los blo
ques se copian al espacio del usuario y la operacin termina.
La realizacin de la proyeccin fsica depende mucho de la forma de almacenar el fichero en los dispo-
read (fd, buffer, tamao)

Usuario
f ^ ^ 'b f f e r
U
------ tam ao------
Archivo lqico
'
|
Rlnqnps lgirns
Bloques de disco
Figura 9.17 Flujo de operaciones en unfichero.
3 v [fe;4
jf5
11340 1756 I.840
fe s
[ 8322 I
599
sitivos y de las estructuras de datos usadas para representar el fichero. En la seccin siguiente se describen las
principales estructuras usadas para representar un fichero y las formas de almacenar dicho fichero.
9.8.
ESTRUCTURA Y A LM AC EN AM IENTO DEL FICHERO
Una de las cuestiones ms importantes del diseo y la implementacin de un servidor de ficheros es cmo
asignar los bloques de disco a un fichero y cmo hacerlos corresponder con la imagen del fichero que tiene la
oplir.ar.in. Kste problema se resuelve con lo que tradicionalmente se conoce como mecanismos de asigna:
cin. Es fundamental conocer en primera instancia cmo se quieren almacenar los ficheros y directorios" a
nivel interno del sistema. Dado que los dispositivos de almacenamiento son dispositivos de bloque (vea el
captulo 8), es necesario decidir cmo se va a hacer corresponder el modelo de bytes contiguos que usa el
usuario con el modelo de bloques fsicos de los dispositivos. El sistema operativo debe pues proporcionar una
estructura de fichero que permita proyectar conjuntos de bytes sobre bloques de disco. lJara ello existen dos
opciones bsicas:
Asignacin de bloques contiguos del dispositivo. Con este mtodo, los ficheros deben estar totalmente
contiguos en los dispositivos. Origina fragmentacin extema debido a los huecos que no se pueden usar. La
representacin del fichero con este mtodo es muy sencilla, como se ver a continuacin.
Asignacin de bloques discontiguos del dispositivo. Con este mtodo, se asigna al fichero el primer
bloque que se encuentra libre. De esta forma se elimina el problema de la fragmentacin externa del disco y
el de la bsqueda de huecos. Adems, los ficheros pueden crecer mientras exista espacio en el disco. Sin em
bargo, este mtodo complica la implementacin de la imagen de fichero que usa el servidor de ficheros. La
razn es que se pasa de un conjunto de bloques contiguos a un conjunto de bloques dispersos, debiendo co
nocer dnde estn dichos bloques y en qu orden deben recorrerse. Los tipos principales de estructuras de
ficheros con asignacin discontigua son: ficheros enlazados, ficheros indexados y rboles balanceados. A
continuacin se estudian en detalle.
9.8.1. Ficheros contiguos

Los ficheros contiguos, o almacenados de forma contigua, (figura 9.18) comienzan en un bloque del disposi
tivo y se extienden de forma contigua. El nmero de bloques ocupados, y por tanto el hueco contiguo que se
necesita en el dispositivo, es directamente proporcional al tamao del fichero e inversamente proporcional al
tamao de bloques. Por ejemplo, un fichero de 64 KBytes ocupar 32 contiguos bloques de 2 Kbytes. Este
tipo de almacenamiento es el usado en CD-ROM v en cintas. Es muy sencillo de implementar y el rendimien
to de la E/S es muy bueno, pero si no se conoce el tamao total del fichero cuando se creaTbuede ser necesa
rio buscar un nuevo hnecn de bloques consecutivos cada vez que el fichein crece.. Adems, la necesidad de
buscar huecos contiguos origina una gran fragmentacin extema en el disco, y a que hay muchos huecos no
utilizables debido a la poltica de asignacin. Seria pues necesario/oTMpactorjsl disco muy frecuentemente.
Debido a estas desventajas, ningn sistema operativo moderno usa este mtodo, a pesar de que la representa
cin interna del fichero es muy sencilla: basta con conocer el primer bloque del fichero y su longitud.
Cul es el tamao mximo de fichero que se puede representar con este mtodo? Depende nicamente
del tamao de dispositivo y del apuntador de posicin del fichero. Si la posicin dentro del fichero se repre
senta con 32 bits, se puede representar un fichero de 4 Gbytes. Sin embargo, si es de 64 bits, se puede repre
sentar 4 * 260, que sobrepasa con mucho los sistemas de almacenamiento actuales. Asumiendo un bloque de 4
KBytes, el tamao total de fichero que se puede representar con un nodo-i como el de la figura 9.19, es el
siguiente:
Tamao fichero = num. Bloques Dispositivo* 4 KBytes.
Como se puede observar el fichero representable no tiene otra limitacin que la capacidad del dispositi
vo que lo alberga y la capacidad del sistema de representacin de la arquitectura del computador. Actualmen-
600
CONTIGUO
;;
X X X
1 2
A A A AA
X X
4 5 6 7
X X
a y a -'.:--
B B B
9 10 11 12 13 14 15
f
Archivo B
archivo A: (3 ,5 )
archivo B: (12, 3)
/venivo a
ENLAZADO
BLOQUES
ENLAZADO
GRUPOS
X X X
A A A
X X
A A
0 1 2 3 4 5 6 7 8 9 1 0
X X
BB
11 1 2 1 3 1 4 1 5
0 1 2 3 4 5 6 7 8
9 1 0 1 1 1213 1415
f
Archivo B
archivo A: (3 ,3 ), (8 ,2 )
archivo B: (12,2), (15,1)
Archivo B
archivo A: 6, 8 ,4 , 2
archivo B: 5, 9 ,1 2
Figura 9.18 Representacin interna deficheros contiguos y enlazados.

te los CD-ROM almacenan unos 600 MBytes y los DVD del orden de 9 Gbytes. Las cintas pueden almacenar
del orden de 80 o 100 Gbytes.
Cul es el peor tiempo de acceso a un bloque de uno de estos ficheros para un disco con tiempo de ac
ceso de 10 mseg.? Asumiendo que el descriptor del fichero (directorio) est en memoria, si en el ejemplo
anterior se pide el byte 6 Mbytes el bloque donde est el byte es el siguiente:
Bloque = offset / tamao bloque + 1 = 6
Mbytes / 4 Kbytes + 1 = 1536
No es necesario acceder a ms bloques que el de datos, que se obtiene sumando al bloque calculado el
bloque base o inicial del fichero. Por tanto, hay un acceso a disco.
Tiempo acceso
10 mseg. = 10 mseg.
9.8.2. Ficheros enlazados

Los ficheros enlazados se basan en el uso de una lista de bloques discontiguos enlazados para representar un
fichero. En una lista enlazada desde cada bloque de un fichero existe un apuntador al siguiente bloque del
mismo. En el descriptor del fichero se indica nicamente el primer bloque del fichero. La lista puede ser de
dos tipos: lista de bloques y lista de grupos de bloques contiguos.
En una lista enlazada pura, desde cada bloque de un fichero existe un apuntador al siguiente bloque del
mismo. En el descriptor del fichero se indica nicamente el primer bloque del fichero. Este mtodo tiene va
rias desventajas:
No es adecuado para accesos aleatorios, ya que hay que leer todos los bloques para recorrer la cade
na de enlaces hasta el destino.
Puesto que el apuntador al bloque siguiente ocupa espacio (digamos 4 bytes) y estn incluidos en el
fichero, el clculo de la longitud real del fichero es ms complicado.
601
Tabla 9.1 Tamaos de fichero de sistemas FAT.

Bits
Direccionamiento
Tamao Bloque
Bloques por
Agrupacin
16
2 ** 16
4 Kbytes
32
2 ** 32
4 Kbytes
1
8
1
Tamao
Fichero (by
tes)
516 Mbytes
2 Gbytes
16 TBytes
La inclusin de los apuntadores en los bloques de datos hace que el tamao de estos deje de ser ml
tiplo de 2 (cosa que ocurre habitualmente), complicando mucho el clculo del nmero de bloque en
el que est un determinado byte del fichero.
Es muy p oco fiable, ya que la prdida de un bloque del fichero supone la prdida de todos los datos
del fichero que van detrs de dicho bloque.
Las desventajas de la lista enlazada se pueden eliminar si se quitan los apuntadores de los bloques del
fichero y se almacenan en un ndice enlazado, gestionado por el servidor de ficheros, que representa el disco.
Para representar un fichero desde cada bloque o grupo se apunta al siguiente del fichero indicando en cada
bloque el siguiente bloque del fichero. El ltimo bloque del mismo incluye la entrada EOF. La lista de grupos
est formada por un encadenamiento de entradas que incluyen el bloque de comienzo y el nmero de bloques
contiguos incluidos en el grupo. La primera es tpica de sistemas FAT (file allocation table) y la segunda de
sistemas FAT con agrupaciones, como se ver a continuacin (vase figura 9.18).
La gran desventaja de esta solucin es que para acceder a una posicin aleatoria de un fichero es nece
sario recorrer el fichero desde el primer bloque hasta encontrar el bloque de la posicin deseada, lo que hace
a este sistema muy lento para accesos aleatorios si los ficheros son grandes. Tiene adems otro problema: el
espacio que ocupan las tablas de ndices, l'or ejemplo, si se quiere representar un dispositivo de 4 Gbytes
dividido en bloques de 2 KBytes, hara falta una lista de bloques con 2*1024*1024 entradas, lo que, asu
miendo entradas con 32 bits, origina una lista de bloques de 8 MBytes. El tamao de esta tabla hara difcil
mantenerla en memoria.
Cul es el tamao mximo de fichero que se puede representar con este mtodo? De nuevo depende
nicamente del tamao de dispositivo y del apuntador de posicin delTichero. Sin embargo, en este caso es
necesario tener en cuneta los bits que se usan para representar el nmero de bloque dentro de la lista enlaza
da. La tabla 9.1 muestra la diferencia entre una representacin FAT con entradas de 16 bits (FAT16), con 32
bits (FAT 32) y ambos casos apuntando en lugar de bloques agrupaciones de 4 bloques.
Como se puede ver el sistema FAT16 tiene serias limitaciones para ser usado en dispositivos grandes.
Asignando todos los bloques del dispositivo a un fichero se puede llegar a un fichero mayor de 2 Gbytes,
pero a costa de asignar agrupaciones cada vez mayores. Este diseo, como se ver a continuacin, desperdi
cia muchsimo espacio de disco y es poco aconsejable. El sistema FAT32 permite direccionar dispositivos
muy grandes y desperdicia menos espacio de disco, pero a costa de ocupar mucho espacio con la tabla de
enlaces.
;.Cul es el peor tiempo de acceso a un bloque de uno de estos ficheros para un disco con tiempo de ac
ceso de 10 mseg.? Pues la respuesta es clara, depende proporcionalmente de su posicin en la tabla de enla
ces (FAT). Asumiendo que el descriptor del fichero (directorio) est en memoria y que desde l se apunta al
primer bloque del fichero en la FAT, si en el ejemplo anterior se pide el byte 6 Mbytes del fichero, el bloque
donde est el byte es el siguiente:
Asumiendo que el primer bloque del fichero sea el 10, es necesario recorrer los 1536 enlaces siguientes
del fichero para poder calcular el bloque del dispositivo que tiene ese byte. Para ello es necesario leer los
bloques de la FAT a memoria y luego el bloque de datos. Cuntos bloques de la FAT hay que leer? Asu
miendo un bloque de 4 KBytes y 32 bits para direccional cada bloque, cada bloque de la FAT contendr 1024
enlaces. Si el fichero estuviera almacenado contiguamente, bastara con 2 accesos a FAT y uno a datos:
602

Tiempo acceso ptimo = (2 FAT + 1 datos) * 10 mseg. = 3 0 mseg.
El problema surge cuando los bloques del fichero estn dispersos por toda la FAT. En este caso el
tiempo peor de acceso nos puede llegar a realizar 1536 accesos a disco para leer los nmeros de bloque de la
FAT.
Tiempo acceso pesimista = (1536 FAT + 1 datos) * 10 mseg. = 15370 mseg.
Asumiendo que en cada bloque de la FAT se encuentran un 10% del fichero, es decir 124 bloques, ser
an necesarios 13 accesos a la FAT, luego:
Tiempo acceso 10% = (13 FAT + 1 datos) * 10 mseg. = 140 mseg.
Como se puede observar, el tiempo de acceso depende mucho de que el fichero est almacenado conti
guamente en los dispositivos.
Prestaciones 9.1 Como se puede ver, el tiempo de acceso depende de lo compacta que est la informacin d1;
los ficheros en el disco y de que los bloques de un fichero estn lo ms cerca posible. Esto se puede conseguir?,
compactando el disco con cierta frecuencia.
9.8.3. Ficheros indexados

Los problemas anteriores se pueden resolver usando ficheros indexados, es decir ficheros que se representan
mediante un ndice multinivel que apunta directamente a los bloques del fichero. Este es el caso del nodo-i
que describe al objeto fichero en UNIX y LINUX. Con estasolucion. calITchero tiene sus bloques de ndi
ce que incluyen apuntadores a los bloques de disco del fichero. El orden lgicose consigue mediante la insercin de los apuntadores en orden creciente, a partir del primero, en los bloques de ndices. Por ejemplo, el
byte 5672 de un fichero, almacenado en un sistema de ficheros que usa bloques de 4 Kbytes, se encontrar en
el segundo apuntador del ndice. La ventaja, de usar ndices es que hasta r.nn traer-a-memoria e.l bloqueas
ndices donde est el apuntador a loS-datoS-paraJener acceso al bloque-de-datos.
Adems, si un apuntador de bloque ocupa 4-.bytes-V-eLhloaue-.es_ckJl-Kbvtes.-con un nico acceso a
disco tendremos 1024 apuHtadores a bloques..delJichero. La figura 9.19 muestra un ejemplo del nodo: i d?
U f x coiTsus bloqlies de ndice y sus bloques de disco asociados. Como puede verse, cada descriptor de
fichero (nodo-i) tiene varios apuntadores directos a bloques de datos y 3 apuntadores a bloques de ndices de
primero, segundo y tercer nivel. El uso de ficheros indexados es tpico de los sistemas de almacenamiento de
UNIX SV y sus variantes, como FFF (Fast File System), ext2, etctera
Este mtodo tiene dos ventajas: Permite almacenar ficheros pequeos sin necesitar-bloques-de-indices;
Permite accesos aleatorios a ficheros muv-grandes-con-UiLmximo de 3 accesos a bloques de ndices lo que
reduce mucho el tiempoUe acceso"{rente a los mtodos.enlazados. Sin embargo, sigue teniendo una desventaj^_hay qu acceder~al~5odo-i para tener las direcciones de los bloques de_discQ-y-luego-leer-Ios-datos-Los
sistemas operativos tipo UNIX tratan de paliar este problema manteniendo los nodos-i de los ficheros abier
tos en una tabla de memoria.
Cul es el tamao mximo de fichero que se puede representar con este mtodo?
Asumiendo un tamao de bloque de disco de 4 Kbytes y apuntadores a bloque de 4 bytes, cada bloque
indirecto puede almacenar 1024 direcciones de bloque. El tamao total de fichero que se puede representar
con un nodo-i como el de la figura 9.19, es el siguiente:
Tamao fichero = num. Bloques * 4 * 1024 bytes =
(10 + 1 Kbloque + 1 Mbloque + 1 Gbloque) * 4096
> 4 Tbytes
603
Como se puede observar el fichero representable es muy grande, lo que junto con el tiempo de acceso
son las razones principales por la cuales este mtodo de representacin no ha quedado obsoleto, como ha
ocurrido con las listas enlazadas.
ceso de 10 mseg.? Asumiendo que el descriptor (nodo-i) est en memoria, si en el ejemplo anterior se pide el
byte 6 Mbytes el bloque donde est el byte es el siguiente:
Es necesario acceder a los bloques de indireccin triple. Luego el peor tiempo de acceso sera:
Tiempo acceso pesimista = (3 * bloques indirectos + 1 bloque de datos) *
10 mseg. = 40 mseg.
9.8.4 . rboles balanceados

La estructura indexada supuso un gran cambio respecto a las listas de enlaces, pero aun as tiene tresj r o b lemas: l m ite mximo del tamao del fichero, bsquedas lentas por contenido y asignaciones de bloquesaTfirjiprn m u y lentas. Para tratar de resolver estos problemas se ha introducido en los sistemas de ficheros
actuales un mtodo de almacenamiento indexado similar a los antiguos ficheros ISAM, pero basadojjn_plas,mar.la estructura de un fichero mediante un rbol balanceado^jo^&jsvita-tenemnjficherp de.ndices.
'
Urrrbcrnialaceado es"una estructura de rbol con un nmero fijo de hijos en cada nodo, en el caso
extremo se usan rboles binarios (B-Tree). La figura 9.20 muestra la estructura de un fichero almacenado
usando un rbol. Como se puede observar, del nodo-i (o raz del rbol) cuelgan n nodos. En cada nodo, in
cluido el nodo-i, hay datos y enlaces. Si los datos caben en el nodo-i, no se necesitan ms nodosTSino, el
fichero crece usando los enlaces del nodo-i a los niveles inferiores, que a su vez tambin contendrn datos e
ndices. Los nodos de los niveles intermedios se denominan nodos internos. En los niveles ms inferiorsHeT
rbol se encuentran las hojas que solo contienen datos puros, siendo estos los bloques del fichero. Solo las
hojas pueden ser nodos sin formato, el deben tener un formato bien definido, como se ve en la figura 9.20.
Originalmente, todos los bloques del fichero incluan claves, datos e ndices a bloques siguientes. Los direc
torios apuntaban al primer bloque del fichero y desde ste se iba apuntando a todos los dems mediante una
estructura de rbol descendente. F.n la actualidad, a1gnnns.sist.emas NTFS. JFS, Reiser y X F S solo almacenan
punteros en los nodos intermedios y datos de las hojas. Adems esta tcnica se complementa con la asignanodo-i
Figura 9.19 Representacin indexada: nodo-i de UNIX.
605
ceso de 10 mseg.? Asumiendo que el descriptor (nodo-i) est en memoria, si en el ejemplo anterior se pide el
byte 6 Mbytes el bloque donde est el byte es el siguiente:
Con una amplitud de 1024, se almacenaran 4 Mbytes en el primer nivel. Sera pues necesario imple
mentar un nodo ndice de segundo nivel para estos 1024 y puntero al bloque 1536 se encontrara con solo leer
el primer bloque de ndices, por lo que seran necesarios 2 accesos a disco:
Tiempo acceso pesimista = (1 * bloques ndice + 1 bloque de datos) *
10 mseg. = 20 mseg.
Suponiendo un rbol de amplitud 4, en cada nodo de ndices se podran almacenar tambin 4 Kbytes de
datos, por lo que en cada nivel n se almacenaran 4" * 4 Kbytes, obtenindose el total mediante la frmula:
E 4 ' * 4096, i=0..n-l
Lo que para el ejemplo significa 4 accesos a disco, es decir:
Tiempo acceso pesimista = (4 * bloques ndice + 1 bloque de datos)
10 mseg. = 50 mseg.
Para evitar accesos extra, Windows NTFS almacena datos en el mismo descriptor de fichero. De esta
forma, muchos ficheros pequeos pueden leerse completamente con un nico acceso a disco. Para ficheros
ms grandes, el servidor de ficheros mantiene una estructura jerrquica en forma de rbol, donde en cada
bloque se almacenan datos y apuntadores a los bloques siguientes. Si el fichero es muy grande, algunos de
estos bloques pueden a su vez estar llenos de apuntadores a nuevos bloques. Este esquema permite un acceso
muy rpido a los datos, ya que cada acceso trae datos, pero complica la implementacin del modelo de fiche
ros en el servidor de ficheros porque el primer bloque necesita un clculo de direccin especial. Adems para
optimizar ms las bsquedas y los accesos, en el Reiser File Systems usan rboles variables (dancing trees),
es decir rboles que pueden mezclar nodos sin atender a cada modificacin del rbol, sino en respuesta a un
volcado de bloques en memoria o como resultado de una clausura de transaccin que enva varios bloques a
discos. Con ello se consigue agrupar mucho ms los rboles y se escriben porciones mucho mayores, lo que
optimiza el acceso a disco.
En las secciones siguientes veremos cmo se plasman estas estructuras de almacenamiento en los dis
positivos usando sistemas de ficheros.
9.9.
ESTRUCTURA Y ALM AC EN AM IENTO DEL DIRECTORIO
Al igual que un fichero, un directorio es un objeto y debe ser representado por una estructura de datos. Una
cuestin importante de diseo es decidir qu informacin debera ir asociada a una entrada del directorio.
Hay tres alternativas principales:
Directorios para ficheros contiguos, que almacenan los atributos del fichero- en su entrada del direc
torio, junto con el primer bloque del fichero y el tamao del fichero.
Directorios para ficheros enlazados, que almacenan los atributos del fichero en su entrada del direc
torio, junto con los nmeros de todos sus bloques o del primero de ellos y el tamao del fichero.
Directorios ficheros indexados, que almacenan nicamente el identificador del descriptor de fichero
(en UNIX, el nodo-i) y colocan los atributos del objeto fichero dentro de la estructura de datos aso
ciada a su descriptor.
Los directorios para ficheros contiguos estn presentes en algunos sistemas de ficheros modernos,
como el ISO-9660 que se usa en los CD-ROM. En este caso la estructura del directorio, como se puede ver
en la figura 9.21, es muy sencilla. Esto se debe a que estos sistemas de ficheros solo incluyen almacenamien
to contiguo de ficheros, por lo que basta con conocer el primer bloque y la longitud del fichero, as como el
nombre y otros sencillos atributos x para tener el fichero perfectamente descrito. En este caso un fichero se
606

Nmero
Tipo de
del primer
archivo Reservado Hora bloque
Tamao
Directorio de MS-DOS
Directorio de CP/M
Ubicacin Fecha y
archivo
hora
Nombre
base
_L
1
Longitud Tarnao
archivo
Num.
CD
t
Nombre Sistema
archivo
Directorio de ISO-966C) (CD-ROM)

Figura 9.21 Entradas de directorios enlazados y contiguos.
puede extender a varios CD-ROM, por lo que se escribe tambin en el directorio el volumen del CD en que
se encuentra.
En la creacin de directorios en un CD bajo formato IS09660 se deben respetar las siguientes reglas:
los rboles de directorios no pueden exceder una profundidad de 8 subdirectorios; los nombres de los ficheros
solo pueden tener un mximo de 8 caracteres y deben incluir siempre un punto seguido de una extensin de 3
caracteres como mximo; los nombres de directorios no llevan extensin y son de 8 caracteres como mxi
mo; slo se permiten letras maysculas.
Hay dos extensiones a este tipo de directorio: Rock-Ridge, que permite almacenar en este directorio en
tradas de tipo UNIX, y Joliet, que permite almacenar en este directorio entradas de tipo Windows.
Ambos usan para ello los campos reservados a informacin de sistema y escriben en ellos los datos ne
cesarios para poder emular UNIX o Windows. Por ejemplo, algunos de los datos que se usan en Rock-Ridg
son: PX: bits autorizacin rwxrwxrwx; PN: contiene nmeros de dispositivos; SL: enlaces simblicos; IT:
hora de creacin, ltima modificacin y ltimo acceso. En el caso del Joliet se incluyen extensiones para
nombre largo de ficheros; caracteres Unicode para nombres en idiomas distintos al ingls; anidacin; nombre
de directorio con extensiones.
Los directorios para ficheros enlazados son ms propios de sistemas operativos antiguos, como CP/M
o MS-DOS, y almacenan atributos del fichero en su entrada de directorio. CP/M tiene un nico directorio,
en el que cada entrada incluye toda la informacin suficiente para acceder al fichero asociado (vase figura
9.21). Por tanto, una vez encontrado el nombre del fichero dentro del directorio, se dispone de sus atributos,
su tipo y un nmero mximo de bloques de disco asociados al fichero. Si se necesitan ms bloques de datos
es necesario asignar una nueva entrada de directorio y fijar su posicin dentro del fichero (1, 2, etctera)
mediante el campo e x te n d id o . Esta solucin slo permite esquemas de nombres de un nico nivel. MSDOS tiene entradas de directorio de 32 bytes que contienen el nombre del fichero, sus atributos, valores de
tiempos y el primer bloque de disco del fichero. A partir de este bloque, el sistema de ficheros accede a una
tabla de bloques del dispositivo (FAT), dentro de la cual puede acceder a bloques sucesivos del fichero por
hallarse encadenados mediante una lista. La principal diferencia entre esta solucin y la de CP/M, es que en
MS-DOS una entrada del directorio puede a su vez representar a otro directorio, con lo que se pueden definir
esquemas jerrquicos de nombres. Adems, el lmite en la extensin del fichero ya no est incluido en la en
trada del directorio, sino que depende del tamao de la FAT.
607
Los sistemas operativos modernos usan la tercera opcin, directorios para ficheros indexados, porque
tiene muchas ms ventajas que la primera y porque sera imposible reflejar la complejidad del fichero dentro
del directorio, al no existir listas encadenadas de bloques. En el sistema operativo UNIX la entrada de direc
torio es una estructura de datos muy sencilla (figura 9.22) que contiene nicamente el nombre del fichero
asociado a ella y el identificador del descriptor de fichero, nmero de nodo-i, usado por el sistema operativo.
Toda la informacin relativa a los atributos del fichero se almacena en su nodo-i. El uso de una entrada de
directorio como la de UNIX tiene varias ventajas:
La entrada de directorio no se ve afectada por los cambios de atributos del fichero.
Los nodos-i pueden representar a su vez directorios o ficheros, con lo que se pueden construir es
quemas de nombres jerrquicos de forma sencilla.
a La longitud de los nombres no est predeterminada, pudiendo ser variable hasta un lmite grande
(4096 caracteres en las versiones actuales).
o La interpretacin de nombres es muy regular, lo que aporta sencillez al sistema de ficheros.
Facilita la creacin de sinnimos para el nombre del fichero.
Para optimizar la gestin de directorios y facilitar la vida a los programadores de sistemas se incluyeron
en UNIX las llamadas al sistema de gestin de directorios mostradas en la seccin final del captulo.
Como se puede ver tambin en la figura, la entrada de directorio de Windows NTFS es similar a la de
Linux ext2, pero incluye adems atributos del fichero, lo que facilita la bsqueda de ficheros por distintos
conceptos y no slo por el nombre. Una entrada similar a esta se convierte en un registro de una tabla de base
de datos en el nuevo WinFS.
9.10. SISTEMAS DE FICHEROS

Como se vio en el captulo anterior, previamente a la utilizacin de un dispositivo de almacenamiento es ne
cesario dividir fsicamente, o lgicamente, los discos en particiones o volmenes . Una particin es una
porcin de un disco a la que se la dota de una identidad propia y que puede ser manipulada por el sistema
operativo como una entidad lgica independiente. Admite formato, instalacin de sistemas de ficheros, com
probaciones, etctera Este objeto no es utilizable directamente por la parte del sistema operativo que
gestiona los ficheros y directorios, que debe instalar un sistema de ficheros dentro de dicha particin. (Acla
racin 9.3) Adems, en el caso de discos de arranque del sistema, los sistemas operativos exigen que existan
algunas particiones dedicadas a propsitos especficos de los mismos, tales como arranque del sistema {parti
cin raz), intercambio de pginas de memoria virtual {particin de intercambio), etctera La figura 9.23
muestra la diferencia entre particin y disco. Un disco puede dividirse en varias particiones o puede contener
una nica particin. Adems, algunos sistemas operativos modernos permiten construir particiones extendi
das que engloban varias unidades de disco.
Nodo-i: Puntero al
descriptor del archivo Nombre
Nodo-i
I
_ A ___________________
Directorio de UNIX SV
Entrada
jyifPT
Longitud Longitud
entrada nombre Tipo
I
Directorio de LINUX Ext2

Longitud
Atributos nombre
Nombre Unicode
Directorio de Windows NTFS

Figura 9.22 Entradas de directorios indexados.
Nombre
I
608
Aclaracin 9.3 El sistema operativo puede acceder directamente a la particin como si fuera un dispositivo:
orientado a caracteres, pero con acceso a bloques. En este caso no es necesario que la particin tenga instiSI
do ningn tipo de sistemas de ficheros. Este tipo de accesos, habitual en bases de datos y en dispsitiv^di
swap, son muy raros a nivel de usuario en aplicaciones de propsito general. En muchos casos hay restricc?
nes de seguridad para acceder a los dispositivos de ese modo. Adems, cuando se acceden as, el sistema pe?!
rativo no puede hacer la alineacin de memoria a bloques de fichero, por lo que es obligacin del usuario5
alienar dichas peticiones_________________
- i.
Cuando se crea un sistema de ficheros en una particin de un disco, se crea una entidad lgica autocontenida con espacio para la informacin de carga del sistema de operativo, descripcin de su estructura, des
criptores de ficheros, informacin del estado de ocupacin de los bloques del sistema de ficheros y bloques
de datos.
El sistema de ficheros permite organizar la informacin dentro de los dispositivos de almacenamiento
secundario en un formato inteligible para el sistema operativo de forma que pueda realizar operaciones con
los ficheros y directorios que ponga en el mismo. El sistema de ficheros deben satisfacer los siguientes obje
tivos: satisfacer las necesidades de almacenamiento de las operaciones de usuario, optimizar el rendimiento,
garantizar la integridad y validez de los datos, ofrecer un conjunto lgico de servicios y rutinas de entra
da/salida y proporcionar soporte de entrada/salida para los distintos tipos de dispositivos de almacenamiento
y para las distintas estructuras de ficheros y directorios vistos anteriormente.
Habitualmente, cuando se instala el sistema operativo, los dispositivos de almacenamiento estn vacos.
Una vez creadas las particiones, el sistema operativo debe crear las estructuras de los sistemas de ficheros
dentro de esas particiones. Para ello se proporcionan mandatos como f ormat o mkf s al usuario. Los siguien
tes mandatos de UNIX crean dos sistemas de ficheros, uno para intercambio y uno para datos, dentro de dos
particiones del disco duro a : /dev/hda2 y /dev/hda3:
#mkswap -c /dev/hda2 2 0 800
#mkfs -c /dev/hda3 -b 8196 123100
El tamao del sistema de ficheros, por ejemplo 20800, se define en bloques. Un bloque se define como
una agrupacin lgica de sectores de disco y es la unidad de transferencia mnima que usa el sistema de
ficheros. Se usan para optimizar la eficiencia de la entrada/salida de los dispositivos secundarios de almace
namiento. Aunque todos los sistemas operativos proporcionan un tamao de bloque por defecto, habitual
mente los usuarios pueden definir el tamao de bloque a usar dentro de un sistema de ficheros. Por ejemplo,
en UNIX, mediante el mandato mkfs -b 8192 define un tamao de bloque de 8 Kbytes para /dev/hda3.
(Prestaciones 9.2) El tamao de bloque puede variar de un sistema de ficheros a otro, pero no puede cambiar
dentro del mismo sistema de ficheros.
Prestaciones 9.2. Aunque no es obligatorio, el tamao de bloque suele ser mltiplo par del nmero de sect|>
res del disco para obtener ms rendimiento del disco y para facilitar la implementacin del sistema de fiche-;
ros.
________________________ |______________________________ '________________ ___________
'..Vi
En muchos casos, adems de estos parmetros, se puede definir el tamao de la agrupacin, es decir el
P a r ti c i n
Particin 2
Particin 3
Figura 9.23 Distintas particiones y discos.
609
conjunto de bloques que se gestionan como una unidad lgica de gestin del almacenamiento. El problema
que introducen las agrupaciones, y los bloques grandes, es la existencia de fragmentacin interna. Por ejem
plo, si el tamao medio de fichero es de 6 Kbytes, un tamao de bloque de 8 Kbytes introduce una fragmen
tacin interna media de un 25%. Si la agrupacin es de 4 bloques (asignacin de 32 Kbytes), la
fragmentacin interna alcanzara casi el 80%.
Una vez decidido el tamao del bloque y agrupacin que se quiere usar, es necesario decidir la estructu
ra del sistema de ficheros plasmar en la particin. Aunque las estructuras, y la informacin que se almacena
en ella, pueden ser muy distintas, como veremos a continuacin, todos los sistemas de ficheros tienen los
siguientes campos comunes:
Descripcin del sistema de ficheros. Incluye descripcin del tipo de sistema de ficheros, configura
cin, etctera
Descripcin del mapa del dispositivo. Incluye algn tipo de informacin (enlaces, mapas de bits,
etctera.) que indica el estado de ocupacin o no de cada bloque del dispositivo.
Metadatos (nodos-i, FAT, etctera) de los ficheros almacenados en el sistema de ficheros.
Bloques de datos.
Para gestionar los ficheros y directorios, todos los sistemas operativos de propsito general incluyen
dos componentes, denominados servidor de directorios y servidor de ficheros, que se encargan de gestionar
todo lo referente a los sistemas de ficheros y las operaciones relacionadas con ellos. Estos componentes se
estudian en detalle en las secciones siguientes.
Si embargo, antes de llegar a ellos, se estudiarn los distintos tipos de sistemas de ficheros ms habitua
les en los sistemas operativos actuales. Como se podr observar, cada uno de ellos se corresponde casi direc
tamente con una de las formas de almacenar los ficheros descritos anteriormente.
9.10.1. Mecanismos de gestin de espacio libre

El espacio de los dispositivos debe ser asignado a los objetos de nueva creacin y a los ya existentes que re
quieran ms espacio de almacenamiento. Es pues necesario conocer el estado de ocupacin de los bloques de
los dispositivos para poder realizar las operaciones de asignacin de forma eficiente. Por ello, todos los sis
temas de ficheros mantienen mapas de recursos, habitualmente construidos como mapas de bits o listas de
recursos libres.
Los mapas de bits, o vectores de bits, incluyen un bit por recurso existente (descriptor de fichero, blo
que o agrupacin). Si el recurso est libre, el valor del bit asociado al mismo es 1, si est ocupado es 0. Por
ejemplo, sea un disco en el que los bloques 2, 3, 4, 8, 9 y 10 estn ocupados y el resto libres, y en el que los
descriptores de fichero 2, 3 y 4 estn ocupados. Sus mapas de bits de seran:
MB de bloques:
1100011100011....
MB de descriptores:
1100011...
La principal ventaja de este mtodo es que es fcil de implementar y sencillo de usar. Adems es muy
eficiente si el dispositivo no est muy lleno o muy fragmentado, ya que se encuentran zonas contiguas muy
fcilmente. Sin embargo tiene dos inconvenientes importantes: es difcil e ineficiente buscar espacio si el
dispositivo est fragmentado y el mapa de bits ocupa mucho espacio si el dispositivo es muy grande. Por
ejemplo, un sistema de ficheros de 4 Gbytes, con un tamao de bloque de 4 Kbytes, necesita 1 Mbit para el
mapa de bits de bloques. Para que la bsqueda sea eficiente, los mapas de bits han de estar en memoria, ya
que sera necesario recorrer casi todo el mapa de bits para encontrar hueco para un fichero. Imagine que un
sistema tuviera montados 8 dispositivos como el anterior, necesitara 1 Mbyte de memoria slo para los ma
pas de bits. Si se aplicara una agrupacin de 4 bloques, el tamao final del mapa de cada dispositivo sera de
256 Kbits (32 Kbytes), lo que equivale a 256 Kbytes para los 8 dispositivos. Estas cantidades, con ser gran
des, son mucho menores que los 32 Mbytes y 8 Mbytes que seran respectivamente necesarios con la FAT de
MS-DOS.
610
Las listas de recursos libres permiten resolver el problema de forma completamente distinta. La idea
es mantener enlazados en una lista todos los recursos disponibles (bloques o descriptores de ficheros) mante
niendo un apuntador al primer elemento de la lista. Este apuntador se mantiene siempre en memoria. Cada
elemento de la lista apunta al siguiente recurso libre de ese tipo. Cuando el servidor de ficheros necesita recursos libres, recorre la lista correspondiente y desenlaza elementos, que ya no estarn libres. Como el lector
puede comprender, este mtodo no es eficiente, excepto para dispositivos muy llenos y fragmentados, donde ^
las listas de bloques libres son muy pequeas. En cualquier otro caso, recorrer las listas requiere mucha en-l
trada/salida. La FAT del sistema operativo MS-DOS es una lista enlazada.
Una posible optimizacin de la gestin de bloques libres es reunir los bloques en agrupaciones y man
tener mapas de bits o listas de recursos libres para ellas. Por ejemplo, si en el dispositivo anterior se usan
agrupaciones de 64 Kbytes (16 bloques), el mapa de bits se reduce a 8 Kbytes. Sin embargo, esto complica la
poltica de gestin de espacio libre en el servidor de ficheros. Los sistemas operativos UNIX, LINUX y Win
dows usan este mtodo. Igualmente, se puede usar la agrupacin de bloques en las listas de recursos libres.
Obviamente, cuando se usan agrupaciones, la mnima unidad que se puede asignar es una agrupacin, por lo
que es muy importante decidir cul va a ser el tamao de la misma. Cuanto mayor sea, ms grande puede ser
la fragmentacin interna del dispositivo. Para paliar en parte este problema, los sistemas que usan agrupacio
nes suelen usar tambin el mecanismo de gestin de fragmentos descrito en la seccin del Fast File System
(FFS).
9.10.2. Sistemas de ficheros contiguos: ISO-9660

El sistema de ficheros ISO-9660 se dise para su uso en dispositivos de tipo CD-ROM. Estos dispositivos .
tienen la particularidad de que cada uno de sus bloques solo se pueden escribir una vez. Por ello se efecta
almacenamiento contiguo de ficheros hasta que se termina la sesin de escritura. En ese momento se pueden
hacer dos cosas: cerrar el volumen y cerrar la sesin. En el primer caso, se pone una marca al final de los
datos y ya no se puede escribir ms en el CD-ROM. En el segundo caso, se pone una marca de fin de sesin y
posteriormente se puede grabar otras sesiones hasta que se cierre el volumen.
Como se puede apreciar en la figura 9.24, un sistema de ficheros tipo IS09660 se divide en cinco par
tes: rea de sistema, formada por los 16 primeros bloques (0 al 15) de una imagen IS09660, que no tienen
uno habitualmente pero se usan en las versiones Rock-Ridge y Joliet; descripcin del volumen, el bloque 16
contiene toda la informacin de la imagen; tablas de localizacin, para acelerar el acceso a los directorios
esta seccin contiene la ruta de bsqueda de todos los directorios; directorios, Contiene punteros hacia los
subdirectorios y hacia los ficheros situados en dicho directorio, junto con el nmero de bloque y la longitud
del fichero que definen; ficheros, que contienen los datos de los usuarios.
La descripcin del volumen incluye datos que permiten identificar la plataforma para la que ha sido de
signado o System ID (32 bytes), la identificacin del nombre de volumen o Volume label (32 bytes), el campo
que identifica su serie u orden en aplicaciones con mltiples CD o Volume Set ID (128 bytes), la informacin
acerca de los datos de la aplicacin o Application ID (128 bytes), la definicin del status de derechos de co
pia del CD o Copyright (37 bytes / ...), la identidad del productor o Publisher (128 bytes / ...), el nombre del
autor del contenido del disco o Data preparer (128 bytes), la informacin acerca del "Volume Set o Abs-im,
tract Description (37 bytes / ...) y la informacin bibliogrfica acerca de este CD, por ejemplo el ISBN, o fe
Bibliography (37 bytes /...).
La asignacin de bloques contiguos a ficheros se lleva a cabo en paquetes contiguos. Por ejemplo, con
este mtodo, un fichero de 64 Kbytes ocupara 16 bloques consecutivos en un sistema de ficheros que use un
tamao de bloque de 4 Kbytes. Es muy sencillo de implementar y el rendimiento de la E/S es muy bueno, /
pero si no se conoce el tamao total del fichero cuando se crea, puede ser necesario buscar un nuevo hueco
de bloques consecutivos cada vez que el fichero crece. Adems, la necesidad de buscar huecos contiguos '
origina una gran fragmentacin externa en el disco, ya que hay muchos huecos no utilizables debido a la pol
tica de asignacin. Sera pues necesario compactar el disco muy frecuentemente. Debido a estas desventajas, ,f
ningn sistema operativo moderno usa este mtodo, a pesar de que la representacin interna del fichero es
muy sencilla: basta con conocer el primer bloque del fichero y su longitud.
611
Sistema de archivos ISO -9660
sst m a
&V
osyp
ES
ES
e s
EH
.lo c a liz a c i n
D ire cto rio s
m m 'mm eh ehi
e e
su
Q I] [ ] n a
!] n u QU
mi mi
Em Em
Lzj EDEH] EDED11

iJl H~4~1M5l Re itfi EDO
Figura 9.24 Estructura del sistema de ficheros ISO-9660 y asignacin de bloques.

El gran problema de este tipo de sistema de ficheros, cuando se implementa en medios que se pueden
borrar y reescribir, es la fragmentacin externa. Puesto que es necesario asignar espacio contiguo a los fi
cheros, a medida que se borran ficheros se originan en el dispositivo conjuntos de bloques libres de distintos
tamaos (figura 9.24). Si se quiere crear un fichero nuevo es necesario buscar un hueco para el mismo. Para
ello se pueden aplicar las polticas que ya se vieron en el capitulo de gestin de memoria: mejor hueco (best
fit), primer hueco (first fit), etctera. Para ello es necesario incluir una lista de huecos. En cualquier caso, los
huecos que quedan son cada vez menores y no se pueden utilizar. Incluso, en un dispositivo muy fragmenta
do con un 50% libre y huecos libres de tamao medio 24 Kbytes, puede ocurrir que se quiera crear un fichero
de 640 KBytes y no quepa. La nica solucin para este problema es compactar el disco, es decir, recolocar
todos los ficheros desde el principio del sistema de ficheros sin dejar ningn hueco. Dependiendo de la acti
vidad en el dispositivo, esta operacin debe efectuarse con cierta frecuencia. Esta operacin presenta dos
problemas: es muy lenta y bloquea el dispositivo mientras se lleva a cabo. Debido a ello, es muy difcil traba
jar con este tipo de sistemas de fichero en dispositivos de lectura/escritura.
9.10.3. Sistemas de ficheros enlazados: FAT16 y FAT32

Los sistemas de ficheros enlazados (Figura 9.25) se basan en el uso de una tabla de apuntadores (FAT, File
Allocation Tabl) que indica los bloques que pertenecen a un fichero (como ya se vio anteriormente). Cada
entrada de directorio indica el primer bloque del fichero que representa, es decir la entrada de la FAT donde
est su primer bloque. Desde cada entrada de la FAT se apunta al bloque siguiente del fichero, hasta que se
llega al ltimo, donde se incluye una marca espacial de EOF (End OfFile). En la figura hay dos ficheros (A y
B). Los ficheros pueden tener sus bloques discontinuos.
Esta forma tan sencilla de representar los ficheros se traslada inmediatamente al sistema de ficheros en
lazado. El sistema de fichero FAT tiene la estructura que se muestra en la figura 9.25. Incluye un bloque de
carga, con informacin descriptiva del sistema de ficheros, dos copias de la FAT, una entrada para el directo
rio raz y los ficheros y directorios que cuelgan de l y el resto del dispositivo se dedica a almacenar ficheros
y directorios. Las dos copias de la FAT se incluyen para aumentar la tolerancia a fallos del sistema, ya que la
existencia de una sola copia hara que cualquier fallo inutilizara total o parcialmente en sistema de ficheros.
Sin embargo, con dos copias basta con tener una bien para poder seguir operando y poder reconstruir la otra
copia. En el resto del sistema de ficheros se incluye un directorio raz, o directorio principal del sistema de
ficheros, usado para conectar este sistema de ficheros con otros y los bloques de archivos y directorios in
cluidos en el disco, que estn mezclados y no tienen reas separadas.
612
El sistema de ficheros FAT fue diseado inicialmente para su uso en MS-DOS, con arquitecturas de 16
bits de tipo Intel 286 y tamaos de discos de 32 64 MBytes y se denomin FAT16. Con esta tecnologa, el
sistema de ficheros FAT est limitado a 65.525 bloques, lo que hizo que quedara rpidamente corto para el
creciente tamao de los discos. Para solventar este problema, se agruparon los bloques en paquetes (clusters)
cada vez de mayor tamao (4, 8, 16, y 32), de forma que cada entrada de la FAT representaba una de estas
agrupaciones. Aun as, el tamao mximo de este tipo de sistemas de ficheros es de 2 GB, lmite que surge
del nmero mximo de clusters (216) y del tamao mximo del cluster que deba ser potencia de 2 y menor de
2 16 bytes (es decir 64 Kbytes), lo que produce un tamao mximo de clster de 32.768 bytes (32 KB). La
propia tabla FAT ocupada 216 * 2 = 2 17 bytes, es decir 128 Kbytes, que cabe cmodamente en memoria.
El problema de la organizacin en clusters es que presenta mucha fragmentacin interna, ya que cada
vez que se crea un fichero se le asigna como mnimo un cluster. Si el cluster es de 32 KB y el tamao medio
de los ficheros 8 KB, se desperdicia un 75% del espacio de almacenamiento. Por ello, cuando se introdujeron
las arquitecturas de 32 bits, Microsoft cre el sistema de ficheros FAT32, que usaba 32 bits para direccional
los bloques de sistema de ficheros, lo que permita incluir hasta 232 bloques (4 Gbloques) en un sistema de
este tipo. Tener un nmero de bloques tan alto permite usar clusters de un tamao ms reducido, usar disposi
tivos ms grandes y eliminar en gran parte la fragmentacin interna. Por ejemplo, si se usan clusters de 4
KBytes, se pueden construir ficheros de hasta 16 Tbytes. Todo ello a costa del aumento del tamao de la
FAT, que ahora tericamente puede llegar a ocupar 23" * 4 = 234 bytes, es decir 16 Gbytes, lo que supone una
buena porcin del disco. Asumiendo un caso actual ms realista, con una particin de 64 Gbytes y bloque de
4 Kbytes, se necesitara una FAT de 16 mega direcciones de 4 bytes, lo que significa ocupar un espacio d
disco de 64 Mbytes para cada tabla FAT. Este tamao ya no cabe tan cmodamente en memoria, por lo que
ser necesario hacer entrada/salida a disco para gestionar la FAT.
Puesto que un fichero puede estar muy disperso por el disco, puede ocurrir que hay que leer muchos
bloques de la FAT para leer dicho fichero. Adems, debido a la creacin y borrado de ficheros, quedan agu
jeros como los vistos en el caso anterior lo que origina la dispersin de los ficheros. Para evitar este proble
ma es conveniente compactar el disco con cierta periodicidad, aun cuando el sistema de ficheros no est
excesivamente lleno.
La asignacin de espacio libre se lleva a cabo buscando por las FAT los bloques necesarios. Obvia
mente, cuanto ms compacta est la FAT, ms posibilidades hay de encontrar grupos de bloques libres. C
mo se sabe que un bloque del sistema de ficheros est libre? Porque la entrada correspondiente de la FAT
tiene un cero (0). Si est ocupado, incluye el nmero del bloque siguiente del fichero. Para optimizar la bs
queda de bloques libres, el sistema mantiene un apuntador al ltimo bloque libre encontrado y busca de esa
posicin hacia delante.
Comprobar la integridad de un sistema de ficheros FAT es sencillo. Basta con comprobar que cada en
trada de una FAT es igual a la de la otra, recorriendo ambas FAT de principio a fin. Si no son iguales, habr
que hacerlas iguales eligiendo la correcta si es posible. La otra cuestin a comprobar es que el directorio raz
tenga un nmero de primer bloque vlido. El procedimiento anterior es sencillo y rpido. Si se hace una
comprobacin ms exhaustiva, se mira directorio a directorio para ver si el primer bloque de cada fichero
Sistema de archivos FA.T

'B lque'de
FAT
carga
FAT
Directorio
raz ,
Figura 9.25 Estructura del sistema de ficheros FAT.
Archivos y
directorios
613
existe y est marcado como ocupado en la FAT.
g.10.4. Estructura de los sistemas de ficheros UNIX SV

La figura 9.26 muestra las estructuras de un sistema de ficheros para UND SV, MINIX, etctera, as como la
disposicin de sus distintos componentes. Esta es la estructura clsica de los sistemas de ficheros de UNLX.
Como se puede ver en la figura, se basa en el uso de ficheros indexados.
En UND, cada sistema de ficheros tiene un bloque de carga que contiene el cdigo del programa de
arranque del programa almacenado en la ROM del computador. Cuando se arranca la mquina, el iniciador
ROM lee el bloque de carga del dispositivo que almacena al sistema operativo, lo carga en memoria, salta a
la primera posicin del cdigo y lo ejecuta. Este cdigo es el que se encarga de instalar el sistema operativo
en el computador, leyndolo desde el disco. No todos los sistemas de ficheros necesitan un bloque de carga.
En MS-DOS o UNIX, por ejemplo, slo los dispositivos de sistema, es decir aquellos que tienen el sistema
operativo instalado contienen un bloque de carga vlido. Sin embargo, para mantener la estructura del siste
ma de ficheros uniforme, se suele incluir en todos ellos un bloque reservado para carga. El sistema operativo
incluye un nmero, denominado nmero mgico, en dicho bloque para indicar que es un dispositivo de car
ga. Si se intenta cargar de un dispositivo sin nmero mgico, o con un valor errneo del mismo, el monitor
ROM lo detecta y genera un error.
A continuacin del bloque de carga, est la metainformacin del sistema de ficheros (superbloque, no
dos-i, ..) La metainformacin describe el sistema de ficheros y la distribucin de sus componentes. Suele
estar agrupada al principio del disco y es necesaria para acceder al sistema de ficheros. El primer componente
de la metainformacin en un sistema de ficheros UNIX es el superbloque (el Bloque de Descripcin del
Dispositivo en Windows), que contiene la informacin que describe toda la estructura del sistema de fiche
ros. La informacin contenida en el superbloque indica al sistema operativo las caractersticas del sistema de
ficheros, dnde estn los distintos elementos del mismo y cunto ocupan. Para reducir el tamao del super
bloque, slo se indica la informacin que no puede ser calculada a partir de otra. Por ejemplo, si se indica que
el tamao del bloque usado es 4 Kbytes, que el sistema tiene 16 K nodos-i y que el nodo-i ocupa 512 bytes,
es sencillo calcular que el espacio que ocupan los nodos-i en el sistema de ficheros es 2048 bloques. Asimis
mo, si se usan mapas de bits para representar el estado de ocupacin de los nodos-i, necesitaremos 16 Kbits,
lo que significa que el mapa de bits de los nodos-i ocupara 4 bloques del sistema de ficheros.
La figura 9.27 muestra una parte del superbloque de un sistema de ficheros de LINUX. Como se puede
ver, adems de la informacin reseada, se incluye informacin comn para todos los sistemas de ficheros
que proporciona el sistema operativo y una entrada para cada tipo de ficheros en particular (MLNIX, MSDOS, ISO, NFS, SYSTEM V, UFS, genrico, etctera). En este caso se incluye informacin de gestin tal
como el tipo del dispositivo, el tamao de bloque, nmero mgico, tipo de fichero, operaciones sobre el su
perbloque y de cuota de disco y apuntadores a los tipos de fichero que soporta.
Sistema de archivos UNIX SV

Bloque de Super
carga
bloque
Mapas
de bits
Nodos-i
Figura 9.26 Estructura del sistema de ficheros UNIXSV.
Archivos y
directorios
614
m?
h i
Para cada uno de ellos, se incluye una estructura de datos para su superbloque particular, el mximo
tamao de fichero posible, la proteccin que se aplica al sistema de ficheros, etctera Adems, para optimizar
aspectos como la bsqueda de espacio libre, se incluye informacin sobre la situacin del primer bloque libre
y del primer descriptor de ficheros libre. Como ejemplo de superbloque particular, se muestra el de MINIX
Cuando arranca el computador y se carga el sistema operativo, el superbloque del dispositivo de carga,
o sistema de ficheros raz, se carga en memoria en la tabla de superbloques. A medida que otros sistemas
de ficheros son incorporados a la jerarqua de directorios (en U N IX se dice que son montados) sus superblo
ques se cargan en la tabla de superbloques existente en memoria. La forma de enlazar unos con otros se ver
ms adelante.
Tras el superbloque, el sistema de ficheros incluye informacin de gestin de espacio en el disco. Esta
informacin se basa en el uso de mapas de bits y es necesaria por dos razones: para permitir al servidor de
ficheros implementar distintas polticas de asignacin de espacio y para reutilizar los recursos liberados para
nuevos ficheros y directorios. Normalmente, los sistemas de ficheros incluyen dos mapas de espacio libre:
Mapas de bloques de datos, o mapas de bits, en los que se indica si un bloque de datos est libre o
no. En caso de que el espacio de datos se administre con agrupaciones para optimizar la gestin de
espacio libre, esta informacin se refiere a las agrupaciones. Si el bit[j] = 0, el bloque est libre; si el
bit[j] = 1, el bloque est ocupado.
Mapas de la descriptores fsicos de ficheros, como nodos-i en UNIX o registros de Windows, en la
que se indica si un descriptor de fichero est libre o no. Si el bit[j] = 0, el nodo-i est libre; si el bit[j]
= 1, el nodo-i est ocupado.
Los mapas de bits ocupan espacio en disco. Por ejemplo, para un disco de 64 Gbytes y bloque de 4
Kbytes, se necesitan 16 Mbits (2 Mbytes). Sin embargo, estos mapas de bits se pueden albergar en memoria
de forma cmoda actualmente.
Despus de los mapas de recursos del sistema de ficheros, se encuentran los descriptores fsicos de fi
cheros. Estos descriptores son los nodos-i de UNIX, tienen una estructura y tamao variable dependiendo de
cada sistema operativo, segn se vio en secciones anteriores. Por ejemplo, en LINUX ocupa 128 bytes y en
UNIX casi 2 Kbytes. El tamao del rea de descriptores de fichero es fcilmente calculable si se conoce el
tamao del nodo-i y el nmero de nodos-i disponibles en el sistema de ficheros. Normalmente, cuando se
Superbloque Virtual .
r Dispositivo
M fey 'sT ania to16 bloque del superbloque
^ f $ - vF1ags, nmero mgico y tiempos
^gO peraciones sobre el sistema de archivos
& & .Ofcracione3 sobre el superbloque
- . Superbloque de EXT2
:
.
. .
/. Superbloque de MINIX
' Superbloque de UFS

' ' ' Superbloque de NFS
Superbloque de MINIX
Nmero de agrupaciones
:Nmro]da,bloques de mapa de bits de nodos-i
Nmero d btoqs de mapas de bits de agrupaciones
, ; primer bloque de datos
Mximo tamao de archivo
fjS S ^ -flh te ro al nodo-i raz del SF montado
f e iS H Puntero al nodo-i de montaje
^ N m e ro de dispositivo
Fia; de proteccin (ro,...)
^Versin de SF
|gfe_bit!b ra;enel mapa de bits de nodos-J
Ijbre en l mapa de bits de dusters
Figura 9.27 Superbloque de sistemas deficheros MINIX en LINUX.
Informacin
presente
en disco y
en memoria
615
crea un sistema de ficheros, el sistema operativo habilita un nmero de descriptores de fichero proporcional
al tamao del dispositivo. Por ejemplo, en LINUX se crea un nodo-i por cada 2 bloques de datos. Este par
metro puede ser modificado por el usuario cuando crea un sistema de ficheros, lo que en el caso de UNIX se
hace con el mandato mkf s.
El ltimo componente del sistema de ficheros son los bloques de datos. Estos bloques, bien tratados de
forma individual o bien en grupos, son asignados a los ficheros por el servidor de ficheros, que establece una
correspondencia entre el bloque y el fichero a travs del descriptor del fichero. Tanto si se usan bloques indi
viduales como agrupaciones, el tamao de la unidad de acceso que se usa en el sistema de ficheros es uno de
los factores ms importantes en el rendimiento de la entrada/salida del sistema operativo. Puesto que el blo
que es la mnima unidad de transferencia que maneja el sistema operativo, elegir un tamao de bloque pe
queo, por ejemplo 512 bytes, permite aprovechar al mximo el tamao del disco. As, el fichero p ru eba de
1,2 Kbytes ocupara 3 bloques y slo desperdiciara Vi bloque o el 20% del espacio de disco si todos los fi
cheros fuesen de ese tamao. Si el bloque fuese de 32 Kbytes, el fichero ocupara un nico bloque y desper
diciara el 90% del bloque y del espacio de disco. Ahora bien, transferir el fichero pru eba, en el primer caso,
necesitara la transferencia de 3 bloques, lo que significa buscar cada bloque en el disco, esperar el tiempo de
latencia y hacer la transferencia de datos. Con bloques de 32 Kbytes slo se necesitara una operacin. La
figura 9.28 muestra la relacin entre tamao de bloque, velocidad de transferencia y porcentaje de uso del
sistema de ficheros, con un tamao medio de fichero de 14 Kbytes. Como puede verse, los dos ltimos par
metros son contradictorios, por lo que es necesario adoptar una solucin de compromiso que proporcione
rendimientos aceptables para ambos. En el caso del dispositivo cuyos resultados se muestran en la figura, el
tamao de bloque puede estar entre 4Kbytes y 8 Kbytes. Es interesante resaltar que esta curva cambia con la
tecnologa de los discos y con el tamao medio de los ficheros, que ha cambiado desde 1 Kbyte en los siste
mas UNIX de hace 15 aos hasta los 14 Kbytes medidos en estudios ms actuales. Adems, el uso masivo de
informacin multimedia tender a incrementar mucho el tamao medio de los ficheros en un futuro prximo,
por lo que es necesario evaluar los parmetros cuidadosamente y ajustarlos al tipo de almacenamiento que se
llevar a cabo en cada dispositivo (general, cientfico, multimedia, etctera).
La asignacin de espacio libre se lleva a cabo buscando en los mapas de bits los bloques necesarios.
Para buscar en los mapas de bits se llevan a cabo mscaras de bits a nivel de palabra de 32 bits. Si se mantie
ne un indicador del ltimo bit asignado (u ba), se puede calcular la palabra a la que pertenece mediante la
operacin pal = uba / 32. Una vez conocida la palabra se lee y se efecta una mscara con Oxffffffff
para ver si hay algn bloque libre en esa palabra:
Si pal & Oxffffffff = 0 -> hay un bloque libre.
Con este mtodo se pueden asignar fcilmente grupos de hasta 32 bloques consecutivos. Si se necesita
ms espacio es cuestin de repetir la operacin anterior. En caso de que el sistema de ficheros est muy lleno
habr que repetir la operacin muchas veces buscando por el mapa de bits. En cualquier caso, la asignacin
de bloques es rpida si el mapa de bits est en memoria.
Tamao de Bloque
Figura 9.28 Relacin entre el tamao de bloque, el ancho de banda y el uso del disco.

Libro Sistemas Operativos Una Visión Aplicada 2 Edición

Cargado por

Copyright:

Formatos disponibles

Libro Sistemas Operativos Una Visión Aplicada 2 Edición

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Libro Sistemas Operativos Una Visión Aplicada 2 Edición

Cargado por

Copyright:

Formatos disponibles

1

Sistemas operativos. Una visin aplicada

ESTRUCTURA Y FUNCIONAMIENTO DEL COMPUTADOR

Figura 1.1 Esquema de funcionamiento del computador.

Conceptos arquitectnicos del computador

mente la siguiente secuencia:

Lee de memoria la siguiente instruccin mquina que forma el programa.

MODELO DE PROGRAMACIN DEL COMPUTADOR

Puntero de pila de usuario

Figura 1.3 Modelo de programacin de un computador.

Sistemas operativos. Una visin aplicada

1.2.1. Modos de ejecucin

1.2.2. Secuencia de funcionamiento del procesador

C onceptos arquitectnicos del c o m p u ta d o r

Figura 1.4 Modelos de programacin de usuario y de privilegiado.

a) Lectura de la Instruccin apuntada por PC

Figura 1.5 Secuencia de ejecucin del procesador.

Sistemas operativos. Una visin aplicada

1.2.3. Registros de control y estado

Bits de estado aritmticos como: Signo, Acarreo, Cero o Desbordamiento.

Conceptos arquitectnicos del computador

Error de paridad en bus.

Figura 1.6 Acceso a la rutina de tratamiento de la interrupcin.

Sistemas operativos. Una visin aplicada

Figura 1.7 Mecanismo de inhibicin/prioridad de interrupcin.

Conceptos arquitectnicos del computador

Figura 1.8 Relojes del computador:

Conceptos arquitectnicos del computador

1.6.2. E/S y concurrencia

Sistemas operativos. Una visin aplicada

Se pone a "0" el registro R1

Conceptos arquitectnicos del computador

1.6.3. Buses y direccionamiento

Tabla 1.3 Reparto del mapa de direcciones del PXA-255.

INTRODUCCION A LOS SISTEMAS

Sistemas operativos. Una visin aplicada

2.1^ QU ES UN SISTEMA OPERATIVO?

Estado inicial de los registros del procesador.

d ieo en lenguaje mouina.

Figura 2.1 Preparacin del cdigo ejecutable.

Introduccin a ios sistemas operativos

2.1.1. Sistema operativo

Figura 2.2 Niveles del sistema operativo.

Sistemas operativos. Una visin aplicada

El sistema operativo como gestor de recursos

Introduccin a los sistemas operativos

Sistemas operativos. Una visin aplicada

2.1.2. Concepto de usuario y de grupo de usuarios

2.2. ARRANQUE Y PARADA DEL SISTEMA

Introduccin a los sistemas operativos

MS-DOS o los .l o g i n y .c s h r c en UNIX. A continuacin, el shell se queda esperando rdenes de los

2.2.3. Parada del computador

2.3._ ACTIVACIN DEL SISTEMA OPERATIVO

Sistemas operativos. Una visin aplicada

Excepciones hardware sncronas (vase seccin 1.3 Interrupciones, pgina 6 ).

2.3.1. Servicios del sistema ^nprativo v funcione? rie llamada

tSe solicita el SO mediante una interrupcin

Figura 2.6 Modelo simplificado de la activacin del sistema operativo.

Introduccin a los sistemas operativos

_ Capa 5: Programas de usuario_

| Red de Interconexin