Sistemas Operativos

Sistemas Operativos
Curso acadmico 2014/2015
Esta obra de Jess Torres est bajo una Licencia Creative Commons
Atribucin 4.0 Internacional. ISBN 978-84-695-9610-4
ndice de contenido
1. Introduccin 1
1.1. Qu hace un sistema operativo?..............................................................................................1
1.2. Tipos de sistemas operativos.....................................................................................................4
1.3. Historia de los sistemas operativos.........................................................................................10
2. Estructura de los sistemas operativos 11

2.1. Componentes del sistema........................................................................................................11
2.2. Servicios del sistema...............................................................................................................16
2.3. Operacin del sistema operativo.............................................................................................18
2.4. Llamadas al sistema................................................................................................................20
2.5. Programas del sistema............................................................................................................23
2.6. Estructura del sistema.............................................................................................................25
2.7. Mquinas virtuales..................................................................................................................32
2.8. Arranque del sistema...............................................................................................................38
3. Gestin de procesos 41
3.1. Procesos..................................................................................................................................41
3.2. Procesos cooperativos.............................................................................................................50
3.3. Hilos........................................................................................................................................67
3.4. Planificacin de la CPU..........................................................................................................77
4. Gestin de memoria 105

4.1. Memoria principal.................................................................................................................105
4.2. Memoria Virtual....................................................................................................................143
5. Gestin del almacenamiento 185

5.1. Interfaz del sistema de archivos............................................................................................185
5.2. Implementacin de sistemas de archivos..............................................................................198
5.3. Estructura del almacenamiento masivo................................................................................215
ndice de figuras
Figura 1.1: Vista abstracta de los componentes de un sistema informtico.........................................2
Figura 1.2: Disposicin de la memoria en un sistema de procesamiento por lotes..............................5
Figura 1.3: Disposicin de la memoria en un sistema multiprogramado.............................................6
Figura 1.4: Instalacin de un mainframe IBM 702............................................................................13
Figura 1.5: Mainframe GE-6180 con sistema operativo MULTICS (MIT ca. 1976).........................14
Figura 1.6: Miniordenador DEC PDP-7.............................................................................................15
Figura 2.2: Llamada al sistema en Linux MIPS.................................................................................25
Figura 2.1: Diagrama general de organizacin de los sistemas operativos........................................26
Figura 2.3: Elementos de la interfaz de programacin de aplicaciones en GNU/Linux....................27
Figura 2.4: Mapeo de la memoria fsica en el espacio de direcciones virtual de un proceso.............37
Figura 2.5: Ejemplo de sistema operativo con estructura sencilla (MSDOS)....................................39
Figura 2.7: Ejemplo de sistema operativo con estructura sencilla (UNIX original)..........................40
Figura 2.6: Diagrama de bloques de Microsoft Windows XP............................................................40
Figura 2.8: Diagrama de bloques de GNU/Hurd................................................................................43
Figura 2.9: Ejemplo de sistema operativo con estructura modular (GNU/Linux).............................45
Figura 3.1: Estructura de un proceso en memoria..............................................................................48
Figura 3.2: Diagrama de estado de los procesos................................................................................49
Figura 3.3: Diagrama de colas de la planificacin de procesos..........................................................51
Figura 3.4: Ejemplo de creacin de un proceso con fork()/exec().....................................................55
Figura 3.5: Modelos de comunicacin...............................................................................................57
Figura 3.6: Ejemplo de utilizacin de tuberas para la comunicacin entre procesos........................63
Figura 3.7: Comparacin entre procesos monohilo y proceso multihilo............................................66
Figura 3.8: Modelo muchos a uno......................................................................................................69
Figura 3.9: Modelo uno a uno............................................................................................................71
Figura 3.10: Muchos a muchos..........................................................................................................72
Figura 3.11: Modelo de dos niveles....................................................................................................73
Figura 3.12: Histograma de los tiempos de las rfagas de CPU........................................................86
Figura 3.13: Planificacin con colas multinivel.................................................................................88
Figura 3.14: Etapas de procesamiento de un programa de usuario..................................................102
Figura 4.1: Soporte del hardware para la paginacin.......................................................................105
Figura 4.2: Descomposicin de las direcciones virtuales en paginacin.........................................107
Figura 4.3: Bit de vlido en la tabla de pginas................................................................................111
Figura 4.4: Proceso en memoria.......................................................................................................111
Figura 4.5: Copy-on-write antes de que el proceso 1 modifique la pgina A..................................118
Figura 4.6: Copy-on-write despus de que el proceso 1 modifique la pgina A..............................120
Figura 4.7: Hiperpaginacin en sistemas multiprogramados...........................................................128
Figura 4.8: Proceso en memoria.......................................................................................................136
Figura 5.1: Disco duro......................................................................................................................141
iii
ndices
Figura 5.2: Estructura lgica de un disco magntico.......................................................................142

Figura 5.3: Estructura de un sistema de archivos.............................................................................147
iv
1. Introduccin
1.1. Funciones del sistema operativo

Es habitual cuando hablamos de un elemento tan complejo como un sistema operativo que resulte
ms sencillo definirlo por lo que hace que por lo que es. Por ello, comenzaremos viendo el papel del
sistema operativo en el conjunto de un sistema informtico.
Un sistema informtico cualquiera puede ser dividido en cuatro componentes (vase la Figura 1.1):
el hardware, el sistema operativo, los programas de aplicacin y los usuarios.
El hardware la CPU, la memoria, los dispositivos de entrada salida, etc. proporcionan los
recursos computaciones del sistema.
Los programas de aplicacin procesadores de textos, hojas de clculo, compiladores,

navegadores de Internet. Definen las diferentes formas en las que los recursos de sistema son
utilizados para resolver los problemas informticos de los usuarios.
El sistema operativo controla y coordina el uso de hardware por parte de las diversas
aplicaciones para los diferentes usuarios del sistema. Un sistema operativo no hace trabajo
til. Simplemente proporciona un entorno adecuado para que otros programas puedan
hacerlo.
Con el fin de entender cules son las funciones de un sistema operativo; se puede explorar su papel
desde dos puntos de vista: el del sistema informtico y el del usuario.
Sistemas Operativos - 2014/2015 1. Introduccin
usuario usuario usuario usuario

...
1 2 3 n
editor juego compilador ... base

de datos
programas del sistema y aplicaciones
sistema operativo
hardware
Figura 1.1: Vista abstracta de los componentes de un sistema informtico.
1.1.1. Punto de vista del sistema informtico

Desde el punto de vista del sistema informtico, el sistema operativo es el programa ms
ntimamente relacionado con el hardware. En este contexto, el sistema operativo acta como:
1. Gestor de los recursos de sistema informtico.
2. Programa encargado del control de la ejecucin de los programas de usuario y del acceso a
los dispositivos de E/S.
Un sistema informtico tiene mltiples recursos tanto hardware como software tiempo de CPU,
espacio de memoria, espacio de almacenamiento de archivos, dispositivos de E/S, servicios de red,
etc.. El sistema operativo, como gestor de estos recursos, los asigna a los diferentes programas,
resolviendo los conflictos en las peticiones y haciendo que el sistema opere eficientemente y
resuelva los problemas de los usuarios.
Adems, como un programa encargado del control de la ejecucin de los programas de los usuarios,
el sistema operativo tiene la tarea de prevenir errores y el uso inadecuado del ordenador.
1.1.2. Punto de vista del usuario

Sin embargo, la funcin del sistema operativo desde el punto de vista del usuario vara de acuerdo
con la interfaz utilizada. Por ejemplo, los usuarios que se sientan frente a un sistema de escritorio
1-2
1.1. Funciones del sistema operativo Sistemas Operativos - 2014/2015
(vase el apartado 1.3.2) disponen de monitor, teclado, ratn y una unidad central. Estos sistemas se
disean buscando la mxima productividad en equipos donde un usuario monopoliza todos los
recursos; por lo que el sistema operativo se disea considerando fundamentalmente la facilidad de
uso, poniendo algo de atencin en el rendimiento y nada en el aprovechamiento de los recursos.
En otros casos un usuario se sienta frente a un terminal1 conectado a un mainframe (vase el

apartado 1.3.1), mientras muchos otros acceden al mismo sistema a travs de otros terminales. Por
tanto, todos los usuarios comparten los recursos del sistema informtico y pueden intercambiar
informacin. En esos casos el sistema operativo debe maximizar el aprovechamiento de los recursos
con el objetivo de garantizar que toda la CPU, memoria y E/S sean empleadas de forma eficiente, y
que ningn usuario utiliza ms que lo que le corresponde.
Otro ejemplo son los sistemas de mano (vase el apartado 1.3.5), por ejemplo tablets y telfonos
mviles. A causa de las limitaciones de la interfaz, en el diseo del sistema operativo debe primar la
usabilidad2, aunque el rendimiento por tiempo de vida de la batera tambin es importante.
1.2. Definicin de sistema operativo

No existe una definicin universal de lo que es un sistema operativo. Hay quin considera que es lo
que el fabricante nos vende cuando decimos que queremos comprar un sistema operativo. Esta
definicin no parece muy precisa puesto que las caractersticas incluidas pueden variar
enormemente de un sistema a otro. Por ejemplo, algunos sistemas apenas alcanzan el megabyte de
espacio, careciendo incluso de las aplicaciones ms bsicas, como puede ser un editor, mientras que
otros ocupan gigabytes de espacio y estn completamente basados en sistemas grficos de ventanas.
Una definicin mucho ms comn es que el sistema operativo es aquel programa que se ejecuta
continuamente en el ordenador lo que denominamos comnmente kernel o ncleo siendo todo lo
dems programas del sistema y aplicaciones. Sin embargo, es indudable que en algunos casos sta
definicin no incluye como parte del sistema operativo algunas caractersticas que intuitivamente
solemos considerar dentro del mismo. Por ejemplo, si aplicamos esta definicin a los sistemas
operativos de estructura microkernel (vase el apartado 2.3.3), no podramos decir que servicios
como la comunicacin en red, la gestin del sistema de archivos y la gestin de la memoria (vanse
1 Los terminales son sistemas informticos utilizados para la conexin de los usuarios a un mainframe. Slo suelen
disponer de los recursos necesarios para realizar esa tarea.
2 La usabilidad es la medida de la facilidad de uso de un producto o servicio, tpicamente una aplicacin software o un
aparato. Ms informacin en http://es.wikipedia.org/wiki/Usabilidad.
1-3
el apartado 2.1.2) son proporcionados por el sistema operativo. Aunque pueda parecer lo contrario,
la cuestin de que incluye y que no incluye un sistema operativo no carece de importancia, como se
demostr durante el caso del Departamento de Justicia de los Estados Unidos contra Microsoft por
la excesiva inclusin de funcionalidades en sus sistemas operativos3.
Parece evidente que un sistema operativo se define mejor por lo que hace es decir, sus
funciones que por lo que es. Sin embargo, sta primera manera de definirlo tambin tiene sus
dificultades. Por ejemplo, el principal objetivo de los sistemas operativos de escritorio es la
facilidad de uso, mientras que en los mainframe el objetivo fundamental es la eficiencia en el
aprovechamiento de los recursos. Puesto que ambos objetivos pueden ser en ocasiones
contradictorios, resulta obvio que lo que tiene que hacer un sistema operativo para alcanzar esos
objetivos puede ser diferente en cada caso, lo que dificulta el obtener una definicin nica.
De lo que no hay duda es de que los sistemas operativos existen porque es ms fcil hacer un
sistema informtico usable con ellos que sin ellos. El objetivo fundamental de las computadoras es
ejecutar programas para resolver fcilmente los problemas de los usuario, por lo que con ese
objetivo se construye el hardware de los ordenadores. Puesto que el hardware por si slo resulta
difcil de utilizar, es necesario desarrollar programas de aplicacin para que sean utilizados por los
usuarios. Sin embargo, estas aplicaciones necesitan realizar operaciones comunes, como controlar
los dispositivos de E/S o reservar porciones de la memoria. Esas funciones comunes de control y
asignacin de recursos, que se corresponden con las funciones del sistema operativo desde el punto
de vista del sistema informtico vistas en el tema 1.1.1, son la labor del sistema operativo.
1.3. Tipos de sistemas operativos
1.3.1. Mainframe
Los ordenadores centrales o mainframes fueron los primeros computadores utilizados en muchas
aplicaciones comerciales y cientficas. Se caracterizan no tanto por la potencia de su CPU 4 como
por: su gran capacidad de memoria, su gran capacidad de almacenamiento secundario, la gran
3 Ms informacin sobre el caso en http://goo.gl/u1tf.

4 Generalmente se considera que las mayor diferencia entre los superordenadores y los mainframes est en que los
primeros se centran en resolver problemas limitados por la velocidad de clculo lo cual requiere miles de CPU de
alto rendimiento mientras que lo segundos se centran en problemas limitados por la E/S y la fiabilidad slo
necesitan entre una y varias docenas de CPU. Ms informacin en http://es.wikipedia.org/wiki/Ordenador_central.
1-4
1.3. Tipos de sistemas operativos Sistemas Operativos - 2014/2015
sistema operativo
rea de los
programas de usuario
Figura 1.2: Disposicin de la memoria en un sistema de procesamiento por lotes.
cantidad de dispositivos de E/S y la rapidez de estos, as como por su alta fiabilidad. Estas mquinas
pueden funcionar durante aos sin problemas ni interrupciones y las reparaciones se realizan sin
detener su funcionamiento.
a) Sistemas de procesamiento por lotes

Los sistemas de procesamiento por lotes o sistemas en batch fueron los primeros ordenadores
(vase el apartado 1.4.2). Eran enormes mquinas operadas desde una consola y conectados a
lectores de tarjetas perforadas5, dispositivos de cinta e impresoras. El trabajo, normalmente en
tarjetas perforadas, era preparado por el programador y entregado al operador. Para acelerar la
ejecucin el operador deba agrupar los programas con requerimientos similares en lotes y
mandarlos a ejecutar segn iba quedando disponible el ordenador. Finalmente, el resultado de cada
programa deba ser devuelto al programador correspondiente.
El sistema operativo permaneca siempre residente en memoria (vase la Figura 1.2).
La nica tarea del sistema operativo era transferir automticamente el control de un trabajo
al siguiente.
El mayor inconveniente de ste tipo de sistemas era que la CPU permaneca mucho tiempo
desocupada porque era y es varios ordenes de magnitud ms rpida que la E/S. Los programas
necesitan realizar operaciones de E/S para obtener los datos requeridos para sus clculos por
ejemplo guardados en tarjetas perforadas por lo que se pierde mucho tiempo esperando a que
estn disponibles dichos datos.
5 Mas informacin sobre la forma de trabajo con tarjetas perforadas en http://goo.gl/S9FTOk.
1-5
b) Sistemas multiprogramados
Con la aparicin de la tecnologa de los discos magnticos se pudo mantener todos los trabajos en el
disco y no en tarjetas perforadas sobre la mesa del operador. Esto permiti que el sistema operativo
pudiera encargarse de escoger el orden de ejecucin de los trabajos.
3. En disco se almacena una cola con todos los trabajos que deben ser ejecutados.
4. El sistema operativo mantiene varios trabajos en memoria del conjunto de trabajos en la cola
en disco (vase la Figura 1.3).
5. El sistema operativo ejecuta en la CPU unos de los trabajos en memoria.
6. Si el trabajo en la CPU requiere E/S, en lugar de mantener a la CPU ocupada intilmente, el

sistema operativo escoge otro trabajo de entre los que estn en memoria y lo ejecuta en la
CPU. El nuevo programa en la CPU no es interrumpido cuando el anterior termina de
utilizar la E/S, sino que ste ltimo debe esperar en la memoria una nueva oportunidad para
ser escogido.
7. Cuando un programa en la CPU termina, un hueco queda libre en la memoria. Por lo tanto es
necesario que el sistema operativo escoja un trabajo de la cola en disco y lo cargue en la
memoria.
8. El proceso se repite mientras hayan trabajos que ejecutar.
Para seguir un esquema como el anterior es necesario que el sistema operativo realice tres tareas
esenciales:
La planificacin de trabajos. Su responsabilidad es elegir cual es el siguiente trabajo que

debe ser cargado para mantener llena la memoria.
La planificacin de la CPU. Se encarga de elegir el siguiente trabajo que debe ser ejecutado
en la CPU de entre los disponibles en la memoria (vase el apartado 3.4).
La gestin de la memoria. Es necesaria puesto que la memoria tiene que ser repartida entre
los trabajos que deben ser alojados en la misma (vase el apartado 2.1.2).
Un ejemplo de este tipo de sistemas operativos es el IBM OS/360 que fue liberado en 1966 para
utilizarlo en los mainframes IBM System/360 (vase el apartado 1.4.3).
1-6
c) Sistemas de tiempo compartido

La mayor parte de los sistemas actuales son sistemas de tiempo compartido. Los sistemas
anteriores ofrecan un uso eficiente de la CPU pero no eran capaces de proporcionar interaccin con
el usuario. El usuario se limitaba a entregar los trabajos al operador y a esperar a que ste le
devolviera los resultados.
Los sistemas de tiempo compartido se caracterizan por tener:
Un sistema de interaccin directa entre el usuario y el sistema. Por ejemplo, un terminal.
Un sistema multiprogramado dnde la conmutacin es tan frecuente que el usuario puede

interactuar con cada programa mientras se ejecuta.
Utilizando esta estrategia un sistema de tiempo compartido puede disponer de varios terminales de
forma que mltiples usuarios puedan utilizar la mquina simultneamente 6. Los usuarios comparten
la CPU y los otros recursos del sistema, sin embargo, la sensacin para cada uno es la de que el
sistema completo est dedicado a l en exclusiva. Realmente el sistema conmuta de un usuario a
otro o para ser exactos de un programa a otro, pudiendo ser de usuarios distintos pero debido a la
lentitud de la E/S interactiva7 los usuarios no perciben demora alguna.
Los sistemas de tiempo compartido significaron un salto importante en complejidad por diversas
razones:
Varios trabajos deben estar en memoria al mismo tiempo el sistema operativo requiere
mecanismos de gestin de la memoria y proteccin (vase el apartado 2.1.2).
Para tener un tiempo de respuesta razonable los trabajos en memoria deben poder ser
guardados o recuperados desde el disco que sirve como almacenamiento de respaldo el
sistema operativo puede utilizar tcnicas de memoria virtual (vase el apartado 4.5.1) para
poder ejecutar trabajos que no estn completamente cargados en memoria.
La CPU debe ser compartida entre los trabajos el sistema operativo requiere mecanismos
de planificacin de la CPU (vase el apartado 3.4).
La ejecucin de los trabajos debe ser ordenada el sistema operativo debe proporcionar
6 A los sistemas que tienen esta funcionalidad se los denomina sistemas multiusuario.
7 La E/S interactiva incluye la salida de datos por pantalla y la entrada de datos utilizando dispositivos como el
teclado, el ratn, etc. La velocidad de este tipo de E/S viene limitada por las capacidades humanas, por lo que hay
que tener en cuenta que lo que para los humanos es rpido para una CPU resulta sumamente lento.
1-7
mecanismos de sincronizacin (vase el apartado 3.3.3) y comunicacin (vase el apartado

3.2).
El sistema debe disponer de un sistema de archivos (vase el tema 5), que a su vez debe
residir en un conjunto de discos el sistema operativo requiere mecanismos de gestin de
discos.
Las primeras versiones de UNIX liberado por primera vez en 1970 el sistema operativo VMS
desarrollado en 1978 para los VAX de Digital Equipment Corportation y el IBM OS/400
introducido en 1988 utilizado en los minicomputadores AS/400, son algunos ejemplos de
sistemas operativos de tiempo compartido (vase el apartado 1.4.4).
1.3.2. Sistemas de escritorio

Los sistemas de escritorio aparecieron en los primeros aos de la dcada de 1970 y carecan de las
caractersticas necesarias para ser multiusuario y multitarea. A diferencia de los sistemas de
entonces, los sistemas operativos de escritorio actuales si tienen esas caractersticas pero se siguen
diseando con un objetivo diferente al de los mainframe. Como ya hemos comentado, mientras que
en los sistemas de tiempo compartido y los multiprogramados se persigue maximizar la utilizacin
eficiente de los recursos, en los sistemas de escritorio se debe maximizar la respuesta al usuario 8 y
la facilidad de uso.
Pese a estas diferencias los sistemas operativos de escritorio se han beneficiado del desarrollo de
los sistemas operativos para mainframes. Por ejemplo, en un sistema diseado para ser utilizado
por un nico usuario no tiene sentido implementar un sistema de archivos con permisos. Por eso los
primeros sistemas operativos de escritorio carecan de esta caracterstica, que ya exista en los
mainframe de la poca. Sin embargo, hoy en da los sistemas de escritorio son multiusuario e
incluyen sistemas de archivos con permisos como medida de proteccin de los datos de los
usuarios.
Los ejemplos de este tipo de sistemas operativos van desde CP/M lanzado en 1977 hasta los
actuales GNU/Linux, Microsoft Windows 7 y Apple Mac OS X, pasando por MS-DOS, IBM OS/2
y las diversas versiones de Microsoft Windows (vase el apartado 1.4.5).
8 El tiempo de respuesta al usuario se puede considerar como el intervalo de tiempo entre un comando de un usuario
por ejemplo un click y la respuesta del sistema a dicho comando. En ocasiones este tiempo se minimiza a costa de
un uso menos eficiente de los recursos del sistema por lo que no es un objetivo deseable para disear un mainframe.
Mas informacin en el tema 3.4.3.
1-8
1.3.3. Sistemas distribuidos

En la actualidad es comn el uso de redes por ejemplo Internet o la red de rea local de una
oficina para interconectar ordenadores individuales; cada uno equipado con su procesador, su
memoria, sus dispositivos de almacenamiento, su fuente de alimentacin, etc. En las redes de
ordenadores los procesadores de dichos ordenadores se comunican con otros procesadores a travs
de lneas de comunicacin, como redes Ethernet o lneas telefnicas. Estos sistemas son
comnmente denominados sistemas distribuidos.
a) Tipos de sistemas informticos distribuidos

Sin entrar en detalles los sistemas distribuidos pueden ser clasificados en dos grandes tipos:
En los sistemas cliente-servidor existen ordenadores que actan como servidores encargados
de satisfacer las peticiones generadas por otros ordenadores que actan como clientes. Este
tipo de sistemas ha ido sustituyendo a los terminales conectados a mainframes debido a que
los sistemas de escritorio son cada vez ms potentes y ms baratos. Concretamente, los
terminales han sido sustituidos por los sistemas de escritorio que, al disponer de ms recursos,
son capaces de realizar muchas de las funcionalidades que anteriormente eran manejadas
directamente por los mainframes. Al mismo tiempo estos mainframes se han reemplazado por
servidores, no muy diferentes a los sistemas de escritorios, pero preparados para atender las
peticiones de sus clientes. Ejemplos de este este tipo de sistemas son los servidores de base de
datos, que responden a las consultas SQL de los clientes, o los servidores de archivos, que
proporcionan una interfaz de sistema de archivos con la que los clientes pueden crear, leer,
escribir y borrar archivos en el servidor.
En los sistemas de redes entre iguales o P2P (peer-to-peer) clientes y servidores no se

distinguen los unos de los otros. Todos los nodos del sistema son iguales y cada uno puede
actuar como cliente y/o servidor dependiendo de cuando piden o proporcionan un servicio. La
ventaja fundamental de este tipo de sistemas es que en los sistemas cliente-servidor el servidor
es el cuello de botella9, pero en los sistemas de redes entre iguales la carga se distribuye entre
los diversos nodos de la red. Ejemplos de este tipo de sistemas son las redes eDonkey y
BitTorrent.
9 Un servidor puede ser el cuello de botella no solo por su potencia sino tambin por el ancho de banda de su
conexin a la red. La potencia del servidor es lo de menos cuando se intenta distribuir en Internet archivos de gran
tamao por ejemplo imgenes de CD o DVD pues el problema es que varias descarga simultaneas pueden
consumir todo el ancho de banda del servidor durante largos periodos de tiempo.
1-9
b) Sistemas operativos para sistemas distribuidos

Desde el punto de vista de los sistemas operativos para sistemas distribuidos es necesario hacer la
siguiente distincin:
Los sistemas operativos de red ofrecen a las aplicaciones que corren sobre ellos servicios de
acceso a redes de ordenadores. Por ejemplo, implementan algn mecanismo que permita a
diferentes procesos en diferentes ordenadores intercambiar mensajes. Adems suelen
incorporar la opcin de proporcionar algunos servicios de red, como la comparticin de
archivos y dispositivos. Los ordenadores con sistemas operativos de red son autnomos,
aunque conocen la existencia de la red y estn en disposicin de comunicarse con otros
ordenadores de la misma. Este tipo de sistemas operativos son los ms utilizados en los tipos
de sistemas distribuidos comentados anteriormente.
Los sistemas operativos distribuidos crean en el usuario la ilusin de estar en un slo

ordenador, aunque en realidad el sistema operativo controla todos los ordenadores de la red
dando al usuario acceso transparente a los recursos en todos los equipos de la misma. Con este
tipo de sistemas operativos el usuario no sabe en que ordenador se ejecutan sus procesos, ni
donde se almacenan sus archivos, ni que equipo tiene conectado los distintos perifricos a los
que tiene acceso. Un ejemplo de sistema operativo distribuido es Amoeba10.
1.3.4. Sistemas de tiempo real

Se utilizan cuando tenemos requerimientos rgidos de tiempo en la ejecucin de las tareas o en el
procesamiento de flujos de datos. Por lo tanto, se usa frecuentemente en dispositivos de control
dedicados a una tarea especfica; dnde se deben tomar datos de uno o varios sensores, para
posteriormente analizar dichos datos y accionar algn mecanismo de control dentro de unos
mrgenes rgidos de tiempo. Los sistemas de tiempo real se suelen utilizar en: algunos sistemas de
control industrial, domtica, armamento, la inyeccin electrnica de combustible en los
automviles, el procesamiento de imgenes mdicas, etc..
Los sistema de tiempo real estn muy relacionados con los sistemas empotrados. Estos sistemas
estn tanto en el motor de los automviles y los robots que los fabrican, como en reproductores de
10 Amoeba es un sistema operativo de investigacin distribuido de estructura microkernel (vase el apartado 2.3.3)
escrito por Andrew S. Tanenbaum en Vrije Universiteit. Ms informacin en http://www.cs.vu.nl/pub/amoeba/.
1-10
DVD, microondas, etc. Los sistemas empotrado realizan tareas muy especficas, sus sistemas
operativos tienen caractersticas muy limitadas y no suelen tener interfaz de usuario.
Los sistemas de tiempo real pueden ser clasificados en sistemas de tiempo real estricto y sistemas
de tiempo real flexible:
Los sistemas de tiempo real estricto o hard real-time garantizan que las tareas sern
realizadas dentro de unos mrgenes estrictos de tiempo. Para ello todos los imprevistos que
puedan ocasionar retardos en el funcionamiento del sistema operativo deben estar
perfectamente limitados en tiempo. Por lo tanto, la memoria virtual y otras facilidades que
abstraen del funcionamiento real del hardware no estn presentes en este tipo de sistemas
porque introducen impredecibilidad. Los sistemas de tiempo real estricto no son compatibles
con los sistemas de tiempo compartido.
Los sistemas de tiempo real flexible o soft real-time son tiles cuando hay tareas que tienen
mayor importancia que el resto por lo que deben ser realizadas con mayor prioridad y esta
prioridad debe ser conservada hasta que terminan. El tiempo real flexible no sirve cuando se
tienen tareas con limitaciones precisas de tiempo porque no hay manera de garantizar que
dichas restricciones se van a cumplir. Sin embargo si es til para tareas relacionadas con la
multimedia, la realidad virtual, etc. Este tipo de tiempo real est disponible en la mayor parte
de los sistemas operativos de propsito general pues es compatible con la memoria virtual y
otras facilidades propias de los sistemas de tiempo compartido.
1.3.5. Sistemas de mano

Los sistemas de mano incluyen a los tablets, lectores de libros electrnicos y telfonos mviles. Los
desarrolladores de sistemas de mano y aplicaciones para estos sistemas deben enfrentarse a diversos
desafos. Muchos de ellos vienen originados por el tamao limitado de los dispositivos y la
alimentacin mediante el uso de bateras. Debido a esas limitaciones muchos sistemas de mano
tienen poca cantidad de memoria, procesadores lentos y pantallas pequeas.
1.4. Historia de los sistemas operativos

La historia de los sistemas operativos se puede dividir en 5 grandes etapas o generaciones.
1-11
1.4.1. 1 Generacin (1945-55)
a) Caractersticas
Sin sistema operativo.
Slo hardware, sin lenguajes de programacin.
b) Ejemplos
Mainframe IBM 701 y 704.
1.4.2. 2 Generacin (1955-64)
a) Caractersticas
Sistemas operativos de procesamiento por lotes.
Sistema operativo bsico. Se utilizan lenguajes de programacin.
b) Ejemplos
El primer sistema operativo fue desarrollado por General Motors Research Laboratory en 1956
para su mainframe IBM 701 (vase la Figura 1.4) con el fin de automatizar la carga de los
trabajos.
1.4.3. 3 Generacin (1965-1968)
a) Caractersticas
Sistemas operativos multiprogramados.
Ms lenguajes de programacin y multiprogramacin.
b) Ejemplos
IBM OS/360. Desarrollado por IBM para su mainframe System/360.
1-12
1.4. Historia de los sistemas operativos Sistemas Operativos - 2014/2015
Figura 1.4: Instalacin de un mainframe IBM 702.
Fue el primero en hacer los dispositivos de almacenamiento de acceso aleatorio un

requisito para poder operar.
Anunciado en 1964, fue liberado en 1966 con un ao de retraso. Los motivos

fundamentales fueron ciertos problemas de organizacin interna de la compaa y la
falta de experiencia en proyectos de tal envergadura, pues las previsiones iniciales eran
de 1 milln de lneas de cdigo y miles de componentes de software. La experiencia
negativa del desarrollo del IBM OS/360 condujo al nacimiento de la ingeniera del
software.
1.4.4. 4 Generacin
Esta generacin abarca desde mediados de los aos 60 hasta finales de la dcada de los 70.
a) Caractersticas
Sistemas operativos de tiempo compartido.
Aparecen los programas interactivos y las mquinas virtuales.
1-13
Figura 1.5: Mainframe GE-6180 con sistema operativo MULTICS (MIT ca. 1976)
b) Ejemplos
MULTICS. Fue anunciado en 1964 como el primer sistema operativo de propsito general
fruto de la colaboracin entre el MIT, General Electrics y Bell Labs (vase la Figura 1.5).
Primer sistema operativo en proporcionar un sistema de archivos jerrquico, un

intrprete de comandos implementado como programa de usuario, listas de control de
acceso individuales para cada archivo, enlazado dinmico, etc.
1-14
Elimin la separacin entre el espacio de direcciones de los procesos y los archivos. En

un sistema moderno eso sera como si cada archivo estuviera mapeado en memoria
(vase el apartado 4.5.6).
VM/CMS. Es un sistema de IBM utilizado en los mainframe System/360, System/370,

System/390 y zSeries.
El desarrollo comenz en 1965 y la primera versin estuvo disponible a primeros de

1966.
VM es una mquina virtual que proporciona a cada usuario la sensacin de tener su

propio mainframe personal.
CMS es un sistema monousuario diseado para operar fundamentalmente encima de

VM.
Figura 1.6: Miniordenador DEC PDP-7.
1-15
UNIX. Desarrollado originalmente por Bell Labs en 1970 para los sistemas PDP-11/20.
La autora del mismo se le atribuye a un grupo de programadores, liderados por Ken

Thompson, que decidieron rehacer el trabajo de MULTICS pero a menor escala despus
de que Bell Labs abandonara el proyecto en 1969. Inicialmente se llam UNICS y fue
desarrollado para los sistemas PDP-7 (vase la Figura 1.6).
La primer versin, como muchos otros sistemas operativos anteriores, estaba

implementada en ensamblador. Dennis Ritchie y Brian Kernighan disearon un nuevo
lenguaje llamado C especialmente pensado para que UNIX fuera escrito con l. Eso
permiti que UNIX pudiera ser modificado fcilmente para funcionar en otros
ordenadores. Adems el cdigo era ms conciso y compacto, lo que se tradujo en el
aumento de la velocidad de desarrollo de UNIX.
AT&T, la compaa matriz de Bell Labs, no poda competir en la industria de los

ordenadores por lo que puso el cdigo fuente de UNIX a disposicin de universidades,
compaas privadas y del gobierno de los Estados Unidos.
Una de las ms importantes versiones de UNIX fue desarrollada por la Universidad de

California en Berkeley. Esta versin implementaba el estndar de comunicaciones
TCP/IP, el cual permiti convertir la cerrada ARPANET en la abierta Internet.
En la actualidad se puede considerar que hay dos grandes familias de UNIX. Por un lado
AT&T UNIX System V, del que derivan sistemas tales como SCO OpenServer,
Oracle/Sun Microsystems Solaris Operating Environment y SCO UnixWare. Y por el
otro, BSD11 del que derivan FreeBSD, NetBSD, OpenBSD, Darwin y DragonFly BSD,
entre muchos otros.
VMS. Es un sistema operativo diseado originalmente por Digital Equipment Corporation

ahora propiedad de HP en 1978 para operar en sistemas VAX. Posteriormente fue portado a
sistemas DEC Alpha e Intel Itanium.
IBM OS/400. Es un sistema utilizado en la familia IBM AS/400 ahora llamada iSeries.
OS/400 y AS/400 fueron introducidos en el mercado en 1988.
La familia IBM AS/400 es una familia de minicomputadores. Este termino en desuso
11 La siglas BSD provienen de Berkeley Software Distribution.
1-16
hace referencia a mquinas multiusuario de rango medio, entre los mainframes y los
sistemas de escritorio.
1.4.5. 5 Generacin (aos 1980, 1990 y 2000):

Esta generacin abarca desde la dcada de los 80 hasta la actualidad.
a) Caractersticas
Sistemas operativos de escritorio y ordenadores personales (PC)12.
Monousuario, multitarea, sistemas distribuidos, sistemas paralelos, sistemas de tiempo real,

etc.
b) Ejemplos
CP/M. Sistema operativo estndar para la primera generacin de microcomputadores13.
Creado por Digital Research, Inc., fundada por Gary Kildall, para ser el sistema
operativo de los microordenadores basados en Intel 8080/85 y Zilog Z80.
La combinacin del CP/M junto al bus S-100 en el MITS Altair 8800 14 fue el primer
estndar industrial.
MS-DOS. Sistema operativo estndar para la segunda generacin de microcomputadores.
Fue el primer sistema operativo del IBM PC lanzado en 1981 y durante mucho tiempo
fue ampliamente utilizado en la plataforma PC compatible. No era ni multitarea ni
multiusuario.
MS-DOS fue creado por Seattle Computer Products con el nombre de 86-DOS, pero era
comnmente conocido como QDOS (Quick and Dirty Operating System). Microsoft
adquiri el sistema y lo vendi a IBM con el nombre de MS-DOS.
Tanto IBM como Microsoft lanzaron versiones de DOS, aunque originalmente IBM
12 Se puede observar una muestra de la interfaz grfica de usuario de algunos estos sistemas en http://goo.gl/0fFLN
13 Una microcomputadora es un ordenador que tiene un microprocesador. La primera generacin de
microcomputadoras tambin fue conocida como computadoras domsticas.
14 El MITS Altair 8800 fue un microcomputador diseado en 1975 basado en el procesador Intel 8080A. Hoy en da es
considerado el primer ordenador personal de la historia. Su bus de sistema, el S-100, se convirti en un estndar de
facto y su primer lenguaje de programacin fue el producto que ayud a fundar Microsoft, el Altair BASIC.
1-17
solamente validaba y empaquetaba el software de Microsoft. Microsoft liberaba sus

versiones bajo el nombre de MS-DOS, mientras IBM las liberaba bajo el nombre de
PC-DOS.
OS/2. Sistema operativo creado por Microsoft e IBM y posteriormente desarrollado por IBM
en exclusiva. Se cre como el sistema operativo predilecto para la segunda generacin de
ordenadores personales de IBM, equipados con procesador Intel 80286.
OS/2 fue pensado como un sucesor con operacin en modo dual (vase el apartado
2.2.1) de MS-DOS y Microsoft Windows 2.0.
OS/2 1.0 fue anunciado en abril y liberado en diciembre de 1987 como un sistema
operativo en modo texto. La interfaz grfica de usuario prometida denominada
Presentation Manager se introdujo en la versin 1.1 en noviembre de 1988.
La colaboracin entre IBM y Microsoft termin en 1990 entre la liberacin de Windows

3.0 y la de OS/2 1.3. El aumento de popularidad de Windows llevo a Microsoft a dejar
de centrarse en el desarrollo de OS/2, lo que llev a IBM a preocuparse por los
continuos retrasos en el desarrollo de OS/2 2.0. Inicialmente ambas compaas
acordaron que IBM tomara el mantenimiento de OS/2 1.0 y el desarrollo de OS/2 2.0,
mientras Microsoft continuara desarrollando OS/2 3.0, que entonces era conocido como
NT OS/2. Sin embargo, finalmente Microsoft decidi renombrar NT OS/2 como
Windows NT, dejando el futuro desarrollo de OS/2 en manos de IBM.
OS/2 Warp 3, liberado en 1994, fue un sistema completo de 32-bit.
OS/2 Warp 4, fue liberado en 1996. Poco despus de su lanzamiento IBM anunci que
OS/2 desaparecera.
Windows 3.x. La familia Windows 3.x de Microsoft Windows fue desarrollada desde 1990
hasta 1994. La 3.0 fue la primera versin de xito de Windows, permitiendo a Microsoft
competir con el Macintosh de Apple Computer y el Commodore Amiga.
En 1983 Microsoft anuncia el desarrollo de Windows, una interfaz grfica de usuario

para su propio sistema MS-DOS, que estaba disponible para los IBM PC y compatibles
desde 1981.
Windows 3.x requera una instalacin previa de MS-DOS y era iniciado como un
programa ms, que poda ser terminado en cualquier momento devolviendo al usuario a
1-18
la linea de comandos del MS-DOS. Este sistema operativo le proporcionaba a Windows

controladores de dispositivo para ciertas tareas, como el acceso al CD-ROM o a la
interfaz de red. Sin embargo, Windows necesitaba de aplicaciones especificas,
almacenadas en un formato ejecutable mucho ms complejo que el de los programas de
MS-DOS. Adems, debido a que MS-DOS no aislaba a las aplicaciones del hardware y
no se protega as mismo de los errores en dichas aplicaciones, Windows dispona de
mltiples controladores de dispositivo propios, as como su propio sistema de gestin de
la memoria. Es decir, que Windows realmente no se ejecutaba sobre MS-DOS sino que
haca uso de l. Por ello puede ser considerado un sistema operativo.
Windows 95, 98, Me. Sistemas operativos hbridos grficos de 16-bit/32-bit sucesores de
Windows 3.x.
Windows 95, liberado en 1995, fue el primer Windows unido a una versin de MS-DOS
especfica; aunque este hecho se intentaba mantener oculto. Entre las caractersticas de
Windows 95 se pueden destacar: mejoras significativas en la interfaz de usuario,
nombres de archivo de hasta 256 caracteres con conservacin de maysculas y
minsculas y multitarea expropiativa (vase el apartado 3.4.1) para las aplicaciones de
32-bit.
Windows 98 fue liberado el 25 de junio de 1998.
Windows Me, liberado el 14 de septiembre de 2000, fue la ltima versin de la familia

de sistemas operativos hbridos de 16-bit/32-bit que sucedi a Windows 3.1.
Windows NT. Sistema operativo de 32-bit antecesor del actual Windows 7.
Su desarrollo empez en 1988 con el nombre de OS/2 3.0. Cuando Windows 3.0 fue
liberado en mayo de 1990 tuvo tanto xito que Microsoft decidi cambiar la API 15 del
an en desarrollo NT OS/2 como era conocido en la poca pasando de ser una versin
extendida de la API de OS/2 a una versin extendida de la API de Windows. Esta
decisin caus tensin entre Microsoft e IBM y provoc que finalmente la colaboracin
terminara.
Microsoft contrat a un grupo de desarrolladores de Digital Equipment Corporation para
15 Una interfaz de programacin de aplicaciones o API (del ingls application programming interface) es el conjunto
de funciones, procedimientos o mtodos que ofrece el sistema operativo para ser utilizado por las aplicaciones.
1-19
crear Windows NT, por lo que muchos de sus elementos reflejan la experiencia anterior
de DEC en VMS.
Las API soportadas por Windows NT por ejemplo Win32, POSIX y OS/2 2.1 son
implementadas como subsistemas encima de un API nativo pblicamente no
documentado. Esta estructura en subsistemas fue lo que permiti la adopcin tarda de la
API de Windows, tal y como hemos comentado anteriormente.
Windows NT 3.1 la primera versin de Windows NT, liberada el 13 de julio de 1993

era un sistema operativo microkernel (vase el apartado 2.3.3) multiplataforma que
corra sobre procesadores Intel IA-32, DEC Alpha, MIPS R4000 y PowerPC.
Windows NT 4.0 fue la ltima versin en soportar plataformas distintas a Intel IA-32.
Aunque el desarrollo de Windows 2000 para Alpha continu hasta 1999, cuando
Compaq dej de soportar Windows NT en esa arquitectura. Adems Windows NT 4.0
integr en el ncleo ms funciones por ejemplo parte del subsistema grfico para
obtener mayor rendimiento.
Windows 2000, XP, Vista, 7. Sistemas operativos sucesores de Windows NT.
Windows 2000 o Windows NT 5.0, liberado el 17 de febrero de 2000 fue el primer

sistema operativo de la familia NT al que se le eliminaron las siglas del nombre por
motivos de marketing. El objetivo era favorecer la unificacin de las dos familias de
sistemas operativos Windows Windows 9x y Windows NT alrededor de la tecnologa
NT.
Windows XP o Windows NT 5.1 complet el proceso de unificacin de las dos

familias de sistemas operativos Windows, forzando la extincin de la familia Windows
9x al sustituirla con una versin de Windows XP, denominada Windows XP Home
Edition, especfica para la informtica domstica.
GNU/Linux. Se trata del ms famoso ejemplo de software libre y de desarrollo de fuente

abierta.
El proyecto GNU se inici en 1983 con el fin de desarrollar un sistema operativo estilo
UNIX, incluyendo herramientas de desarrollo de software y aplicaciones de usuario,
hecho enteramente de software libre.
El ncleo Linux fue inicialmente escrito como hobby por el estudiante universitario fins
1-20
Linus Torvalds mientras estudiaba en la Universidad de Helsinki. Torvalds originalmente

usaba Minix, un sistema operativo simplificado escrito por Andrew Tanenbaum para
ensear diseo de sistemas operativos. Sin embargo, el hecho de que Tanenbaum no
diera soporte a las mejoras de su sistema operativo introducidas por otros
desarrolladores, llev a Torvalds a escribir un sustituto de Minix.
En 1991, cuando se liber la primera versin del ncleo Linux, el proyecto GNU haba
desarrollado todos los componentes necesarios del sistema excepto el ncleo. Torvalds y
otros desarrolladores rpidamente adaptaron Linux para que funcionara con los
componentes de GNU, creando un sistema operativo completamente funcional.
El ncleo fue licenciado bajo la GNU General Public License (GPL) pero no es parte del
proyecto GNU. El proyecto GNU tiene su propio kernel denominado Hurd, pero sigue
en desarrollo.
Mach. Es un ncleo de sistema operativo desarrollado en la Universidad Carnegie-Mellon

(CMU). El proyecto en CMU se desarroll desde 1985 hasta 1994.
Mach explora el concepto que denominamos como microkernel (vase el apartado

2.3.3).
En algn momento se pens que Mach podra dominar el universo de los sistema
operativos debido a las ventajas de los sistemas microkernel. El mayor esfuerzo para
conseguirlo hasta la fecha es GNU/Hurd pero lleva ms de una dcada de retraso. Sin
embargo, otros sistemas operativos microkernel han tenido ms xito, como es el caso de
QNX.
Apple Computers seleccion OpenStep como base para el sucesor de su clsico Mac OS.
OpenStep es realmente una versin actualizada de NeXTSTEP, que era un sistema
basado en un ncleo Mach 2.5 con porciones del sistema BSD de la Universidad de
Berkeley. Por lo tanto, la mezcla de Mach con BSD16 de OpenStep es la base del sistema
operativo Mac OS X de Apple.
16 A la base del sistema operativo Mac OS X se la denomina Darwin. Concretamente se trata de un sistema FreeBSD
portado para correr sobre el ncleo Mach.
1-21
1956 1976 1991 2001
1952 Linux
Primer sistema operativo. CP/M GNU Hurd El ncleo libre Windows XP
Mainframe General Motors Research S.O. de la 1 generacin Ncleo del ms utilizado con Su versin Home
IBM 701 Laboratory. Para IBM 701. de micro ordenadores. proyecto GNU. el proyecto GNU. extingui la
familia de
Windows 9x.
1964 1966 1988
1945 1995
Multics IBM OS/360 OS/2
Primer sistema de Nace la ingeniera del Sistema de 16bits Windows 95
propsito general. software. pensado como Familia de sistemas
sucesor de MS-DOS operativos hbridos
1970 1978
de 16/32bits.
1955 1964 1985
Digital VMS 1994
UNIX
Para VAX. Mach
Ncleo microkernel OS/2 3.0
de la CMU. Sistemas operativo
de IBM de 32bits.
1965 1983
1993
UNIX System V Proyecto GNU
1 Generacin Proyecto de Windows NT 3.1
UNIX BSD software libre. Llamado NT OS/2
Sin sistema operativos
ni lenguajes de programacin 2 Generacin hasta que IBM
Sistemas operativos de 1981 abandon el
1968 proyecto al Microsoft
procesamiento por lotes
4 Generacin MS-DOS sustituir la API OS/2
Uso de lenguajes por la API Win32.
de programacin
S.O. del IBM PC.
Sistemas operativos de
tiempo compartido
Hay programas interactivos
y mquinas virtuales 1980
3 Generacin 5 Generacin
Sistemas operativos Sistemas de escritorio
multiprogramados
Monousuario y multiusuario, multitarea, sistemas distribuidos,
Ms lenguajes de programacin, sistemas en cluster, sistemas de tiempo real, etc.
multiprogramacin
2. Estructura de los sistemas operativos
2.1. Organizacin de los sistemas operativos

El estudio de la organizacin interna de los sistemas operativos requiere del anlisis de tres aspectos
diferentes:
1. Los componentes del sistema operativo y sus interconexiones (vase el apartado 2.1.2).
2. Los servicios que el sistema operativo proporciona a travs del funcionamiento coordinado de
dichos componentes (vase la Figura 2.1).
3. La interfaz de programacin que el sistema operativo ofrece a usuarios y programadores como

forma de acceso a dichos servicios.
El estudio de los componentes del sistema operativo lo dejaremos para ms adelante, tras ver la
forma usual en la que los programas acceden a los servicios del sistema operativo y, por tanto, en la
que se comunican indirectamente con dichos componentes. Respecto a los servicios que el sistema
operativo proporciona, no entraremos en ello puesto que cada uno ofrece servicios diferentes,
aunque siempre es posible identificar unos pocos tipos comunes a todos.
2.1.1. Interfaz de programacin de aplicaciones

Un sistema operativo proporciona un entorno controlado para la ejecucin de programas. Dicho
Sistemas Operativos - 2014/2015 2. Estructura de los sistemas operativos
aplicaciones
interfaz de programacin de aplicaciones
servicio de servicio de
servicio de servicio de
operaciones con manipulacin de
ejecucin de programas operaciones de E/S
la memoria archivos
gestor del
gestor del sistema
gestor de procesos gestor de memoria gestor de E/S almacenamiento
de archivos
secundario
hardware
Figura 2.1: Diagrama general de organizacin de los sistemas operativos.
entorno debe proporcionar ciertos servicios que pueden ser accedidos por los programas a travs de
una interfaz de programacin de aplicaciones o API (Application Programming Interface).
Algunas de las APIs disponibles para los desarrolladores de aplicaciones son la API Win32 en
sistemas Microsoft Windows y la API POSIX para sistemas compatibles POSIX 17 como es el
caso de los diferentes UNIX, Linux y Mac OS X.
Concretamente, junto a cada interprete o compilador de un lenguaje de programacin suele ir una

librera estndar que ofrece clases y/o funciones con las que los programas pueden acceder a los
servicios del sistema operativo y realizar las tareas ms comunes. Estas libreras generalmente no
forman parte del sistema operativo, sino de las herramientas de desarrollo de cada lenguaje de
programacin, y constituyen la interfaz de programacin de aplicaciones del lenguaje al que
acompaan.
Las libreras estndar necesitan acceder a los servicios del sistema operativo para, a su vez, dar
servicio a los programas que las usan. Es decir, cuando un programa invoca alguna funcin o
mtodo de la librera estndar que lo acompaa, es muy probable que sta necesite invocar uno o
ms servicios del sistema operativo para atender la peticin convenientemente. Para ello las
17 POSIX (Portable Operating System Interface for Unix) es el nombre de una familia de estndares que definen una
interfaz de programacin de aplicaciones para sistemas operativos. Esto permite que un mismo programa pueda ser
ejecutado en distintas plataformas, siempre que sean compatibles con POSIX. La prctica totalidad de los sistemas
UNIX modernos son compatibles POSIX ya que la especificacin deriva de la interfaz tpica de ese tipo de sistemas.
2-24
2.1. Organizacin de los sistemas operativos Sistemas Operativos - 2014/2015
libreras estndar utilizan la librera del sistema o libreras del sistema, en el caso de que hayan
varias que acompaa al sistema operativo. La librera del sistema si forma parte del sistema
operativo y contiene un conjunto de clases y/o funciones generalmente ms primitivas que las de
la librera estndar de los lenguajes de programacin que los programas deben utilizar para
acceder a los servicios del sistema operativo. Es decir, la librera del sistema constituye la interfaz
de programacin de aplicaciones del sistema operativo. Es muy comn que esta interfaz est
implementada para ser usarla con programas en lenguaje C, lo que permite que tanto los programas
en C como en C++ la puedan utilizar directamente. Sin embargo con otros lenguajes de
programacin esto no suele ser posible, por lo que no queda ms remedio que acceder a los
servicios del sistema operativo a travs de la librera estndar del lenguaje en cuestin.
Algunos de los servicios ofrecidos pueden ser implementados en la propia librera del sistema pero
en la mayor parte de los casos sta debe solicitar dichos servicios al resto del sistema operativo. La
librera del sistema, al igual que la estndar y otras libreras utilizadas por el programa, se cargan
dentro de la regin de memoria asignada al proceso donde se ejecuta el programa que las utiliza.
Por lo tanto, la invocacin de sus mtodos y funciones se realiza como si fueran cualquier otro
mtodo o funcin del programa. Sin embargo el cdigo del ncleo del sistema operativo suele estar
en una ubicacin diferente que, desde el punto de vista de los programas, no es conocida y
generalmente est protegida frente a accesos indebidos (vase el apartado 2.2.2). Eso significa que
#
# Fragmento de cdigo para escribir SIZE bytes desde la direccin BUFFER al
# archivo con el descriptor FILEDES.
#
# Prototipo en C de la llamada al sistema write()
#
# ssize_t write (int FILEDES, const void *BUFFER, size_t SIZE)
#
# ...
lw $a0,FILEDES # cargar FILEDES
la $a1,BUFFER # cargar BUFFER
lw $a2,SIZE # cargar SIZE
li $v0,4 # cargar id. de la llamada write()
syscall # llamar al sistema
# v0 contiene el valor de retorno
# que es el nmero de bytes escritos
# ...
Figura 2.2: Llamada al sistema en Linux MIPS.
2-25
para que la librera del sistema invoque los servicios que necesita hace falta un procedimiento
diferente, al que se le denomina llamada al sistema.
Las llamadas al sistema proporcionan una interfaz con la que los procesos pueden invocar los
servicios que el sistema operativo ofrece. Estas llamadas estn habitualmente disponibles como
instrucciones en lenguaje ensamblador (vase la Figura 2.2) pero generalmente los programas no las
utilizan directamente sino que emplean la interfaz ofrecida por la librera del sistema, que su vez se
implementa mediante invocaciones a las llamadas al sistema.
En la Figura 2.3 se ilustra el papel de todos los elementos comentados con el ejemplo de un
programa en C++ que invoca el mtodo std::ofstream::open():
1. El programa invoca el mtodo std::ofstream::open() de la librera estndar de C++ para

abrir un archivo determinado.
2. La librera estndar utiliza la librera de sistema, de la que invoca a varias funciones, para
realizar la tarea encomendada. Entre las funciones llamadas est fopen(), que se utiliza para
abrir el archivo indicado.
sistema operativo
llamada al sistema
fopen()
librera del sistema

int fd = syscall(__NR_open, filename, ...); (glibc)

std::ofstream::open()
librera estndar de
FILE *f = fopen(filename, ...); C++ (libstdc++)

ofstream ofs;
ofs.open(filename); programa en C++
proceso
Figura 2.3: Elementos de la interfaz de programacin de aplicaciones en GNU/Linux.
2-26
3. La librera del sistema utiliza los servicios del sistema operativo, expuestos mediante la
interfaz de llamadas al sistema, para realizar la tarea encomendada por la invocacin de
fopen(). Entre las llamadas al sistema utilizadas est open, que le dice al sistema operativo
que deseamos abrir el archivo indicado.
4. Al realizar la llamada el sistema operativo toma el control deteniendo la ejecucin del proceso
que la solicita. Entonces se realiza la tarea mediante el funcionamiento coordinado de los
diferentes componentes del sistema (vase el apartado 2.1.2).
a) Invocacin de las llamadas al sistema

Generalmente una llamada al sistema se invoca mediante una instruccin especfica en lenguaje
ensamblador que genera una excepcin18 por ejemplo la instruccin int 80 en la Figura 2.2 que
es capturada por el sistema operativo, deteniendo la ejecucin del proceso que la invoc. Cuando se
realiza la llamada es necesario que el proceso identifique la operacin que quiere que se realice.
Esto se suele hacer poniendo un nmero identificativo de la llamada en un registro concreto de la
CPU. Por ejemplo, el nmero de la llamada al sistema open del ejemplo de la Figura 2.3 es 219.
Sin embargo, una llamada al sistema suele requerir ms informacin que simplemente la identidad
de la llamada. Si por ejemplo se quisiera leer un bloque de datos desde un almacenamiento
secundario, al menos se debera indicar el archivo o dispositivo desde el que se desea realizar la
lectura, as como la direccin y tamao de la regin de la memoria donde se quiere que los datos
sean copiados. En concreto hay tres mtodos para pasar parmetros a una llamada al sistema:
En el paso de parmetros por registros se cargan los parmetros de la llamada al sistema en

los registros de la CPU antes de realizar la llamada. Este mtodo es el ms eficiente, pero
limita el nmero de parmetros al nmero de registros disponibles en la CPU. Es utilizado, por
ejemplo, en Linux para IA-3220 cuando la llamada al sistema tiene menos de seis parmetros
(vase la Figura 2.2).
En el paso de parmetros por tabla en memoria se copian los parmetros de la llamada al
18 Una excepcin es una interrupcin generada por software, que puede ser debida a un error por ejemplo una divisin
por cero o un acceso no vlido a memoria o a una llamada al sistema de un proceso para que se ejecute un servicio
del sistema operativo.
19 En GNU/Linux se puede conocer el nmero correspondiente a cada llamada al sistema soportada por el ncleo
consultado el listado del archivo /usr/include/asm/unistd.h.
20 IA-32 (Intel Architecture, 32-bit), conocida en la actualidad de manera genrica como x86 o i386, es la arquitectura
del conjunto de instrucciones de los procesadores Intel de 32 bits. Concretamente es una extensin de 32 bits,
implementada por primera vez en el Intel 80386, para la arquitectura x86 original de 16 bits.
2-27
sistema en una tabla en memoria, de manera que la direccin de dicha tabla debe ser cargada
en un registro de la CPU antes de la llamada al sistema. Evidentemente no limita el nmero de
parmetros que pueden ser pasados a una llamada al sistema. Por ejemplo, es utilizado en
Linux IA-32, cuando la llamada al sistema tiene ms de cinco parmetros, y en Microsoft
Windows.
En el paso de parmetros por pila se insertan los parmetros de la llamada al sistema en la

pila del proceso. En este caso el sistema operativo es el encargado de extraer los parmetros de
la pila durante la llamada al sistema. Al igual que en el caso anterior tampoco se limita el
nmero de parmetros que pueden ser pasados. Es utilizando, por ejemplo, en FreeBSD.
En cualquier caso, sea cual sea el mtodo utilizado, el sistema operativo debe comprobar de
manera estricta los parmetros pasados en la llamada al sistema antes de realizar cualquier
operacin, puesto que nunca debe confiar en que los procesos hagan su trabajo correctamente. A fin
de cuentas una de las funciones del sistema operativo es el control de dichos procesos.
2.1.2. Componentes del sistema

Como ya hemos comentado en diversas ocasiones en este tema, el sistema operativo ofrece una
serie de servicios a travs del funcionamiento coordinado de los diferentes componentes que lo
forman. A fin de cuentas, crear un software tan complejo como un sistema operativo no es sencillo,
por ello resulta ms prctico dividirlo en piezas ms pequeas especializadas en aspectos concretos
de la gestin del sistema.
a) Gestin de procesos
La gestin de los procesos es un elemento central de todo sistema operativo ya que el proceso es la
unidad de trabajo en cualquier sistema operativo moderno:
Un proceso puede ser considerado como un programa en ejecucin, es decir, cuando las
instrucciones del programa son ejecutadas por una CPU. Un proceso es un entidad activa que
necesita recursos CPU, memoria, archivos, E/S que se le asignan cuando es creado o cuando
lo solicita durante la ejecucin. Cuando el proceso termina el sistema operativo reclama de
estos recursos aquellos que sean reutilizables.
Un programa no es un proceso, es una entidad pasiva; como el contenido de un archivo en

disco con las instrucciones que algn da una CPU ejecutar. Un programa no puede hacer
2-28
ningn tipo de trabajo a menos que sus instrucciones sean ejecutadas por una CPU pero si eso
ocurre, ya no sera un programa sino un proceso.
La CPU ejecuta las instrucciones de cada proceso una detrs de otra, de manera que para
conocer la siguiente instruccin a ejecutar cada proceso tiene un contador de programa que se
lo indica a la CPU. Por tanto, aunque dos procesos estn asociados al mismo programa no
pueden ser considerados el mismo proceso, ya que la secuencia de ejecucin de instrucciones
puede ser distinta al tener cada uno un contador de programa independiente.
Por el momento estamos considerando que proceso y trabajo (vase el apartado 1.3.1) hacen
referencia al mismo concepto. Sin embargo ms adelante veremos que el segundo es mucho ms
general que el primero puesto que un proceso puede colaborar con otros procesos para desarrollar
un trabajo determinado (vase el apartado 3.1.7).
Responsabilidades de la gestin de procesos

El sistema operativo es responsable de la siguientes actividades relacionadas con la gestin de
procesos:
Crear y terminar procesos.
Suspender y reanudar los procesos.
Proporcionar mecanismos para la sincronizacin de procesos.
Proporcionar mecanismos para la comunicacin entre procesos.
Proporcionar mecanismos para el tratamiento de interbloqueos.
b) Gestin de la memoria principal

La memoria principal es un recurso fundamental para las operaciones de cualquier sistema
operativo moderno. Esto es as porque generalmente es el nico almacenamiento al que la CPU
tiene acceso directo, por lo que para que un programa pueda ser ejecutado debe ser copiado a la
memoria principal. Adems sirve de zona de intercambio de datos entre la CPU y los dispositivos
de E/S. Por ejemplo, para que la CPU pueda procesar los datos de un archivo en disco, stos
primero deben ser transferidos a la memoria principal.
Para mejorar el aprovechamiento de la CPU y la respuesta al usuario es necesario tener copiados

varios programas en la memoria al mismo tiempo. Puesto que dichos programas deben compartir la
2-29
memoria existe automticamente la necesidad de que el sistema operativo disponga de un

componente de gestin de la memoria principal.
Responsabilidad de la gestin de la memoria

El componente de gestin de la memoria debe asumir las siguientes responsabilidades:
Controlar qu partes de la memoria estn actualmente en uso y cules no.
Decidir que procesos aadir o extraer de la memoria cuando hay o falta espacio en la misma.
Asignar y liberar espacio de la memoria principal segn sea necesario.
c) Gestin del sistema de archivos

Los ordenadores pueden almacenar informacin en diferentes tipos de medios fsicos por ejemplo
en discos magnticos, en CD/DVD-ROM, en memorias de estado slido, etc. cada uno de los
cuales tiene caractersticas propias. El acceso a cada tipo medio es controlado por un dispositivo
por ejemplo el controlador de disco, la unidad de CD-ROM, etc. que tambin tiene caractersticas
propias. Para simplificar todo esto el sistema operativo proporciona una visin lgica uniforme de
todos los sistemas de almacenamiento. Es decir, abstrae las propiedades fsicas de los dispositivos
de almacenamiento para definir una unidad de almacenamiento lgico, el archivo. Un archivo o
fichero es una coleccin de informacin relacionada definida por su creador por ejemplo
programas, imgenes, datos. Los archivos normalmente se organizan en directorios para facilitar
su uso.
Responsabilidades de la gestin del sistema de archivos

El sistema operativo es responsable de la siguientes actividades relacionadas con la gestin del
sistema de archivos:
Crear y borrar archivos.
Crear y borrar directorios para organizar los archivos.
Soportar primitivas21 para la manipulacin de archivos y directorios.
Mapear en memoria archivos del almacenamiento secundario.
21 El trmino primitivas hace referencia a funciones que realizan operaciones muy bsicas. Estas operaciones bsicas
pueden ser combinadas para realizar operaciones ms complejas.
2-30
Copias de seguridad de los archivos en sistemas de almacenamiento estables y seguros.
d) Gestin del sistema de E/S

El sistema de E/S oculta las peculiaridades del hardware al resto del sistema. El sistema de E/S
consta de:
Un componente de gestin de memoria con soporte para servicios de buffering22, caching23 y

spooling24. Estos servicios son habitualmente utilizados por el resto del sistema de E/S.
Una interfaz genrica de acceso a los controladores de dispositivo. Esta interfaz genrica hace
que el acceso de los procesos a los dispositivos sea a travs de una interfaz similar, sin
importar las particularidades de cada dispositivo. Por ejemplo, una caracterstica de los
sistemas UNIX es que cada dispositivo de E/S se representa como un archivo en el sistema de
archivos. Esto permite que los procesos utilicen para acceder a los dispositivos de E/S las
mismas primitivas que emplean para manipular los archivos.
Controladores de dispositivo que son quines conocen las peculiaridades especficas del
dispositivo para el que ha sido creado.
e) Gestin del almacenamiento secundario

Los programas que se desean ejecutar deben estar en la memoria principal, o almacenamiento
primario, pero sta es demasiado pequea para alojar todos los datos y todos los programas del
sistema. Adems, incluso aunque pudiera ser as, los datos almacenados en la memoria principal se
perderan en caso de que fallara la alimentacin. Por eso los ordenadores deben disponer de un
almacenamiento secundario para respaldar a la memoria principal. Hoy en da lo ms comn es
utilizar discos duros para esa tarea.
22 El buffering o uso de memoria intermedia es una estrategia para leer datos desde un dispositivo de E/S. La CPU
instruye al dispositivo para que escriba bloques de datos en la memoria de forma que la operacin se realiza
mientras la CPU est ocupada procesando los bloques ledos anteriormente desde el dispositivo. Al escribir en un
dispositivo de E/S el proceso es anlogo.
23 En el caching el sistema mantiene en la memoria principal una copia de los datos almacenados en los dispositivos de
E/S del sistema como, por ejemplo, en los discos. Esto mejora la eficiencia del sistema puesto que el acceso a la
memoria principal es ms rpido que el acceso a los dispositivos de E/S. La memoria principal es de tamao
limitado, por lo que slo se mantiene copia de los datos utilizados con mayor frecuencia.
24 El spooling se utiliza en dispositivos que no admiten el acceso simultaneo de varias aplicaciones a vez, como es el
caso de impresoras y unidades de cinta. Cuando varias aplicaciones intentan enviar un trabajo a una impresora el
sistema operativo lo intercepta para copiar los datos enviados a un archivo distinto para cada aplicacin. Cuando una
aplicacin termina de enviar el trabajo el archivo correspondiente es encolado para su impresin. As los archivos
son impresos de uno en uno.
2-31
Responsabilidades de la gestin del almacenamiento secundario

El sistema operativo es responsable de la siguientes actividades relacionadas con la gestin del
almacenamiento secundario:
Gestin del espacio libre.
Asignacin del espacio de almacenamiento.
Planificacin del acceso al disco.
f) Gestin de red
El componente de red se responsabiliza de la comunicacin entre los procesadores en sistemas
interconectados mediante una red de ordenadores por ejemplo en Internet o la red de rea local de
una oficina.
g) Proteccin y seguridad
Proteccin es cualquier mecanismo para controlar el acceso de los procesos y usuarios a los
recursos definidos por el sistema. Estos son necesarios cuando un sistema informtico tiene
mltiples usuarios y permite la ejecucin concurrente de varios procesos, pues as slo pueden
utilizar los recursos aquellos procesos que hayan obtenido la autorizacin del sistema operativo.
Adems la proteccin tambin permite mejorar la fiabilidad al permitir detectar los elementos del
sistema que no operan correctamente. Un recurso desprotegido no puede defenderse contra el uso
o mal uso de un usuario no autorizado o incompetente.
Ejemplos tpicos de mecanismos de proteccin son el hardware de direccionamiento de memoria,

que se utiliza para que los procesos se ejecuten en su propio espacio de direcciones, y el
temporizador, que garantiza que ningn proceso toma el control de la CPU de manera indefinida.
Adems los registros de los dispositivos de E/S suelen estar protegidos del acceso directo de los
usuarios, lo que protege la integridad de los dispositivos, mientras que en algunos sistemas se
pueden establecer permisos sobre los archivos para garantizar que slo los procesos con la debida
autorizacin tienen acceso.
En todo caso, un sistema puede tener la proteccin adecuada pero estar expuesto a fallos y permitir
accesos inapropiados. Por eso es necesario disponer de mecanismos de seguridad que se encarguen
de defender el sistema frente a ataques internos y externos. Eso incluye a virus y gusanos, ataques
2-32
de denegacin de servicio25, robo de identidad y uso no autorizado del sistema, entre muchos otros
tipos de ataque.
2.1.3. Interfaz de usuario

Aunque cada sistema operativo ofrece servicios diferentes, vamos a detenernos en uno comn e
importante para todos los sistemas que han sido diseados para que los usuarios interacten con
ellos directamente, la interfaz de usuario.
Las interfaces de usuario pueden ser de diferentes tipos:
Interfaz de lnea de comandos o intrprete de comandos, que permite que los usuarios
introduzcan directamente los comandos que el sistema operativo debe ejecutar. En algunos
sistemas este tipo de interfaz se incluye dentro del ncleo, pero en la mayor parte como
MSDOS y UNIX se trata de un programa especial denominado shell que se ejecuta cuando
un usuario inicia una sesin.
Interfaz de proceso por lotes, en la que los comandos y directivas para controlar dichos
comandos se listan en archivos que posteriormente pueden ser ejecutados. Este tipo de interfaz
es la utilizada en sistemas no interactivos, como los de procesamiento por lotes y los
multiprogramados. Tambin suele estar disponible en los sistemas de tiempo compartido, junto
con algn otro tipo de interfaz de usuario, como es el caso de la shell de los sistemas UNIX.
Interfaz grfica de usuario o GUI (Graphical User Interface) que permite a los usuarios
utilizar un sistema de ventanas y mens controlable mediante el ratn.
Puesto que la interfaz de usuario puede variar de un sistema a otro, y de un usuario a otro dentro del
mismo sistema, no se suele incluir como un componente bsico del sistema operativo, pero si como
un servicio til para los usuarios.
A parte de la interfaz de usuario, cualquier sistema operativo moderno incluye una coleccin de
programas del sistema. El papel de estos programas del sistema es proporcionar un entorno
conveniente para la ejecucin y desarrollo de programas. Entre los programas del sistema se suelen
incluir aplicaciones para manipular archivos y directorios, programas para obtener informacin
sobre el estado del sistema como la fecha y hora o la memoria y el espacio en disco disponible,
25 En los ataques de denegacin de servicio se intentan utilizar todos los recursos de sistema para evitar que ste pueda
dar servici a los usuarios legtimos.
2-33
herramientas de desarrollo como intrpretes, compiladores, enlazadores y depuradores,

programas de comunicaciones como clientes de correo electrnico y navegadores web, etc.
Adems, muchos sistemas operativos disponen de programas que son tiles para resolver los
problemas ms comunes de los usuarios. Entre estos programas se suelen incluir: editores de
archivos de texto y procesadores de texto, hojas de clculo, sistemas de base de datos, juegos, etc.
Ha esta coleccin de aplicaciones se la suele conocer con el trmino de utilidades del sistema o
programas de aplicacin.
2.2. Operacin del sistema operativo

Los sistemas operativos modernos pertenecen a un tipo de software que se dice que est controlado
mediante interrupciones:
Si no hay ningn proceso que ejecutar ni ningn dispositivo de E/S pide la atencin del
sistema, el sistema operativo debe permanecer inactivo esperado a que algo ocurra.
Los sucesos que requieren la activacin del sistema casi siempre se indican mediante una
interrupcin:
Cuando un proceso comente un error como una divisin por cero o un acceso a
memoria no vlido o un programa solicita un servicio al sistema operativo a travs de
una llamada al sistema lo que se genera es una excepcin que no es ms que una
interrupcin generada por software que despierta al sistema operativo para que haga lo
que sea ms conveniente.
Cuando los dispositivos de E/S requieren la atencin del sistema operativo por ejemplo
porque se ha completado una transferencia de datos se genera una interrupcin que
despierta al sistema operativo.
Dado que el sistema operativo y los procesos de usuarios comparten los recursos del sistema
informtico, necesitamos estar seguros de que un error que se produzca en un programa slo afecte
al proceso que lo ejecuta. Por ejemplo, en los sistemas de tiempo compartido y en cualquier otro
tipo de sistema operativo donde los programas tengan que compartir la memoria, como es el caso de
los sistema microprogramados un programa errneo puede modificar el cdigo de otro programa,
los datos de otro programa o el propio sistema operativo. Por eso es necesario establecer
mecanismos de proteccin frente a los errores en los programas que se ejecutan en el sistema.
2-34
2.2. Operacin del sistema operativo Sistemas Operativos - 2014/2015
2.2.1. Operacin en modo dual

Para evitar este tipo de problemas es necesario poder distinguir entre la ejecucin de cdigo del
sistema operativo y del cdigo de los programas de usuario. El mtodo que utilizan la mayor parte
de los sistemas operativos consiste en utilizar algn tipo de soporte en el hardware que permita
diferencia entre varios modos de ejecucin y restringir la utilizacin de las instrucciones peligrosas
instrucciones privilegiadas para que slo puedan ser utilizadas en el modo en el que se ejecuta
el cdigo del sistema operativo.
Como mnimo son necesarios dos modos de operacin diferentes:
En el modo usuario se ejecuta el cdigo de las tareas de los usuarios. Si se hace un intento de
ejecutar una instruccin privilegiada en este modo, el hardware la trata como ilegal y genera
una excepcin que es interceptada por el sistema operativo, en lugar de ejecutar la instruccin.
En el modo privilegiado tambin denominado modo supervisor, modo del sistema o modo
kernel se ejecuta el cdigo de las tareas del sistema operativo. El hardware es el encargado
de garantizar que las instrucciones privilegiadas slo pueden ser ejecutadas en este modo.
El modo actual de operacin puede venir indicado por un bit de modo que se aade al hardware de
la computadora, de forma que si por ejemplo el bit est a 0, el cdigo en ejecucin opera en modo
privilegiado mientras que si el bit est a 1, el cdigo en ejecucin opera en modo usuario.
Comnmente en el grupo de las instrucciones privilegiadas se suelen incluir:
Las instruccin para conmutar al modo usuario.
Las instrucciones de E/S.
Las instrucciones necesarias para la gestin de las interrupciones.
A continuacin podemos ver el ciclo de vida de la ejecucin de instrucciones en un sistema con

modo dual de operacin:
1. Inicialmente, al arrancar la computadora, el hardware se inicia en el modo privilegiado es

decir, con el bit de modo a 0. En este modo se carga el sistema operativo e inicia su
ejecucin.
2. El sistema operativo debe cambiar al modo usuario poniendo el bit de modo a 1 antes de
ceder el control a un proceso de usuario. Esto ocurre cuando es necesario que un proceso de
usuario contine o inicie su ejecucin (vase el apartado 3.4.2).
2-35
3. El hardware conmuta a modo privilegiado cuando ocurre una interrupcin o una excepcin
poniendo el bit de modo a 0 antes de pasar el control al cdigo del sistema operativo que se
encargar de tratarlas.
Esto ltimo es importante pues, como ya hemos comentado, los sistemas operativos estn
controlados mediante interrupciones. Al activarse el modo privilegiado cada vez que ocurre una
interrupcin podemos estar seguros de que las tareas del sistema operativo se ejecutar en modo
privilegiado.
Cuando se dispone de la proteccin del modo dual el hardware se encarga de detectar los errores de
ejecucin y de notificarlo al sistema operativo mediante excepciones, siendo responsabilidad de este
ltimo realizar un tratamiento adecuado de los mismos. Por lo general, si un programa falla de
alguna forma, como por ejemplo intentando utilizar una instrucciones ilegal o de acceder a una zona
de memoria invlida, el sistema operativo lo hace terminar de manera anormal.
2.2.2. Proteccin de la memoria

La memoria principal debe acomodar tanto el sistema operativo como a los diferentes procesos de
los usuarios. Por eso la memoria normalmente se divide en dos partes:
1. La primera parte sirve para albergar el sistema operativo residente 26. El sistema operativo
puede estar localizado tanto en la parte baja como en la parte alta de la memoria. El factor
determinante en la eleccin es la localizacin del vector de interrupciones. Puesto que en la
mayor parte de las arquitecturas ste reside en la parte baja de la memoria, normalmente el
sistema operativo tambin se aloja en la parte baja.
2. La segunda parte alberga los procesos de usuario.
Sin embargo en los sistemas operativos modernos los procesos no tienen acceso libre a toda
memoria fsica con el objeto de proteger a los procesos en ejecucin y al sistema operativo de
posibles errores en cualquiera de ellos:
El sistema operativo proporciona a cada proceso una vista privada de la memoria similar a
la que tendran si cada uno de ellos se estuviera ejecutando en solitario (vase la Figura 2.4).
A esa vista que tiene cada proceso de la memoria es a lo que se denomina espacio de
26 El termino sistema operativo residente hace referencias a los componentes del sistema operativo que deben estar
permanentemente en la memoria. Comnmente dicho conjunto de elementos componen el ncleo del sistema.
2-36
2.2. Operacin del sistema operativo Sistemas Operativos - 2014/2015
sistema operativo
proceso 2
proceso 1
sistema operativo
proceso 2
0x00000000 0x00000000
memoria fsica espacio de direcciones
del proceso 2
Figura 2.4: Mapeo de la memoria fsica en el espacio de direcciones virtual de un proceso.
direcciones virtual del proceso y est formado por el conjunto de direcciones que puede
generar la CPU para un proceso dado.
Durante los accesos a la memoria principal en tiempo de ejecucin estas direcciones virtuales
son convertidas en direcciones fsicas antes de ser enviadas a la memoria principal. Por tanto
las direcciones fsicas son las direcciones reales que ve la memoria, mientras que el espacio
de direcciones fsico es el conjunto de direcciones fsicas que corresponden a un espacio de
direcciones virtual dado.
La conversin de una direccin virtual en una fsica la realiza en tiempo de ejecucin un

dispositivo hardware denominado MMU (Memory-Management Unit). Las ventajas de este
dispositivo desde el punto de vista de la proteccin de la memoria son que:
Permite el aislamiento de los procesos, creando para cada uno la ilusin de que toda la
memoria es para l y evitando que un proceso pueda acceder a la memoria de otros procesos.
Permite marcar los modos de acceso autorizados en las diferentes regiones de la memoria
como por ejemplo lectura, escritura y ejecucin evitando que el cdigo ejecutado en modo
usuario tenga acceso a zonas a las que no debera tenerlo. El acceso a la memoria en un modo
no autorizado se considera una instruccin privilegiada, por lo que ese tipo de acceso desde el
modo usuario siempre genera una excepcin.
2-37
2.2.3. El temporizador
El temporizador se utiliza para poder estar seguros de que el sistema operativo es capaz de
mantener el control de la CPU, puesto que lo que no puede ocurrir es que un proceso entre en un
bucle infinito de manera que nunca devuelva el control al sistema operativo.
El temporizador se configura durante el arranque del sistema para interrumpir a la CPU a intervalos
regulares. As cuando el temporizador interrumpe el control se transfiere automticamente al
sistema operativo. Entonces este puede: conceder ms tiempo al proceso en ejecucin, detenerlo y
darle ms tiempo de CPU en el futuro o tratar la interrupcin como un error y terminar de manera
anormal el programa. Indudablemente las instrucciones que pueden modificar el contenido del
temporizador son instrucciones privilegiadas.
2.3. Sistemas operativos por su estructura

Ya hemos discutido anteriormente acerca de los componentes ms comunes en un sistema operativo
(vase el apartado 2.1.2). En esta seccin comentaremos su organizacin e interconexin dentro del
ncleo.
aplicaciones
programa residente del sistema
drivers de dispositivo de MSDOS
drivers de dispositivo de la BIOS
hardware
Figura 2.5: Ejemplo de sistema operativo con estructura sencilla (MSDOS).
2-38
2.3. Sistemas operativos por su estructura Sistemas Operativos - 2014/2015
2.3.1. Estructura sencilla

Los sistemas con estructura sencilla no tienen una estructura bien definida. Es decir, los interfaces
y niveles de funcionalidad no estn bien separados.
Por ejemplo, en MSDOS los programas de aplicacin podan acceder directamente a la BIOS o al
hardware para hace acceder a cualquier dispositivo (vase la Figura 2.5). Disponiendo de esa
libertad un programa errneo cualquiera poda corromper el sistema completo. Como el Intel 8086
para el que fue escrito MSDOS no proporcionaba un modo dual de operacin, los diseadores del
sistema no tuvieron ms opcin que dejar accesible el hardware a los programas de usuario.
Otro ejemplo es el de UNIX original, donde se combinaba un montn de funcionalidad en un

mismo nivel, el ncleo (vase la Figura 2.6). Es decir, todo lo que estaba por encima del hardware y
por debajo de las llamadas al sistema era el ncleo. Este proporciona la planificacin de CPU, la
gestin de la memoria, el soporte de los sistemas de archivos y muchas otras funcionalidades del
sistema operativo. En general se trata de una enorme cantidad de funcionalidad que es difcil de
implementar y mantener en un mismo nivel. Esa concentracin de funcionalidad en el ncleo
define a los sistemas de estructura sencilla como sistemas de ncleo moltico.
Tanto MSDOS como UNIX eran originalmente sistemas pequeos y simples, limitados por la
aplicaciones
intrpretes de comando
compiladores e intrpretes
modo libreras del sistema
usuario
modo
privilegiado llamadas al sistema
planificador de la
gestin de seales sistema de ficheros CPU
del terminal reemplazo de
sistema de E/S de
sistema de E/S de bloques pginas
caracteres paginacin bajo
drivers de disco y
drivers de terminal cinta demanda
memoria virtual
interfaz del ncleo con el hardware
hardware
Figura 2.6: Ejemplo de sistema operativo con estructura sencilla (UNIX original).
2-39
funcionalidades del hardware de su poca, que fueron creciendo ms all de las previsiones
originales. Lo cierto es que con mejor soporte del hardware se puede dividir el sistema operativo en
piezas ms pequeas y apropiadas que las del MSDOS y UNIX original.
2.3.2. Estructura en capas

Un mtodo para dividir el sistema operativo en piezas ms pequeas, con el fin de hacerlo ms
modular, es partirlo en capas. Las capas se seleccionan de manera que cada una use slo funciones
y servicios de las capas inferiores y de servicios slo a las capas superiores. Cada capa no tiene que
saber como se implementan las funciones que utiliza de las capas inferiores, slo debe conocer qu
logon OS/2 Win 16 Win 32 MSDOS POSIX

process applications applications applications applications applications
security OS/2 Win 16 MSDOS POSIX

subsystem subsystem VDM VDM subsystem
authentication
pakage
security account Win 32

manager database subsystem
modo
usuario
modo
privilegiado
executive
I/O manager
security virtual local
object process plug and
reference memory procedue window
file system manager manager play manager
monitor manager call facility manager
cache
manager
graphic
device device
driver kernel
drivers
I/O manager
network
drivers
hardware abstraction layer
hardware
Figura 2.7: Diagrama de bloques de Microsoft Windows XP.
2-40
es lo que hacen y como utilizar. Por lo tanto cada capa tiene la responsabilidad de ocultar la
existencia de estructuras de datos, operaciones y hardware a las capas de nivel superior. Este tipo de
sistemas son los que se denominan con estructura en capas.
Los sistemas con estructura en capas siguen concentrado la mayor parte de la funcionalidad en el
ncleo, por lo que tambin son sistemas monolticos aunque el ncleo es ms modular. Ejemplos de
este tipo de sistemas operativos son el IBM OS/2 y Microsoft Windows (vase la Figura 2.7).
Sin embargo esta forma de dividir los componentes del sistema operativo no est libre de
inconvenientes:
La mayor dificultad con los sistemas con estructura en capas es definirlas. Esto debe ser
planificado cuidadosamente debido a la restriccin, comentada anteriormente, de que un capa
slo puede utilizar los servicios de las capas inferiores. Por ejemplo, el planificador de CPU
suele tener informacin de los procesos que estn en la memoria y parte de esa informacin
puede ser intercambiada con el disco para aumentar la memoria principal disponible. Este
planteamiento nos lleva a pensar que la gestin del almacenamiento secundario debe ir en una
capa inferior a la del planificador de la CPU. Sin embargo el planificador debe replanificar la
CPU cuando el proceso que actualmente la ocupa solicita alguna operacin de E/S, por lo que
la gestin del almacenamiento secundario debe estar encima del planificador de la CPU para
que le pueda decir que replanifique. Al final la solucin de compromiso es tender hacia
sistemas con pocas capas donde cada una tiene mucha funcionalidad.
Esta estrategia es sin duda mucho menos eficiente que la de los sistemas de estructura
sencilla. En cada capa los parmetros son modificados y los datos necesarios deben de ser
transferidos, por lo que cada una aade cierto nivel de sobrecarga al funcionamiento del
sistema.
2-41
2.3.3. Microkernel
Los sistemas microkernel eliminan todos los componentes no esenciales del ncleo y los
implementa como programas de nivel de usuario. Aunque hay poco consenso, en general un ncleo
microkernel proporciona funciones mnimas de gestin de procesos y memoria, junto a algn
mecanismo de comunicacin. En estos sistemas la funcin principal del ncleo es precisamente
proporcionar dicho mecanismo de comunicacin entre el programa cliente y los diversos servicios
del sistema. Generalmente esta comunicacin se implementa mediante paso de mensajes (vase el
apartado 3.2).
Entre los beneficios de estos sistemas operativos se incluyen:
Facilidad a la hora de aadir nuevas funcionalidades. Los nuevos servicios son aadidos
como aplicaciones de nivel de usuario, por lo que no es necesario hacer modificaciones en el
ncleo.
Facilidad a la hora de portar el sistema a otras plataformas.
Ms seguridad y fiabilidad. Puesto que los servicios se ejecutan a nivel de usuario en procesos
separados, un servicio que falla no puede afectar a otros ni puede ser utilizado para ganar
acceso a otros servicios o al ncleo.
El mayor inconveniente es su pobre rendimiento causado por la sobrecarga que aade el

mecanismo de comunicacin. Por ejemplo Microsoft Windows NT naci con una estructura de
microkernel en capas donde una parte importante de los servicios eran proporcionados por unos
procesos de usuario llamados subsistemas. Adems el sistema operativo poda mostrar diferentes
personalidades o entornos operativos OS/2, POSIX y DOS a travs del uso de subsistemas
ambientales, que tambin se ejecutaban como procesos de usuario. Las aplicaciones de Microsoft
Windows NT se comunicaban con estos subsistemas utilizando una forma de IPC (vase el apartado
3.2.3) denominada LPC (Local Procedure Call), una forma local y optimizada de RPC27. Con esta
estructura la prdida de rendimiento respecto a Microsoft Windows 95 era tan importante que los
diseadores se vieron obligados a mover ms servicios al espacio del ncleo. En la actualidad
Microsoft Windows XP (vase la Figura 2.7) que es un heredero directo de Microsoft Windows
27 La RPC (Remote Procedure Call) es una mecanismo de llamada a procedimiento diseado para ser utilizado entre
sistemas conectados por redes de ordenadores, permitiendo que un proceso cliente llame a un procedimiento en un
proceso servidor, aunque ambos estn en equipos diferentes, y ocultado los detalles de la comunicacin que
permiten que la llamada tenga lugar.
2-42
aplicaciones aplicaciones
Hurd POSIX
glibc
(1)
servidores Hurd
sistema de
autenticacin contrasea
ficheros
procesos red ...
modo
usuario (1)
modo (1)
privilegiado
GNU Mach
OSkit paso de gestor de

mensajes memoria
controladores gestor de
tareas
de dispositivo
hardware
Figura 2.8: Diagrama de bloques de GNU/Hurd.
NT tiene una arquitectura ms monoltica que microkernel 28 ya que aunque muchos servicios
siguen siendo proporcionados por procesos de usuario, esto slo ocurre con aquellos donde el
rendimiento no es un factor crtico.
Sin embargo varios sistemas operativos siguen utilizando ncleos microkernel, como Tru64 UNIX
y GNU/Hurd (vase la Figura 2.8). Ambos proporcionan una interfaz UNIX implementada sobre un
microkernel Mach. Otro ejemplo es QNX, un sistema operativo de tiempo real con una gran
aceptacin que basa en la estructura de microkernel su estabilidad como sistema para tareas
crticas. Adems siguen existiendo algunos proyectos de investigacin dirigidos a resolver los
problemas de rendimiento asociados a los ncleos microkernel.
28 A las 280 llamadas al sistema de Microsoft Windows XP algo menos de 200 en Microsoft Windows NT 3.51 se
deben sumar las ms de 650 del subsistema grfico, alojado en el ncleo desde Microsoft Windows NT 4.0.
2-43
2.3.4. Estructura modular

Los sistemas de estructura modular tienen divido el ncleo en mdulos, cada uno de los cuales
implementa funciones y servicios concretos, a imagen y semejanza de las tcnicas de programacin
orientada a objetos. Quizs por eso sea la mejor metodologa actual para disear sistemas
operativos. Adems se parecen a los sistemas con estructura en capas en que cada mdulo del
ncleo tiene definidos interfaces protegidas, pero a diferencia de estos todos los mdulos pueden
llamar a cualquier otro mdulo.
Estos ncleos suelen disponer un pequeo conjunto de componentes fundamentales que se cargan
durante el arranque, aunque tambin pueden enlazar dinmicamente servicios adicionales tanto
durante la inicializacin del sistema como o en tiempo de ejecucin. En este aspecto se asemejan a
los ncleos microkernel, ya que el mdulo principal slo tiene funciones bsicas, aunque es mucho
ms eficiente al no necesitar un mecanismo de paso de mensajes, puesto que los componentes se
cargan directamente en la memoria destinada al ncleo. Por lo tanto tambin deben ser
considerados como sistemas monolticos.
Este tipo de estructura es la utilizada en los UNIX modernos, como Oracle/Sun Microsystems
Solaris, Linux (vase la Figura 2.9) y Mac OS X.
2-44
aplicaciones
libreras del sistema (glibc)

modo
usuario
modo
privilegiado
llamadas al sistema
sistema de ficheros virtual planificador de procesos gestor de memoria IPC
planificacin de
buffer-cache File IPC
procesos
VFS bin_exec gestin del tiempo core mmap swap Net IPC
controladores de
gestin de mdulos Kernel IPC
dispositivo
System V IPC
red
Linux
hardware
Figura 2.9: Ejemplo de sistema operativo con estructura modular (GNU/Linux).

3. Gestin de procesos
3.1. Procesos
Los primeros sistemas informticos slo permitan que un programa se ejecutara de cada vez. Dicho
programa tena un control completo sobre el sistema y acceso a todos los recursos del mismo. Por el
contrario, los sistemas de tiempo compartido actuales permiten que mltiples programas sean
cargados y ejecutados concurrentemente. Obviamente esta evolucin requiere un control ms fino y
la compartimentacin de los diversos programas para que no interfieran unos con otros. Esto a su
vez conduce a la aparicin de la nocin de proceso, que no es sino la unidad de trabajo en un
sistema operativo moderno de tiempo compartido.
Por simplicidad, en este tema utilizaremos los trminos trabajo y proceso de forma indistinta. A fin
de cuentas tanto los trabajos en los sistemas de procesamiento por lotes como los procesos en los
sistemas de tiempo compartido son la unidad de trabajo en sus respectivos sistemas y el origen de
toda actividad en la CPU.
Por ltimo, antes de continuar, no debemos olvidar que en un sistema operativo hay:
Procesos del sistema ejecutando el cdigo del sistema operativo contenido en los programas
del sistema, que generalmente realizan tareas que es mejor mantener fuera del ncleo.
Procesos de usuario ejecutando cdigo de usuario contenido en los programas de aplicacin.

Sistemas Operativos - 2014/2015 3. Gestin de procesos
Sin embargo en lo que resta de tema no estableceremos ningn tipo de distincin entre ellos. Al fin
y al cabo todos son simples procesos de cara al resto del sistema.
3.1.1. El proceso
Como ya hemos comentado con anterioridad, un proceso es un programa en ejecucin. Sin
embargo los procesos no son slo el cdigo del programa, sino que tambin suelen contener
algunos otros elementos:
El cdigo del programa, conocido como la seccin text.
La seccin de datos contiene las variables globales. Se divide entre la seccin data, donde se
almacenan las variables inicializadas, y la seccin bss, donde se almacenan las variables sin
inicializar.
La pila contiene datos temporales como parmetros y direcciones de retorno de las funciones
y variables locales. Es conocida como la seccin stack.
El montn, que es donde se aloja la memoria que se asigna dinmicamente durante la

ejecucin del proceso.
Informacin de la actividad actual, como el contador de programa, los registros de la CPU,

etc.
En la Figura 3.1 se puede observar la disposicin de algunos de estos elementos en la memoria.
Mx.
sistema operativo
pila
montn
datos
cdigo
0x00000000
Figura 3.1: Estructura de un proceso en memoria.
3-48
3.1. Procesos Sistemas Operativos - 2014/2015
En todo caso es importante recordar que un proceso es una entidad activa, con un contador de
programa especificando la prxima instruccin a ejecutar y un conjunto de recursos del sistema
asociados. Mientras que un programa no es un proceso ya que es una entidad pasiva, como un
archivo en disco que contiene el cdigo que algn da ser ejecutado en la CPU. Por lo tanto dos
procesos pueden estar asociados al mismo programa pero no por eso dejan de ser distintos procesos
(vase el apartado 2.1.2). Ambos tendrn la misma seccin text pero el contador de programas, la
pila, la seccin data, etc. contendrn valores diferentes.
3.1.2. Estados de los procesos

Los procesos tienen un estado que cambia a lo largo de su ejecucin y est definido parcialmente
por la actividad actual del propio proceso. Los estados por los que puede pasar un procesos varan
de un sistema operativo a otro, aunque los siguientes son comunes a todos ellos:
Nuevo. El proceso est siendo creado.
Ejecutando. El proceso est siendo ejecutado puesto que ha sido escogido por el planificador
de la CPU. Slo puede haber un proceso en este estado por CPU en el sistema.
Esperando. El proceso est esperando por algn evento, como por ejemplo que termine
alguna operacin de E/S o que se reciba alguna seal. Obviamente varios procesos pueden
estar en este estado.
Preparado. El proceso est esperando a que se le asigne la CPU. Varios procesos pueden estar
en este estado.
nuevo terminado
admitido salida
temporizador
preparado ejecutando
asignacin por el
E/S o evento planificador de la CPU a la espera de un
completado evento o E/S
esperando
Figura 3.2: Diagrama de estado de los procesos.
3-49
Terminado. El proceso ha finalizado su ejecucin y espera a que se liberen los recursos que le
fueron asignados.
El diagrama de estado de los procesos se muestra en la Figura 3.2.
3.1.3. Bloque de control de proceso

El bloque de control de proceso o PCB (Process Control Block) es una estructura de datos que
representa a cada proceso en el sistema operativo. Sirve de almacn para cualquier informacin
que puede variar de un proceso a otro.
Estado del proceso. Por ejemplo: nuevo, preparado, esperando, etc.
Contador de programa. Indica la direccin de la prxima instruccin del proceso que debe
ser ejecutada por la CPU.
Registros de la CPU.
Informacin de planificacin de la CPU. Incluye la informacin requerida por el

planificador de la CPU. Por ejemplo la prioridad del proceso, punteros a las colas de
planificacin donde est el proceso, punteros al PCB del proceso padre y de los procesos hijos,
etc.
Informacin de gestin de la memoria. Incluye la informacin requerida para la gestin de

la memoria. Por ejemplo los valores de los registros base y lmite que definen el rea de la
memoria fsica que ocupa el proceso, la tabla de pginas en el caso de que se use paginacin
(vase el apartado 4.4) o la tabla de segmentos en el caso de que se utilice segmentacin
etc.
Informacin de registro. Esta informacin incluye la cantidad de CPU usada, lmites de

tiempo en el uso de la CPU, estadsticas de la cuenta del usuario al que pertenece el proceso,
estadsticas de la ejecucin del proceso, etc.
Informacin de estado de la E/S. Incluye la lista de dispositivos de E/S reservados por el

proceso, la lista de archivos abiertos, etc.
3-50
cola de preparados CPU
interrupcin del temporizador
peticin de E/S
E/S cola de espera de E/S
esperar por
un evento
evento cola de espera del evento
Figura 3.3: Diagrama de colas de la planificacin de procesos.
3.1.4. Colas de planificacin

En los sistemas operativos hay diferentes colas de planificacin para los procesos en distintos
estados.
Cola de trabajo. Contiene a todos los procesos en el sistema de manera que cuando un
proceso entra en el sistema va a esta cola.
Cola de preparados. Contiene a los procesos que estn cargados en la memoria principal y
estn preparados para ser ejecutados. La cola de preparados es generalmente una lista
enlazada de PCB donde cada uno incluye un puntero al PCB del siguiente proceso en la cola.
Colas de espera. Contienen a los procesos que estn esperando por un evento concreto, como
por ejemplo la finalizacin de una solicitud de E/S. Estas colas tambin suelen ser
implementadas como listas enlazadas de PCB y suele existir una por evento, de manera que
cuando ocurre algn evento todos los procesos en la cola asociada pasan automticamente a la
cola de preparados.
Colas de dispositivo. Son un caso particular de cola de espera. Cada dispositivo de E/S tiene
asociada una cola de dispositivo que contiene los procesos que estn esperando por ese
dispositivo en particular.
Una manera habitual de representar la planificacin de procesos es a travs de un diagrama de colas

como el de la Figura 3.3. Analizndolo podemos tener una idea clara del flujo tpico de los procesos
dentro del sistema:
3-51
1. Un nuevo proceso llega al sistema. El proceso es colocado en la cola de preparados. All

espera hasta que es seleccionado para su ejecucin y se le asigna la CPU. Mientras se ejecuta
pueden ocurrir varias cosas:
El proceso puede solicitar una operacin de E/S por lo que abandona la CPU y es
colocado en la cola de dispositivo correspondiente. No debemos olvidar que aunque en
nuestro diagrama no exista ms que una de estas colas, en un sistema operativo real
suele haber una para cada dispositivo.
El proceso puede querer esperar por un evento. Por ejemplo puede crear un subproceso
y esperar a que termine. En ese caso el proceso hijo es creado mientras el proceso padre
abandona la CPU y es colocado en una cola de espera hasta que el proceso hijo termine.
La terminacin del proceso hijo es el evento que espera el proceso padre para continuar
su ejecucin.
El proceso puede ser sacado forzosamente de la CPU como resultado de la

interrupcin del temporizador que indica que lleva demasiado tiempo ejecutndose y
colocado en la cola de preparados.
2. Cuando la espera concluye los procesos pasan del estado de espera al de preparado y son
insertados en la cola de preparados.
3. El proceso repite este ciclo hasta que termina. En ese momento es eliminado de todas las
colas mientras el PCB y los recursos asignados son liberados.
3.1.5. Planificacin de procesos

Durante su ejecucin, los procesos se mueven entre las diversas colas de planificacin a criterio del
sistema operativo como parte de la tarea de planificacin. Este proceso de seleccin debe ser
realizado por el planificador adecuado:
En los sistemas de multiprogramados 29 el planificador de largo plazo o planificador de

trabajos selecciona los trabajos desde la cola de entrada en el almacenamiento secundario,
dnde estn todos almacenados, y los carga en memoria.
El planificador de corto plazo o planificador de CPU selecciona uno de los procesos en la
29 Los sistemas de tiempo compartido como GNU/Linux, Microsoft Windows o cualquier sabor de UNIX carecen de
planificador de trabajos. En estos sistemas simplemente se cargan los procesos en memoria para que sean ejecutados
cuando el usuario lo solicita.
3-52
cola de preparados y lo asigna a la CPU. Obviamente este planificador es invocado cuando

un proceso en ejecucin abandona la CPU por cualquiera de los motivos comentados.
Algunos sistemas operativos utilizan el planificador de medio plazo para sacar procesos de la
memoria y reintroducirlos posteriormente. A este esquema se le denomina intercambio o
swapping y puede ser necesario utilizarlo cuando escasea la memoria.
3.1.6. Cambio de contexto

El cambio de contexto es la tarea de asignar a la CPU un proceso distinto al que la tiene asignada
en el momento actual. Esto implica salvar el estado del viejo proceso en su PCB y cargar en la CPU
el estado del nuevo. Entre la informacin que debe ser preservada se incluye:
Los registros de la CPU.
El estado del proceso.
La informacin de gestin de la memoria. Por ejemplo la informacin referente al espacio

de direcciones del proceso.
El cambio de contexto es sobrecarga pura puesto que no hace ningn trabajo til mientras se
conmuta. Su velocidad depende de aspectos tales como: el nmero de registros, la velocidad de la
memoria y la existencia de instrucciones especiales30.
3.1.7. Operaciones sobre los procesos

En general los procesos pueden ser creados y eliminados dinmicamente, por lo que los sistemas
operativos deben proporcionar mecanismos para la creacin y terminacin de los mismos.
a) Creacin de procesos
Un proceso denominado padre puede crear mltiples procesos los hijos utilizando una
llamada al sistema especfica para la creacin de procesos. En general cada proceso se identifica
de manera unvoca mediante un identificador de proceso o PID (Process Identifier), que
30 Algunas CPUs disponen de instrucciones especiales para salvar y cargar todos los registros de manera eficiente.
Esto reduce el tiempo que la CPU est ocupada en los cambios de contexto. Otra opcin es el uso de juegos de
registros, como es el caso de los procesadores Sun UltraSPARC e Intel Itanium. Con ellos el juegos de registros de
la CPU puede ser mapeado sobre un banco de registros mucho ms extenso. Esto permite que la CPU almacene de
forma eficiente el valor de los registros de ms de un proceso.
3-53
normalmente es un nmero entero. Puesto que cada nuevo proceso puede a su vez crear otros
procesos, al final se acaba obteniendo un rbol de procesos31.
Hay varios aspectos en la creacin de los procesos que pueden variar de un sistema operativo a otro:
Cmo obtienen los subprocesos los recursos que necesita para hacer su trabajo?
En algunos sistemas operativos los subprocesos slo puede aspirar a obtener un

subconjunto de los recursos de su padre. Esto permite evitar, por ejemplo, que un
proceso pueda sobrecargar el sistema creando demasiados procesos.
Mientras que en otros cada subproceso puede solicitar y obtener los recursos
directamente del sistema operativo.
Qu ocurre con los recursos de un proceso cuando decide crear subprocesos?
El proceso puede estar obligado a repartir sus recursos entre sus hijos.
O puede que est en disposicin de compartir algunos recursos como memoria y

archivos con algunos de sus hijos. Por ejemplo en POSIX todos los archivos abiertos
por un proceso son heredados en ese estado por sus hijos.
Cmo un proceso puede pasar parmetros de inicializacin a sus procesos hijo? Adems
de los diversos recursos que un proceso obtiene cuando es creado, el proceso padre suele
poder pasar parmetros de inicializacin a sus procesos hijo. Por ejemplo en lenguaje C/C++
se puede obtener acceso a estos parmetros travs de los argumentos argc y argv de la
funcin main() del programa.
Qu ocurre con la ejecucin de un proceso cuando crea un subproceso? Si eso ocurre se

suelen contemplar dos posibilidades en trminos de la ejecucin del padre:
El padre contina ejecutndose concurrentemente con el hijo.
El padre decide esperar a que algunos o todos sus hijos terminen.
Cmo se construye el espacio de direccin de los subprocesos? En general hay dos

posibilidades:
31 En los sistemas UNIX el proceso init es el proceso padre raz de todos los procesos de usuario. Su PID siempre es
1 ya que es el primer proceso creado por el sistema operativo al terminar la inicializacin del ncleo. Por lo tanto es
el responsable de crear todos los otros procesos que son necesarios para el funcionamiento del sistema.
3-54
/* lanzar otro proceso */

pid_t pid = fork();
if (pid == 0) { // proceso hijo

execlp("/bin/ls", "ls", "-l", NULL);
}
else if (pid > 0) { // proceso padre
// el padre esperar a que el hijo termine
wait(NULL);
std::cout << "El hijo a terminado. << std::endl;
exit(0);
}
else { // error
perror("fallo en fork()");
exit(-1);
}
Figura 3.4: Ejemplo de creacin de un proceso con fork()/exec().
El espacio de direcciones del proceso hijo es un duplicado del que tiene el padre. Es
decir, que inicialmente tiene el mismo cdigo y datos que el padre.
El espacio de direcciones del proceso hijo se crea desde cero y se carga en l un nuevo
programa.
Para ilustrar la diferencia entre estos dos ltimos casos, supondremos que tenemos un proceso que
quiere crear un subproceso. En los sistemas operativos POSIX un nuevo proceso siempre se crea
con la llamada fork() que se encargar de crear el nuevo proceso con una copia del espacio de
direcciones del proceso original (vase la Figura 3.4). Esto facilita la comunicacin entre procesos
puesto que al copiarse el espacio de direcciones tambin se copia la tabla de archivos abiertos. No
debemos olvidar que muchos de los recursos de un sistema POSIX se muestran de cara a los
procesos que los utilizan como archivos. Por lo tanto, el proceso hijo no slo tiene acceso a los
archivos abiertos por el padre antes de la llamada al fork() sino tambin a tuberas (vase el
apartado 3.2.4), sockets (vase el apartado 3.2.4) y regiones de memoria compartida (vase el
apartado 3.2.2), entre otros muchos recursos. Todos estos son mecanismos que los procesos pueden
utilizar para comunicarse.
Tanto padre como hijo continan la ejecucin en la siguiente instruccin despus del fork(). La
diferencia es que para el padre el valor de retorno de la llamada fork() es el identificador de
3-55
proceso del hijo, mientras que para el hijo el valor de retorno es cero. De esa forma padre e hijo
pueden saber quin es cada uno (vase la Figura 3.4).
En muchas ocasiones lo que se desea es iniciar la ejecucin de un nuevo programa. Como POSIX
no dispone de una llamada al sistema para dicha tarea, lo que se debe hacer es invocar la llamada
exec() en el hijo despus del fork(). La llamada exec() carga un nuevo archivo ejecutable en el
espacio de direcciones del proceso actual e inicia su ejecucin, destruyendo la imagen del programa
que realiz la llamada a exec(). Mientras tanto el padre puede crear ms hijos o si no tiene nada
ms que hacer puede esperar. Para ello utiliza la llamada wait() que mueve el proceso a una cola
de espera hasta que termine el hijo creado previamente (vase la Figura 3.4).
Respecto a la familia de sistemas operativos Microsoft Windows NT, se supone que ambos modelos
son soportados a travs de la llamada al sistema NTCreateProcess(). Es decir, que el espacio de
direcciones del padre puede ser duplicado o se puede indicar el nombre de un programa para que el
sistema operativo lo cargue en un nuevo proceso. Sin embargo el hecho es que los programadores
no tienen acceso directo a NTCreateProcess() ya que se supone que debe ser utilizada a travs de
la funcin CreateProcess() de la librera de sistema de la API Win32. Dicha funcin no duplica el
espacio de direcciones del padre, sino que simplemente carga en un nuevo proceso el programa
indicado en los argumentos32.
b) Terminacin de procesos
Un proceso termina cuando se lo indica al sistema operativo con la llamada al sistema exit(). En
ese momento puede devolver un valor de estado a su padre, que este puede recuperar a travs de la
llamada al sistema wait(). Cuando un proceso termina todos los recursos son liberados incluyendo:
la memoria fsica y virtual, archivos abiertos, buffers de E/S, etc.
En todo caso un proceso puede provocar la terminacin de otro proceso a travs de una llamada al
sistema. Habitualmente el proceso que la invoca es el padre ya que puede que sea el nico con
permisos para hacerla. Los motivos pueden ser:
El hijo ha excedido el uso de algunos de los recursos reservados. Obviamente esto tiene
sentido cuando los hijos utilizan un subconjunto de los recursos asignados al padre.
32 Esta decisin de diseo en el API principal de Microsoft Windows estuvo motivada por el hecho de que la creacin
de nuevos procesos tiene un coste alto en ese sistema operativo. En Microsoft Windows la forma adecuada de
realizar varias tareas al mismo tiempo es utilizando hilos (vase el apartado 3.3).
3-56
La tarea asignada al hijo ya no es necesaria.
El padre termina y el sistema operativo est diseado para no permite que el hijo pueda
seguir ejecutndose si no tiene un padre. Esto provoca que el sistema operativo inicie lo que
se denomina una terminacin en cascada33, donde todos los procesos que cuelgan de uno
dado terminan.
3.2. Procesos cooperativos

Desde el punto de vista de la cooperacin podemos clasificar los procesos en dos grupos:
Los procesos independientes, que no afectan o pueden ser afectados por otros procesos del
sistema. Cualquier proceso que no comparte datos temporales o persistentes con otros
procesos es independiente.
Los procesos cooperativos, que pueden afectar o ser afectados por otros procesos ejecutados
en el sistema. Los procesos que comparten datos siempre son cooperativos.
3.2.1. Motivaciones para la colaboracin entre procesos

Hay diversos motivos para proporcionar un entorno que permita la cooperacin de los procesos:
sistema operativo sistema operativo sistema operativo sistema operativo
proceso A proceso B
memoria compartida
memoria compartida send() receive()
proceso A proceso B
memoria compartida comunicacin entre procesos
Figura 3.5: Modelos de comunicacin.

33 En UNIX si un proceso muere a su hijo se le reasigna como padre el proceso init con PID 1. Al menos en
GNU/Linux, los intentos de matar a este ltimo son ignorados por el sistema.
3-57
Comparticin de informacin. Dado que varios usuarios pueden estar interesados en los
mismos bloques de informacin por ejemplo en un archivo compartido el sistema operativo
debe proporcionar un entorno que permita el acceso concurrente a este tipo de recursos.
Velocidad de cmputo. Para que una tarea se ejecute ms rpido se puede partir en subtareas
que se ejecuten en paralelo. Es importante destacar que la mejora en la velocidad slo es
posible si el sistema tiene varios componentes de procesamiento como procesadores o
canales E/S.
Modularidad. Podemos querer crear nuestro software de forma modular, dividiendo las
funciones del programa en procesos separados.
Conveniencia. Incluso un usuario individual puede querer hacer varias tareas al mismo
tiempo. Por ejemplo editar, imprimir y compilar en paralelo.
Las ejecucin concurrente de procesos cooperativos requiere mecanismos tanto para comunicar
unos con otros (vase los apartados 3.2.2 y 3.2.3) como para sincronizar sus acciones (vase el
apartado 3.3.3).
3.2.2. Memoria compartida

La memoria compartida es una estrategia para comunicar procesos dnde uno de ellos gana
acceso a regiones de la memoria del otro (vase la Figura 3.5). Puesto que normalmente el sistema
operativo intenta evitar que un proceso pueda tener acceso a la memoria de otro proceso (vase el
apartado 2.2.2), para que pueda haber memoria compartida es necesario que los dos procesos estn
de acuerdo en eliminar dicha restriccin.
Dos procesos que comparten una regin de la memoria pueden intercambiar informacin leyendo y
escribiendo datos en la misma, pero:
La estructura de los datos y su localizacin dentro de la regin compartida la determinan los

procesos en comunicacin y no el sistema operativo.
Los procesos son responsables de sincronizarse (vase el apartado 3.3.3) para no escribir en el
mismo sitio al mismo tiempo, lo que que podra generar inconsistencias.
Las principales ventajas de la memoria compartida frente a otros mecanismos de comunicacin son:
Eficiencia, puesto que la comunicacin tiene lugar a la velocidad de la memoria principal.
3-58
3.2. Procesos cooperativos Sistemas Operativos - 2014/2015
Conveniencia, puesto que el mecanismo de comunicacin slo requiere leer y escribir de la

memoria.
3.2.3. Comunicacin entre procesos

La comunicacin entre procesos o IPC (Interprocess Communication) es un mecanismo para que
los procesos puedan compartir informacin y sincronizar sus acciones sin necesidad de compartir
el espacio de direcciones. Este mecanismo debe ser proporcionado por el sistema operativo que, a
diferencia de cuando se usa memoria compartida, se encarga de la sincronizacin y as como de
establecer el formato que deben tener los datos. Es particularmente til en entornos distribuidos
dnde los procesos a comunicar residen en ordenadores diferentes conectados a una red. Por
ejemplo se utiliza para comunicar un navegador y un servidor Web en Internet.
La mejor forma de proporcionar IPC es utilizando un sistema de paso de mensajes (vase la Figura
3.5).
a) Sistema de paso de mensajes

La funcin de un sistema de paso de mensajes es permitir que los procesos se comuniquen sin
necesidad de recurrir a la comparticin de recursos compartir memoria, archivos, etc..
El componente de IPC de cualquier sistema operativo debe proporcionar al menos dos llamadas al
sistema:
send (message) para mandar mensajes a otro proceso.
receive (message) para recibir mensajes de otro proceso.
Adems los diseadores del sistema operativo deben escoger entre implementar un componentes de
IPC con mensajes de tamao fijo o mensajes de tamao variable.
Mensajes de tamao fijo. La implementacin del sistema operativo es sencilla pero la

programacin de aplicaciones es mucho ms compleja.
Mensajes de tamao variable. La implementacin del sistema operativo es ms compleja

pero la programacin de aplicaciones es ms simple.
Para que dos procesos se puedan comunicar es necesario que haya un enlace de comunicaciones.
No trataremos aqu la implementacin fsica del enlace que por ejemplo puede ser mediante
3-59
memoria compartida, un bus hardware, o una red de comunicaciones sino de su implementacin

lgica.
En general existen varias opciones a la hora de implementar de manera lgica un enlace y las
correspondientes operaciones de envo y recepcin:
Comunicacin directa o indirecta.
Comunicacin sncrona o asncrona.
Buffering explcito o automtico.
b) Referenciacin
Los procesos que se quiera comunicar debe tener una forma de referenciarse el uno al otro. Para ello
puede utilizar la comunicacin directa o la indirecta.
Comunicacin directa
En la comunicacin directa cada proceso debe nombrar explcitamente al proceso destinatario o
receptor de la informacin. Por ejemplo:
send (P, message) para mandar un mensaje al proceso P.
receive (Q, message) para recibir un mensaje del proceso Q.
El esquema anterior se de nomina direccionamiento simtrico pero existe una variante de ese
mismo esquema denominado direccionamiento asimtrico.
En el direccionamiento simtrico tanto el proceso transmisor como el receptor tienen que

nombrar al otro para comunicarse.
En el direccionamiento asimtrico slo el transmisor nombra al receptor, mientras que el

receptor no tiene que nombrar al transmisor.
send (P, message) para mandar un mensaje al proceso P.
receive (&id, message) para recibir un mensaje de cualquier proceso. En este caso el
sistema operativo asigna a la variable id el identificador del proceso transmisor del
mensaje antes de volver de la llamada al sistema.
La principal desventaja de este tipo de comunicacin es que cambiar el identificador de un proceso
3-60
requiere actualizar todas las referencias al anterior identificador en todos los procesos que se
comunican con el. En general cualquier tcnica que requiera que los identificadores de los procesos
sean establecidos explcitamente en el cdigo de los programas no es deseable. Esto es as porque
en muchos sistemas los identificadores de los procesos cambian de una ejecucin a otra. Por lo
tanto lo mejor sera disponer de una solucin con un nivel adicional de indireccin que evite que los
identificadores tenga que ser usados explcitamente
Comunicacin indirecta
En la comunicacin indirecta los mensajes son enviados a buzones, maillox o puertos que son
objetos dnde los procesos pueden dejar y recoger mensajes.
send (A, message) para mandar un mensaje al puerto A.
receive (A, message) para recibir un mensaje del puerto A.
Este tipo de comunicacin da lugar a algunas situaciones que deben ser resueltas. Por ejemplo,
qu pasa si los procesos P, Q y R comparten el puerto A, P manda un mensaje, y Q y R
invocan la llamada receive() en A?. La respuesta correcta depender de cul de los siguientes
mtodos escogieron los diseadores del sistema:
No permitir que cada enlace est asociado a ms de dos procesos.
No permitir que ms de un proceso puedan ejecutar receive() al mismo tiempo. Por ejemplo,
haciendo que slo el proceso que crea el puerto tenga permiso para recibir de l. Los sistemas
que optan por esta solucin suelen disponer de algn mecanimos para transferir el permiso de
recibir a otros procesos.
O permitir que el sistema operativo escoja arbitrariamente quin recibe el mensaje si dos o
ms procesos ejecutan receive() al mismo tiempo. La eleccin puede ser aleatoria o
mediante algn algoritmo, por ejemplo por turnos.
c) Buffering
Los mensajes intercambiados durante el proceso de comunicacin residen en una cola temporal.
Bsicamente hay tres formas de implementar dicha cola:
Con capacidad cero o sin buffering la cola tiene una capacidad mxima de 0 mensajes, por lo
3-61
tanto no puede haber ningn mensaje esperando en el enlace. En este caso el transmisor debe
bloquearse hasta que el receptor recibe el mensaje.
Con buffering automtico:
Con capacidad limitada la cola tiene una capacidad limitada a N mensaje, por que si la
cola no se llena el transmisor no espera. Sin embargo si la cola se llena, el transmisor
debe bloquearse a la espera de haya espacio en la cola.
Con capacidad ilimitada la cola es de longitud potencialmente34 infinita, lo que permite

que el transmisor nunca espere.
d) Sincronizacin
La comunicacin entre dos procesos tiene lugar por medio de las llamadas send() y receive(); de
tal forma que generalmente la primera se bloquea cuando la cola de transmisin se llena en
funcin del tipo de buffering mientras que la segunda lo hace cuando la cola de recepcin est
vaca.
Sin embargo existen diferentes opciones de diseo a la hora de implementar cada una de estas
primitivas en funcin de si se pueden bloquear o no. Por tanto, el paso de mensajes puede ser con
bloqueo o sin bloqueo, o lo que es lo mismo sncrono u asncrono.
Cuando el envo es sin bloqueo, el proceso transmisor nunca se bloquea. En caso de que la
cola de mensaje est llena, la solucin ms comn es que la llamada send() vuelva con un
cdigo de retorno que indique que el proceso debe volver a intentar el envo ms tarde.
Cuando el envo es con bloqueo, el proceso transmisor se bloquea cuando no queda espacio en
la cola de mensajes y hasta que pueda depositar el mensaje en la misma.
Cuando la recepcin es sin bloqueo, el proceso receptor nunca se bloquea. En caso de que la
cola de mensajes est vaca, el sistema operativo puede indicar al proceso que lo intente ms
tarde a travs de un cdigo de retorno o devolviendo un mensaje nulo.
Cuando la recepcin es con bloqueo, el receptor se bloquea cuando no hay mensajes en la

cola.
34 Las colas de longitud real infinita son imposibles puesto que los recursos son limitados. La longitud de estas colas
viene determinada por la memoria principal disponible, que suele ser lo suficientemente grande para que podamos
considerar que las colas son infinitas.
3-62
Diferentes combinaciones de send() y receive() son posibles. Es decir, transmisin y recepcin

pueden ser sncronas o asncronas de manera independiente.
3.2.4. Ejemplos de mecanismos comunicacin entre procesos
a) Tuberas
Las tuberas son un mecanismo de IPC de comunicacin indirecta que est incluido en muchos
sistemas operativos. La comunicacin es de capacidad cero y sncrona, aunque en algunos sistema
operativos tambin puede ser asncrona.
Conceptualmente cada tubera tiene dos extremos. Un extremo permite al proceso en ese extremo
escribir en la tubera, mientras el otro extremo permite a los procesos leer de la tubera.
int fds[2];
char buffer[255];
// crear una tubera

int res = pipe(fds);
if (res < 0) { // error
perror("fallo en pipe()");
exit(-1);
}
pid_t pid = fork();

if (pid == 0) { // proceso hijo
close(fds[0]);
write(fds[1], "El hijo ha sido creado", 23);
}
else if (pid > 0) { // proceso padre
close(fds[1]);
read(fds[0], buffer, sizeof(buffer));
std::cout << "Mi hijo ha dicho: '" << buffer <<
"'" << std::endl;
// el padre esperar a que el hijo termine */

wait(NULL);
std::cout << "El hijo a terminado" << std::endl;
}
else { // error
perror("fallo en fork()");
exit(-2);
}
exit(0);
Figura 3.6: Ejemplo de utilizacin de tuberas para la comunicacin entre procesos.
3-63
Existen dos tipos de tuberas:
Las tuberas annimas slo existen en el espacio de direcciones del proceso que las crea.
Los procesos hijo pueden heredar las tuberas abiertas por el proceso padre. Usando esa
capacidad de herencia se puede comunicar un proceso padre con sus hijos de manera
privada (vase la Figura 3.6).
Las tuberas con nombre son pblicas al resto del sistema, por lo que tericamente son
accesibles por cualquier proceso.
Se suelen utilizar en aplicaciones cliente servidor dnde un proceso servidor ofrece

algn servicio a otros procesos cliente a travs de la tubera.
En POSIX se denominan FIFO y tienen presencia en el sistema de archivos como

archivos especiales.
En Windows las tuberas con nombre son bidireccionales.
Por simplicidad las tuberas son tratadas de forma similar a los archivos por lo que en ambos casos
se utilizar las mismas primitivas de E/S read() y write().
b) Seales en sistemas operativos POSIX

En POSIX la forma ms sencilla de comunicar dos procesos del mismo sistema es mediante el
envo de una seal de uno al otro.
Los procesos pueden mandar seales utilizando la llamada al sistema kill(), que slo requiere el
identificador del proceso de destino y el nmero de la seal. Por tanto, estamos hablando de un
mecanismo de comunicacin directa. Cada seal tiene un efecto particular por defecto que por lo
general es matar al proceso en el proceso que las recibe. Sin embargo cada proceso puede declarar
un manejador de seales que redefina la accin por defecto para una seal determinada. Un
manejador de seales no es ms que una funcin que es ejecutada asncronamente cuando la seal
es recibida. En ese sentido las seales en POSIX puede interpretarse como una forma de
interrupcin por software.
Las seales fueron diseadas originalmente como un mecanismo para que el sistema operativo
notificara a los programas ciertos errores y sucesos crticos, no como un mecanismo de IPC. Por
ejemplo:
3-64
La seal SIGHUP es enviada a cada proceso iniciado desde una sesin de terminal cuando dicha
sesin termina.
La seal SIGINT es enviada al proceso que est enganchado a la consola cuando el usuario
pulsa el carcter de interrupcin frecuentemente la combinacin de teclas Control-C.
Sin embargo esto no evita que las seales puedan ser tiles como mecanismo de IPC. No en vano el
estndar POSIX incluye dos seales SIGUSR1 y SIGUSR2 especialmente indicadas para este uso.
Adems las seales son utilizadas frecuentemente como medio de control de los demonios35 del
sistema. Por ejemplo permiten que un administrador u otro proceso le indique a un demonio que
debe reinicializarse, empezar a realizar el trabajo para el que fue diseado o escribir su estado
interno en un sitio conocido del almacenamiento.
c) Sockets
Un socket es un punto final en una comunicacin bidireccional entre procesos. Para que una pareja
de procesos se pueda comunicar son necesarios dos sockets uno para cada proceso de manera que
cada uno de ellos representa un extremo de la conexin.
La API de sockets fue creada por la Universidad de Berkeley para ser la que abstrajera el acceso a la
familia de protocolos de Internet (TCP/IP) en el UNIX desarrollado por esa misma universidad. Sin
embargo rpidamente se convirti en el estndar de facto para la comunicacin en red, por lo que
todos los sistemas operativos modernos incluidos los sistemas POSIX y Microsoft Windows
tienen una implementacin de la misma.
Pese a sus orgenes, los sockets se disearon para ser independientes de la tecnologa de red
subyacente. Por ejemplo:
En las redes TCP/IP para crear un socket es necesario indicar la direccin IP y el nmero de
puerto en el que debe de escuchar o desde el que se debe conectar a otro socket. Mientras que
en el momento de establecer una conexin con ese otro socket, se debe indicar la direccin IP
y el nmero de puerto donde el socket debe estar escuchando. Esto es as porque la tecnologa
de red TCP/IP subyacente establece que cada mquina tiene una IP y que los procesos se
comunican a travs de los puertos en las mismas.
35 Un demonio es un proceso no interactivo que se ejecuta en segundo plano en vez de ser controlado directamente por
el usuario. Este tipo de programas se ejecutan de forma continua y proporcionan servicios especficos, como por
ejemplo es el caso de los servidores de correo electrnico, servidores de pginas Web o de bases de datos.
3-65
En los sistemas POSIX es habitual el uso de sockets de dominio UNIX para comunicar
procesos dentro de un mismo sistema. Estos no son ms que sockets locales identificados
mediante un nombre de archivo y que, por tanto, estn representados en el sistema de archivos.
Su principal utilidad estn en las aplicaciones que siguen el modelo cliente-servidor pero
donde no es interesante o seguro que el servicio est disponible a travs de la red. Por
ejemplo se suelen utilizar para conectar gestores de bases de datos con aplicaciones Web
servidas desde el mismo equipo.
Si comparamos los ejemplos anteriores, podemos observar que existen grandes diferencias en
cuanto a la tecnologa de comunicacin empleada cuando se trata de comunicar procesos en redes
TCP/IP o en un mismo equipo mediante sockets de dominio UNIX. Sin embargo para ambos casos
la API de sockets siempre es la misma.
Los sockets implementan buffering automtico y admiten tanto comunicacin sncrona como
asncrona, aunque el comportamiento final de la interfaz depende de la tecnologa de red utilizada.
3.3. Hilos
Hasta el momento el modelo de proceso que hemos descrito asume que tenemos un slo hilo de
ejecucin, es decir, que se ejecuta en la CPU una nica secuencia de instrucciones. Un proceso con
un hilo de ejecucin slo puede realizar una tarea a la vez. Por ejemplo, en un procesador de textos
con un slo hilo de ejecucin el usuario nunca podra escribir al mismo tiempo que se comprueba la
ortografa. Por eso muchos sistemas operativos modernos han extendido el concepto de proceso
proceso monohilo proceso multihilo
hilo hilo hilo

ficheros ficheros
pila pila pila

datos pila datos
registros registros registros

cdigo registros cdigo
Figura 3.7: Comparacin entre procesos monohilo y proceso multihilo.
3-66
3.3. Hilos Sistemas Operativos - 2014/2015
para permitir mltiples hilos de ejecucin en cada uno. Los procesos con varios hilos pueden
realizar varias tareas a la vez.
3.3.1. Introduccin
El hilo es la unidad bsica de uso de la CPU en los sistemas operativos multihilo. De los recursos
de un proceso es privado a cada hilo (vase la Figura 3.8):
El identificador del hilo lo identifica en el sistema de la misma manera que lo hace el

identificador de proceso con el proceso.
El contador de programa indica la direccin de la prxima instruccin del proceso que debe
ser ejecutada por la CPU.
Los registros de la CPU.
La pila contiene datos temporales como parmetros y direcciones de retorno de las funciones
y variables locales.
Sin embargo todos los hilos de un mismo proceso comparten (vase la Figura 3.8):
El cdigo del programa.
Otras secciones de datos, como el montn.
Y otros recursos del proceso como archivos abiertos y seales.
a) Beneficios
Muchos son los beneficios que aporta la programacin multihilo:
Respuesta. Una aplicacin multihilo interactiva puede continuar ejecutndose aunque parte de
la misma est bloqueada o realizando una operacin lenta, mejorando la respuesta al usuario
de la misma. Por ejemplo, un navegador Web multihilo puede gestionar la interaccin del
usuario a travs de un hilo mientras el contenido solicitado se descarga en otro hilo.
Comparticin de recursos. Por defecto los hilos comparten la memoria y los recursos del
proceso al que pertenecen. El compartir el cdigo es lo que permite a una aplicacin tener
varios hilos que realizan diferentes actividades dentro del mismo espacio de direcciones
Economa. Reservar memoria y otros recursos para la creacin de un proceso es costoso.
3-67
Puesto que los hilos comparten los recursos de los procesos a los que pertenecen es ms
econmico crearlos. Tambin es ms econmico el cambio de contexto entre ellos ya que hay
que guardar y recuperar menos informacin. Por ejemplo en Oracle/Sun Microsystems Solaris
crear un proceso es 30 veces ms lento que crear un hilo; y el cambio de contexto es 5 veces
ms lento.
Aprovechamiento de las arquitecturas multiprocesador. En esas arquitecturas diferentes

hilos pueden ejecutarse en paralelo en distintos procesadores. Por el contrario un proceso
monohilo slo se puede ejecutar en una CPU a la vez, independientemente de cuantas estn
disponibles para ejecutarlo.
b) Soporte multihilo
Las libreras de hilos proporcionan al programador la API para crear y gestionar los hilos de su
proceso. Hay dos formas fundamentales de implementar una librera de hilos:
La primera forma es implementar la librera enteramente en el espacio de usuario, sin

requerir el soporte del ncleo:
Los hilos as gestionados no existen para el ncleo. Slo existen en el espacio de usuario
dentro del proceso que los ha creado. Por ese motivo se los denomina hilos de usuario.
El cdigo y los datos de la librera residen en el espacio de usuario, por lo que invocar
una funcin de la misma se reduce a una simple llamada a una funcin, evitando el coste
de hacer llamadas al sistema.
La segunda forma es implementar la librera en el ncleo.
Los hilos as gestionados son soportados y gestionados por el ncleo, quien se encarga
de planificarlos en la CPU. Por ese motivo se los denomina hilos de ncleo.
El cdigo y los datos de la librera residen en el espacio del ncleo, por lo que invocar
una funcin de la misma requiere frecuentemente hacer una llamada al sistema.
En la actualidad en los diferentes sistemas operativos se pueden encontrar libreras de ambos tipos.
Por ejemplo, la librera de hilos del API Win32 es del segundo tipo mientras que la librera de hilos
POSIX Threads frecuentemente utilizada en los sistemas POSIX puede ser de ambos tipos,
dependiendo solamente del sistema donde se implemente36.
36 POSIX Threads se implementa en el ncleo en los sistemas Linux y en la mayor parte de los UNIX actuales.
3-68
3.3.2. Modelos multihilo

Las distintas formas de implementar los hilos comentadas anteriormente en espacio de usuario o
en el ncleo no son excluyentes ya que en un sistema operativo concreto se pueden implementar
ambas, una de las dos o ninguna esto ltimo en el caso de los sistemas operativos que no soportan
de ninguna forma mltiples hilos de ejecucin. As que en general debe existir una relacin entre
los hilos de usuario y los del ncleo. A continuacin veremos tres formas de establecer dicha
relacin.
a) Muchos a uno
En un sistema operativo cuyo ncleo no soporta mltiples hilos de ejecucin la nica posibilidad es
utilizar una librera de hilos implementada en el espacio de usuario. El planificador de dicha librera
se encarga de determinar que hilo de usuario se ejecuta en cada momento en el proceso, mientras
este es planificado en la CPU por el ncleo, obviamente elegido cuando le corresponda de entre
todos los procesos del sistema.
A efectos prcticos un proceso sin hilos se puede interpretar como un proceso con un nico
hilos de usuario
u u
u u
modo
usuario
modo
privilegiado
hilos de ncleo
Figura 3.8: Modelo muchos a uno.
3-69
hilo de ejecucin en el ncleo. Por eso se dice que en el modelo muchos a uno se mapean los
mltiples hilos de usuario de un proceso en el nico hilo de ncleo del mismo (vase la Figura 3.8).
Las principales caractersticas de este modelo son:
La gestin de hilos se hace con una librera en el espacio de usuario, por lo que puede ser
muy eficiente. Como hemos visto anteriormente la invocacin de las funciones de la librera se
hace por medio de simples llamadas a funciones.
El proceso entero se bloquea si un hilo hace una llamada al sistema que deba ser bloqueada.
Por ejemplo operaciones de E/S a archivos, esperar a que suceda un evento, etc.
Como slo un hilo de usuario puede ser asignado al hilo de ncleo, los hilos de un mismo
proceso no se pueden ejecutar en paralelo en sistemas multiprocesador. El planificador de la
librera de hilos es el encargado de determinar que hilo de usuario es asignado al nico hilo de
ncleo del proceso y este slo puede ejecutarse en una nica CPU al mismo tiempo.
El problema del bloqueo de procesos puede ser evitado sustituyendo las funciones de la librera de
sistema, de manera que las llamadas al sistema que se pueden bloquear sean sustituidas por
versiones con llamadas equivalentes pero no bloqueantes. Por ejemplo, las llamadas al sistema de
E/S se pueden reemplazar por llamadas de E/S asncrona, que retornan inmediatamente aunque la
operacin no haya sido completada. Despus de cada una de estas llamadas asncronas al sistema, la
librera del sistema invoca al planificador de la librera de hilos para que bloquee el hilo que ha
realizado la llamada y asigne el hilo de ncleo a un nuevo hilo de usuario. Obviamente el
planificador de la librera de hilos debe estar al tanto de cuando las operaciones asncronas son
completadas para poder volver a planificar los hilos de usuario bloqueados. Este procedimiento es a
todas luces bastante complejo y requiere versiones no bloqueantes de todas las llamadas al sistema,
as como modificar las funciones bloqueantes de la librera del sistema para implementar el
comportamiento descrito.
Ejemplos de implementaciones este modelo de hilos son la Green Threads, una de las
implementaciones de hilos para Solaris y Java, Stackless Python37 y GNU Portable Threads38. Estas
implementaciones son muy tiles en los sistemas monohilo, de cara a poder ofrecer cierto soporte
de hilos a las aplicaciones, pero tambin en los sistemas multihilo, ya que debido a su bajo coste en
37 Ms informacin de Stackless Python: http://www.stackless.com/

38 Ms informacin de GNU Pthreads: http://www.gnu.org/software/pth/.
3-70
hilos de usuario
u u u u
modo
usuario
modo
privilegiado
k k k k
hilos de ncleo
Figura 3.9: Modelo uno a uno.
recursos y a su alta eficiencia son ideales cuando la cantidad de hilos a crear el nivel de
concurrencia va a ser previsiblemente muy alta .
b) Uno a uno
Si el ncleo del sistema operativo soporta hilos de ejecucin, lo ms comn es que estos sean
visibles directamente en el espacio de usuario. Por lo tanto se dice que en el modelo uno a uno se
mapea cada hilo de usuario en exactamente un hilo de ncleo (vase la Figura 3.9).
Las principales caractersticas de este modelo son:
Permite a otro hilo del mismo proceso ejecutarse aun cuando un hilo hace una llamada al
sistema que debe bloquearse, ya que el ncleo se encarga de ponerlo en espera y planificar en
la CPU a otro de los hilos preparados para ejecutarse de entre todos los existentes en el
sistema.
Permite paralelismo en sistemas multiprocesador, ya que diferentes hilos pueden ser

planificados por el ncleo en distintos procesadores
Crear un hilo de usuario requiere crear el correspondiente hilo de ncleo. Debido a que la
3-71
hilos de usuario
u u
u u
modo
usuario
modo
privilegiado
k k k
hilos de ncleo
Figura 3.10: Muchos a muchos.
cantidad de memoria disponible para el ncleo suele estar limitada, muchos sistemas
restringen la cantidad mxima de hilos soportados.
Las gestin de los hilos se hace con una librera en el espacio de ncleo, lo que requiere
utilizar llamadas al sistema.
Este modelo se utilizar en la mayor parte de los sistemas operativos multihilo modernos. Linux,
Microsoft Windows 95/98/NT/2000/XP y superiores, y Solaris 9 y superiores, son ejemplos de
sistemas operativos que los utilizan.
c) Muchos a muchos
En teora debera ser posible aprovechar lo mejor de los dos modelos anteriores. Por eso en el
modelo muchos a muchos se mapean los hilos de usuario en un menor o igual nmero de hilos de
ncleo del proceso (vase la Figura 3.10). As los desarrolladores pueden utilizar la librera de hilos
en el espacio de usuario para crear tantos hilos como quieran. El planificador de la librera de hilos
se encarga de determinar que hilo de usuario es asignado a que hilo de ncleo. Mientras que el
planificador de la CPU asigna la CPU a alguno de los hilos de ncleo del sistema.
Los hilos de ncleo pueden ser ejecutados en paralelo en sistemas multiprocesador.
3-72
hilos de usuario
u u
u u u
modo
usuario
modo
privilegiado
k k k k
hilos de ncleo
Figura 3.11: Modelo de dos niveles.
Permite a otro hilo del mismo proceso ejecutarse cuando un hilo hace una llamada al sistema
que debe ser bloqueada, puesto que si un hilo de usuario realiza una llamada al sistema que
debe ser bloqueada, el correspondiente hilo de ncleo quedar bloqueado. Sin embargo, el
resto de los hilos de usuario pueden seguir ejecutndose en los otros hilos de ncleo.
Existe una variacin del modelo muchos a muchos donde, adems de hacer lo comentado
anteriormente, se permite que un hilo de usuario quede ligado a un nico hilo de ncleo. Esta
variacin se denomina en ocasiones modelo de dos niveles (vase la Figura 3.11) y es soportada en
sistemas operativos como Solaris 8 y anteriores, IRIX, HPUX y Tru64 UNIX.
Tanto en el modelo muchos a muchos como en el de dos niveles es necesario cierto grado de
coordinacin entre el ncleo y la librera de hilos del espacio de usuario. Dicha comunicacin tiene
como objetivo ajustar dinmicamente el nmero de hilos del ncleo para garantizar la mxima
eficiencia. Uno de los esquemas de comunicacin se denomina activacin del planificador y
consiste en que el ncleo informa a la librera de hilos en espacio de usuario del bloqueo de un hilo
de un proceso. Antes de dicha notificacin el ncleo se encarga de crear un nuevo hilo de ncleo en
el proceso, de manera que el planificador de la librera pueda encargarse de asignarle alguno de los
3-73
otros hilos de usuario. As es como se ajusta el nmero de hilos dinmicamente de manera que el
proceso nunca quede bloqueado.
Debido a la complejidad del mecanismo descrito anteriormente y a la dificultad de coordinar el

planificador de la librara de hilos con el de la CPU para obtener un rendimiento ptimo, sistemas
como Linux y Solaris a partir de la versin 9 han optado por el modelo uno a uno. Con el
objetivo de evitar las penalizaciones de dicho modelo, los desarrolladores de Linux han preferido
concentrar sus esfuerzos en conseguir un planificador de CPU ms eficiente, as como en reducir los
costes de la creacin de hilos de ncleo.
3.3.3. Sincronizacin
Hemos comentado anteriormente que los hilos comparten el espacio de direcciones del proceso al
que pertenecen. Al mismo tiempo distintos procesos pueden compartir regiones de la memoria con
el objeto de cooperar en las tareas que deben desempear. Ambas posibilidades introducen algunos
riesgos, puesto que el acceso concurrente a los datos compartidos puede ocasionar inconsistencias.
En este apartado vamos a discutir como se puede asegurar la ejecucin ordenada de hilos y/o
procesos cooperativos que comparten regiones de la memoria, con el fin de mantener la
consistencia de los datos.
a) El problema de las secciones crticas

Llamamos condicin de carrera a la situacin donde varios procesos o hilos pueden acceder y
manipular los mismos datos concurrentemente, y donde el resultado de la ejecucin depende del
orden particular en el que tienen lugar dichos accesos. Estas situaciones ocurren frecuentemente en
los sistemas operativos puesto que diferentes componentes del mismo manipulan los mismos
recursos interfiriendo unos con otros. Para evitar que estas situaciones lleven a la corrupcin de los
datos y a cadas del sistemas debemos asegurarnos que slo un procesos o hilo en cada momento
puede manipular esos recursos compartidos. Por tanto necesitamos algn tipo de mecanismo de
sincronizacin.
Una forma de controlar el acceso a los recursos compartidos es que cada proceso o hilo pueda tener
un tipo de secciones de cdigo denominadas seccin crtica dnde se puedan cambiar las variables
compartidas, actualizar tablas o listas, escribir en un archivo, etc. El acceso a las secciones crticas
es controlado de manera que cuando un proceso se est ejecutando en su seccin de este tipo
3-74
ningn otro pueda hacerlo en la suya. S eso ocurre, se dice que la ejecucin es mutuamente
exclusiva en el tiempo.
Para ilustrarlo supongamos que dos procesos comparten una regin de la memoria que contiene
un vector de elementos y un contador con el nmero de elementos del vector.
El primer proceso realiza varias tareas que no entraremos a describir. Sin embargo como
resultado de esas tareas en ocasiones aade un elemento a un vector e incrementa un
contador que indica el nmero de elementos en el vector. Es decir, el primer proceso acta
como productor. A continuacin mostramos una porcin de la subrutina del productor.
while (count == VECTOR_SIZE);
// aadir un elemento al vector

++count;
vector[in] = item;
in = (in + 1) % VECTOR_SIZE;
El segundo proceso tambin realiza varias tareas que no describiremos. Pero para realizar
esas tareas en ocasiones debe tomar un elemento del vector compartido y decrementar el
contador. Es decir, el segundo proceso acta como consumidor. A continuacin
mostramos una porcin de la subrutina del consumidor.
while (count == 0);
// quitar un elemento del vector

--count;
item = vector[out];
out = (out + 1) % VECTOR_SIZE;
Aunque las subrutinas del productor y del consumidor son correctas cuando se ejecutan por
separado, no funcionan adecuadamente cuando se ejecutan concurrentemente. El motivo es que
los distintos procesos o hilos comparten la variable count. Supongamos que el valor de dicha
variable es 5 actualmente y que el productor y el consumidor ejecutan concurrentemente la
sentencia ++count y --count respectivamente. Si hacemos la traza de la ejecucin de esas
sentencias, veremos que el valor de la variable count finalmente podra ser 4, 5 o 6. Pero el
nico resultado correcto es 5, que es el que obtendramos si ejecutamos las sentencias
secuencialmente.
3-75
Como ejemplo mostraremos como el resultado de la sentencia ++count puede ser incorrecto. En
este punto es importante destacar que la sentencia ++count no tiene porque tener una
instruccin en lenguaje mquina equivalente, por lo que podra ser implementada de la siguiente
manera:
registro1 = count;
registro1 = registro1 + 1;
count = registro1;
Donde registro1 es un registro de la CPU. De forma parecida la sentencia --count puede ser
implementada de la siguiente manera:
registro2 = count;
registro2 = registro2 - 1;
count = registro2;
Donde nuevamente registro2 es un registro de la CPU. Realmente aunque registro1 y registro2

pueden ser el mismo registro fsico, el contenido de los registros se guarda y se recupera durante
los cambios de contexto, por lo que cada hilo ve sus propios valores y no los del otro.
La ejecucin concurrente de las sentencias ++count y --count es similar a la ejecucin

secuencial, pero las instrucciones de lenguaje mquina de ambas sentencias pueden ser
entrelazadas en algn orden aleatorio. No debemos olvidar que la ejecucin concurrente se
puede dar bien porque tenemos una sistema multiprocesador, donde ambos hilos se ejecutan a la
vez, o bien porque tenemos un sistema monoprocesador, donde uno de los hilos puede ser
interrumpido en cualquier momento (vase el apartado 3.4.1) para asignar la CPU al otro. Un
posible entrelazado de las instrucciones en lenguaje mquina podra ser:
S0: productor: registro1 = count {registro1 = 5}

S1: productor: registro1 = registro1 + 1 {registro1 = 6}
S2: consumidor: registro2 = count {registro2 = 5}
S3: consumidor: registro2 = registro2 1 {registro2 = 4}
S4: productor: count = registro1 {count = 6}
S5: consumidor: count = registro2 {count = 4}
En este caso llegamos al valor incorrecto de count = 4, indicando que hay 4 elementos en el
3-76
vector cuando realmente hay 5. Si invertimos el orden de las sentencias S4 y S5, obtendramos el
valor incorrecto count = 6. Como se puede apreciar, hemos llevado a estos valores incorrectos
porque hemos permitido la manipulacin concurrente de la variable count.
b) Semforos
Para que las operaciones sobre los datos compartidos se ejecuten de manera ordenada, el sistema
operativo debe proporcionar a los programadores de aplicaciones objetos abstractos cuya
implementacin utilice las caractersticas que la CPU ofrece para tal fin. Ese es el caso de los
semforos.
Los semforos son un tipo de objetos que nos permite controlar el acceso a una seccin crtica, por
medio de dos primitivas: acquire() y release().
semaphore S;
acquire (S); // Entrar en la seccin crtica
... // Seccin crtica
release (S); // Salir de la seccin crtica
El semforo S debe ser compartido entre los hilos que tengan secciones crticas cuya ejecucin
deber ser mutuamente exclusiva. A continuacin describimos el mecanismo de funcionamiento.
1. Un semforo es fundamentalmente un contador con el nmero mximo de hilos o procesos

en sistemas operativos monohilo que pueden estar dentro de la seccin crtica en un
momento dado. Este contador puede ser inicializado al definir el semforo. Los semforos con
contadores inicializados a 1 se denominan mutex o semforos binarios.
2. El contador es decrementado por acquire() cada vez que un hilo entra en la seccin crtica.
3. El contador es incrementado por release() cada vez que un hilo sale de la seccin crtica.
4. Cuando el contador est a 0, los hilos que ejecuten acquire() deben esperar hasta que otro
hilo salga, puesto que no se puede seguir decrementando el contador. El hilo saliente ejecuta
release() que incrementa el contador, permitiendo que uno de los hilos a la espera en
acquire() lo decremente y entre en la seccin crtica.
Como hemos comentado anteriormente la implementacin de acquire() y release() debe
3-77
realizarse utilizando las caractersticas proporcionadas por el hardware, de forma que el incremento,
decremento y comparacin del contador se pueda realizar de forma atmica39.
Por otro lado existen dos alternativas desde el punto de vista de la forma en la que se implementa la
espera de los hilos dentro de acquire():
El hilo puede cambiar su estado a esperado y moverse a una cola de espera asociada al
semforo. Entonces el planificador de la CPU escoger a otro proceso para ser ejecutado.
El hilo puede iterar sobre el contador a la espera de que sea incrementado. Este tipo de
espera ocupada slo se utiliza en el caso de esperas previsiblemente cortas, puesto que se
desperdician ciclos de CPU que otro hilo podra utilizar de forma ms productiva. Por eso,
para evitar que las esperas ocupadas sean demasiado largas, los sistema operativos nunca
expropian (vase el apartado 3.4.1) hilos que se estn ejecutando dentro de secciones crticas
controladas por semforos con este tipo de espera.
A estos semforos tambin se los denomina spinlocks. Los spinlocks son utilizados frecuentemente
para proteger las estructuras del ncleo de los sistemas multiprocesador, donde un hilo itera en un
procesador mientras que otro hilo ejecuta la seccin crtica en otro procesador, especialmente
cuando las tareas a realizar dentro de dicha seccin crtica requiere poco tiempo. Adems son muy
eficientes al no obligar a hacer cambios de contexto entre hilos, lo que podra necesitar un tiempo
considerable.
3.3.4. Otras consideraciones sobre los hilos
a) Datos especficos de hilo

Los hilos de un mismo proceso comparten los datos del mismo, siendo este uno de los principales
beneficios de la programacin multihilo. Por ejemplo todas las variables globales del programa son
compartidas por todos los hilos. Sin embargo en algunas ocasiones puede interesar definir ciertos
datos como privados a cada hilo. A esos datos se los denomina TSD o thread-specific data y son
soportados por muchas libreras de hilos, incluyendo el API Win32 y Pthreads, aunque no es comn
que sean soportados directamente por los distintos lenguajes de programacin.
39 Una operacin o conjunto de operaciones es atmica o no interrumpible si de cara al resto del sistema parece que la
operacin ocurre de forma instantnea e indivisble.
3-78
b) Cancelacin de hilos
La cancelacin es la operacin de terminar un hilo antes de que termine su trabajo. Por ejemplo,
en un navegador web un hilo se puede encargar de la interfaz de usuario mientras otros hilos se
encargan de descargar las pginas y las imgenes de la misma. Si el usuario pulsa el botn
cancelar es necesario que todos los hilos que intervienen en la descarga sean cancelados. Esto
puede ocurrir de dos maneras:
En la cancelacin asncrona un hilo puede terminar inmediatamente la ejecucin de otro.

Esto puede causar problemas al no liberarse los recursos reservados al proceso por parte del
hilo no se cierran los archivos abiertos, no se libera la memoria, etc.. Adems si el hilo que
termina estaba modificando estructuras de datos que comparta con otros hilos, estas podran
quedar inconsistentes.
En la cancelacin en diferido el hilo comprueba peridicamente cuando debe terminar. Esto

da al hilo una oportunidad de terminarse as mismo de forma ordenada y en un punto dnde es
seguro hacerlo. En la terminologa de Pthreads a estos puntos se los denomina puntos de
cancelacin o cancellation points y muchas llamadas al sistema lo son por si mismas.
c) Funciones reentrantes y seguras en hilos

A la hora de utilizar una librera en un programa multihilo es necesario que tengamos en cuenta los
conceptos de reentrante y de seguridad de hilos:
Una funcin40 es reentrante si puede ser interrumpida en medio de su ejecucin y mientras

espera puede volver a ser llamada con total seguridad. Obviamente las funciones recursivas
deben ser reentrantes para poder llamarse a s mismas una y otra vez con total seguridad.
En el contexto de la programacin multihilo ocurre una reentrada cuando, durante la ejecucin
de una funcin por parte de un hilo, este es interrupido por el sistema operativo para planificar
posteriormente a otro del mismo proceso que invoca la misma funcin. En general una funcin
es reentrante si:
No modifica variables estticas o globales. Si lo hiciera slo puede hacerlo mediante

operaciones leer-modificar-escribir que sean ininterrumpibles es decir, atmicas .
No modifica su propio cdigo y no llama a otras funciones que no sean reentrantes.
40 Al usar el trmino funcin nos estamos refiriendo a cualquier procedimiento, funcin, mtodo, subprograma,
subrutina o rutina del programa.
3-79
Una funcin es segura en hilos o thread-safe si al manipular estructuras compartidas de

datos lo hace de tal manera que se garantiza la ejecucin segura de la misma por mltiples
hilos al mismo tiempo. Obviamente estamos hablando de un problema de secciones crticas,
por lo que se resuelven sincronizando el acceso a estos datos mediante el uso de semforos,
mutex u otros recursos similares ofrecidos por el sistema operativo.
En ocasiones ambos conceptos se confunden porque es bastante comn que el cdigo reentrante
tambin sea seguro en hilos. Sin embargo es posible crear cdigo reentrante que no sea seguro en
hilos y viceversa. Por ejemplo, una funcin que manipule datos especficos de hilo seguramente no
ser reentrante aunque si segura en hilos. Mientras que una funcin que slo utilice variables locales
y que no invoque a otras funciones seguramente ser reentrante y segura en hilos.
d) Las llamadas al sistema fork( ) y exec( ) en procesos multihilo

Qu debe ocurrir si un hilo de un proceso multihilo ejecuta la llamada fork()? el nuevo proceso
debe duplicar todos los hilos? o debe tener un nico hilo?. Como hemos comentado anteriormente
la llamada al sistema exec() sustituye el programa en ejecucin con el programa indicado. Esto
incluye la destruccin de todos los hilos del programa original, por lo que duplicar los hilos en el
fork() parece algo innecesario.
El estndar POSIX establece que si se utiliza fork() en un programa multihilo, el nuevo proceso
debe ser creado con un slo hilo, que ser una rplica del que hizo la llamada, as como un
duplicado completo del espacio de direcciones del proceso. Sin embargo algunos sistemas UNIX
tienen una segunda llamada no estndar, denominada forkall(), capaz de duplicar todos los hilos
del proceso padre. Obviamente slo resulta conveniente emplearla si no se va a utilizar la llamada
exec().
e) Manejo de seales en procesos multihilo

Una seal se utiliza en UNIX para informar a un proceso cuando un evento a ocurrido. Existen dos
tipos de seales:
Las seales sncronas se deben a alguna accin del propio proceso. Ejemplos de seales de
este tipo son las originadas por accesos ilegales a memoria o divisiones por 0. Las seales
sncronas son enviadas al mismo proceso que las origina.
3-80
Las seales asncronas son debidas a procesos externos. Un ejemplo de este tipo de seales es
la terminacin de procesos con teclas especiales como Control-C.
Las seales que llegan a un proceso pueden ser interceptadas por un manejador definido por el
programador. En caso de que ste no haya sido definido, se utiliza un manejador por defecto cuya
accin depende del tipo de evento.
La pregunta es: cuando se tienen mltiples hilos a cul de ellos deben llegar las seales para ser
manejadas? Obviamente las seales sncronas, por su propia naturaleza, deben ser enviadas al hilo
que las genera. Pero con las seales asncronas la cosa no est tan clara. Dependiendo del caso
algunas deben ser capturadas por un slo hilo, mientras que otras como aquellas que ordenan
terminar el proceso deben ser enviadas a todos.
La mayor parte de los UNIX multihilo permiten especificar que seales acepta cada hilo y cuales
no. Por lo tanto una seal asncrona slo ser entregada a aquellos hilos que no la bloquean. Puesto
que generalmente las seales necesitan ser manejadas una sola vez, normalmente slo llegan al
primer hilo al que se le asigna la CPU y que no las est bloqueando.
3.4. Planificacin de la CPU

El planificador de la CPU o planificador de corto plazo selecciona de la cola de preparados el
siguiente proceso o hilo del ncleo a ejecutar. En dicha cola suelen estar los PCB de todos los
procesos que esperan una oportunidad para usar la CPU. Aunque se suelen pensar en la cola de
preparados como una cola FIFO, como veremos ms adelante, no tiene por qu ser as. En cualquier
caso, sea cual sea el algoritmo de planificacin utilizado, ste no debe ser excesivamente lento ya
que es ejecutado con mucha frecuencia; aproximadamente una vez cada 100 milisegundos.
Aunque a lo largo de este tema hablaremos de planificar procesos en la CPU, en los sistemas
operativos multihilo se planifican los hilos de ncleo y no los procesos. Por ello todo lo que
comentemos a partir de ahora se aplica de la misma manera a los hilos de ncleo, en aquellos
sistemas operativos que los soportan.
3.4.1. Planificacin expropiativa

Las decisiones de planificacin se deben tomar necesariamente en los siguientes casos:
3-81
1. Cuando un proceso pasa de ejecutando a esperando. Por ejemplo, por solicitar una operacin
de E/S, esperar a que un hijo termine, etc.
2. Cuando un proceso termina.
Cuando el planificador es invocado en alguno de los casos anteriores decimos que tenemos un
sistema operativo con planificacin cooperativa o no expropiativa.
En la planificacin cooperativa cuando la CPU es asignada a un proceso, dicho proceso la acapara

hasta terminar o pasar al estado de esperando. La planificacin cooperativa no requiere de ningn
hardware especial, por lo que en algunas plataformas puede ser la nica opcin. Por ello estaba
presente en los sistemas operativos ms antiguos, como Microsoft Windows 3.1 y Mac OS.
Sin embargo, las decisiones de planificacin tambin pueden ser tomadas en otros casos:
1. Cuando ocurre una interrupcin del temporizador.
2. Cuando un proceso pasa de esperando a preparado. Por ejemplo porque para un proceso ha
terminado la operacin de E/S por la que estaba esperando.
Cuando el planificador es invocado en los cuatro casos decimos que tenemos planificacin
expropiativa o apropiativa. La planificacin expropiativa si requiere de un soporte adecuado por
parte del hardware, por lo que se utiliza en la mayor parte de los sistemas operativos modernos.
Ejemplos de estos sistemas son Microsoft Windows 9x/NT/2000/XP, Mac OS X, GNU/Linux y los
UNIX modernos.
La utilizacin de un planificador expropiativo introduce algunas dificultades adicionales:
Puesto que un proceso puede ser expropiado en cualquier momento, el sistema operativo debe
proporcionar mecanismos de sincronizacin (vase el apartado 3.3.3) para coordinar el acceso
a datos compartidos que podran estar siendo modificados por el proceso que abandona la
CPU.
Qu pasa si un proceso va a ser expropiado cuando se est ejecutando una llamada al

sistema? No debemos olvidar que generalmente dentro del ncleo se manipulan datos
importantes que deben permanecer consistentes en todo momento. Para resolver esta cuestin
los diseadores pueden optar por impedir la expropiacin dentro del ncleo. Es decir, antes de
hacer el cambio de contexto, que sacara al proceso de la CPU, se espera a que la llamada se
complete o se bloquee pasando el proceso al estado de esperando. Esto permite ncleos
simples y garantiza que las estructuras del mismo permanezcan consistentes, pero es un
3-82
3.4. Planificacin de la CPU Sistemas Operativos - 2014/2015
modelo pobre en sistemas de tiempo real o multiprocesador. Exploraremos otras soluciones

ms adelante (vase el apartado 3.4.6).
3.4.2. El asignador
El asignador es el componente que da el control de la CPU al proceso seleccionado por el
planificador de corto plazo. Esta tarea implica realizar las siguientes funciones:
Cambiar el contexto.
Cambiar al modo usuario.
Saltar al punto adecuado del programa para continuar con el proceso.
Puesto que el asignador es invocado para cada conmutacin entre procesos, es necesario que el
tiempo que tarda en detener un proceso e iniciar otro sea lo ms corto posible. Al tiempo que
transcurre desde que un proceso es escogido para ser planificado en la CPU hasta que es asignado
a la misma se lo denomina latencia de asignacin.
3.4.3. Criterios de planificacin

Los diferentes algoritmos de planificacin de la CPU tienen diversas propiedades que pueden
favorecer a una clase de procesos respecto a otra. Por ello es interesante disponer de algn criterio
para poder comparar dichos algoritmos y determinar cual es el mejor. Se han sugerido muchos
criterios para comparar los algoritmos de planificacin de CPU pero la eleccin de uno u otro puede
crear una diferencia sustancial a la hora de juzgar cual es el mejor. A continuacin presentamos los
criterios ms comunes.
a) Criterios a maximizar
Uso de CPU: Un buen planificador debera mantener la CPU lo ms ocupada posible. El uso
de CPU es la proporcin de tiempo que se usa la CPU en un periodo de tiempo determinado.
Se suele indicar en tanto por cierto.
tiempoque laCPU permanece ocupada

uso de CPU = % (1)
tiempo durante el que setoma la medida
Tasa de procesamiento: Cuando la CPU est ocupada es porque el trabajo se est haciendo.
3-83
Por tanto una buena medida del volumen de trabajo realizado puede ser el nmero de tareas o
procesos terminados por unidad de tiempo. A dicha magnitud es a la que denominamos como
tasa de procesamiento.
numero de procesos terminados

tasa de procesamiento= procesos/s (2)
tiempo durante el que se toma lamedida
b) Criterios a minimizar
Tiempo de ejecucin: Es el intervalo de tiempo que transcurre desde que el proceso es
cargado hasta que termina.
Tiempo de espera: Es la suma de tiempos que el proceso permanece a la espera en la cola de

preparados. Evidentemente esta medida de tiempo no incluye el tiempo de espera debido a las
operaciones de E/S.
Tiempo de respuesta: Es el intervalo de tiempo que transcurre desde que se le lanza un

evento se pulsa una tecla, se hace clic con el ratn o llega un paquete por la interfaz de red
hasta que se produce la primera respuesta del proceso. Evidentemente esto mide el tiempo
que se tarda en responder y no el tiempo de E/S, mientras que el tiempo de ejecucin s suele
estar limitado por la velocidad de los dispositivos E/S.
c) Eleccin del criterio adecuado

En funcin del tipo de sistema o de la clase de trabajos que se van a ejecutar puede ser conveniente
medir la eficiencia del sistema usando un criterio u otro. Esto a su vez beneficiar a unos algoritmos
de planificacin frente a otros, indicndonos cules son los ms eficientes para nuestra clase de
trabajos en particular.
En general podemos encontrar dos clases de trabajos para los que puede ser necesario evaluar la
eficiencia del sistema de manera diferente.:
En los sistemas interactivos ya sean sistemas de escritorio o mainframes de tiempo

compartido los procesos pasan la mayor parte del tiempo esperando algn tipo de entrada por
parte de los usuarios. En este tipo de sistemas el tiempo de ejecucin no suele ser el mejor
criterio para determinar la bondad de un algoritmo de planificacin, ya que vendr
determinado en gran medida por la velocidad de la entrada de los usuarios. Por el contrario se
espera que el sistema reaccione lo antes posible a las rdenes recibidas, lo que hace que el
3-84
tiempo de respuesta se el criterio ms adecuado para evaluar al planificador de la CPU.

Adems el tiempo de respuesta se reduce generalmente cuando el tiempo que pasan los
procesos interactivos en la cola de preparados tambin lo hace tras haber sido puestos ah por
la ocurrencia de algn evento por lo que tambin puede ser una buena idea utilizar como
criterio el tiempo de espera. Esta seleccin de criterios no slo es adecuada para los sistemas
interactivos, ya que existen muchos otros casos donde es interesante seleccionar un
planificador de la CPU que minimice el tiempo de respuesta. Esto por ejemplo ocurre con
algunos servicios en red como: sistemas de mensajera instantnea, chats, servidores de
videojuegos, etc.
Por el contrario en los mainframes de procesamiento por lotes y multiprogramados, en los

superordenadores que realizan complejas simulaciones fsicas y en los grandes centros de
datos de proveedores de Internet como Google, lo de menos es el tiempo de respuesta y lo
realmente importante es realizar cada tarea en el menor tiempo posible. Por eso en ese tipo de
sistemas es aconsejable utilizar criterios tales como el tiempo de ejecucin o la tasa de
procesamiento.
Obviamente estos criterios varan de un proceso a otro, por lo que normalmente lo que se busca es
optimizar los valores promedios en el sistema. Sin embargo no debemos olvidar que en muchos
casos puede ser ms conveniente optimizar el mximo y mnimo de dichos valores antes que el
promedio. Por ejemplo, en los sistemas interactivos es ms importante minimizar la varianza en el
tiempo de respuesta que el tiempo de respuesta promedio, puesto que para los usuarios un sistema
con un tiempo de respuesta predecible es ms deseable que uno muy rpido en promedio pero con
una varianza muy alta.
3.4.4. Ciclo de rfagas de CPU y de E/S

El xito de la planificacin de CPU depende en gran medida de la siguiente propiedad que podemos
observar en los procesos: La ejecucin de un proceso consiste de ciclos de CPU y esperas de E/S,
de forma que alternan entre estos dos estados. La ejecucin empieza con una rfaga de CPU,
seguida por una rfaga de E/S, que a su vez es seguida por otra de CPU y as sucesivamente.
Finalmente la ltima rfaga de CPU finaliza con una llamada al sistema generalmente exit()
para terminar la ejecucin del proceso.
3-85
duracin de la rfaga
Figura 3.12: Histograma de los tiempos de las rfagas de CPU.
La curva que relaciona la frecuencia de las rfagas de CPU con la duracin de las mismas tiende a
ser exponencial o hiper-exponencial (vase la Figura 3.12) aunque vara enormemente entre
procesos y sistemas informticos distintos. Esto significa que los procesos se pueden clasificar entre
aquellos que presentan un gran nmero de rfagas de CPU cortas o aquellos con un pequeo
nmero de rfagas de CPU largas. Concretamente:
Decimos que un proceso es limitado por la E/S cuando presenta muchas rfagas de CPU
cortas, debido a que si es as pasa la mayor parte del tiempo esperando por la E/S.
Decimos que un proceso est limitado por la CPU cuando presenta pocas rfagas de CPU
largas, debido a que si es as hace un uso intensivo de la misma y a penas pasa tiempo
esperando por la E/S.
Esta distincin entre tipos de procesos puede ser importante en la seleccin de un algoritmo de
planificacin de CPU adecuado. En general:
El algoritmo escogido debe favorecer planificndolos antes a los procesos limitados por la
E/S, evitando as que los procesos limitados por la CPU que son los que tienden a usarla ms
tiempo la acaparen. Si eso ocurriera, los procesos limitados por la E/S se acumularan en la
cola de preparados, dejando vacas las colas de dispositivos. A este fenmeno tan negativo que
provoca una infrautilizacin de los dispositivos de E/S se lo denomina efecto convoy.
Adems planificar primero a los procesos limitados por la E/S tiene dos efectos muy positivos:
3-86
Los procesos interactivos son generalmente procesos limitados por la E/S, por lo que
planificarlos primero hace que mejore el tiempo de respuesta.
Generalmente el tiempo de espera promedio se reduce cuando se planifican primero los

procesos con rfagas de CPU cortas41, Segn las definiciones anteriores, estos procesos
son precisamente los limitados por la E/S.
3.4.5. Planificacin
Hasta el momento hemos considerado la cola de preparados como una estructura donde los procesos
que estn preparados para ser ejecutados se ordenan y se escogen segn el criterio del algoritmo de
planificacin. Aunque a lo largo de todo el tema 3 se puede haber intuido que dicha cola es de tipo
FIFO lo que se conoce como algoritmo de planificacin FCFS o First Come, First Served ya al
principio del apartado 3.4 indicamos que no tiene porqu ser as pues existen muchos otros
algoritmos SJF o Shortest-Job First, SRTF o Shortest-Remaing-Time First, RR o Round-Robin,
por prioridades, etc. que pueden ser preferibles en funcin del criterio que utilicemos para evaluar
la eficiencia de los mismos.
Sin embargo en los sistemas operativos modernos realmente las cosas son un poco ms complejas
ya que generalmente se utiliza algn tipo de planificacin con colas multinivel. En este tipo de
planificacin no existe una nica cola de preparados sobre la que se utiliza un nico algoritmo de
planificacin sino que:
La cola de preparados se divide en varias colas separadas y los procesos son asignados a
alguna de dichas colas en base a caractersticas de los mismos.
Cada cola puede tener un algoritmo de planificacin de la CPU distinto. Es decir, alguno de
los que hemos mencionado anteriormente y que se estudiarn en las clases de problemas.
Mediante un algoritmo determinado se debe seleccionar la cola que debe escoger al siguiente
proceso a ejecutar.
Precisamente una cuestin interesante es la indicada en ste ltimo punto cmo seleccionar la cola
que debe escoger al siguiente proceso que debe ser ejecutado?.
41 En la literatura sobre algoritmos de planificacin de la CPU se indica que SJF (Shortest-Job First) y SRTF
(Shortest-Remaing-Time First) son los ptimos respecto al tiempo de espera promedio precisamente porque siempre
escogen al proceso con la rfaga de CPU ms corta de entre los que esperan en la cola de preparados.
3-87
0
procesos del sistema
1
procesos interactivos
2
procesos de edicin interactivos
3
procesos por lotes
4
procesos de estudiantes
Figura 3.13: Planificacin con colas multinivel.
a) Prioridad fija
Aunque existen muchas maneras de clasificar los procesos entre las diferentes colas, lo ms comn
en los sistemas operativos modernos es hacerlo en base a la prioridad de los procesos (vase la
Figura 3.13):
A cada proceso se le asigna una prioridad.
En la cola de preparados hay una cola para cada nivel de prioridad.
Los procesos, al entrar en la cola de preparados, son insertados en aquella cola que coincide
con su prioridad.
El planificador escoge primero siempre la cola de prioridad ms alta que no est vaca.
Definicin de las prioridades

Las prioridades se suelen indicar con nmeros enteros en un rango fijo. Por ejemplo [0-7], [0-31],
[0-139] o [0-4095]. En algunos sistemas operativos los nmeros ms grandes representan mayor
prioridad, mientras que en otros son los procesos con nmeros ms pequeos los que se planifican
primero. En ste curso utilizaremos la convencin de que a menor valor mayor prioridad.
En los sistemas con prioridad fija:
Una vez se asigna una prioridad a un proceso sta nunca cambia.
Las prioridades normalmente vienen determinadas por criterios ajenos al sistema operativo.
3-88
Por ejemplo: la importancia del proceso, la cantidad de dinero pagada para el uso del sistema u
otros factores polticos. A este tipo de prioridades se las denomina definidas externamente.
Planificacin expropiativa o cooperativa

La planificacin con prioridades puede ser expropiativa o cooperativa. En el caso expropiativo
cuando un proceso llega a la cola de preparados su prioridad es comparada con la del proceso en
ejecucin, de manera que el segundo es expulsado si la prioridad del primero es superior a la suya.
Obviamente en la planificacin cooperativa los nuevos procesos simplemente son insertados en la
cola que les corresponde en base a su prioridad, independientemente de si tienen o no mayor
prioridad que el que se est ejecutando.
Planificacin entre procesos con la misma prioridad

Cada cola en cada nivel de prioridad puede tener cualquier algoritmo de planificacin de CPU, lo
que virtualmente significa que el abanico de posibilidad es muy amplio. Sin embargo lo ms comn
es que los diseadores del sistema opten por utilizar o bien el planificador FCFS o bien el RR42.
En la planificacin FCFS (First Come, First Served) o primero que llega, primero servido la cola es
FIFO:
Los procesos que llegan se colocan al final de la cola que les corresponde.
El proceso asignado a la CPU se coge siempre del principio de la cola seleccionada.
El algoritmo RR (Round-Robin) es similar al FCFS pero utilizando el temporizador para expropiar

la CPU a los procesos a intervalos regulares, alternando as entre ellos de manera que se da a todos
los procesos la oportunidad de ejecutarse. Como se puede intuir, fue diseado para los sistemas de
tiempo compartido, siendo ampliamente utilizado en cualquier sistema operativo de propsito
general moderno.
El algoritmo RR requiere los siguientes elementos:
Se define una ventana de tiempo o cuanto, generalmente entre 10 y 100 ms.
42 Los algoritmos FCFS y RR se pueden combinar de mltiples maneras. En algunos sistemas todas las colas son o
bien FCFS o bien RR, mientras que en otros unas colas pueden ser de un tipo y otras del otro. Por ejemplo, en el
ncleo Linux las prioridades ms altas las etiquetadas como de tiempo real tienen tanto una cola FCFS como una
cola RR. En cada prioridad primero se planifican los procesos de la cola FCFS y despus lo de la cola RR.
3-89
La cola RR se define como una cola circular dnde el planificador asigna la CPU a cada
proceso en intervalos de tiempo de hasta un cuanto.
Cuando se utilizar la planificacin RR el tamao del cuanto es un factor clave en la eficiencia del
planificador:
Cuando se reduce el tiempo del cuanto, el tiempo de respuesta y el tiempo de espera promedio
tienden a mejorar. Sin embargo el nmero de cambios de contexto ser mayor, por lo que la
ejecucin de los procesos ser mas lenta. Adems es importante tener en cuenta que interesa
que el tiempo del cuanto sea mucho mayor que el tiempo del cambio de contexto; pues si por
ejemplo el tiempo del cambio de contexto es un 10% del tiempo del cuanto, entonces
alrededor del 10% de CPU se perdera en cambios de contexto.
Cuando se incrementa el tiempo del cuanto, el tiempo de espera promedio se incrementa dado
que entonces el RR tiende a comportarse como un FCFS, que suele tener grandes tiempos de
espera promedio. Adems se puede observar experimentalmente que el tiempo de ejecucin
promedio generalmente mejora cuantos ms procesos terminan su prxima rfaga de CPU
dentro del tiempo del cuanto43. Por lo tanto nos interesan un cuanto grande para que ms
procesos terminen su siguiente rfaga dentro del mismo.
La regla general que siguen los diseadores es intentar que el 80% de las rfagas de CPU sean
menores que el tiempo de cuanto. Se busca as equilibrar los criterios anteriores, evitando que el
tiempo de cuanto sea demasiado grande o demasiado corto44.
Muerte por inanicin y otros inconvenientes

El principal problema de este tipo de planificacin es el bloqueo indefinido o muerte por
inanicin, puesto que el algoritmo puede dejar a los procesos de baja prioridad esperando
indefinidamente si hay un conjunto de procesos de mayor prioridad demandando CPU
continuamente.
Adems, como vimos en el apartado 3.4.4, es conveniente favorecer a los procesos limitados por la
E/S frente a los procesos limitados por la CPU para evitar el efecto convoy y para mejorar los
43 Por ejemplo, dados tres procesos con una duracin cada uno de ellos de 10 unidades de tiempo y cuanto igual a 1, el
tiempo de ejecucin promedio ser de 29 unidades. Sin embargo si el cuanto de tiempo fuera 10, el tiempo de
ejecucin promedio caera a 20 unidades de tiempo.
44 De manera prctica actualmente se utilizan tiempos de cuanto de entre 10 y 100 ms. Estos tiempos son mucho
mayores que los tiempos de cambios de contexto, que generalmente son inferiores a 10s.
3-90
tiempos tanto de espera como de respuesta promedio. Lamentablemente este tipo de planificacin
con prioridad fija no es capaz de hacerlo ya que la prioridad de los procesos viene determinada
exclusivamente por criterios externos al funcionamiento del sistema operativo.
b) Prioridad dinmica
La mayor parte de los sistemas operativos modernos de propsito general 45 solucionan los
inconvenientes de la planificacin con prioridad fija permitiendo que la prioridad de los procesos
se ajuste dinmicamente bajo su propio criterio:
Por ejemplo, una solucin al problema de la muerte por inanicin es utilizar un mecanismo de
envejecimiento que aumente gradualmente la prioridad de los procesos mientras estn
esperando en la cola de preparados por ejemplo 1 unidad de prioridad cada 15 minutos. De
esta manera los procesos de baja prioridad tarde o temprano tendrn oportunidad de ejecutarse.
Con este mecanismo una vez consiguen ejecutarse, se les restablece su prioridad original.
Para favorecer en la planificacin a los procesos limitados por la E/S el sistema puede aadir
o quitar prioridad a los procesos, respecto a su prioridad fija, en funcin de medidas internas
del sistema operativo. Por ejemplo se puede tomar en consideracin: lmites de tiempo,
necesidades de memoria, nmero de archivos abiertos, la proporcin entre el tiempo de rfaga
de E/S promedio y el de rfaga de CPU promedio del proceso, etc. Obviamente el objetivo
suele ser mejorar el rendimiento del sistema priorizando unos procesos respecto a otros.
El resultado de estas polticas es que la prioridad que finalmente utiliza el sistema operativo para
planificar los procesos en un valor calculado dinmicamente a partir de intereses externos y
medidas internas. Por lo tanto los procesos pueden cambiar mltiples veces de cola durante su
tiempo de vida. A la planificacin de mltiples niveles donde los procesos pueden cambiar de una
cola a otra se la denomina planificacin con colas multinivel realimentadas.
c) Planificacin por reparto proporcional

Hasta el momento hemos hablado de planificadores que se concentran en cul es el proceso ms
importante que debe ser ejecutado en cada instante. Sin embargo otra opcin, desde el punto de
vista de la planificacin ,es repartir el tiempo de CPU entre los procesos a un ritmo controlado. Esto
45 Microsoft Windows, Mac OS X, Oracle/Sun Microsystems Solaris, las versiones de Linux anteriores a la 2.6.23 y,
en general, casi la totalidad de los sistemas operativos modernos de propsito general utilizan este tipo de
planificacin de prioridades dinmicas con RR como planificador en cada prioridad.
3-91
es precisamente lo que hace la planificacin equitativa (Fair Scheduling) que intenta repartir por
igual el tiempo de CPU entre los procesos de la cola de preparados. Por ejemplo, si 4 procesos
compiten por el uso de la CPU, el planificador asignar un 25% del tiempo de la misma a cada uno.
Si a continuacin un usuario iniciase un nuevo proceso, el planificador tendra que ajustar el reparto
asignando un 20% del tiempo a cada uno. El algoritmo de planificacin equitativa es muy similar al
algoritmo RR pero, a diferencia de este ltimo en el que se utiliza un cuanto de tamao fijo, la
ventana de tiempo se calcula de dinmicamente para garantizar el reparto equitativo de la CPU.
Al igual que en los algoritmos anteriores, en ocasiones puede ser interesante priorizar unos procesos
frente a otros, tanto por motivos ajenos al sistema operativo como por motivos internos. Por
ejemplo se puede querer favorecer a los procesos limitados por la E/S para mejorar la eficiencia del
sistema, tal y como comentamos en el apartado 3.4.4. La planificacin equitativa resuelve este
problema asignando proporcionalmente ms tiempo de CPU a los procesos con mayor prioridad. A
esta generalizacin del planificador equitativo se la conoce como planificador equitativo
ponderado46.
3.4.6. Planificacin de tiempo real

En el apartado 1.3.4 discutimos la importancia de los sistemas de tiempo real. A continuacin,
describiremos las funcionalidades necesarias para soportar la ejecucin de procesos en tiempo real
dentro de un sistema operativo de propsito general.
a) Tiempo real estricto

Los sistemas de tiempo real estricto son necesarios para realizar tareas crticas que deben ser
completadas dentro de unos mrgenes de tiempo preestablecidos. Generalmente las tareas son
entregas al sistema operativo junto con una declaracin de las restricciones de tiempo periodicidad
y lmite de tiempo y la cantidad de tiempo que necesitan para ejecutarse. El planificador slo
admitir las tareas si puede garantizar el cumplimiento de las restricciones de tiempo, rechazndolas
en caso contrario. El proporcionar estas garantas requiere que el planificador conozca exactamente
el tiempo mximo que se tarda en realizar todas y cada una de las funciones del sistema operativo.
Esto es imposible en sistemas con almacenamiento secundario o memoria virtual, ya que introducen
variaciones no controladas en la cantidad de tiempo necesario para ejecutar una tarea. Por tanto, el
46 Linux desde la versin 2.6.23 utiliza un tipo de planificador equitativo ponderado denominado CFS (Completely
Fair Scheduler) o planificador completamente justo.
3-92
tiempo real estricto no es compatible con los sistemas operativos de propsito general, como los de
tiempo compartido.
b) Tiempo real flexible

La ejecucin de procesos de tiempo real flexible es menos restrictiva. Tan slo requiere que los
procesos crticos reciban mayor prioridad que los que no lo son. Esto es compatible con los sistemas
de tiempo compartido, aunque puede generar excesos en la cantidad de recursos asignados a los
procesos de tiempo real, as como inanicin y grandes retardos en la ejecucin del resto de los
procesos. Sin embargo esto nos permite conseguir sistemas de propsito general que soporten
multimedia, videojuegos y otras tareas que no funcionaran de manera aceptable en un entorno que
no implementara tiempo real flexible. Por ello la mayor parte de los sistemas operativos modernos
soportan este tipo de tiempo real.
Implementar el soporte de tiempo real flexible en un sistema operativo de propsito general

requiere:
Sistema operativo con planificacin con prioridades. Los procesos de tiempo real deben tener
la mayor prioridad. Adems, no deben ser afectados por ningn mecanismo de envejecimiento
o bonificacin47, que s puede afectar a los procesos de tiempo no real.
Baja latencia de asignacin. Cuanto menor es la latencia ms rpido comenzar a ejecutarse el

proceso de tiempo real despus de ser seleccionado por el planificador de la CPU.
Mientras que el primer requerimiento es bastante sencillo de conseguir, el segundo es mucho ms

complejo. Muchos sistemas operativos tienen un ncleo no expropiable. Estos ncleos no pueden
realizar un cambio de contexto mientras se est ejecutando cdigo del ncleo por ejemplo debido a
una llamada al sistema por lo que se ven obligados a esperar hasta que la tarea que se est
realizando se termine antes de asignar la CPU a otro proceso. Esto aumenta la latencia de
asignacin dado que algunas llamadas al sistema pueden ser muy complejas y requerir mucho
tiempo para ser completadas. Con el objetivo de resolverlo existen diversas alternativas:
47 Linux, Microsoft Windows y la mayor parte de los sistemas operativos modernos de propsito general dividen el
rango de prioridades en dos partes. El conjunto de prioridades ms altas son prioridades de tiempo real y por tanto
son fijas. Mientras que el grupo de prioridades ms bajas son de tiempo no real y dinmicas. Adems el planificador
se implementa de tal manera que un proceso con prioridad dinmica nunca puede alcanzar el rango de prioridades de
tiempo real.
3-93
Puntos de expropiacin
Una posibilidad es hacer que el cdigo del ncleo sea expropiable. Esto se consigue introduciendo
puntos de expropiacin en diversos lugares seguros dentro del cdigo. En dichos puntos se
comprueba si algn proceso de prioridad ms alta est en la cola de preparados. En caso de que sea
as se expropia la CPU al proceso actual y se le asigna al proceso de ms alta prioridad.
Debido a la funcin que realizan los puntos de expropiacin, slo pueden ser colocados en lugares
seguros del cdigo del ncleo. Es decir, slo pueden estar situados all donde no se interrumpe la
modificacin de estructuras de datos. Sin embargo esto limita el nmero de puntos que pueden ser
colocados, por lo que la latencia de asignacin puede seguir siendo muy alta para algunas tareas
muy complejas del cdigo del ncleo.
Ncleo expropiable
Otra posibilidad es disear un ncleo completamente expropiable. Puesto que en este caso la
ejecucin de cualquier tarea en el ncleo puede ser interrumpida en cualquier momento por
procesos de mayor prioridad que el que actualmente tiene asignada la CPU es necesario proteger
las estructuras de datos del ncleo con mecanismos de sincronizacin, lo que hace que el diseo de
un ncleo de estas caractersticas sea mucho ms complejo.
Supongamos que un proceso de baja prioridad es interrumpido, porque hay un proceso de alta
prioridad en la cola de preparados, mientras accede a una importante estructura de datos del ncleo.
Durante su ejecucin el proceso de alta prioridad podra intentar acceder a la misma estructura que
manipulaba el proceso de baja prioridad cuando fue interrumpido. Debido al uso de mecanismos de
sincronizacin el proceso de alta prioridad tendra que abandonar la CPU a la espera de que el de
baja libere el acceso. Sin embargo este tardar en ser asignado a la CPU mientras haya algn otro
proceso de alta prioridad en la cola de preparados. Adems otros procesos puede irse aadiendo a la
cola de espera del mecanismo de sincronizacin que regula el acceso a la estructura de datos del
ncleo. Al hecho de que un proceso de alta prioridad tenga que esperar por uno de baja se le conoce
como inversin de la prioridad. Para resolverlo se utiliza un protocolo de herencia de la
prioridad dnde un proceso de baja prioridad hereda la prioridad del proceso de ms alta prioridad
que espera por un recurso al que el primero est accediendo. En el momento en que el proceso de
baja prioridad libere el acceso a dicho recurso, su prioridad retornar a su valor original.
Linux 2.6, Solaris y Microsoft Windows NT/2000/XP son algunos ejemplos de sistemas operativos
3-94
con ncleos expropiables. En el caso concreto de Solaris la latencia de asignacin es inferior a 1 ms.
mientras que con la expropiacin del ncleo desactivada sta puede superar los 100 ms.
Lamentablemente el conseguir baja latencia de asignacin no tiene coste cero. El hecho de que el
ncleo sea expropiable aumenta el nmero de cambios de contexto, lo que reduce el rendimiento del
sistema a cambio de una mejor respuesta. Por ello resulta muy interesante para aplicaciones de
tiempo real, multimedia y sistemas interactivos pero es poco adecuado para servidores y
computacin de alto rendimiento. Es por eso que Linux 2.6 permite escoger entre tener un ncleo
expropiativo, usar puntos de expropiacin o nada de lo anterior. De esta forma Linux est preparado
tanto para servidores como para sistemas de escritorio o de tiempo real.
3.4.7. Planificacin en sistemas multiprocesador

Para tratar el problema de la planificacin en los sistemas multiprocesador nos limitaremos al caso
de los sistemas homogneos48. En dichos sistemas los procesadores son idnticos, por lo que
cualquiera de ellos puede ejecutar cualquier proceso. Esto es bastante comn y simplifica el
problema de la planificacin. Aun as no debemos olvidar que incluso en el caso de los sistemas
homogneos pueden aparecer limitaciones en la planificacin. Por ejemplo:
Un dispositivo de E/S puede estar conectado mediante un bus privado a un procesador en

particular. En ese caso los procesos que quieren utilizar ese dispositivo deben ejecutarse en
dicho procesador.
Los procesadores SMT49 (Simultaneous Multithreading) permiten la ejecucin concurrente de

varios hilos como si de varias CPUs se tratara. Sin embargo, al no disponer cada hilo de una
CPU completa es posible que algunos deban esperar a que algn otro libere unidades de la
CPU que le son necesarias. Eso debe ser tenido en cuenta por el planificador con el fin de
optimizar el rendimiento del sistema.
Al margen de estas cuestiones, existen diversas posibilidades a la hora de enfrentar el problema de

la planificacin en un sistema multiprocesador:
48 Un ejemplo de lo contrario de sistema heterogneo se puede observar en los PC modernos donde muchos
disponen tanto de una CPU como de una GPU especializada en el procesamiento de grficos y en las operaciones de
coma flotante.
49 El HyperThreading disponible en algunos procesadores de Intel es una implementacin de la tecnologa
Simultaneous Multithreading.
3-95
Cuando utilizamos multiprocesamiento asimtrico50 todas las decisiones de planificacin,

procesamiento de E/S y otras actividades son gestionadas por un nico procesador, el servidor
o maestro. El resto de procesadores se limitan a ejecutar el cdigo de usuarios que les es
asignado. Este esquema es sencillo puesto que evita la necesidad de compartir estructuras de
datos entre el cdigo que se ejecuta en los procesadores.
Cuando utilizamos multiprocesamiento simtrico51 o SMP cada procesador ejecuta su propia

copia del ncleo del sistema operativo y se auto-planifica mediante su propio planificador de
CPU. En estos sistemas nos podemos encontrar con varias alternativas:
Algunos sistemas disponen de una cola de preparados comn para todos los
procesadores. Puesto que se mira en una nica cola, todos los procesos pueden ser
planificados en cualquier procesador. Este esquema requiere el uso mecanismos de
sincronizacin debido a que hay estructuras de datos que se comparten entre todos los
ncleos. En caso contrario varios procesadores podran escoger y ejecuta el mismo
proceso a la vez.
Por el contrario otros sistemas disponen de una cola de preparados para cada
procesador. El mayor inconveniente de esta solucin es que puede generar
desequilibrios entre los procesadores, ya que un procesador puede acabar desocupado
con la cola de preparados vaca mientras otro est muy ocupado.
Muchos sistemas operativos modernos implementan el esquema SMP con una cola de preparados
comn. Esto incluye Microsoft Windows NT/2000/XP, Solaris, Mac OS X y versiones anteriores a
Linux 2.6. Sin embargo, esta solucin presenta algunos inconvenientes:
La posibilidad de que un proceso se pueda ejecutar en cualquier CPU aunque parezca

beneficiosa es negativa desde el punto de vista de que dejan de ser tiles las cachs de los
procesadores, penalizando notablemente el rendimiento del sistema. Por eso realmente la
mayora de los sistemas operativos de este tipo intenta evitar la migracin de procesos de un
procesador a otro. A esto se lo conoce con el nombre de afinidad al procesador.
50 En los sistemas de multiprocesamiento asimtrico hay una CPU maestra y varias esclavas a quienes la primera
entrega el trabajo. En ocasiones las CPU esclavas se distinguen por haber sido diseadas para realizar algn tipo de
trabajo de forma eficiente como es el caso las GPU, que no son sino CPU diseadas para el procesamiento de
grficos o por el hardware al que estn conectadas como por ejemplo las CPU unidas a discos para gestionarlos.
51 En los sistemas de multiprocesamiento simtrico o SMP (Symmetric Multiprocessing) todos los procesadores son
iguales. Todos comparten los mismos recursos, pueden acceder a los mismos dispositivos y cada uno ejecuta una
copia del ncleo del sistema operativo. Por lo tanto el sistema operativo debe saber compartir los recursos y repartir
la carga entre las CPU. Casi todos los sistemas multiprocesador modernos son de este tipo.
3-96
Los mecanismos de sincronizacin requeridos para controlar el acceso a la cola de preparados

pueden mantener a los procesadores mucho tiempo desocupados mientras esperan en
sistemas con un gran nmero de procesadores y con muchos procesos a la espera de ser
ejecutados.
Cada vez ms sistemas modernos incluido Linux 2.6 estn optando por utilizar el esquema SMP
con una cola de preparados por procesador. De esta manera, al no utilizar mecanismos de
sincronizacin, se eliminan los tiempos de espera para acceder a la cola de preparados y escoger un
nuevo proceso. Sin embargo, con el fin de mantener la carga de trabajo equilibrada entre todos los
procesadores es necesario disponer de algunos mecanismos de balanceo de carga. Por ejemplo:
En la migracin comandada o push migration un tarea especfica que se ejecuta con menor
frecuencia que el planificador de la CPU estima la carga de trabajo de cada CPU y en caso de
encontrar algn desequilibrio mueve algunos procesos de la cola de preparados de unos
procesadores a la de los otros
En la migracin solicitada o pull migration un procesador inactivo extrae de la cola de

preparados de un procesador ocupado alguna tarea que est esperando.
Tanto el planificador de Linux 2.6 como el planificador ULE, disponible en los sistemas FreeBSD,
implementan ambas tcnicas. Mientras que en Microsoft Windows, apartir de Windows Vista, slo
se hace uso de la migracin solicitada.
3.4.8. Planificacin de la CPU en Microsoft Windows

Para ilustrar los visto hasta el momento sobre la planificacin de la CPU en sistemas operativos
modernos, vamos a estudiar las principales caractersticas de las ltimas versiones de Microsoft
Windows a este respecto.
a) Desde el punto de vista del ncleo

Las actuales versiones de sistemas operativos Windows se agrupan dentro de la familia
Microsoft Windows NT; que naci con el sistema operativo Windows NT 3.1 en 1993 y que
llega hasta hoy en da con Microsoft Windows 8.1 y Windows Server 2012 R2 que se
corresponden con la versin 6.3 de dicha familia Windows NT
El ncleo de la familia Windows NT es multihilo e internamente implementa un algoritmo de
3-97
planificacin expropiativa con colas multinivel realimentadas basado en prioridades:
Dispone de 32 niveles con una prioridad fija entre 0 y 31 donde la prioridad 31 es la ms

alta, mientras que la 0 la ms baja se dedicada en exclusiva a un hilo encargado de poner
las pginas de memoria a cero. El planificador siempre escoge un proceso de la cola de
prioridad ms alta.
En cada nivel hay una cola RR para escoger el proceso que debe ser asignado a la CPU.
Ese algoritmo es ideal para los sistemas de tiempo compartido ya que facilita que los
procesos de una misma prioridad compartan la CPU.
Como cualquier sistema operativo moderno, el ncleo de Windows es expropiable lo que

sabemos que ofrece latencias de asignacin ms bajas que si no lo fuera y soporta tiempo real
flexible:
El rango de prioridades se reparte de forma que las ms altas las que van desde la 16 a la
31 son para los procesos de tiempo real y las mas bajas para los de tiempo no real.
Los hilos de tiempo real no se ven nunca afectados o beneficiados por bonificaciones ni
penalizaciones en la prioridad la prioridad real del hilo es siempre la prioridad esttica
fijada por el programador y en ningn caso las bonificaciones o penalizaciones en las
prioridades pueden hacer que un proceso pase de un tipo al otro.
Respecto a esto ltimo, en Windows los programadores o administradores del sistema pueden
utilizar el API para establecer la prioridad de los hilos. Sin embargo sobre estas preferencias el
ncleo aplica ciertas bonificaciones para obtener la prioridad real; combinando diferentes
criterios para reducir la latencia, mejorar la respuesta obviamente a travs de beneficiar a los
hilos limitados por E/S evitar la muerte por inanicin y la inversin de prioridad. Estas
bonificaciones pueden ocurrir en los siguientes casos:
Ante eventos del planificador/asignador de la CPU para reducir la latencia. Por ejemplo,
cuando se configura un temporizdor, la hora del sistema cambia, un proceso termina, un
mutex o un semforo es liberado o se entrega un evento de una operacin de E/S asncrona.
Cuando se completan ciertas operaciones de E/S para reducir la latencia. Por ejemplo,
acceso al disco, CD-ROM o grficos (+1); comunicaciones en red, tuberas o puerto serie
3-98
(+2); teclado o ratn (+6); sonido (+8).
Ante operaciones relacionadas con la interfaz de usuario para reducir la latencia y

mejorar la respuesta. Por ejemplo, se bonifica a los hilos, que gestionan elementos de la
GUI, cuando despiertan porque cierta actividad en el sistema de ventanas hace que les
llegue algn evento o a cualquier hilo del proceso en primer plano cuando deja de estar en
espera. En ese ltimo caso el sistema incluso les ofrece ms tiempo de cuanto con el objeto
de mejorar la respuesta de las aplicaciones interactivas.
Cuando la aplicacin es un juego o una herramienta multimedia para evitar saltos en la

reproduccin siempre que se registren en un servicio denominado Multimedia Class
Scheduler Service (MMCSS).
Ante operaciones de espera sobre recursos del ncleo para evitar la muerte por inanicin
y la inversin de prioridad. Por ejemplo bonificando la prioridad del hilo que dispone en
exclusiva de dicho recurso.
Ante hilos que llevan mucho tiempo para ser ejecutados para evitar la muerte por
inanicin. Para ser exactos el planificador escoge cada segundo unos pocos hilos que
lleven esperando aproximadamente 4 segundos, les triplica el cuanto y les aumenta la
prioridad a 15. Los hilos recuperan la prioridad y el cuanto anterior cuando agotan el
tiempo de cuanto actual o son expropiados.
Respecto al tiempo de cuanto, desde Windows Vista NT 6.0 no se usa el temporizador para
controlarlo sino un contador de ciclos de reloj de la CPU 52. As el sistema puede determinar con
precisin el tiempo que se hay estado ejecutando un hilo, sin incluir los tiempos dedicados a
otras cuestiones, como por ejemplo a manejar interrupciones.
En Windows los hilos se insertan en la cabeza de su cola no en el final y conservan lo que les
queda de cuanto, cuando son expropiados. Mientras que se insertan por el final con el valor de
cuanto reiniciado, cuando abandonan la CPU por haber agotado el cuanto anterior.
b) Desde el punto de vista del API de Windows

En Windows las prioridades de los procesos se pueden ver desde dos perspectivas: la del API de
52 Desde el Intel Pentium las CPU de la familia x86 incorporan un contador de marca de tiempo (Time Stamp Counter
o TSC) de 64 bits que indica el nmero de ciclos transcurridos desde el ltimo reset del procesador.
3-99
Windows y la del ncleo. Esta ltima es la que hemos estudiado en el apartado anterior.
Mientras que el API tiene una organizacin muy diferente que en ltima instancia debe ser
mapeada a las prioridades numricas del ncleo de Windows.
El API organiza los procesos por clases de prioridad: Tiempo real (15), Alta (10), Arriba de lo
normal (9), Normal (8), Debajo de lo normal (7), Baja (6) y Reposo (1) . Al tiempo que cada
hilo tiene una prioridad relativa: De tiempo crtico (15), Ms alta (2), Arriba de lo normal (1),
Normal (0), Debajo de lo normal (1), Ms baja (2) y Reposo (15). Por lo que la prioridad
interna de cada hilo, desde el punto de vista del ncleo, es el resultado de sumar la prioridad
base obtenida a partir de la clase de prioridad del proceso con la prioridad relativa del hilo en
cuestin.
3-100
4. Gestin de la memoria
4.1. Memoria principal

La memoria es un recurso central para el funcionamiento de un sistema operativo moderno, puesto
que es el nico medio de almacenamiento al que la CPU puede acceder directamente. Por ello, para
que un programa pueda ser ejecutado debe ser cargado en la memoria, desde el disco, y creadas o
modificadas las estructuras internas del sistema operativo necesarias para convertirlo en un proceso.
Adems, dependiendo de la forma en la que se gestiona la memoria, los procesos o partes de los
mismos pueden moverse de la memoria al disco y viceversa durante su ejecucin, con el objetivo de
ajustar las necesidades de memoria manteniendo la utilizacin de la CPU lo ms alta posible.
Como ya comentamos en el aparatado 1.3.1, en los sistemas multiprogramados existe una cola de
entrada que se define como aquella formada por el conjunto de procesos en disco que esperan
para ser cargados en la memoria para su ejecucin.
Por tanto, el procedimiento normal de ejecucin de un programa en dichos sistemas es:
1. Seleccionar un proceso de la cola de entrada y cargarlo en la memoria.
2. Mientras el proceso se ejecuta, ste accede a instrucciones y datos de la memoria.
3. Finalmente el proceso termina y su espacio en memoria es marcado como disponible.
En los sistemas de tiempo compartido no existe cola de entrada, por lo que los programas se
Sistemas Operativos - 2014/2015 4. Gestin de la memoria
cdigo
fuente
compilador o
ensamblador
mdulo tiempo de
compilacin
objeto
enlazado
otros esttico
mdulos enlazador
objeto
modulo
ejecutable
tiempo
de carga
enlazado
librera del dinmico
sistema y otras cargador
libreras de enlace
dinmico
enlazado imagen
tiempo de
dinmico con binaria en
ejecucin
carga diferida la memoria
Figura 4.1: Etapas de procesamiento de un programa de usuario.
cargan inmediatamente en memoria cuando su ejecucin es solicitada por los usuarios. Excepto por
eso, el procedimiento normal de ejecucin de un programa es el mismo que para los sistemas
multiprogramados.
4.2. Reubicacin de las direcciones

La mayor parte de los sistemas permiten que un proceso de usuario resida en cualquier parte de la
memoria fsica. As, aunque el espacio de direcciones del sistema comience en 0x000000, la
primera direccin del proceso de usuario no tiene porque ser esa. En la mayor parte de los casos, un
programa de usuario debe pasar por diferentes etapas algunas de las cuales son opcionales antes
4-102
4.2. Reubicacin de las direcciones Sistemas Operativos - 2014/2015
de ser ejecutado (vase la Figura 4.1). En cada una de ellas las direcciones pueden representarse de
formas distintas, por lo que en cada paso es necesario reubicar las direcciones usadas en una etapa
en direcciones de la siguiente. Por ejemplo, en el cdigo fuente de un programa las direcciones son
generalmente simblicas, como los nombres de las variables y las funciones. A continuacin, un
compilador suele reasignar esas direcciones simblicas en irecciones reubicables del estilo de 120
bytes desde el comienzo del mdulo. Finalmente, el enlazador o el cargador convierte esas
direcciones reubicables en irecciones absolutas como 0x210243.
Por tanto, en cada etapa se mapean las direcciones de un espacio de direcciones en el siguiente. Sin
embargo, para que al final el programa pueda ser ejecutado es necesario que tanto a los datos como
a las instrucciones se les reasignen direcciones absolutas de la memoria. Esto realmente puede
ocurrir en cualquiera de las siguientes etapas:
En tiempo de compilacin. Si durante la compilacin o el enlazado se conoce el lugar de la

memoria donde va a ser ejecutado el proceso, se puede generar directamente cdigo con
direcciones absolutas, o cdigo absoluto. Si en algn momento la direccin de inicio donde es
cargado el programa cambia, es necesario recompilar el cdigo fuente del programa. Los
programas con formato COM del MS-DOS son un ejemplo de este tipo de programas.
En tiempo de carga. Si no se conoce durante la compilacin el lugar donde va a residir un

programa cuando sea ejecutado, el compilador debe generar cdigo reubicable. En este tipo
de cdigo se utilizan direcciones reubicables, de manera que se retrasa la reubicacin a
direcciones absolutas hasta el momento de la carga del programa. Esto permite a muchos
sistemas operativos que un proceso pueda residir en cualquier parte de la memoria fsica,
cargando los procesos donde ms convenga para maximizar el aprovechamiento de la misma.
En tiempo de ejecucin. Si un proceso puede ser movido durante su ejecucin de un lugar de

la memoria a otro, la reubicacin de direcciones debe ser retrasada hasta el momento de la
ejecucin de cada instruccin del programa. Para que esto sea posible necesitamos disponer de
hardware especial que suele estar presente en la mayor parte de las CPU modernas, por lo que
la inmensa mayora de los sistemas operativos modernos de propsito general utilizan este
mtodo.
En el apartado 2.2.2 vimos en lo sistemas operativos modernos, como medida de proteccin, los
procesos no tienen acceso libre a la memoria fsica. En lugar de eso el sistema operativo asistido
por la MMU (Memory-Management Unit) proporciona a cada proceso un espacio de direcciones
virtual que ofrece una vista privada de la memoria similar a la que tendran si cada uno de los
4-103
procesos estuviera siendo ejecutando en solitario (vase la Figura 2.4). Es durante los acceso a la
memoria principal en tiempo de ejecucin cuando estas direcciones virtuales son convertidas en las
direcciones fsica con las que realmente se accede a la memoria.
El mecanismo de proteccin descrito es una forma muy comn de reubicacin de las direcciones en
tiempo de ejecucin que est presente en la mayor parte de los sistemas operativos modernos de
propsito general. A parte de la proteccin, algunas de las caractersticas de dicho mecanismo son:
Los programas pueden ser cargados en cualquier zona libre de la memoria fsica e incluso
movidos de una regin a otra durante la ejecucin de los procesos, puesto que la
transformacin (reubicacin) de las direcciones virtuales en direcciones fsicas se realiza
durante la ejecucin de cada instruccin.
La reubicacin de las direcciones virtuales es decir, la asignacin de direcciones virtuales a

las direcciones del programa puede hacerse en tiempo de compilacin puesto que de
antemano se sabe que todo el espacio de direcciones virtual va a estar disponible. Lo comn es
que los programas se ubiquen en la parte baja del espacio de direcciones virtual, por ejemplo
en empezando en la direccin 0x00000000.
Se puede reducir el consumo de memoria principal compartiendo las regiones de memoria

fsica asignadas al cdigo y los datos de slo lectura de los procesos de un mismo programa.
El cdigo de un programa suele contener direcciones tanto para los saltos como para el acceso
a los datos. Al ubicar los programas siempre en las mismas regiones de los espacios de
direcciones virtuales nos estamos asegurando de que el cdigo en memoria de los procesos de
un mismo programa siempre es el mismo, por lo que se puede compartir la memoria fsica que
ocupan.
4.3. Enlazado dinmico y libreras compartidas

Fundamentalmente existen dos tipos de enlazado:
En el enlazado esttico, las libreras del sistema y otros mdulos son combinados por el
enlazador para formar la imagen binaria del programa que es almacenada en disco. Algunos
sistemas operativos, como MS-DOS, slo soportan este tipo de enlazado.
En el enlazado dinmico, ste se pospone hasta la carga o la ejecucin (vase la Figura 4.1).
Generalmente el enlazado dinmico ocurre durante la carga del programa:
4-104
4.3. Enlazado dinmico y libreras compartidas Sistemas Operativos - 2014/2015
1. Durante la carga del mdulo ejecutable se comprueban las dependencias del mismo. Estas se
almacenan en el mismo archivo en disco que dicho mdulo.
2. Las libreras a enlazar se cargar y ubican en el espacio de direcciones virtual creado para el
nuevo proceso.
3. Finalmente, las referencias del programa a las subrutinas de cada una de las libreras
cargadas se actualizan con la direccin en memoria de las mismas. As la invocacin de las
subrutinas por parte del programa se puede realizar de forma transparente, como si siempre
hubieran formado parte del mismo.
Cuando el enlazado se va a realizar en tiempo de ejecucin se habla de enlazado dinmico con

carga diferida. En ese caso el procedimiento es el siguiente.
1. Durante el enlazado esttico del mdulo ejecutable se pone un stub a cada referencia a
alguna subrutina de la librera que va a ser enlazada dinmicamente.
2. Si durante la ejecucin alguna de dichas subrutinas es invocada, se ejecuta el stub. El stub es

una pequea pieza de cdigo que sabe como carga la librera, si no ha sido cargada
previamente, y como localizar la subrutina adecuada en la misma.
3. Finalmente, el stub se sustituye a si mismo con la direccin de la subrutina y la invoca. Esto

permite que la siguiente ejecucin de la subrutina no incurra en ningn coste adicional.
Sin esta habilidad cada programa en el sistema, por ejemplo, debe tener una copia de la librera del
sistema incluida en la imagen binaria del mismo, lo que significa un desperdicio de espacio libre en
disco y memoria principal. Adems este esquema facilita la actualizacin de las librera, puesto que
los programas pueden utilizar directamente las versiones actualizadas sin necesidad de volver a ser
enlazados.
Puesto que durante la compilacin de una librera no se conoce la regin que va a ocupar dentro de
los espacios de direcciones virtuales de los distintos procesos que la van a utilizar:
Para las libreras el compilador debe generar cdigo PIC (Position-Independent Code) o
independiente de la posicin. Este tipo de cdigo se puede ejecutar adecuadamente y sin
modificaciones independientemente del lugar de la memoria donde est ubicado. Esto permite
reducir el consumo de memoria principal compartiendo las regiones de memoria fsica
asignadas al cdigo de una misma librera en los distintos procesos que la utilizan.
En los sistemas operativos donde no se usa cdigo PIC el compilador debe generar cdigo
4-105
reubicable para que la reubicacin de las direcciones virtuales de las libreras dinmicas se
haga en tiempo de carga. Esto aumenta el tiempo de carga de las libreras y slo permite que
compartan memoria fsica el cdigo de las instancias de una misma librera que ha sido
cargado en la misma regin del espacio de direcciones virtual en los distintos procesos que la
utilizan.
Habitualmente las libreras incluyen informacin acerca de la versin que puede ser utilizada para
evitar que los programas se ejecuten con versiones incompatibles de las mismas, o para permitir
que haya ms de una versin de cada librera en memoria. As los viejos programas se pueden
ejecutar con las viejas versiones de las mismas, o con versiones actualizadas pero compatibles,
mientras los nuevos programas se ejecuten con las versiones ms recientes e incompatibles con los
viejos programas. A este sistema se lo conoce como libreras compartidas.
4.4. Paginacin
El mapeo entre direcciones virtuales y fsicas puede realizarse de diversas maneras. La forma ms
direccin direccin
virtual fsica f 00. . .00

CPU p d f d

f 11. . . 11
p

f

memoria fsica
tabla de
pginas
Figura 4.2: Soporte del hardware para la paginacin.
4-106
4.4. Paginacin Sistemas Operativos - 2014/2015
extendida es la paginacin, que no es sino un esquema de gestin de la memoria que permite que
el espacio de direcciones fsico de un proceso no sea continuo.
4.4.1. Mtodo bsico

En la paginacin la memoria fsica se divide en bloques de tamao fijo denominados marcos,
mientras que el espacio de direcciones virtual se divide en bloques del mismo tamao que los
marcos, denominados pginas. Cuando un proceso va a ser ejecutado sus pginas son cargadas
desde el almacenamiento secundario en marcos libres de la memoria fsica.
La paginacin es una forma de reubicacin de las direcciones en tiempo de ejecucin donde la

transformacin de las direcciones virtuales en direcciones fsicas se realiza de la siguiente manera
(vase la Figura 4.2):
1. Cada direccin virtual generada por la CPU es divida en dos partes: un nmero de pgina p
y un desplazamiento d.
2. El nmero de pgina es utilizado por la MMU para indexar la tabla de pginas, que contiene
el nmero de marco f de cada pgina en la memoria fsica.
3. El nmero de marco es combinado con el desplazamiento para generar la direccin fsica que
va a ser enviada por el bus de direcciones hacia la memoria.
El tamao de las pginas y el de los marcos viene definido por el hardware y normalmente es un
nmero entero potencia de 2 que puede variar entre 512 bytes y 16 MB, dependiendo de la
arquitectura. Es decir, si el espacio de direcciones es de 2 m y el tamao de pgina es de 2 n, los m - n
bits de mayor orden del espacio de direcciones indican el nmero de pgina, mientras que los n bits
de menor orden indican el desplazamiento (vase la Figura 4.3)
nmero de pgina desplazamiento
p d
m-n n
Figura 4.3: Descomposicin de las direcciones virtuales en paginacin.
4-107
a) Desde el punto de vista de los procesos

Cada pgina de un proceso requiere un marco. Por tanto, cuando un proceso llega al sistema:
1. Si el proceso requiere n pginas, el sistema operativo debe escoger n marcos. Estos marcos
son tomados de la lista de marcos libres que debe mantener el sistema. Puesto que son
escogidos de all donde los haya libres, el espacio de direcciones fsico puede no ser contiguo
aunque los procesos vean un espacio de direcciones virtual contiguo.
2. Los marcos seleccionados son asignados al proceso y cada pgina del proceso es cargada en
uno de dichos marcos.
3. La tabla de pginas es actualizada de manera que en la entrada de cada pgina del proceso se
pone el nmero de marco correspondiente.
Un aspecto importante de la paginacin es la diferencia entre como ven los proceso la memoria y
como es realmente la memoria fsica. Cada proceso ve la memoria como un espacio nico que lo
contiene slo a l. Sin embargo la realidad es que el programa est disperso por la memoria fsica,
que adems puede almacenar a otros programas. Esto es posible porque en cada momento la tabla
de pginas slo contiene las pginas del proceso actual.
b) Desde el punto de vista del sistema operativo

Puesto que el sistema operativo es quin gestiona la memoria fsica, ste debe mantenerse al tanto
de las particularidades de su uso:
Que marcos estn asignados y a que pgina de que proceso o procesos.
Que marcos estn disponibles.
Toda esta informacin generalmente se guarda en una estructura denominada la tabla de marcos,
que tiene una entrada por cada marco de la memoria fsica.
Adems el sistema operativo debe mantener una copia de la tabla de pginas para cada proceso en
el PCB, igual que mantiene una copia del contador de programa y del contenido de los registros de
la CPU. Esta copia es utilizada:
Por el asignador para sustituir la tabla de pginas hardware cuando realiza un cambio de
contexto. Por lo tanto el uso de la paginacin incrementa el tiempo del cambio de contexto.
Para el mapeo manual de direcciones virtuales en fsicas. Por ejemplo, cuando un proceso
4-108
realiza una llamada al sistema para realizar una operacin de E/S y proporciona una direccin
como parmetro, dicha direccin debe ser mapeada manualmente para producir la direccin
fsica correspondiente que ser utilizada por el hardware para realizar la operacin.
c) Tamao de las pginas

Una decisin de diseo importante es escoger el tamao de las pginas adecuado:
Con pginas ms pequeas esperamos tener menos fragmentacin interna. Los marcos son
asignados como unidades indivisibles, por lo que si los requerimientos de memoria de un
procesos no coinciden con un lmite de pginas el ltimo marco asignado no sera utilizado
completamente (en ocasiones incluso se podra desperdiciar un marco completo). A ese
fenmeno se lo conoce como fragmentacin interna
Con pginas ms grande se pierde menos espacio en la tabla de pginas. No olvidemos que
cuanto ms pequeas son las pginas ms pginas son necesarias y, por tanto, ms entradas en
la tabla de pginas se necesitan. Adems la E/S es ms eficiente cuanto ms datos son
transferidos en cada operacin.
Los tamaos de pginas tpicos son 4 y 8 KB. Por ejemplo, normalmente cada entrada en la tabla de
paginas es de 4 bytes aunque esto tambin puede variar. Eso significa que cada entrada puede
direccionar a uno de los 2 32 marcos de la memoria fsica. Si suponemos que el tamao de cada
marco es de 4 KB, podemos determinar que el sistema es capaz de direccionar 2 44 bytes o 16 TB
de memoria fsica, para lo que es necesario disponer de una tabla de pginas de 4 MB.
4.4.2. Soporte hardware de la tabla de pginas

La implementacin en hardware de la tabla de pginas puede realizarse de diversas maneras:
Como un conjunto de registros dedicados de la CPU. Es decir, la tabla de pginas del proceso
actual es alojada dentro de la propia CPU, en unos registros destinados a tal fin.
Almacenada en la memoria. Es decir, la tabla de pginas del proceso actual es alojada en la

memoria, normalmente en un formato definido por la CPU.
Debido a la velocidad de los registros de la CPU la implementacin como conjunto de registros es

la ms eficiente. Sin embargo slo puede ser utilizado para tablas de pginas razonablemente
pequeas. El DEC PDP-11 para el que se diseo el primer UNIX es un ejemplo de sistema con
4-109
esta implementacin. En el mismo se utilizaba un espacio de direcciones de 16 bits y un tamao de

pginas de 8 KB, por lo que slo necesitaba 8 registros dedicados para alojar toda tabla de pginas.
En los sistemas modernos se utilizan tablas de pginas muchos ms grandes de un milln de

entradas o ms que difcilmente pueden alojarse en registros dentro de la CPU, ya que alojar tablas
de pginas de ms de 256 entradas es muy costoso. Por eso los sistemas actuales almacenan la tabla
de pginas del proceso en ejecucin en la memoria. Eso permite disponer tablas de pginas de gran
tamao aunque a costa de necesitar dos acceso a la memoria fsica por cada acceso a una palabra
de la memoria virtual53.
Para que la MMU pueda conocer la ubicacin de la tabla de pginas durante la traduccin de las
direcciones, la CPU debe disponer de un registro el PTBR (Page-Table Base Register) donde se
guarda la direccin de la tabla de pginas actual. Adems esto permite que el cambio de contexto
sea ms rpido respecto al uso de registros para almacenar la tabla de pginas puesto que slo es
necesario carga un nico registro ms el PTBR durante el mismo.
4.4.3. Proteccin
La proteccin de las pginas se consigue mediante unos bits de proteccin asociados a cada
entrada de la tabla de pginas y normalmente almacenados en la misma. Estos bits pueden ser:
Solo lectura.
Lectura Escritura. En algunos sistemas hay un bit especfico para este permiso, mientras
que en otros se utilizan bit separados como: lectura, escritura y ejecucin.
Slo ejecucin. Que no existen en todas las plataformas. Por ejemplo, la familia Intel x86
careci de esta caracterstica hasta que AMD la incluy en su arquitectura AMD64, lo que
oblig a Intel a incluirla en las versiones ms modernas de su Pentium IV. El bit que para ser
exacto indica no ejecucin fue introducido para evitar cierto tipo de ataques de seguridad.
Durante la traduccin de las direcciones la MMU comprueba que el tipo de acceso sea vlido. Si
esto no es as, se genera una excepcin de violacin de proteccin de memoria, dado que el acceso
53 La solucin a este problema pasa porque la CPU disponga de una eficiente y pequea de entre 64 y 1024 entradas
memoria cach en la que almacenar las entradas de la tabla de pgina previamente utilizadas en la traduccin de las
direcciones. A dicha cach se la denomina TLB (Translation Look-aside Buffer). Obviamente es necesario que el
asignador borre la TLB durante los cambios de contexto.
4-110
0000 nmero bit de

de marco vlido 1 pgina 0
pgina 0
1 v 2 pgina 3
pgina 1
3 v
3 pgina 1
6 v
pgina 2
2 v 4
pgina 3
7 v
5
0 i
5096 pgina 4
5120 0 i 6 pgina 2
pgina 5
tabla de pginas
7 pgina 4
Figura 4.4: Bit de vlido en la tabla de pginas.
en un modo o autorizado se considera una instrucciones privilegiada. Normalmente el sistema

operativo responde a dicha excepcin terminando el proceso que la gener.
Adems de los bits comentados se suele aadir a cada entrada un bit de vlido:
Cuando una pgina es vlida, la pagina asociada est en el espacio de direcciones virtual del
proceso. Es decir, es legal.
Cuando la pgina no es invlida, la pgina no est asociada al espacio de direcciones virtual

del proceso. Es decir, es ilegal.
El sistema operativo puede utilizar este bit para permitir o denegar el acceso a una pgina, por
ejemplo porque no le ha asignado un marco ya que no est siendo utilizada por el proceso. Al igual
que con los bits de permisos, los intentos de acceso a una pgina ilegal generan una excepcin.
Por ejemplo, en la Figura 4.4 vemos el espacio de direcciones virtual y la tabla de pginas de un
proceso de 5096 bytes en un sistema con pginas de 1024 bytes. Puesto que el proceso no ocupa
todo el espacio de direcciones, slo las direcciones de la 0 a la 5119 son vlidas. En dicho ejemplo
podemos apreciar varios fenmenos:
4-111
Mx.
sistema operativo
pila
montn
datos
cdigo
0x00000000
Figura 4.5: Proceso en memoria.
Debido a la fragmentacin interna las direcciones de la 5097 a la 5119 son vlidas, aunque el
proceso solo ocupe hasta la 5096. Es decir, se est asignando al proceso una porcin de
memoria que no necesita.
Las pginas ocupadas por el proceso son vlidas. Pero todas las paginas en direcciones por
encima de la 5119 estn marcadas como ilegales. As el sistema operativo no tiene que asignar
marcos a pginas no utilizadas por el proceso.
En general los procesos slo necesitan una porcin muy pequea de su espacio de direcciones
virtual. En esos casos es un desperdicio de memoria crear y almacenar un tabla de pgina completa
con una entrada para cada pgina del espacio de direcciones. Para evitarlo en algunas CPU existe el
PTLR (Page-Table Length Register) que se utiliza para indicar el tamao actual de la tabla de
pgina. Este valor es comparado por la MMU durante la traduccin con el nmero de pgina de
cada direccin virtual, de manera que las pginas con entradas ms all de la ltima almacenada en
la tabla son consideradas ilegales.
En realidad, tal y como vimos en el apartado 3.1.1, lo ms comn es que los procesos tengan un
spacio de direcciones virtual disperso como el de la Figura 4.5. En la misma podemos observar
como el sistema operativo ubica los diferentes componentes del proceso de una forma particular
dentro del espacio de direcciones virtual. Este esquema permite que tanto el montn a travs del
mecanismo de asignacin dinmica de memoria de malloc() como la pila puedan extenderse, en
base a las necesidades de memoria que tenga el proceso, sobre la regin de memoria no ocupada.
4-112
Esa regin tambin puede ser parcialmente ocupada por libreras de enlace dinmico o por otros
objetos compartidos que sean necesitados durante la ejecucin del proceso. En cualquier caso las
pginas de dicha regin forman parte del espacio de direcciones virtual pero no tienen marcos de
memoria fsica asignados, en tanto en cuanto el proceso no las vaya a utilizar. La falta de marco es
indicada por el sistema operativo utilizando el bit de vlido para denegar el acceso.
4.4.4. Pginas compartidas

Una de las ventajas importantes de la paginacin es la posibilidad de compartir pginas entre
procesos. Para conseguir esto basta con que las pginas compartidas de los distintos procesos
tengan asignadas un mismo marco. Esto permite, por ejemplo, que los procesos de un mismo
programa puedan compartir las pginas de cdigo o los datos de slo lectura con el fin de ahorrar
memoria. Tambin permite compartir las pginas de cdigo de una librera compartida enlazada a
diferentes procesos.
Compartir pginas no slo permite ahorrar memoria pues en los sistemas operativos modernos la
memoria compartida (vase el apartado 3.2.2) se implementa mediante pginas compartidas.
4.5. Paginacin bajo demanda

La paginacin bajo demanda es la tcnica con la que frecuentemente se implementa la memoria
virtual en los sistemas con paginacin. El concepto de memoria virtual no debe confundirse con el
de espacio de direcciones virtual, aunque estn relacionados puesto que el que exista separacin
entre la memoria fsica y la manera en la que los procesos perciben la memoria es un requisito
para poder implementar la memoria virtual.
4.5.1. Memoria virtual

La memoria virtual es una tcnica que permite la ejecucin de procesos sin que stos tengan que
ser cargados completamente en la memoria.
Los programas suelen tener partes de cdigo que rara vez son ejecutadas, por ejemplo las subrutinas
para manejar condiciones de error que, aunque tiles, generalmente nunca son invocadas. Tambin
es frecuente que se reserve ms memoria para datos de lo que realmente es necesario. Por ejemplo
muchos programadores tiene la costumbres de hacer cosas tales como declarar un array de 1000 por
4-113
1000 elementos cuando realmente slo necesitan 100 por 100. Teniendo todo esto en cuenta y con el
fin de mejorar el aprovechamiento de la memoria, parece que sera interesante no tener que cargar
todas las porciones de los procesos pero de manera que stos aun as puedan seguir siendo
ejecutados. Eso es exactamente lo que proporciona la memoria virtual, en general, y la paginacin
bajo demanda, en particular, para los sistemas que soportan paginacin.
La habilidad de ejecutar un proceso cargado parcialmente en memoria proporciona algunos

beneficios importantes:
Un programa no estar nunca ms limitado por la cantidad de memoria disponible. Es decir,

los desarrolladores pueden escribir programas considerando que disponen de un espacio de
direcciones virtual extremadamente grande y sin considerar la cantidad de memoria realmente
disponible. Es importante no olvidar que sin memoria virtual para que un proceso pueda ser
ejecutado debe estar completamente cargado en la memoria.
Puesto que cada programa ocupa menos memoria ms programas se pueden ejecutar al
mismo tiempo, con el correspondiente incremento en el uso de la CPU y en el rendimiento del
sistema y sin efectos negativos en el tiempo de respuesta y en el de ejecucin.
4.5.2. Mtodo bsico

En la paginacin bajo demanda las pginas individuales, en las que se dividen los espacios de
direcciones virtuales de los diferentes procesos, pueden ser sacadas de la memoria de manera
temporal y copiadas a un almacenamiento de respaldo, para posteriormente volver a ser tradas a
la memoria cuando son necesitadas por su proceso. A este proceso de guardado y recuperacin de
las pginas sobre el almacenamiento de respaldo se lo denomina intercambio o swapping y es
llevado a cabo por un componente del sistema operativo denominado el paginador.
Para que se puedan cargar las pginas cuando son necesitadas por su proceso hace falta que el
paginador sepa cuando lo son. Eso requiere que el hardware proporcione algn tipo de soporte, por
ejemplo incorporando un bit de vlido a la entrada de cada pgina en la tabla de pginas:
Cuando el bit de vlido est a 1 la pgina es legal y est en la memoria. Es decir, la pgina
existe en el espacio de direcciones virtual del proceso y tiene asignado un marco de memoria
fsica.
Cuando el bit de vlido est a 0 pueden ocurrir varias cosas:
4-114
4.5. Paginacin bajo demanda Sistemas Operativos - 2014/2015
La pgina es legal pero esta almacenada en disco y no en la memoria.
La pgina no es legal. Es decir, no existe en el espacio de direcciones virtual del

proceso. Esto puede ser debido a que la pgina est en un hueco del espacio de
direcciones en una regin que no est siendo utilizada por lo que el sistema operativo
no le ha asignado espacio de almacenamiento ni en disco ni en la memoria.
Si un proceso accede a una pgina residente en memoria marcada como vlida no ocurre nada y
la instruccin se ejecuta con normalidad. Pero si accede a una pgina marcada como invlida:
1. Al intentar acceder a la pgina la MMU comprueba el bit de vlido y genera una excepcin
de fallo pgina al estar marcada como invlida. Dicha excepcin es capturada por el sistema
operativo.
2. El sistema operativo comprueba en una tabla interna si la pgina es legal o no. Es decir, si la
pgina realmente no pertenece al espacio de direcciones virtual del proceso o si pertenece
pero est almacenada en el disco. Esta tabla interna suele almacenarse en el PCB del proceso
como parte de la informacin de gestin de la memoria.
3. Si la pgina es ilegal, el proceso ha cometido un error y debe ser terminado. En UNIX, por
ejemplo, el sistema enva al proceso una seal de violacin de segmento que lo obliga a
terminar.
4. Si la pgina es legal debe ser cargada desde el disco:
1.1. El ncleo debe buscar un marco de memoria libre que, por ejemplo, se puede escoger
de la lista de marcos libres del sistema.
1.2. Se solicita una operacin de disco para leer la pgina deseada en el marco asignado.
Puesto que no resulta eficiente mantener la CPU ocupada mientras la pgina es
recuperada desde el disco, el sistema debe solicitar la lectura de la pgina y poner al
proceso en estado de espera.
1.3. Cuando la lectura del disco haya terminado se debe modificar la tabla interna, antes
mencionada, y la tabla de pginas para indicar que la pgina est en la memoria.
1.4. Reiniciar la instruccin que fue interrumpida por la excepcin. Generalmente esto se
hace colocando el proceso nuevamente en la cola de preparados y dejando que el
asignador lo reinicie cuando sea escogido por el planificador de la CPU.
Un caso extremo de la paginacin bajo demanda es la paginacin bajo demanda pura. En ella la
4-115
ejecucin de un proceso se inicia sin cargar ninguna pgina en la memoria. Cuando el sistema
operativo sita al contador de programas en la primera instruccin del proceso que es una pgina
no residente en memoria se genera inmediatamente un fallo de pgina. La pgina es cargada en la
memoria tal y como hemos descrito anteriormente y el proceso continua ejecutndose, fallando
cuando sea necesario con cada pgina que necesite y no est cargada. Las principales ventajas de la
paginacin bajo demanda pura son:
Nunca se traer desde el disco una pgina que no sea necesaria.
El inicio de la ejecucin de un proceso es mucho ms rpido que si se cargara todo el proceso

desde el principio.
4.5.3. Requerimientos de la paginacin bajo demanda

Los requerimientos hardware para que un sistema operativo pueda soportar la paginacin bajo
demanda son:
Tabla de pginas con habilidad para marcar entradas invlidas, ya sea utilizando un bit
especfico o con valores especiales en los bits de proteccin.
Disponibilidad de una memoria secundaria. En esta memoria se guardan las pginas que no
estn presentes en la memoria principal. Normalmente se trata de un disco conocido como
dispositivo de intercambio, mientras que la seccin de disco utilizada concretamente para
dicho propsito se conoce como espacio de intercambio o swap.
Posibilidad de reiniciar cualquier instruccin despus de un fallo de pgina. En la mayor parte

de los casos esta funcionalidad es sencilla de conseguir. Sin embargo, la mayor dificultad
proviene de las instrucciones que pueden modificar diferentes posiciones de la memoria, como
aquellas pensadas para mover bloques de bytes o palabras. En el caso de que el bloque de
origen o de destino atraviese un borde de pgina, la instruccin sera interrumpida cuando la
operacin solo haya sido realizada parcialmente. Si adems ambos bloques se superpusieran,
no se podra reiniciar la instruccin completa. Las posibles soluciones a este problema deben
ser implementadas en el hardware.
4.5.4. Rendimiento de la paginacin bajo demanda

Indudablemente el rendimiento de un sistema con paginacin bajo demanda se ve afectado por el
4-116
nmero de fallos de pginas. En el peor de los casos, en cada instruccin un proceso puede intentar
acceder a una pgina distinta empeorando notablemente el rendimiento. Sin embargo esto no ocurre
puesto que los programas tienden a tener localidad de referencia (vase el apartado 4.5.9).
a) Tiempo de acceso efectivo

El rendimiento de un sistema con paginacin bajo demanda est relacionado con el concepto de
tiempo de acceso efectivo a la memoria. ste intenta estimar el tiempo que realmente se tarda en
acceder a la memoria teniendo en cuenta mecanismos del sistema operativo como la paginacin
bajo demanda.
En muchos sistemas informticos el tiempo de acceso a la memoria fsica Tm es de unos pocos

nanosegundos. Por lo tanto, si no hay fallos de pgina, el tiempo de acceso efectivo es igual al
tiempo de acceso a la memoria. Pero si hay fallos de pgina, primero es necesario leer la pgina del
disco, por lo que el tiempo de acceso efectivo a la memoria es mayor.
Supongamos que conocemos la probabilidad p de que ocurra un fallo de pgina. El tiempo de

acceso efectivo se podra calcular como una media ponderada por la probabilidad p del tiempo de
acceso a la memoria Tm mas el tiempo necesario para gestionar cada fallo de pgina o tiempo de
fallo de pgina Tfp:
T em=1 pT m p T fp (3)
Por tanto, para calcular el tiempo de acceso efectivo Tem necesitamos estimar el tiempo de fallo de
pgina Tfp, que se consume fundamentalmente en:
Servir la excepcin de fallo de pgina. Esto incluye capturar la interrupcin, salvar los
registros y el estado del proceso, determinar que la interrupcin es debida a una excepcin de
fallo de pgina, comprobar si la pgina es legal y determinar la localizacin de la misma en el
disco. Aproximadamente, en realizar esta tarea el sistema puede tardar de 1 a 100s.
Leer la pgina en un marco libre. En esta tarea se puede tardar alrededor de 8ms, pero este
tiempo puede ser mucho mayor si el dispositivo est ocupado y se debe esperar a que se
realicen otras operaciones.
Reiniciar el proceso. Si incluimos el tiempo de espera en la cola de preparados, se puede

tardar entre 1 y 100s.
4-117
Como se puede apreciar la mayor parte del tiempo de fallo de pgina es debido al tiempo requerido
para acceder al dispositivo de intercambio.
Para ilustrar el clculo del tiempo de acceso efectivo a la memoria: slo vamos a considerar el
tiempo requerido para acceder al dispositivo de intercambio ignorando las otras tareas a realizar
durante el fallo de pgina vamos suponer que el tiempo de acceso a la memoria Tm es de 200 ns y
que la probabilidad p es muy pequea (es decir, p1 ):
T em = 1 p 200ns p8ms
= 1 p 200ns p8000000ns (4)
200ns7999800nsp
Como se puede apreciar el tiempo de acceso efectivo es proporcional a la tasa de fallos de pgina
r fp = pT fp .
T em T mr fp (5)
Por ejemplo, si un proceso causa un fallo de pgina en uno de cada 1000 accesos (p = 0,001), el
tiempo de acceso efectivo es de 8,2 ms. Es decir, el rendimiento del sistema es 40 veces inferior
debido a la paginacin bajo demanda. Por tanto es necesario mantener la tasa de fallos de pgina
lo ms baja posible para mantener un rendimiento adecuado.
b) Manejo y uso del espacio de intercambio

Otro aspecto fundamental que afecta al rendimiento de la paginacin bajo demanda es el uso del
espacio de intercambio. Cuando un proceso genera un fallo de pgina el sistema operativo debe
recuperar la pgina de all donde est almacenada. Si esto ocurre al principio de la ejecucin, ese
lugar seguramente ser el archivo que contiene la imagen binara del programa, pues es donde se
encuentran las pginas en su estado inicial. Sin embargo el acceso al espacio de intercambio es
mucho ms eficiente que el acceso a un sistema de archivos, incluso aunque el primero est
almacenado dentro de un archivo de gran tamao. Esto es debido a que los datos se organizan en
bloques contiguos de gran tamao, se evitan las bsquedas de archivos y las indirecciones en la
asignacin de espacio. Por ello debemos plantearnos que hacer con las imgenes de los programas
que van a ser ejecutados.
Se puede mejorar el rendimiento copiando en el espacio de intercambio la imagen completa
4-118
de los programas durante el inicio del proceso, para despus realizar la paginacin bajo
demanda sobre dicha copia.
Otra alternativa es cargar las pginas desde el archivo que contiene la imagen cuando son
usadas por primera vez pero siendo escritas en el espacio de intercambio cuando dichas
pginas tiene que ser reemplazadas. Esta aproximacin garantiza que slo las pginas
necesarias son ledas desde el sistema de archivos reduciendo el uso de espacio de
intercambio, mientras que las siguientes operaciones de intercambio se hacen sobre dicho
espacio.
Tambin se puede suponer que el cdigo de los procesos no puede cambiar. Esto permite
utilizar el archivo de la imagen binaria para recargar las pginas de cdigo, lo que tambin
evita escribirlas cuando son sustituidas. Sin embargo el espacio de intercambio se sigue
utilizando para las pginas que no estn directamente asociadas a un archivo, como la pila o
el montn de los procesos. Este mtodo parece conseguir un buen compromiso entre el tamao
del espacio de intercambio y el rendimiento. Por eso se utiliza en la mayor parte de los sitemas
operativos modernos.
4.5.5. Copy-on-write
El copy-on-write o copia durante la escritura permite la creacin rpida de nuevos procesos,
sistema operativo sistema operativo
pgina A
pgina A pgina B pgina A
pgina B pgina B
pgina C pgina C pgina C
sistema operativo
espacio de direcciones memoria fsica espacio de direcciones

del proceso 1 del proceso 2
Figura 4.6: Copy-on-write antes de que el proceso 1 modifique la pgina A.
4-119
minimizando la cantidad de pginas que deben ser asignadas a estos. Para entenderlo es importante
recordar que la llamada al sistema fork() crear un proceso hijo cuyo espacio de direcciones es un
duplicado del espacio de direcciones del padre. Indudablemente esto significa que durante la
llamada es necesario asignar suficientes marcos de memoria fsica como para alojar las pginas del
nuevo proceso hijo. El copy-on-write minimiza de la siguiente manera el nmero de marcos que
deben ser asignadas al nuevo proceso:
1. Cuando la llamada al sistema fork() crea el nuevo proceso lo hace de forma que ste
comparta todas sus pginas con las del padre (vase la Figura 4.6). Sin el copy-on-write el
fork() tendra que asignar marcos de memoria fsica a el hijo, para a continuacin copiar las
pginas del padre en ellos. Sin embargo con el copy-on-write padre e hijo mapean sus pginas
en los mismos marcos, evitando tener que asignar memoria libre.
2. Las pginas compartidas se marcan como copy-on-write. Para ello se puede marcar todas las
pginas como de solo lectura en la tabla de pginas de ambos procesos y utilizar una tabla
interna alojada en el PCB para indicar cuales son realmente de slo lectura y cuales estn en
copy-on-write. Es importante destacar que realmente slo las pginas que pueden ser
modificadas se marcan como copy-on-write. Las pginas que no puede ser modificadas por
ejemplo las que contienen el cdigo ejecutable del programa simplemente pueden ser
compartidas como de slo lectura por los procesos, como hemos comentado anteriormente.
sistema operativo sistema operativo

copia de A
pgina A
pgina A pgina B pgina A
pgina B pgina B
pgina C pgina C pgina C
sistema operativo
espacio de direcciones memoria fsica espacio de direcciones

del proceso 1 del proceso 2
Figura 4.7: Copy-on-write despus de que el proceso 1 modifique la pgina A.
4-120
3. Si algn proceso intenta escribir en una pgina copy-on-write, la MMU genera una
excepcin para notificar el suceso al sistema operativo. Siguiendo lo indicado en el punto
anterior, la excepcin se originara porque la pgina est marcada como de solo lectura, por lo
que el sistema operativo debera comprobar si se trata de un acceso a una pgina
copy-on-write o a un intento real de escribir en una pgina de slo lectura. Para ello el sistema
slo tendra que mirar la tabla interna almacenada en el PCB. Si se ha intentado escribir en
una pgina de solo lectura, el proceso ha cometido un error y generalmente debe ser
terminado.
4. Si el sistema detecta una escritura a una pgina de copy-on-write slo tiene que copiarla en
un marco libre y mapearlo en el espacio de direcciones del proceso (vase la Figura 4.7). Para
esto se sustituye la pgina compartida por otra que contiene una copia pero que ya no est
compartida. Indudablemente la nueva pgina debe ser marcada como de escritura para que en
el futuro pueda ser modificada por el proceso.
5. La pgina original marcada como copy-on-write puede ser marcada como de escritura y no
como copy-on-write, pero slo si ya no va a seguir siendo compartida. Esto es as porque una
pgina marcada como copy-on-write puede ser compartida por varios procesos.
6. El sistema operativo puede reiniciar el proceso. A partir de ahora ste puede escribir en la
pgina sin afectar al resto de los procesos. Sin embargo puede seguir compartiendo otras
pginas en copy-on-write.
El copy-on-write permite ahorrar memoria y tiempo en la creacin de los procesos puesto que slo
se copian las pginas que son modificadas por stos, por lo que se trata de una tcnica comn en
mltiples sistemas operativos, como por ejemplo Microsoft Windows, Linux y Solaris.
El copy-on-write es especialmente interesante si a continuacin se va a utilizar la llamada al

sistema exec() puesto que si es as copiar el espacio de direcciones completo es una prdida de
tiempo.
4.5.6. Archivos mapeados en memoria

Los archivos mapeados en memoria permiten acceder a un archivo como parte del espacio de
direcciones virtuales de un proceso. Algunas de las caractersticas de esta tcnica son:
Cuando una regin del espacio de direcciones queda marcada para ser mapeada sobre una
regin de un archivo se utiliza una estrategia similar a la comentada para el mtodo bsico de
4-121
la paginacin bajo demanda. La diferencia es que las pginas son cargadas desde dicho
archivo y no desde el espacio de intercambio. Es decir, en un primer acceso a una pgina
mapeada se produce un fallo de pgina que es resuelto por el sistema operativo leyendo una
porcin del archivo en el marco asignado a la pgina.
Esto significa que la lectura y escritura del archivo se realiza a travs de lecturas y escrituras
en la memoria, lo que simplifica el acceso y elimina el costo adicional de las llamadas al
sistema: read(), write(), etc.
Las escrituras en disco se suelen realizar de forma asncrona. Para ello el sistema operativo
comprueba peridicamente las pginas modificadas y las escribe en disco.
Los marcos utilizados en el mapeo pueden ser compartidos, lo que permite compartir los
datos de los archivo. Adems se puede incluir soporte de copy-on-write, lo que permite a los
procesos compartir un archivo en modo de slo lectura pero disponiendo de sus propias copias
de aquellas pginas que modifiquen. Indudablemente para que los procesos puedan compartir
datos es necesario que exista algn tipo de coordinacin (vase el apartado 3.3.3).
Algunos sistemas operativos ofrecen el servicio de mapeo de archivos en la memoria slo a travs
de una llamada al sistema concreta, permitiendo utilizar las llamadas estndar read(), write(),
etc. para hacer uso de la E/S tradicional. Sin embargo muchos sistemas modernos utilizan el
mapeo en la memoria independientemente de que se pidan o no. Por ejemplo, en Linux si un
proceso utiliza llamada al sistema mmap() es porque explcitamente pide que el archivo sea
mapeado en memoria. Por tanto, el ncleo mapea el archivo en el espacio de direcciones del
proceso. Sin embargo, si un archivo es abierto con llamadas al sistemas estndar como open()
Linux mapea el archivo en el espacio de direcciones del ncleo y traduce las llamadas read() y
write() en accesos a la memoria en dicha regin. No importa como sea abierto el archivo, Linux
trata toda la E/S a archivos como mapeada en memoria, permitiendo que el acceso a los mismos
tenga lugar a travs del eficiente componente de gestin de la memoria.
4.5.7. Reemplazo de pgina

Hasta el momento hemos considerado que disponemos de memoria fsica suficiente para atender
cualquier fallo de pgina pero qu pasa cuando no quedan marcos libres?. En ese caso la subrutina
que da servicio a la excepcin de fallo de pgina debe escoger alguna pgina, intercambiarla con el
4-122
disco y utilizar el marco de la misma para cargar la nueva pgina. Es decir, debemos modificar la
subrutina descrita en el apartado 4.5.2 de la siguiente manera:
4. Si la pgina es legal, debe ser cargada desde el disco.
1.1. Buscar la localizacin de la pgina en disco.
1.2. El ncleo debe buscar un marco de memoria libre que, por ejemplo, se puede escoger
de la lista de marcos libres del sistema.
a) Si hay uno, usarlo.
b) Si no hay, usar un algoritmo de reemplazo de pgina para seleccionar una vctima.
c) Escribir la vctima en el disco y cambiar las tablas de paginas y de marcos libres de

acuerdo a la nueva situacin. Para evitar mantener la CPU ocupada, el sistema debe
solicitar la escritura de la pgina y poner al proceso en estado de espera.
1.3. Se solicita una operacin de disco para leer la pgina deseada en el marco asignado.
Para evitar mantener la CPU ocupada, el sistema debe solicitar la escritura de la
pgina y poner al proceso en estado de espera.
1.4. Cuando la lectura del disco haya terminado se debe modificar la tabla interna de
pginas vlidas y la tabla de pginas para indicar que la pgina est en la memoria.
1.5. Reiniciar el proceso interrumpido.
Es importante destacar que en caso de reemplazo se necesita realizar dos accesos al disco. Esto se
puede evitar utilizando un bit de modificado asociado a cada pgina en la tabla de pginas.
Este bit es puesto a 1 por el hardware cuando se modifica la pgina.
Se puede evitar escribir en disco aquellas pginas que tienen este bit a 0 cuando son
seleccionada para reemplazo, siempre que el contenido de la pgina no haya sido sobreescrito
por otra en el espacio de intercambio
En general para implementar la paginacin bajo demanda necesitamos:
Un algoritmo de asignacin de marcos que se encarga de asignar los marcos a los procesos.
Un algoritmo de reemplazo de pgina para seleccionar que pgina reemplazamos cuando no

hay marcos suficientes.
4-123
Obviamente estos algoritmos deben ser escogidos de forma que mantengan la tasa de fallos de
pgina lo ms baja posible.
a) Algoritmos de reemplazo de pginas

Existen diversos criterios para escoger la pgina que reemplazamos cuando no hay suficientes
marcos disponibles. En cualquier caso el algoritmo ptimo el que garantiza la tasa de fallos de
pgina ms baja consiste en seleccionar siempre la pgina que ms se va a tardar en necesitar.
Desafortunadamente este algoritmo es difcil de implementar puesto que necesita tener informacin
acerca de cules van a ser las pginas referencias en el futuro. Por eso slo se puede utilizar en
estudios comparativos con el fin de saber cuanto se aproxima al ptimo un algoritmo de reemplazo
concreto.
Otros algoritmos de reemplazo pueden utilizar uno o varios de los siguientes criterios:
Reemplazar la pgina que hace ms tiempo que fue cargada. Este criterio da lugar al
algoritmo FIFO de reemplazo que no siempre tiene un buen rendimiento puesto que la pgina
ms antigua no necesariamente es la que se va a tardar ms tiempo en necesitar que sera la
eleccin ptima.
Reemplazar la pgina que hace ms tiempo que fue utilizada bajo la hiptesis de que si una
pgina no ha sido usada durante un gran periodo de tiempo, entonces es poco probable que
vaya a serlo en el futuro. Este criterio da lugar a la familia de algoritmos LRU (Least Recently
Used):
Estos algoritmos requieren de soporte por parte del hardware puesto que al sistema
operativo no se le notifican los acceso legales a las pginas, por lo que no tiene forma
de saber cuando una pgina fue usada por ltima vez.
Normalmente el soporte por parte del hardware es a travs de un bit en la tabla de

pginas llamado bit de referencia. Este bit se pone a 1 cada vez que una instruccin
ejecutada en la CPU referencia a una pgina, lo que permite al sistema operativo hacerse
una idea aproximada54 de las pginas que han sido usadas recientemente. A los
algoritmos que siguen esta aproximacin se los denomina NRU (Not Recently Used).
54 Se trata de una aproximacin puesto que usando el bit de referencia el sistema operativo no puede conocer con
exactitud la ltima vez que una pgina fue utilizada. Sin embargo, aunque existen soluciones exactas que hacen uso
de un contador o de una pila que se actualiza en cada acceso a las pginas, se trata de soluciones muy costosas como
para ser implementarlas en hardware.
4-124
Dentro de los algoritmos NRU tambin estn aquellos que son mejorados incluyendo el
valor del bit de modificado en el criterio de eleccin de la pgina. Estos algoritmos
escogen las pginas no referencias antes que las referencias para lo que utilizan el valor
del bit de referencia y dentro de cada clase las no modificadas antes que las
modificadas para lo que utilizan el valor del bit de modificado para evitar en lo
posible reemplazar pginas cuyo contenido tiene que ser escrito en disco.
Reemplazar la pgina que ha sido usada con mayor o menos frecuencia utilizando contadores
de referencias para cada pgina almacenados en la tabla de pginas que sos actualizados por
el hardware en cada referencia. Este criterio da lugar a los algoritmos LFU (Least Frequently
Used) cuando se escogen las pginas utilizadas con menos frecuencia y MFU (Most
Frequently Used) cuando se escogen las pginas utilizadas con ms frecuencia.
b) Algoritmos de buffering de pginas

Existen otros procedimientos que pueden ser utilizados, junto con alguno de los algoritmos de
reemplazo comentados, con el objetivo de mejorar su eficiencia. Estos procedimientos se agrupan
dentro de lo que se denomina algoritmos de buffering de pginas.
Se puede mantener una lista de marcos libres. Cuando se produce un fallo de paginas se
escoge un marco de la lista y se carga la pgina, al tiempo que se selecciona una pgina como
vctima y se copia al disco. Esto permite que el proceso se reinicie lo antes posible, sin esperar
a que la pgina reemplazada sea escrito en el disco. Posteriormente, cuando la escritura
finalice, el marco es incluido en la lista de marcos libres.
Una mejora de lo anterior sera recordar que pgina estuvo en cada marco antes de que ste
pasara a la lista de marcos libres. De esta forma las pginas podran ser recuperadas
directamente desde la lista si fallara alguna antes de que su marco fuera utilizado por otra
pgina. Esto permite reducir los efectos de que el algoritmo de reemplazo escoja una vctima
equivocada.
Se puede mantener una lista de pginas modificadas e ir escribindolas cuando el dispositivo

del espacio de intercambio no est ocupado. Este esquema aumenta la probabilidad de que una
pgina est limpia cuando sea seleccionada por el algoritmo de reemplazo, evitando la
escritura en disco.
4-125
c) Reemplazo local frente a global

Cuando un proceso necesita un marco el algoritmo de reemplazo puede tanto extraerlo de cualquier
proceso como ser obligado a considerar slo aquellas pginas que pertenecen al proceso que gener
el fallo. Eso permite clasificar los algoritmos de reemplazo en dos categoras:
En el reemplazo local slo se pueden escoger marcos de entre los asignados al proceso.
El nmero de marcos asignados a un proceso no cambia por que ocurran fallos de

pginas.
El mayor inconveniente es que un proceso no puede hacer disponible a otros procesos

los marcos de memoria que menos usa.
En el reemplazo global se pueden escoger marcos de entre todos los del sistema,
independientemente de que estn asignados a otro proceso o no.
El nmero de marcos asignados a un proceso puede aumentar si durante los fallos de

pgina se seleccionan marcos de otros procesos.
El mayor inconveniente es que los procesos no pueden controlar su tasa de fallos de

pgina, puesto que esta depende del comportamiento de los otros procesos, afectando al
tiempo de ejecucin de forma significativa.
Generalmente el reemplazo global proporciona mayor rendimiento por lo que es el mtodo ms

utilizado.
4.5.8. Asignacin de marcos de pgina

La cuestin que queda por resolver es cmo repartir los marcos de memoria fsica libre entre los
diferentes procesos con el fin de cubrir las necesidades de reemplazo de cada uno de ellos. Posibles
soluciones a esto seran: repartir la memoria por igual entre todos los procesos o hacerlo en
proporcin a la cantidad de memoria virtual que utilizan. Sin embargo parece que puede ser
interesante determinar el mnimo nmero de marcos que realmente necesita cada proceso, pues as
el sistema podra disponer de memoria libre para aumentar el nmero de procesos aumentando el
uso de la CPU o para dedicarla a otras funciones como es el caso de los buffers y las cachs de
E/S .
El mnimo nmero de marcos viene establecido por diversos factores:
4-126
Cuando ocurre un fallo de pgina la instruccin que la ha provocado debe ser reiniciada
despus de cargar la pgina en un marco libre. Por lo tanto un proceso debe disponer de
suficientes marcos como para guardar todas las pginas a las que una simple instruccin
pueda acceder, pues de lo contrario el proceso nunca podra ser reiniciado al fallar
permanentemente en alguno de los acceso a memoria de la instruccin. Obviamente este lmite
viene establecido por la arquitectura de la mquina.
Todo proceso tiene una cierta cantidad de pginas que en cada instante son utilizadas
frecuentemente. Si el proceso no dispone de suficientes marcos como para alojar dichas
pginas, generar fallos de pgina con demasiada frecuencia. Esto afecta negativamente al
rendimiento del sistema, por lo que es conveniente que el sistema asigne al nmero de marcos
necesario para que eso no ocurra.
En general, si se va reduciendo el nmero de marcos asignados a un proceso, mucho antes de haber

alcanzado el mnimo establecido por la arquitectura, el proceso dejar de ser til debido a la elevada
tasa de fallos de pgina, que ser mayor cuantos menos marcos tenga asignados. Cuando eso ocurre
se dice que el proceso est hiperpaginando.
4.5.9. Hiperpaginacin
Se dice que un proceso sufre de hiperpaginacin cuando gasta ms tiempo paginando que
ejecutndose.
a) Causas de la hiperpaginacin
En los primeros sistemas multiprogramados que implementaron la paginacin bajo demanda era
posible que se diera el siguiente caso:
1. El sistema operativo monitorizaba el uso de la CPU. Si el uso de la misma era bajo, se

cargaban nuevos procesos desde la cola de entrada para aumentar el grado de
multiprogramacin.
2. Si un proceso necesitaba demasiada memoria, le poda quitar los marcos a otro puesto que se
utilizaba un algoritmo de reemplazo global. Esto poda ocasionar que aumentara la tasa de
fallos de pgina del proceso que perda los marcos.
3. Al aumentar los fallos de pagina el uso de la CPU decreca, por lo que el sistema operativo
4-127
hiperpaginacin
grado de multiprogramacin
Figura 4.8: Hiperpaginacin en sistemas multiprogramados.
cargaba ms procesos para aumentar el grado de multiprogramacin y con ello el uso de la

CPU.
4. Esto reduca la cantidad de memoria disponible para cada proceso, lo que aumentaba la tasa
de fallos de pginas que nuevamente reduca el uso de la CPU
5. Este mecanismo iteraba hasta reducir considerablemente el rendimiento del sistema.
El fenmeno comentado se ilustra en la Figura 4.8 donde el uso de la CPU es trazado frente al
nmero de procesos cargados en el sistema. Cuando esto ltimo aumenta el uso de la CPU aumenta
hasta alcanzar un mximo. Si el grado de multiprogramacin supera dicho punto, el sistema
comienza a hiperpaginar, por lo que el uso de la CPU disminuye bruscamente. Por lo tanto, si el
sistema est hiperpaginando, es necesario reducir el grado de multiprogramacin con el objetivo de
liberar memoria.
En los sistemas de tiempo compartido modernos ocurre algo parecido a lo descrito para los sistemas
multiprogramados, aunque sin el efecto en cadena ocasionado por el intento del planificador de
largo plazo de maximizar el uso de la CPU, ya que estos sistemas carecen de dicho planificador. Sea
como fuere, en ambos casos los procesos hiperpaginarn si no se les asigna un nmero suficiente
de marcos.
b) Soluciones a la hiperpaginacin
Para el problema de la hiperpaginacin existen diversas soluciones:
4-128
Utiliza un algoritmo de reemplazo local pues de esta manera un proceso que hiperpagina no
puede afectar a otro. Sin embargo, el uso intensivo del dispositivo de intercambio podra
afectar al rendimiento del sistema al aumentar el tiempo de acceso efectivo.
Proporcionar a un proceso tantos marcos como le hagan falta. Como ya hemos comentados
en diversas ocasiones, para evitar la hiperpaginacin es necesario asignar al procesos al menos
un nmero mnimos de marcos, que a priori no es conocido. Una de las estrategias que
pretenden estimar dicho nmero es el modelo de conjunto de trabajo.
c) Modelo del conjunto de trabajo

Para entender el modelo de conjunto de trabajo es necesario comenzar definiendo el modelo de
localidad. El modelo de localidad establece que:
Una localidad es un conjunto de pginas que se utilizan juntas.
Cuando un proceso se ejecuta se va moviendo de una localidad a otra.
Por ejemplo, cuando se invoca una subrutina se define una nueva localidad. En esta localidad las
referencias a la memoria se realizan al cdigo de la subrutina, a las variables locales de la misma y a
algunas variables globales del programa.
Supongamos que proporcionamos a un proceso suficientes marcos como para alojar toda su
localidad en un momento dado. Entonces el proceso generar fallos de pgina hasta que todas las
pginas de su localidad estn cargadas, pero despus de eso no volver a fallar hasta que no cambie
a una nueva localidad. Sin embargo si damos al proceso menos marcos de los que necesita su
localidad, ste hiperpaginar.
El modelo de conjunto de trabajo es una estrategia que permite obtener una aproximacin de la
localidad del programa y consiste en lo siguiente:
Definir el parmetro como el tamao de la ventana del conjunto de trabajo.
En un instante dado el conjunto de pginas presente en las referencias ms recientes a la

memoria se consideran el conjunto de trabajo.
Por lo tanto, el conjunto de trabajo es una aproximacin de localidad del programa.
Por ejemplo, dada la siguiente lista de referencias a pginas en la memoria memoria:
4-129
si = 10 referencias a la memoria, entonces el conjunto de trabajo en t1 es {1, 2, 5, 6, 7}. Mientras

que en t2 el conjunto de trabajo es {3, 4}.
Obviamente la precisin del conjunto de trabajo como aproximacin de la localidad del programa
depende del parmetro . Por ejemplo:
Si es muy pequea, el conjunto de trabajo no cubra toda la localidad.
Si es muy grande, el conjunto de trabajo se superpondran a varias localidades.
d) Uso del conjunto del trabajo para evitar la hiperpaginacin

El uso del conjunto de trabajo es bastante sencillo:
1. Se selecciona .
2. El sistema operativo monitoriza el conjunto de trabajo de cada proceso y le asigna tantos

marcos como pginas haya en el conjunto de trabajo.
3. Si sobran suficientes marcos otro proceso puede ser iniciado en el caso de los sistemas
multiprogramados o se puede destinar la memoria libre a otros usos.
4. Si el tamao del conjunto de trabajo D crece y excede el nmero de marcos disponibles, el

sistema podra seleccionar un proceso para ser suspendido. ste podr volver a ser reiniciado
ms tarde.
Donde el tamao del conjunto de trabajo D es la suma del tamao de los conjuntos de trabajo WSSi
para cada proceso i:
D= WSS i (6)
y representa la demanda total de marcos. Por eso si D es mayor que el nmero de marcos
disponibles, habr hiperpaginacin.
4-130
Este sencillo algoritmo anterior permite evitar la hiperpaginacin. Sin embargo, el problema est en
como mover la ventana del conjunto de trabajo en cada referencia, con el fin de volver a calcular el
conjunto de trabajo. Una posible aproximacin sera utilizar un temporizador que peridicamente
invocase a una subrutina encargada de examinar el bit de referencia de las pginas en la ventana .
Es de suponer que las pginas con el bit de referencia a 1 forman parte de la localidad del programa
y por tanto sern el conjunto de trabajo a lo largo del siguiente periodo.
4.5.10. Otras consideraciones

Ya hemos comentado que las principales decisiones que deben ser tomadas en el diseo de un
sistema con paginacin bajo demanda son la eleccin del algoritmo de reemplazo y la del de
asignacin de marcos de pgina. Sin embargo hay otras consideraciones que deben ser tenidas en
cuenta.
a) Prepaginado
El prepaginado es una tcnica que consiste en cargar mltiples pginas junto con la pgina
demandada en cada fallo de pgina. Esas otras pginas se escogen especulativamente bajo la
hiptesis de que van a ser necesitadas por el proceso en un corto espacio de tiempo, de manera que
si la prediccin es acertada la tasa de fallos de pgina se reduce significativamente. Esta tcnica
puede ser utiliza, por ejemplo, en las siguiente situaciones:
En la paginacin bajo demanda pura, donde el sistema sabe de antemano que cuando se inicia
un proceso siempre fallan las primeras pginas de cdigo, por lo que son buenas candidatas
para el prepaginado.
En el acceso secuencial a archivos mapeados en memoria. El sistema puede determinar que el

acceso es de ese tipo tanto mediante el uso de tcnicas heursticas como mediante las
indicaciones dadas por el proceso en la llamada al sistema con la que se abri el archivo. En
cualquier caso, si el sistema determina que el acceso al archivo es secuencial, en cada fallo de
pgina puede cargar tanto la pgina demanda como las siguientes en previsin de que vayan a
ser utilizas por el proceso.
En general el nico inconveniente del prepaginado es que debe ser ajustarlo para que el coste del
mismo sea inferior al de servir los fallos de pgina.
4-131
b) Aplicaciones en modo RAW

Algunas aplicaciones al acceder a sus datos a travs de los mecanismos de memoria virtual del
sistema operativo ofrecen peor rendimiento del que conseguiran si este mecanismo no existiera. El
ejemplo tpico son las bases de datos, que conocen sus necesidades de memoria y disco mejor que
cualquier sistema operativo de propsito general, por lo que salen beneficiadas si implementan sus
propios algoritmos de gestin de la memoria y de buffering de E/S.
Muchos sistemas operativos modernos permiten que los programas que lo soliciten puedan acceder
a los discos en modo raw. En el modo raw no hay sistemas de archivos, ni paginacin bajo
demanda, ni bloqueo de archivos, ni prepaginacin, ni nada; por lo que dichas aplicaciones deben
implementar sus propios algoritmos de almacenamiento y gestin de la memoria. Sin embargo, hay
que tener en cuenta que la mayor parte de las aplicaciones siempre funcionan mejor utilizando los
servicios convencionales ofrecidos por el sistema operativo.
c) Tamao de las pginas

Como ya comentamos al estudiar el mtodo bsico de paginacin (vase el apartado 4.4.1), una
decisin de diseo importante es escoger el tamao adecuado para las pginas:
Con pginas grandes:
Se consiguen menos fallos de pginas. Por ejemplo, en un caso extremo un proceso de

100 KB solo podra generar un fallo de pgina si cada pgina es de 100 KB, pero puede
generar 102400 fallos si cada pagina es de 1 byte.
Se consiguen tablas de pginas ms pequeas.
La E/S para acceder al contenido de cada pgina requiere menos tiempo. En general el
tiempo de transferencia es proporcional a la cantidad de informacin transferida, lo que
debera beneficiar a los sistemas con pginas de pequeo tamao. Sin embargo la
latencia y el tiempo requerido para posicionar la cabeza lectora de los discos es muy
superior al tiempo de transferencias de datos, por lo que es ms eficiente tener menos
transferencias de mayor tamao como cuando se usan pginas de grandes que ms
transferencias de menor tamao como cuando se usan pginas pequeas.
Con pginas pequeas:
4-132
Se consigue tener menos fragmentacin interna y por tanto un mejor aprovechamiento

de la memoria.
Tericamente se obtiene mejor resolucin para asignar y transferir al disco slo la

memoria que realmente necesitamos. Esto a la larga debera redundar en menos memoria
asignada y menos operaciones de E/S.
En la actualidad el tamao de pgina ms comn es de 4KB en sistemas de 32 bits y 8 KB en los de

64 bits, ya que son adecuados para la mayor parte de las aplicaciones. Sin embargo, muchos
sistemas modernos soportan el uso simultneo de mltiples tamaos de pgina. Esto permite que la
mayor parte de las aplicaciones utilicen el tamao estndar, mientras las que hacen un uso intensivo
de la memoria puedan utilizar pginas de mayor tamao. Por ejemplo, en la familia Intel x86 el
tamao estndar es de 4 KB, pero muchas bases de datos como por ejemplo Oracle y ncleos de
sistema operativo como por ejemplo Linux o Solaris utilizan pginas de 4 MB 55 cuando corren
sobre dicha arquitectura.
d) Efecto de la estructura de los programas

Los programas estructurados con un buena localidad de referencia pueden mejorar su rendimiento
en los sistemas con paginacin bajo demanda.
Vamos a ilustrarlo con el siguiente ejemplo de un programa que inicializa a 0 un array de 128 por
128 elementos.
int data[][] = new int[128][128];
for (int j = 0; j < 128; j++)

for (int i = 0; i < 128; i++)
data[i][j] = 0;
Un array como el indicado es almacenado en filas:
data[0][0], data[0][1], ..., data[0][127]
data[1][0], data[1][1], ..., data[127][127]
De manera que si suponemos que el tamao de cada pgina es de 128 palabras, en el mejor de los
casos cada fila estar almacenada en una pgina. Por lo tanto:
55 Es comn que los ncleos de los sistemas operativos utilicen pginas de gran tamao para alojar su cdigo y sus
datos. De esta forma se minimiza el nmero de entradas de la TLB que utilizan, con el fin de disponer de ms
entradas libres para los procesos en ejecucin.
4-133
Si el sistema le asigna 128 marcos o ms, el proceso solo generar 128 fallos de pgina.
Si el sistema operativo le asigna un solo marco, el proceso tendr 16,384 fallos

aproximadamente.
Sin embargo, el ejemplo sera diferente si el bucle interno del programa recorriera las columnas del
array y no las filas:
int data[][] = new int[128][128];
for (int i = 0; i < 128; i++)

for (int j = 0; j < 128; j++)
data[i][j] = 0;
Pues se podran a 0 primero todas las palabras de una misma pgina antes de empezar con la
siguiente, reduciendo el nmero de fallos de pgina a 128 aunque el sistema operativo slo asigne
un marco al proceso.
Por lo tanto se puede concluir que:
La seleccin cuidadosa de las estructuras de datos y de programacin pueden mejorar la

localidad, reduciendo la tasa de fallos de pginas y el tamao del conjunto de trabajo. Por
ejemplo, las pilas tienen buena localidad puesto que el acceso siempre se realiza en lo alto de
las mismas. Sin embargo las tablas de dispersin, obviamente, estn diseadas para dispersar
las referencias, lo que produce una mala localidad.
La eleccin del lenguaje de programacin tambin puede tener efecto. En los lenguajes como
C y C++ se utilizan punteros con frecuencia, lo que aleatoriza el acceso a la memoria
empeorando la localidad de referencia. Adems algunos estudios indican que los lenguajes
orientados a objetos tienden a tener peor localidad de referencia que los que no lo son.
El compilador y el cargador tambin pueden tener un efecto importante:
Separando el cdigo de los datos para permitir que las paginas de cdigo pueda ser de
slo lectura. Esto es interesante porque las paginas no modificadas no tienen que ser
escritas antes de ser reemplazadas.
El compilador puede colocar las subrutinas que se llaman entre s en la misma pgina.
El cargador puede evitar situar las subrutinas de forma que crucen los bordes de las
pginas.
4-134
e) Interbloqueo de E/S
Supongamos que un proceso solicita una operacin de E/S sobre el contenido de alguna de las
pginas de su espacio de direcciones y que la pgina es reemplazada despus de que el proceso
queda en espera pero antes de que la operacin es realizada. En ese caso la operacin de E/S se
podra acabar realizando sobre una pgina que pertenece a un proceso diferente. Para evitarlo
existen diversas soluciones:
Se puede utilizar la memoria del ncleo como buffer en las operaciones de E/S. En una
escritura esto obliga a la llamada al sistema a copiar los datos desde las pginas del proceso a
la memoria del ncleo antes de solicitar la operacin de E/S. Mientras que en las operaciones
de lectura sera justo al contrario.
Cada pgina puede tener un bit de bloqueo que se utiliza para indicar que pginas no pueden
ser seleccionadas para reemplazo.
Adems los bits de bloqueo se pueden utilizar en otras muchas situaciones:
Bloquear las pginas del ncleo para evitar que sean reemplazadas.
Bloquear las pginas que acaban de ser cargadas. Esto evita que un proceso de mayor
prioridad pueda reclamar el marco antes de que el proceso para el que se carg la pgina sea
reiniciado, desperdiciando el trabajo de cargarla y provocando un nuevo fallo de pgina. Para
implementarlo se puede poner el bit de bloqueo a 1 cuando la pgina se carga, volvindolo a
poner a 0 cuando el proceso es planificado por primera vez despus del fallo de pgina que
provoc la carga de la misma.
En los sistemas con tiempo real flexible se suele permitir que las tareas de tiempo real
informen de cuales son las pginas ms importantes con el fin de que sean bloqueadas para
evitar que puedan ser reemplazadas. Para evitar riesgos, el sistema suele considerar ests
solicitudes como consejos de bloqueo, de manera que es libre de descartar dichos consejos si
el conjunto de marcos libres llega a ser demasiado pequeo o si un proceso concreto pide
bloquear demasiadas pginas.
4.6. Interfaz de gestin de la memoria

Gracias a la abstraccin de las tcnicas de memoria virtual como la paginacin bajo demanda
desde el punto de vista de los procesos en cualquier sistema moderno prcticamente slo hace falta
4-135
una llamada al sistema para gestionar su espacio de direcciones virtual. En los sistemas POSIX
como GNU/Linux esta llamada es mmap() junto a su opuesta munmap() y sirve para:
Reservar una porcin de espacio de direcciones virtual del proceso. Obviamente la llamada
slo hace la reserva para que dicha regin pueda ser usada por el proceso, siendo el
componente de paginacin bajo demanda el responsable de asignar la memoria fsica que la
respalda.
Establecer permisos lectura, escritura y ejecucin, opciones de comparticin entre

procesos, bloqueo de pginas en la memoria fsica, pginas de gran tamao, etc. en la regin
de memoria virtual a reservar.
Mapear archivos en regiones del espacio de direcciones virtual.
Sin embargo en funciones como mmap() la pgina es la unidad mnima en la gestin de la memoria.
Es decir, las regiones reservadas del espacio de direcciones virtual siempre comienzan en un borde
de pgina y su tamao es mltiplo del tamao de pgina. La cuestin es como compatibilizar eso
con las necesidades reales de los programas, que durante su ejecucin necesitan reservar y liberar
constantemente memoria para pequeos elementos como: arrays, cadenas de texto, estructuras,
objetos, etc. Para esos casos utilizar directamente mmap() no es una solucin puesto que la
fragmentacin interna con llevara un importante derroche de recursos.
Mx.
sistema operativo
pila
montn
datos
cdigo
0x00000000
Figura 4.9: Proceso en memoria.
4-136
4.6. Interfaz de gestin de la memoria Sistemas Operativos - 2014/2015
4.6.1. Uso del espacio de direcciones virtual del proceso

Los procesos pueden utilizar diversas ubicaciones dentro de su espacio de direcciones virtual para
almacenar los datos que necesitan para su ejecucin (vase la Figura 4.9):
La variables y constantes globales se almacenan en la seccin de datos, que tiene tamao fijo
ya que las dimensiones de estas variables se conocen de antemano en tiempo de compilacin,
al igual que ocurre con el cdigo del programa.
Las variables locales y los argumentos de las subrutinas se almacenan en la pila junto con la
direcciones de retorno de las mismas. Esta es la ubicacin ideal puesto que la pila es
restablecida, en el retorno, al estado que tena antes de invocar la subrutina, haciendo que las
variables locales y argumentos desaparezcan automticamente.
Las variables asignadas dinmicamente por ejemplo, usando malloc()/free() en C o

new/delete en C++ o Java se almacenan en el montn, que no es ms una regin continua
de memoria ubicada inmediatamente despus de la seccin de datos del proceso.
Cada lenguaje de programacin debe proporcionar por ejemplo a travs de su librera estndar
un mecanismo en espacio de usuario adecuado para la gestin en tiempo de ejecucin de la
memoria del montn del proceso. Para eso cada lenguaje puede utilizar su propia implementacin
de dicho mecanismo o bien recurrir a la proporcionada por la librera del sistema. Por ejemplo, en
C++ los operadores new y delete utilizan sus propios algoritmos de gestin de la memoria del
montn, estando optimizados para la creacin y destruccin de objetos de manera eficiente. Sin
embargo, la librera del sistema tambin proporciona su propia implementacin por ejemplo las
funciones malloc() y free() en el caso de los sistemas POSIX que es utilizada directamente por
los programas escritos en C y puede ser empleada por otras implementaciones de lenguajes de
programacin como soporte de la asignacin dinmica de memoria.
4.6.2. Gestin de la memoria del montn

Para ilustrar como se gestiona la memoria del montn utilizaremos como ejemplo el mecanismo
empleado por la librera de sistema de los sistemas POSIX accesible a travs de las funciones
malloc() y free() aunque es importante tener en cuenta que esta tarea se realiza de manera muy
similar en las implementaciones de otros sistemas operativos y lenguajes de programacin.
El funcionamiento bsico de malloc() sigue las siguiente reglas:
4-137
1. Cuando la memoria solicitada supera cierto umbral 128KB en sistemas GNU/Linux es

reservada directamente mediante la llamada al sistema mmap(). Eso significa que las
peticiones de gran tamao realmente no consumen espacio del montn.
2. En caso contrario la peticin de memoria se atiende utilizando un algoritmo de reserva de

memoria continua sobre el espacio libre en el mnton. Estos algoritmos los veremos
posteriormente.
3. Si no hay suficiente memoria libre contigua como para atender la peticin se utiliza la
llamada al sistema brk() para ampliar el tamao del montn sobre la regin no asignada del
espacio de direcciones virtual del proceso.
Cuando un proceso hace una peticin de asignacin de memoria dinmica espera que el espacio
ofrecido sea continuo en el espacio de direcciones virtual, por lo que es necesario utilizar algn
algoritmo de asignacin de memoria contigua. Como las peticiones de los procesos son de tamao
variable, la forma ms eficiente de enfrentar este problema es utilizando lo que se denomina un
esquema de particionado dinmico:
1. La librera mantiene una lista indicando que regiones del montn estn libres y cuales no. El
montn se inicializa con un tamao determinado completamente libre, por lo que es
considerado como un gran hueco de memoria disponible.
2. Cuando un proceso realiza una peticin a travs de malloc() se busca un hueco lo

suficientemente grande para atenderla. Si se encuentra, slo se le asigna el espacio necesario,
que es marcado como ocupado en la lista. El resto sigue siendo considerado como un hueco
libre, aunque de menor tamao.
3. Si el proceso libera una porcin de la memoria y se crean dos huecos adyacentes, se funden
en uno solo.
En general, en un momento dado tenemos una peticin de tamao n que debemos satisfacer con una
lista de huecos libres de tamao variable. Esto no es ms que un caso particular del problema de la
asignacin dinmica de almacenamiento para el que hay diversas soluciones:
En el primer ajuste se escoge el primer hueco lo suficientemente grande como para satisfacer
la peticin. La bsqueda puede ser desde el principio de la lista o desde donde ha terminado la
bsqueda anterior.
En el mejor ajuste se escoge el hueco ms pequeo que sea lo suficientemente grande para
4-138
4.6. Interfaz de gestin de la memoria Sistemas Operativos - 2014/2015
satisfacer la peticin. Indudablemente esto obliga a recorrer la lista de huecos completa o a

tenerla ordenada por tamao.
En el peor ajuste se escoge el hueco ms grande. Igualmente obliga a buscar en toda la lista de
huecos o a tenerla ordenada por tamao.
En la actualidad la estrategia ms comn es utilizar el mejor ajuste junto con algn tipo de
estructura de datos que mantenga los huecos libres ordenados por tamao, de manera que puedan
ser encontrados eficientemente.
4.6.3. Fragmentacin
Las estrategia comentada no sufre de fragmentacin interna porque se asigna exactamente la
cantidad de memoria solicitada. Sin embargo si sufre de otro tipo de fragmentacin denominada
fragmentacin externa.
La fragmentacin externa ocurre cuando hay suficiente espacio libre para satisfacer una peticin
pero el espacio no es contiguo. Es decir, el espacio de almacenamiento est fraccionado en un gran
nmero de huecos de pequeo tamao, obligando a la librera a invocar la llamada al sistema brk()
con el objetivo de incrementar el tamao del montn. Este problema:
Afecta tanto a la estrategia del primer como del mejor ajuste. Siendo el primero mejor en
algunos sistemas y el segundo mejor en otros.
Algunos anlisis estadsticos realizados con el primer ajuste revelan que incluso con algunas
optimizaciones, con n bloques asignados se pierden 0.5n por fragmentacin externa. Es decir,
un tercio de la memoria no es utilizable. A esto se lo conoce como la regla del 50%.
Lamentablemente este problema no tiene una solucin sencilla ya que aunque se podra intentar
mover los bloques de memoria para que toda la memoria libre quedara en un nico hueco, sera
necesario modificar en tiempo de ejecucin las direcciones virtuales utilizadas por el proceso.
4-139
5. Gestin del almacenamiento
5.1. Dispositivos de almacenamiento

Los ordenadores pueden almacenar informacin en diferentes soportes de almacenamiento por
ejemplo en discos magnticos, en CD-ROM, en memorias de estado slido, etc.. Cada uno tiene
propiedades fsicas diferentes que pasamos a comentar brevemente a continuacin.
Figura 5.1: Disco duro.

Sistemas Operativos - 2014/2015 5. Gestin del almacenamiento
sector
sector de
una pista
pista /
cilindro
Figura 5.2: Estructura lgica de un disco magntico.
5.1.1. Discos magnticos

Los discos magnticos son el tipo principal de almacenamiento secundario, generalmente en la
forma de lo que se denomian discos duros. Tal y como se puede apreciar en la Figura 5.1 cada
unidad est compuesta por una serie de platos de forma circular recubiertos de material magntico.
La informacin se almacena grabndola magnticamente sobre los platos, para lo cual se utilizan
unas cabezas de lectura que flotan tanto por encima como por debajo de cada plato.
Desde el punto de vista lgico (vase la Figura 5.2) la superficie de cada plato est dividida en
pistas circulares, cada una de las cuales se subdivide en sectores. El conjunto de pistas formado
por todas aquellas que estn situadas en la misma posicin en los distintos platos se denomina
cilindro.
5.1.2. Discos pticos

Los discos pticos CD, DVD, BluRay, etc. consisten en un disco circular en el cual la
informacin se almacena haciendo uso de surcos microcpicos que se leen haciendo incidir un lser
sobre una de las caras planas que lo componen.
En este tipo de discos la informacin se almacena siguiendo un recorrdio continuo en espiral que
cubre la superficie entera del disco, extendindose desde el interior hacia el exterior. Dado que el
5-142
5.1. Dispositivos de almacenamiento Sistemas Operativos - 2014/2015
lser simpre debe desplazarse sobre la espiral, el acceso aleatorio a los datos es ms lento que con
otras tecnologas de disco.
5.1.3. Memorias de estado slido

Una memoria de estado slido memoria USB, SSD, etc. es un dispositivo de almacenamiento que
usa una memoria no voltil, como las memorias flash, para almacenar datos, en lugar de utilizar
discos pticos o magnticos. Obviamente en este tipo de memorias la informacin se almacena
como en un vector lineal de byes, aunque algunos dispositivos, de cara al resto del sistema
informtico, muestra una interfaz similar a la utilizada por los discos magnticos.
5.2. Archivos y sistemas de archivos

Teniendo en cuenta la gran diversidad de dispositivos de almacenamiento que existen, para que el
sistema informtico sea cmodo de utilizar el sistema operativo proporciona una visin lgica
uniforme de todos los sistemas de almacenamiento. Es decir, abstrae las propiedades fsicas de los
dispositivos de almacenamiento para definir una unidad de almacenamiento lgico que sea til para
los usuarios, el archivo.
Un archivo es una coleccin de informacin relacionada cuya estructura y el significado de los

datos lo define su creador. Desde la perspectiva de los usuarios, un archivo es la unidad ms
pequea de almacenamiento. Es decir, no se pueden escribir datos en el almacenamiento secundario
a menos que estos se encuentren dentro de un archivo.
El sistema operativo puede ofrecer esta abstraccin gracia al sistema de archivos. Este proporciona
los mecanismos para el almacenamiento de lo datos y programas, tanto del propio sistema
operativo como los de todos los usuarios del sistema informtico, as como para acceder a dichos
datos y programas.
Los sistemas de archivos estn compuestos de dos partes claramente diferencias:
Una coleccin de archivos, cada uno de los cuales almacena una serie de datos relacionados.
Una coleccin de estructuras de metadatos, que contienen informacin relativa a los archivos
almacenados nombre, ubicacin en el disco, permisos, etc. y que se encarga de organizarlos,
generalmente haciendo uso de una estructura de directorios.
5-143
5.3. Volmenes de datos

Los dispositivos de almacenamiento comentados anteriormente pueden ser utilizados
completamente con un nico sistema de archivos. Sin embargo en ocasiones es interesante dividir el
dispositivo con el objeto de utilizar mltiples sistemas de archivos. Mientras que por el contrario en
algunos sistemas operativos estas regiones o dispositivos de almacenamiento completos pueden
combinarse para crear estructuras de mayor tamao, denominadas volmenes, cada una de las
cuales puede alberga un sistema de archivos. As que en general utilizaremos el trmino volumen
para referirnos a un espacio de almacenamiento que alberga un sistema de archivos, tanto si ese
espacio es una parte del espacio completo del dispositivo como si se trata de una estructura de
mayor tamao.
A continuacin comentaremos brevemente las tecnologas utilizadas con mayor frecuencia para
construir estos volmenes.
5.3.1. RAID
La tecnologa RAID (Redundant Array of Inexpensive Disks) permite combinar varios discos duros
para mejorar las prestaciones a travs del paralelismo en el acceso y/o para mejorar la fiabilidad a
travs del almacenamiento de informacin redundante. En concreto se definen diversos niveles
RAID, de entre los cuales los ms comunes son:
En un conjunto RAID 0 se distribuyen los datos equitativamente en bloques de tamao fijo

entre dos o ms discos, sin incluir ningn tipo de informacin redundante. Esto permite leer y
escribir ms datos en el mismo tiempo ya que se pueden enviar en paralelo peticiones a los
distintos discos. Sin embargo la fiabilidad es inversamente proporcional al nmero de discos,
ya que para que el conjunto falle basta con que lo haga cualquiera de ellos.
En un conjunto RAID 1 se crea una copia exacta en espejo de los datos en dos o ms
discos. El resultado es que, incluso con dos discos, se incrementa exponencialmente la
fiabilidad respecto a tener uno solo, ya que para que el conjunto falle es necesario que lo
hagan todos los discos. Adicionalmente el rendimiento en las operaciones de lectura se
incrementa linealmente con el nmero de copias, ya que los datos estn disponibles en todos
los discos al mismo tiempo, por lo que se pueden balacear la operaciones de lectura entre
todos ellos.
En un conjunto RAID 5 se distribuyen los datos equitativamente en bloques de tamao fijo
5-144
5.3. Volmenes de datos Sistemas Operativos - 2014/2015
entre dos o ms discos y se utiliza uno adicional para almacenar la informacin de paridad
de los bloques de una misma divisin 56. El disco utilizado para almacenar el bloque de paridad
cambia de forma escalonada de una divisin a la siguiente, de ah que se diga que el bloque de
paridad est distribuido. Algunos aspectos adicionales a tener en cuenta son que:
Cada vez que se escribe un bloque de datos se debe actualizar el bloque de paridad. Por
lo tanto las escrituras en un conjunto RAID 5 son costosas en trminos de operaciones
de disco y trfico.
Los bloques de paridad no se leen durante las lecturas de datos, ya que eso reducira el
rendimiento. Slo se hace en caso de que la lectura de un sector falle, puesto que el
sector en la misma posicin relativa dentro de cada uno de los otros bloques de datos de
la divisin y en el bloque de paridad se pueden utilizar para reconstruir el sector
erroneo.
En un conjunto RAID 5 el fallo de 2 discos provoca la prdida completa de los datos.

Esto significa que aunque se pueden aadir discos de manera ilimitada, eso no suele
ocurrir puesto que a ms discos en el conjunto ms probabilidad de que fallen dos de
ellos.
En un conjunto RAID 6 se utiliza la misma estrategia que en RAID 5 pero utilizando dos
bloques de paridad, lo que permite que fallen hasta dos discos sin perder los datos.
En un conjunto con niveles anidados se combinan varios niveles RAID bsicos como si fueran
capas superpuestas. Ejemplos tpicos son:
RAID 0+1, donde se hace un espejo de un conjunto RAID 0.
RAID 1+0 o RAID 10, donde diversos conjuntos en espejo se combina en un RAID 0,
aumentando la capacidad total.
RAID 50, donde diversos conjuntos RAID 5 se combinan en un RAID 0, aumentando

tambin la capacidad total.
La implementacin de RAID es otra de las reas donde existen diversas variantes:
RAID puede implementarse en el hardware de la controladora de disco, de tal forma que slo
los discos conectados a esta pueden formar parte de un conjunto RAID determinado. Esta
56 En RAID se denomina divisin o stripe a la serie de bloques consecutivos escogido cada uno de uno de los discos
del conjunto.
5-145
solucin es muy eficiente, especialmente cuando se utilizan niveles que requieren clculo de la
paridad, ya que se evita utilizar tiempo de CPU para ese trabajo. Sin embargo estas
controladoras son notablemente ms caras que las que carecen de soporte para RAID.
RAID puede implementarse dentro del sistema operativo en lo que se denomina el software de
gestin de volmenes. En este caso las soluciones RAID con paridad son bastante lentas por
lo que normalmente slo se soportan los niveles RAID 0, 1, 10 o 0+1. Adems algunas
controladoras modernas que dicen venir con soporte RAID realmente implementan esta
tecnologa en software, a nivel del controlador de dispositivo, mientras que en el hardware
slo se implementan unas caractersticas de apoyo mnimas57.
Cada conjunto RAID se comporta como una unidad de almacenamiento independiente desde el
punto de vista del resto del sistema, por lo que se puede utilizar entero para albergar un nico
sistema de archivos. Sin embargo lo ms comn es dividirlo en regiones con el objeto de utilizar
mltiples sistemas de archivos o combinarlo en estructuras de mayor tamao, para lo cul se pueden
utilizar alguna de las tcnicas que veremos a continuacin.
5.3.2. Particiones
Un disco, un conjunto RAID o cualquier otro dispositivo de almacenamiento se puede dividr en
regiones para utilizar en cada una de ellas un sistema de archivos diferente. A esas regiones se las
conoce comnmente como particiones, franjas o minidiscos.
Segn la plataforma, existen diversas maneras de implementar el soporte de particiones. Entre los
sistemas de escritorio las tecnologas ms difundidas y utilizadas son la MBR (Master Boot Record)
y la GPT (GUID Partition Table). En mbas se almacena, en los primeros sectores del dispositivo
de almacenamiento, una tabla con una entrada por particin donde se guardan las direcciones del
primer y ltimo sector de cada una de ellas en el dispositivo, as como otra informacin. Eso es
todo lo que necesita el sistema operativo para determinar los lmites de la regin ocupada por cada
sistema de archivos.
57 En algunos entornos se denomina a este tipo de implementaciones fakeRAID o hostRAID.
5-146
5.3. Volmenes de datos Sistemas Operativos - 2014/2015
5.3.3. Volmenes dinmicos

Segn la tecnologa que se utilice para particionar es posible encontrarse con una serie de
restricciones comunes:
El limitado nmero de particiones diferentes que puede contener un mismo dispositivo.
Limitaciones o imposibilidad de redimencionar las particiones. Especialmente si el sistema

operativo est en ejecucin.
La imposibilidad de crear particiones que hagan uso de regiones libres en diferentes

dispositivos de almacenamiento.
Para resolverlo algunos sistemas operativos incluyen un software de gestin de volmenes que hace
uso de tecnologa propia para superar estas limitaciones. Estas herramientas generalmente permiten
agrupar dispositivos completos, conjuntos RAID, particiones, etc. y sobre ellos construir los
volmenes que sean necesarios. Estos volmenes pueden ser redimensionados en ocasiones sin
tener que deterner la ejecucin del sistema operativo y en caso de que haga falta se pueden incluir
dinmicamente nuevos dispositivos para incrementar el espacio disponible. Adems, como ya
hemos comentado, el software de gestin de volmenes puede incluir alguna funcionalidad propia
de conjuntos RAID con el objeto de mejorar las prestaciones, a travs del paralelismo en el acceso,
y/o mejorar la fiabilidad, a travs del almacenamiento de informacin redundante.
programas de aplicacin
sistema lgico de archivos
mdulo de organizacin de archivos
sistema bsico de archivos
control de E/S
dispositivos
Figura 5.3: Estructura de un sistema de archivos.
5-147
5.4. Sistemas de archivos

Cada volumen puede albergar un sistema de archivos. A continuacin estudiaremos los elementos
ms comunes a la mayor parte de los sistemas de archivos.
5.4.1. Estructura de un sistema de archivos

Un sistema de archivos suele estar compuesto de varios niveles diferentes. En la Figura 3.7 se
muestra un ejemplo tpico de la estructura de un sistema de archivos diseado en niveles. Cada
nivel utiliza las funciones de los niveles inferiores y proporciona nuevas funciones a los niveles
superiores:
1. En el nivel ms bajo, accediendo directamente a los dispositivos de almacenamiento, se

encuentra el control de E/S. ste est compuesto por los controladores de dispositivo
encargados de transferir la informacin entre la memoria principal y el disco. Estos
controladores, que generalmente son compartidos entre los distintos sistemas de archivos,
transfieren los datos en unidades de bloques, en lugar de transferir un byte cada vez, para
mejorar la eficiencia . Cada bloque est formado por uno o ms sectores58.
2. El sistema bsico de archivos se encarga de enviar comandos genricos al controlador de

dispositivo apropiado con el fin de leer y escribir bloques fsicos en el disco. Cada bloque
fsico se identifica mediante su direccin de disco numrica (por ejemplo: unidad 1, cilindro
73, cabeza 2, sector 10).
3. El mdulo de organizacin de archivos tiene conocimiento de los archivos y se encarga de

traducir las direcciones lgicas de bloque nmeros de bloque dentro del archivo en las
direcciones fsicas de bloque direccones de los bloques correspondientes en el dispositivo de
almacenamiento que sern enviadas al sistema bsico de archivos para que realice las
transferencias solicitadas. Los bloques lgicos de cada archivo son numerados de 0 a N, pero
los bloques fsicos asignados a estos bloques lgicos no tienen porqu coincidir en los
nmeros de bloque. Por eso el mdulo de organizacin de archivos debe utilizar la ubicacin
del contenido del archivo y la informacin sobre la asignacin de bloques, para traducir las
direcciones lgicas en direcciones fsicas. Adems, el mdulo de organizacin incluye el
58 Dependiendo de la unidad de disco, los sectores pueden tener tamaos de entre 32 bytes y 4096 bytes. Lo ms
comn es que su tamao sea de 512 bytes.
5-148
5.4. Sistemas de archivos Sistemas Operativos - 2014/2015
gestor de espacio libre, que controla los bloques no asignados y proporciona dichos bloques
cuando el mdulo de organizacin de archivos lo necesita.
4. El sistema lgico de archivos gestiona los metadatos. Los metadatos incluyen toda la
estructura del sistema de archivos, excepto los propios datos de los archivos. Entre dichos
metadatos est la estructura de directorios y los bloques de control de archivo. Un bloque de
control de archivo o FCB (File Control Block) contiene informacin acerca del archivo,
incluyendo su propietario, los permisos y la ubicacin del contenido del mismo. Adems, el
sistema lgico de archivos tambin es responsable de las tareas de proteccin y seguridad.
Cada sistema operativo puede soportar uno o ms sistemas de archivos para dispositivos de disco.
Por ejemplo, en los sistemas UNIX se utiliza el sistema de archivos UNIX o UFS (UNIX File
System), que est basado en el sistema FFS (Fast File System) de Berkeley. Microsoft Windows
NT/2000/XP soporta los sistemas de archivo FAT, FAT32 y NTFS (NT File System). En Linux se
soportan ms de cuarenta sistemas de archivo, entre los que podramos destacar: el sistema de
archivos extendido ext2, ext3 y ext4 XFS y BtrFS. Adems la mayora de los sistemas operativos
modernos soportan otros sistemas de archivo, como los utilizados en los soportes removibles. Por
ejemplo el ISO-9660, utilizado por la mayor parte de los CD-ROM, o el UFS (Universal File
System), utilizado por los DVD-ROM.
5.4.2. Estructuras de metadatos

Para implementar un sistema de archivos se utilizan diversas estructuras de metadatos alojadas tanto
en el disco como la memoria. Estas estructuras varan dependiendo del sistema operativo y del
sistema de archivos. Sin embargo, a continuacin intentaremos describir brevemente las estructuras
en disco de uso ms comn:
Un bloque de control de arranque (bloque de inicio o sector de arranque) que suele ocupar
el primer bloque de cada volumen y que contiene la informacin necesaria para iniciar un
sistema operativo a partir de dicho volumen. Este bloque puede estar vaco, si el volumen no
contiene un sistema operativo.
Un bloque de control de volumen que contiene todos los detalles acerca del volumen, tales
como: el nmero mximo de bloques, el tamao de los bloques, el nmero de bloques libres y
punteros a los mismos, as como un contador de bloques de informacin FCB y punteros a
estos. En los sistemas de archivos para UNIX y Linux, a esta estructura se la denomina
5-149
superbloque. Mientras que en NTFS esta informacin se almacena en la tabla maestra de

archivos o MFT (Master File Table).
Un FCB por cada archivo donde se almacenan numerosos detalles sobre el mismo, por
ejemplo: los permisos, el propietario, el tamao y la ubicacin de los bloques de datos. En
trminos generales todos los FCB del sistema de archivos se almacenan en una tabla
denominada irectorio de dispositivo o abla de contenidos del volumen. En los sistemas de
archivos para UNIX y Linux cada FCB se denomina inodo y se almacenan a continuacin del
superbloque. En NTFS esta informacin se almacena en la MFT, ya que cada entrada de dicha
tabla es un FCB.
Una estructura de directorios para organizar los archivos. En los sistemas de archivos para
UNIX y Linux, cada directorio almacena los nombres de los archivos que contiene y los
nmeros de FCB asociados a los mismos. En NTFS es similar aunque la estructura de
directorios completa se almacena en la MFT.
La informacin almacenada en memoria se utiliza tanto para la gestin del sistema de archivo como
para mejorar el rendimiento del mismo mediante mecanismos de cach. Los datos se cargan en el
momento comenzar a utilizar el sistema de archivos del montaje y se descartan cuando se va a
dejar de hacer uso del mismo desmontaje. Las estructuras existentes en la memoria pueden
incluir las que a continuacin se describen:
Una tabla de montaje en memoria que contiene informacin acerca de cada volumen
montado.
Una cach en memoria de la estructura de directorios que almacena la informacin relativa a

los directorios a los que se han accedi recientemente. Los directorios que actan como
puntos de montaje puede contener un puntero a la entrada, en la tabla de montaje, del volumen
montado en el directorio.
La tabla global de archivos abiertos que contiene una copia del FCB de cada archivo abierto
en el sistema, adems de otras informaciones.
La tabla de archivos abiertos de cada proceso contiene un puntero a la entrada apropiada de

la entrada global de archivos abiertos, as como otras informaciones adicionales que son
particulares de cada proceso.
5-150
5.4.3. Montaje de sistemas de archivos

Un sistema de archivos debe montarse para que sus archivos sean accesibles a los procesos del
sistema. El proceso de montaje incluye los siguientes pasos:
1. Al sistema operativo se le debe proporcionar el nombre del dispositivo y el punto de montaje.

El punto de montaje es la ubicacin dentro de la estructura de directorios el directorio
concreto a la que queremos conectar el sistema de archivos. Despus de que el proceso de
montaje se haya completado, los archivos y directorios del sistema de archivos montado sern
accesibles como descendientes del directorio del punto de montaje.
2. A continuacin el sistema operativo verifica que el dispositivo contiene un sistema de

archivos vlido. Para ello lee el bloque de control de volumen y comprueba que tiene un
formato vlido.
3. Finalmente el sistema operativo registra en la tabla de montaje y en la estructura de

directorios en memoria que hay un sistema de archivos montado en la ubicacin especificada.
Esto permite que pueda ser recorrida la estructura de directorios, pasando de un sistema de
archivos a otro, segn sea necesario.
En muchos sistemas operativos modernos el montaje se ejecuta automticamente cuando los

dispositivos son detectados durante el arranque del sistema o cuando se conectan durante el
funcionamiento del mismo (por ejemplo cuando se inserta un medio en la unidad CD-ROM o se
pincha una memoria flash en un puerto USB). Adems en algunos se permite que el administrador
del equipo ejecute operaciones de montaje manuales.
5.4.4. Archivos
Cada sistema de archivos contiene una tabla donde cada entrada almacena un bloque de control de
archivo o FCB (File Control Block) por archivo. Concretamente en cada FCB se almacena diversa
informacin acerca del archivo al que representa.
a) Atributos de archivos
La coleccin de atributos asociada a un archivo vara de un sistema operativo a otro, pero
tpicamente son los siguientes:
5-151
Nombre. Nombre simblico del archivo que se mantiene en un formato legible para
conveniencia de las personas.
Identificador. Identifica de forma unvoca el archivo dentro del sistema de archivos.

Generalmente es el numero del FCB que le corresponde en la tabla de contenidos del volumen.
Tipo. Es un atributo necesario en los sistemas que soportan diferentes tipos de archivos.
Ubicacin. Es un puntero a un dispositivo y a la ubicacin del archivo dentro del mismo.
Tamao. Indica el tamao actual de archivo (en bytes, palabras o bloques) y, posiblemente, el
tamao mximo permitido.
Proteccin. Informacin de control de acceso que determina quin puede leerlo, escribirlo,
ejecutarlo, etc.
Fecha, hora e identificacin del usuario. Esta informacin puede mantenerse para los
sucesos de creacin, de ltima modificacin y ltimo uso del archivo. Esto puede resultar til
para la proteccin, seguridad y monitorizacin del uso del archivo.
Los atributos de los archivos se almacenan en las estructuras de metadatos. Normalmente el nombre
se almacena en la estructura de directorios, de tal manera que una entrada de directorio est
compuesta del nombre de un archivo y de su identificador. A su vez, dicho identificador permite
localizar el FCB que contiene el resto de los atributos del archivo.
b) Operaciones con los archivos

Un archivo es un tipo abstracto de datos sobre el que pueden realizarse diversas operaciones.
Concretamente el sistema operativo proporciona llamadas al sistema para: crear, escribir, leer,
reposicionar59, borrar y truncar archivos. Adems en muchos sistemas se suelen incluir llamadas
para otras operaciones comunes, como aadir datos al final de un archivo o el renombrado de un
archivo existente. Estas operaciones primitivas puede combinarse a su vez para realizar otras
operaciones ms complejas por ejemplo podemos crear una copia de un archivo o moverlo a otro
lugar de la estructura de directorios. Adems muchos sistemas tambin disponen de operaciones
59 Generalmente el sistema mantiene un puntero de lectura/escritura que hace referencia a la ubicacin dentro del
archivo en la que debe tener lugar la siguiente operacin. Este puntero se actualiza avanzando cada vez que se
realiza un nueva lectura/escritura. Para desplazarse aleatoriamente por el archivo, el sistema operativo debe ofrecer
una llamada al sistema que permita reposicionar el puntero all donde interese.
5-152
para consultar y modificar diversos atributos de un archivo, como la longitud o el propietario del
mismo.
La mayor parte de estas operaciones implican realizar una bsqueda en el directorio para encontrar
la entrada asociada con el archivo cuyo nombre se ha indicado. Para evitarlo muchos sistemas
requieren60 que el proceso haga una llamada al sistema open(), antes de realizar cualquiera de
estas operaciones por primera vez sobre un archivo. En concreto esta llamada al sistema:
1. Busca en el directorio el nombre del archivo hasta encontrar la entrada sociada y recupera el
identificador del mismo
2. Utiliza el identificador del archivo para recuperar el FCB correspondiente.
3. Crea una entrada para el archivo en la tabla de archivos abiertos donde se almacena la
informacin del FCB.
4. Retorna devolviendo un identificador en forma de puntero o de ndice a la nueva entrada en

la tabla de archivos abiertos.
El nombre con el que se designa a esas entradas en la tabla de archivos abiertos vara de unos
sistemas a otros. En los sistemas UNIX se utiliza el trmino descriptor de archivo o file
descriptor mientras que en los sistemas Microsoft Windows se prefiere el trmino manejador de
archivo o file handler.
Despus de utilizar la llamada al sistema open(), cuando se desee solicitar una operacin sobre un
archivo slo es necesario proporcionar el identificador devuelto, evitando as que haga falta realizar
exploracin alguna del directorio. Cuando el archivo deja de ser utilizado activamente por el
proceso, puede ser cerrado utilizado la llamada al sistema close().
En los sistemas operativos donde varios procesos pueden abrir un mismo archivo se suelen utilizar
dos niveles de tablas de archivos abiertos:
1. Una tabla para cada proceso almacenada en el PCB donde se indican todos los archivos
que ste ha abierto. En dicha tabla se almacena toda la informacin referente al uso de cada
archivo por parte de un proceso. Por ejemplo se puede almacenar la posicin actual utilizada
por las operaciones de lectura y escritura o los derechos de acceso.
60 En unos pocos sistemas los archivos se abren automticamente cuando un proceso solicita su primera operacin
sobre los mismos y se cierran cuando el proceso termina. Sin embargo lo ms comn es que los procesos tengan que
abrir los archivos explcitamente.
5-153
2. Una tabla global para todo el sistema donde se almacena toda la informacin independiente
de los procesos, como la ubicacin del archivo en el disco, las fechas de acceso y el tamao
del archivo.
Cuando un proceso invoca la llamada open() se aade una entrada en la tabla de archivos abiertos
del proceso, que a su vez apunta a la entrada correspondiente dentro de la tabla global del sistema.
Si el archivo no existe en esta ltima, tambin hay que crear una entrada en la tabla global del
sistema haciendo uso de la informacin contenida en el FCB correspondiente. Por otro lado es muy
comn que la tabla global almacene un contador de aperturas para cada archivo con el objetio de
indicar cuantos procesos lo mantienen abierto. Dicho contador se decrementa con cada llamada al
sistema close(), de forma que cuando alcance el cero querr decir que la entrada puede ser
eliminada de la tabla global de archivos abiertos.
c) Tipos de archivo
Cuando se disea un sistema operativo es necesario considerar si debe reconocer y soportar el
concepto de tipo de archivo. Si el sistema operativo reconoce el tipo de un archivo puede operar con
el mismo de formas razonables. Por ejemplo, el sistema puede impedir que un usuario intente
imprimir los archivos que contienen programas en formato binario, pues el documento impreso
sera ininteligible.
En los sistemas operativos ms comunes las tcnicas utilizadas para implementar los tipos de
archivo son las siguientes:
En MSDOS y Microsoft Windows el tipo de archivo se incluye como parte del nombre del
archivo. Es decir, el nombre se divide en dos partes: un nombre y una extensin; normalmente
separadas por un carcter de punto. El sistema puede utilizar la extensin para conocer el tipo
de archivo y el tipo de operaciones que se pueden realizar con el mismo.
En Mac OS X cada archivo tiene un atributo que almacena el tipo (por ejemplo, TEXT para los
archivos de texto o APPL para las aplicaciones) y otro que contiene el nombre del programa
que lo cre. Cuando el usuario hace clic con el ratn sobre el icono de un archivo, el programa
que lo cre se ejecuta automticamente y el archivo se carga en la memoria.
En los sistemas UNIX se utiliza un nmero mgico almacenado al principio de algunos

archivos para indicar el tipo del mismo. No todos los archivos tienen nmeros mgicos, por lo
que se permite hacer sugerencias en forma de extensiones del nombre del archivo. Sin
5-154
embargo estas extensiones ni son obligatorias ni el sistema depende de ellas.

Fundamentalmente su objetivo es ayudar a los usuarios a determinar el tipo de contenido de un
archivo, por lo que pueden ser utilizadas o ignoradas por cada aplicacin concreta, en funcin
de las preferencias de sus desarrolladores.
5.4.5. Estructura de directorios

Algunos sistemas de archivos pueden almacenar millones de archivos en terabytes de disco. Para
gestionar todos esos datos necesitamos organizarlos de alguna manera, lo que generalmente implica
el uso de directorios. Un directorio puede considerarse una tabla de smbolos que traduce los
nombre de los archivos en los identificadores que permiten recuperar sus correspondientes
entradas en la tabla de contenidos del volumen, donde se almacenan los FCB. A continuacin
vamos a estudiar los diversos esquemas para definir la estructura lgica del sistema de directorios.
a) Directorios de un nivel
En la estructura de directorios de un nivel todos los archivos estn contenidos en un nico
directorio; sin embargo esto presenta algunas limitaciones:
Cuando el nmero de usuarios del sistema aumenta se hace ms difcil que cada uno escoja
nombres diferentes para sus archivos, lo cual es necesario puesto que todos los archivos se
encuentran en el mismo directorio.
Incluso en los sistemas operativos monousuario puede ser difcil para un usuario mantener
organizados sus datos a media que se incrementa el nmero de archivos.
Este esquema fue utilizado por la primera versin del sistema operativo MSDOS.
b) Directorio de dos niveles

En la estructura de directorios de dos niveles cada usuario tiene su propio directorio de archivos
de usuario o UFD (User File Directory) que cuelga del directorio maestro de archivos o MFD
(Master File Directory). Cuando un usuario se conecta al sistema o inicia un trabajo se explora el
MFD, que est indexado por el nombre de los usuarios o por los nmeros de cuenta, donde cada una
de sus entradas apunta al UFD de dicho usuario. Puesto que cada UFD incluye slo los archivos del
usuario al que pertenece, el sistema operativo puede confinar todas las operaciones que puede
5-155
realizar un usuarios sobre los archivos a su UFD. Sin embargo, aunque esto resuelve el problema de
la colisin de nombres entre diferentes usuarios, tambin presenta algunas desventajas:
La estructura descrita aisla a los usuarios, lo cual puede ser un problema cuando stos quieren
compartir datos para cooperar en alguna tarea. La solucin pasa por utilizar nombres de ruta
para designar a un archivo de forma unvoca. Por ejemplo, si el usuario usera quiere acceder a
su archivo test, simplemente debe referirse a el como test. Mientras que si quiere acceder al
archivo test del usuario userb, debe utilizar un nombre de ruta como /userb/test, donde se
indica el nombre del usuario y el nombre del archivo. En general cada sistema operativo
utiliza su propia sintaxis par nombrar los archivos contenidos en los directorios de otros
usuarios.
Incluso en este caso puede ser difcil para un usuario mantener organizados sus datos a media
que se incrementa el nmero de archivos.
c) Directorios con estructura de rbol

La estructura de directorio de dos niveles puede generalizarse en la estructura de directorios en
rbol de altura arbitraria. Esto permite que los usuarios puedan crear sus propios subdirectorios
para organizar sus archivo de la forma ms conveniente.
Cada sistema de archivos tiene un directorio raz que puede contener tanto archivos como otros
directorios. A su vez cada directorio puede contener un conjunto de archivos y subdirectorios.
Normalmente cada entrada de directorio incluye un bit donde se indica si dicha entrada apunta a un
archivo o a un subdirectorio. Esto se hace as porque los directorios no son ms que archivos con un
formato interno especial, por lo que el sistema debe saber si la entrada apunta a un directorio para
interpretar correctamente los datos del directorio.
Generalmente cada proceso tiene un directorio actual, de forma que cuando se hace referencia a un
archivo se busca en ese directorio. Si se necesita un archivo que no se encuentra en el directorio
actual, entonces el usuario debe especificar un nombre de ruta o cambiar el directorio actual al
directorio donde fue almacenado el archivo. Los nombres de ruta pueden ser de dos tipos:
Un nombre de ruta absoluto comienza en la raz y va indicando los directorios que componen
la ruta de forma descendente hasta llegar al archivo especificado.
Un nombre de ruta relativo define una ruta a partir del directorio actual.
Con una estructura de directorios en rbol se puede permitir que unos usuarios accedan a los
5-156
archivos de otros. Para eso slo es necesario que se utilicen nombres de ruta para designar los
archivos o que se cambie el directorio actual.
Este tipo de estructura de directorios es la utilizada por MSDOS y por las distintas versiones de
Microsoft Windows.
d) Directorios en grafo acclico

La estructura de directorio en grafo acclico es una generalizacin natural del esquema con
estructura en rbol. A diferencia de ste ltimo, la estructura en grafo acclico permite que los
mismo archivos y subdirectorios existan simultneamente en distintos lugares de la estructura de
directorios. Esto, por ejemplo, hace que los usuarios puedan compartir archivos de forma que se
puedan acceder a los mismo directamente desde el directorio propiedad de los distintos usuarios.
Indudablemente eso significa que para acceder a un archivo o directorio pueden existir diversas
rutas.
Los archivos y subdirectorios compartidos pueden implementarse de diversas formas:
Se pueden crear una entrada de directorio denominada enlace. Un enlace es, generalmente,
un archivo que contiene la ruta relativa o absoluta de otro archivo o subdirectorio. En los
sistemas UNIX a estos se los conoce como enlaces simblicos.
Tambin se pueden duplicar toda la informacin de la entradas de directoio de los archivos

compartidos en todos los directorios que comparten dichos archivos. As, mientras que los
enlaces son claramente diferentes de la entrada original de directorio, las entradas de
directorio duplicadas hacen que el original y la copia sean indistinguibles. En los sistemas
UNIX a las entradas duplicadas se las conoce como enlaces duros.
Una estructura en grafo acclico es ms flexible que una estructura en rbol, pero no por eso est
exenta de inconvenientes:
Si estamos intentando recorrer el sistema de archivos completo por ejemplo, para buscar
un archivo o para copiarlos en un dispositivo de copias de seguridad debemos evitar
acceder ms de una vez a los archivos y subdirectorios compartidos. No olvidemos que en
los sistemas con estructura en grafo acclico cada archivo puede tener mltiples nombres de
ruta absoluta. Esto es ms sencillo de resolver en el caso de los enlaces, puesto que podemos
evitar recorrerlos al ser claramente distinguibles del archivo original.
Cundo puede liberarse el espacio asignado a un archivo compartido? Si lo hacemos
5-157
cuando un usuario lo borra podramos dejar punteros que referencian a archivos que no
existen.
El caso ms sencillo de resolver es el de los enlaces ya que pueden ser borrados sin que
el archivo original se vea afectado, puesto que lo que se elimina es el enlace y no el
archivo original.
Si lo que se pretende borrar es la entrada de un archivo original que es apuntado desde

un enlace, entonces no hay problema en hacelo y liberar el espacio asignado al mismo,
dejando que el enlace apunte a un archivo que no existe. Ciertamente podramos
plantearnos la posibilidad de buscar esos enlaces y eliminarlos pero, a menos que el FCB
de cada archivo guarde las rutas a los enlaces que le sealan, esta bsqueda puede ser
muy costosa. Por eso lo ms comn es conservar los enlaces hasta que se produzca un
intento de utilizarlos, en cuyo caso determinaremos que el archivo referenciado fue
borrado y trataremos el acceso al enlace de forma similar a cualquier otro acceso ilegal a
un archivo que no existe.
Otra opcin es almacenar en la entrada del archivo original un contador con el nmero
de referencias al archivo. As, cuando el contador sea 0, sabremos que a llegado el
momento de liberar el espacio asignado. En los sistemas UNIX se utiliza esta tcnica
para los enlaces duros.
Por ltimo no debemos olvidar que la estructura de directorios en grafo se conserva acclica si se
prohbe que hayan mltiples referencias a un mismo directorio. Ese es el motivo por el que en los
sistemas UNIX no se permite que los enlaces duros hagan referencia a directorios. Sin embargo si
se pueden utilizar enlaces simblicos para este fin, puesto que al ser distinguibles del directorio
original podemos evitar los ciclos si mientras se explora se ignorar dichos enlaces.
e) Directorios en forma de grafo general

Uno de los principales problemas de la estructura de directorios en grafo acclico es garantizar que
no exista ningn ciclo. Esto es interesante puesto que mientras sea as los algoritmos diseados para
recorrer el grafo y para determinar cuando no existen ms referencias a un archivo son
relativamente simples. No olvidemos que:
Es importante evitar encontrar cualquier archivo dos o ms veces, tanto por razones de
correccin como de rendimiento.
5-158
En una estructura de directorios en forma de grafo donde existan ciclos puede que el
contador de referencias no sea 0, aunque no hayan ms referencias al archivo. Esto significa
que generalmente se necesita algn mecanismo de recoleccin de basura 61 para determinar con
seguridad cuando se ha borrado la ltima referencia. Sin embargo la recoleccin de basura
para un sistema de archivos basado en disco consume mucho tiempo, por lo que en pocas
ocasiones se utiliza.
Por tanto, es mucho ms sencillo trabajar con estructuras de directorio en grafo acclico. Para evitar
que en un grafo aparezca un ciclo al aadir un nuevo enlace, se pueden utilizar diversos algoritmos.
Sin embargo, y puesto que estos son muy costosos, lo ms comn es ignorar los enlaces durante el
recorrido de los directorios. En el caso de la duplicacin de entradas de directorio (donde las
entradas duplicadas no se pueden distinguir de la original) lo ms sencillo es evitar que puedan
haber mltiples referencias a un mismo directorio.
5.5. Comparticin de archivos

Como ya hemos comentado, el que los usuarios puedan compartir archivos es algo muy deseable
pues permite que stos puedan colaborar en la realizacin de una tarea determinada. Sin embargo al
aadir esta caracterstica hay que tener en cuenta algunos aspectos que deben ser resueltos en el
diseo del sistema operativo.
5.5.1. Mltiples usuarios y proteccin

Cuando un sistema operativo admite mltiples usuarios y utiliza una estructura de directorio que
permite que stos compartan archivos, cobra gran importancia la proteccin de los datos. En este
sentido el sistema operativo debe adoptar un papel de mediador en lo que respecta a la comparticin
de los archivos.
Para implementar la comparticin y los mecanismo de proteccin el sistema debe soportar ms

atributos para cada archivo y directorio que los que necesita en un sistema monousuario. Aunque a
lo largo de la historia se han adoptado diversos enfoques, la mayora han evolucionado hasta utilizar
los conceptos de propietario (o usuario) y grupo de un archivo:
61 La recoleccin de basura implica recorrer todo el sistema de archivos y marcar todos aquellos elementos que sean
accesibles. Despus, en una segunda pasada, se elimina todo lo que no est marcado.
5-159
El propietario de un archivo es el usuario que puede cambiar los atributos y conceder el

acceso. Se trata del usuario que dispone del mayor grado de control sobre el archivo.
El grupo es un conjunto de usuarios que pueden compartir el acceso al archivo. El propietario

del archivo es quien define que operaciones pueden ser ejecutadas por los miembros del grupo.
Los identificadores del propietario y el grupo de un archivo se almacenan junto con los otros
atributos en el FCB. Cuando un usuarios solicita realiza una operacin sobre un archivo, se compara
el identificador del usuario con el atributo del propietario para determinar si el solicitante es el
propietario. Exactamente de la misma manera se puede proceder con los identificadores de grupo.
El resultado de la comparacin indicar que permisos son aplicables. A continuacin el sistema
aplicar dichos permisos a la operacin solicitada y la autorizar o denegar segn sea el caso.
Existen diversas implementaciones del esquema utilizado para determinar los permisos aplicables
aun usuario que pretende operar sobre un archivo concreto:
El esquema ms general consiste en asociar a cada archivo o directorio una lista de control
de acceso o ACL (Access-control list) que especifique los nombres de usuario o grupos y los
tipos de acceso para cada uno. Cuando un usuario solicita acceder a un archivo concreto, el
sistema operativo comprueba la ACL asociada a dicho archivo. Si dicho usuario, o alguno de
sus grupos, est incluido en la lista para el tipo de acceso solicitado, se permite el acceso. Esta
tcnica presenta diversas ventajas e inconvenientes:
Se trata de la tcnica ms general, permitiendo la implementacin de complejas

metodologas de acceso.
Sin embargo, construir la lista puede ser una tarea tediosa. Por ejemplo, si queremos
que varios usuarios puedan leer unos archivos determinados, es necesario enumerar
todos los usuarios que disponen de ese acceso en las ACL de dichos archivos.
El FCB, que hasta el momento tena un tamao fijo, ahora tendr que ser de tamao
variable para almacenar la ACL, lo que requiere mecanismo ms complejos de gestin
del espacio.
Para solucionar algunos de los problemas de las ACL muchos sistemas utilizan listas de
control de acceso condensadas. Para condensar la longitud de la lista de control de acceso,
muchos sistemas clasifican a los usuarios en tres grupos: propietario, grupo y todos. As slo
es necesario un campo para cada clase de usuario, siendo cada campo una coleccin de bits,
donde cada uno permite o deniega el tipo de acceso asociado al mismo. Por ejemplo, en los
5-160
5.5. Comparticin de archivos Sistemas Operativos - 2014/2015
sistemas UNIX se definen 3 campos (propietario, grupo y todos) de 3 bits cada uno: rwx,
donde r controla el acceso de lectura, w controla el acceso de escritura y x controla la
ejecucin. Las ACL condensadas son ms sencillas de construir, al mismo tiempo que por
tener una longitud fija es mucho ms simple gestionar el espacio para el FCB donde se
almacena.
La tcnica ms comn en los sistemas operativos modernos consiste en combinar ambos tipos
de listas de control de acceso. Sin embargo esta solucin no est exenta de dificultades:
Uno de los problemas es que los usuarios deben poder determinar cuando estn
activados los permisos ACL ms generales. En Linux, por ejemplo, se utiliza el smbolo
+ detrs de los permisos de la ACL condensada para indicar dicha circunstancia. Esos
permisos pueden ser gestionados utilizando los comandos setfacl y getfacl.
Otra dificultad es la relativa a la asignacin de precedencias cuando ambas ACL entran

en conflicto. En general se suele asignar a la ACL ms prioridad que a la ACL
condensada, pues la primera tiene una granularidad ms fina y no se crea de forma
predeterminada.
La familia de sistemas operativos Microsoft Windows utiliza las ACL ms generales, mientras que
en los sistemas operativos Linux y Solaris se implementan ambos tipos de ACL.
Otra tcnica para resolver el problema de la proteccin consiste en asociar una contrasea con
cada archivo o directorio. Sin embargo esto tiene el inconveniente de que el nmero de contraseas
que un usuario puede tener que recordar puede ser muy grande. No olvidemos que si se utiliza la
misma contrasea para todos los archivo, desde el momento en que esa contrasea sea descubierta
todos los archivos sern accesibles.
5.5.2. Semntica de coherencia

La semntica de coherencia especifica cuando las modificaciones que un usuario realice en los
archivos sern observables por los otros usuarios. La semntica de coherencia est directamente
relacionada con los algoritmos de sincronizacin de procesos (vase tema 3.3.3). Sin embargo es
normal que esos complejos algoritmos no se implementen en el caso de la E/S de archivo, debido a
la alta latencia y las bajas velocidades de la transferencia de los discos y de las redes.
A continuacin vamos comentar algunos ejemplos de semntica de coherencia:
5-161
Semntica de UNIX
Los sistemas de archivos de los sistemas operativos UNIX utilizan la siguiente semntica de
coherencia:
Las escrituras en un archivo abierto por parte de un proceso son visibles inmediatamente
para los otros usuarios que hayan abierto ese mismo archivo.
Existe un modo de comparticin que permite a los procesos compartir el puntero de

ubicacin actual dentro del archivo. As el incremento de ese puntero por parte de un
proceso afecta a todos los procesos que estn compartiendo el archivo.
En la semntica de UNIX cada archivo est asociado con una nica imagen fsica a la que se accede
en forma de recurso exclusivo. La contienda por acceder a esta imagen nica provoca retardos en
los procesos.
Semntica de sesin
Suponiendo que una sesin de archivo es el conjunto de operaciones entre las llamadas open() y
close(), el sistema de archivos Andrew o AFS utiliza la siguiente semntica de coherencia:
Las escrituras en un archivo abierto por parte de un proceso no son visibles

inmediatamente para los otros usuarios que hayan abierto ese mismo archivo.
Una vez que se cierra un archivo, los cambios realizados en l son visibles nicamente en
las sesiones que comiencen posteriormente. Las sesiones ya abiertas sobre el archivo no
reflejarn dichos cambios.
Esto significa que un archivo puede permanecer temporalmente asociado a varias imgenes fsicas
al mismo tiempo. As se permite que mltiples usuarios realicen accesos concurrentes, tanto de
lectura como de escritura, en sus propias imgenes del archivo, evitando los retardos.
Semntica de archivos compartidos inmutables

En esta semntica, cuando un archivo es declarado como compartido por su creador ya no puede
ser ser modificado. Estos archivos inmutables cumplen dos propiedades clave: su nombre no puede
reutilizarse y su contenido no puede ser modificado. As podemos estar seguros de que el contenido
de un archivo inmutable es fijo. La implementacin de esta semntica en un sistema distribuido es
muy simple.
5-162
5.5.3. Bloqueos de archivo

Algunos sistemas operativos proporcionan funciones para bloquear un archivo o determinadas
porciones de un archivo abierto. Esto permite que un proceso impida que otros procesos puedan
acceder al archivo bloqueado. Los bloqueos de archivo resultan tiles para aquellos archivos que
son compartidos por varios procesos, como por ejemplo un archivo de registro del sistema que
puede ser consultado y modificado por varios procesos distintos al mismo tiempo.
Los sistemas operativos pueden proporcionar diferentes tipos de bloqueos de archivo:
Un bloqueo compartido es un tipo de bloqueo que puede ser adquirido concurrentemente por
varios procesos.
Un bloqueo exclusivo slo puede ser adquirido por un proceso cada vez.
Algunos sistemas operativos slo proporcionan el bloqueo exclusivo. Sin embargo en los que
implementan ambos tipos de bloqueo, lo normal es que los procesos que pretenden acceder a un
archivo compartido para slo lectura utilicen el bloqueo compartido, mientras que los que acceden
para modificar el contenido utilicen el bloqueo exclusivo. As varios procesos puedan leer el archivo
concurrentemente, pero si un proceso accede para escribir ningn otro podr acceder ni para leer ni
para escribir.
Adems los sistemas operativos pueden proporcionar mecanismos de bloqueo de archivos:
Obligatorios. Si un bloqueo es obligatorio, despus de que un proceso adquiera un bloqueo

exclusivo, el sistema operativo impedir a todos los dems procesos que accedan al archivo
bloqueado. Esto ocurrir incluso si los otros procesos no han sido programados para adquirir
explcitamente el bloqueo. Por tanto, es el sistema operativo el encargado de garantizar la
integridad de los bloqueos.
Sugeridos. Si un bloqueo es sugerido, el sistema operativo slo impedir que accedan al

archivo bloqueado aquellos procesos programados para adquirir el bloqueo explcitamente
usando la llamada al sistema correspondiente. En caso contrario el sistema operativo no
impedir el acceso al archivo. Por tanto, son los desarrolladores del software los encargados de
garantizar que se adquieran y liberen apropiadamente los distintos bloqueos.
Como regla general los sistemas operativos Microsoft Windows implementan un mecanismo de
bloqueo obligatorio, mientras que los sistemas UNIX emplean bloqueos sugeridos.
5-163
5.5.4. Coherencia
Como hemos comentado anteriormente, parte de los metadatos se almacena en la memoria principal
para acelerar el acceso. Dicha informacin generalmente est ms actualizada que la
correspondiente en el disco, puesto que la informacin almacenada en la memoria no tiene porque
ser escrita inmediatamente despus de una actualizacin.
Qu ocurrira entonces si fallase el sistema? Pues que el contenido de la cach y de los bferes se
perdera y con ellos tambin los cambios realizados en los directorios y archivos abiertos. Esto
puede dejar el sistema de archivos en un estado incoherente, pues el estado real de algunos archivos
no sera el que se describe en la estructura de metadatos.
a) Comprobacin de coherencia
El comprobador de coherencia comprueba la estructura de metadatos y tratar de corregir todas
las incoherencias que detecte.
Los algoritmos de asignacin y de gestin del espacio de almacenamiento dictan los tipos de
problemas que el comprobador puede tratar de detectar y tambin el grado de xito que el
comprobador puede tener en esa tarea. Por ejemplo la prdida de un FCB, cuando es este el que
almacena la lista de bloques que contienen los datos del archivo, es desastrosa porque no hay forma
de saber en todo el disco que datos le pertenecen. Por esta razn UNIX almacena en cach las
entradas de directorio para las lecturas, pero todas las escrituras de datos que provoquen algn
cambio en la asignacin de espacio o en algn otro tipo de metadato se realizan sncronamente,
antes de escribir los correspondientes bloques de datos.
b) Soft Updates
Para mejorar la eficiencia del sistema de archivos, sin comprometer la coherencia en caso de fallo,
los distintos sabores de los sistemas UNIX BSD utilizan una tcnica denominada soft updates.
Cuando se monta un sistema de archivos con la opcin soft updates el sistema operativo desactiva
la escritura sncrona de los metadatos, permitiendo que estos sean escritos cuando los algoritmos
de gestin de la cach lo consideren necesario, pero se impone cierto orden en el que dichas
operaciones de escritura deben ser realizadas. Por ejemplo, cuando se van a escribir en el disco las
modificaciones debidas a la creacin de un nuevo archivo, el sistema se asegura de que primero se
escribe el nuevo inodo y posteriormente escribe el directorio con la nueva entrada de archivo.
Teniendo en cuenta que la entrada de directorio contiene un puntero al inodo, es sencillo darse
5-164
cuenta de que hacindolo en este orden nos estamos aseguramos de que el sistema de archivos
permanezca consistente, aunque el sistema falle antes de actualizar la informacin en el disco.
c) Sistemas de archivos basados en registro

Otra solucin al problema de la coherencia consiste en aplicar tcnicas de recuperacin basadas en
registro para las actualizaciones de los metadatos del sistema de archivos.
Fundamentalmente en los sistemas de archivos basados en registro o con journaling todos los
cambios en los metadatos se escriben secuencialmente en un registro62:
Cada conjunto de operaciones necesario para realizar una tarea especfica es una
transaccin.
Las operaciones necesarias para completar una transaccin se escriben secuencialmente y

sncronamente en el registro. Cuando terminan de ser escritos se consideran confirmados y la
llamada al sistema puede volver al proceso de usuario, permitiendo que continue con su
ejecucin.
Mientras tanto las operaciones indicadas en el registro son ejecutadas sobre las estructuras
reales del sistema de archivos. A medida que se realizan los cambios se actualiza el registro
para indicar las operaciones completadas.
Cuando todas las operaciones de una transaccin se han ejecutado con xito, dicha
transaccin se considera completada y se elimina del registro.
En el supuesto de que el sistema falle:
Durante el montaje del sistema de archivos se comprueba el registro.
Todas las transacciones que contenga el registro no habrn sido aplicadas, por lo que ser
necesario terminar de aplicarlas antes de finalizar el proceso de montaje.
Es posible que existan transacciones no confirmadas, es decir, transacciones que no terminaron

de ser escritas en el registro. En ese caso, todos los cambios correspondientes a las
transacciones no confirmadas que hubieran sido aplicados al sistema de archivos, debern
deshacerse para preservar la coherencia.
62 El registro generalmente se almacena en el mismo sistema de archivos. Sin embargo tambin suele ser posible
almacenarlo en otro volumen o incluso en otro disco.
5-165
Esta tcnica est empezando a resultar comn en muchos sistemas operativos. Hasta el punto de que
utilizada en sistemas tales como: ext3, ext4, NTFS, XFS, JFS, ReiserFS, etc.
Un efecto colateral de la utilizacin de un registro es la mejora del rendimiento en el acceso al

sistema de archivo. La razn de esta mejora es que las costosas escrituras sncronas de los
metadatos en lugares aleatorios del volumen se transforman en escrituras sncronas secuenciales
que son mucho ms eficientes en el registro. Mientras que las operaciones indicadas en el registro
se aplican asncronamente mediante escrituras aleatorias en las estructuras apropiadas, por lo que
pueden ser reordenadas a conveniencia para maximizar el rendimiento. El resultado global es una
significativa ganancia en la velocidad de las operaciones relativas a los metadatos, como por
ejemplo la creacin y borrado de archivos.
El sistema de archivos XFS modifica ligeramente esta tcnica, sustituyendo las escrituras sncronas
necesarias para actualizar el registro por escrituras asncronas. El resultado es cierta mejora del
rendimiento, porque el registro deja de ser el cuello de botella para las operaciones sobre los
metadatos. Sin embargo, en el caso de que el sistema fallase, el uso de escrituras asncronas podra
provocar la corrupcin del registro. Para evitarlo XFS impone cierto orden en las operaciones de
escritura sobre el registro, de forma similar a como se hace con los soft updates.
5-166
Bibliografa
La mayor parte de los contenidos de este documento estn basados en las siguientes referencias
bibliogrficas:
Silberschatz, A., Galvin, P. y Gagne, G. Fundamentos de Sistemas Operativos. 7 ed. McGraw

Hill, 2005.
Silberschatz, A., Galvin, P. y Gagne, G. Operating System Concepts with Java. 6 ed. John
Wiley & Sons Inc., 2004.
Otras referencias bibliogrficas utilizadas fueron las siguientes:
Bavier, A. Creating New CPU Schedulers with Virtual Time. En 21st IEEE Real-Time Systems
Symposium (RTSS 2000) WIP Proceedings, 2000.
Friedman, M. B. Windows NT Page Replacement Policies. En 25th International Computer

Measurement Group Conference, December 5-10, 1999, Pag. 234-244.
Ganger, G. R., McKusick, M. K., Soules, C. A. N. y Patt, Y. N. Soft Updates: A Solution to the
Metadata Update Problem in File Systems. En ACM Transactions on Computer Systems,
Vol. 18, No. 2, May 2000, Pag. 127153.
Gorman, M. Understanding the Linux Virtual Memory Manager. Prentice Hall, 2004.
Hailperin, M. Operating Systems and Middleware: Supporting Controlled Interaction. Course

Technology, 2006.
Jacob, B y Mudge, T. Virtual Memory: Issues of Implementation. Computer, 31:33-43, 1998.

ISSN 0018-9162. DOI: 10.1109/2.683005. URL http://dx.doi.org/10.1109/2.683005.
Kernel Enhancements for Microsoft Windows Vista and Windows Server Longhorn[en lnea].
Microsoft Corporation, 2005 [2006]. URL http://goo.gl/ml8C4.
Kernel Enhancements for Windows XP[en lnea]. Microsoft Corporation, 2003 [2006]. URL
http://goo.gl/ugED.
XFS Filesystem Structure[en lnea]. Silicon Graphics Inc, 2006 [2007]. URL
http://goo.gl/RwZwL
C dynamic memory allocation[en lnea]. Wikipedia (en), [2011]. URL http://goo.gl/OkFJ3
RAID[en lnea]. Wikipedia (en), [2011]. URL http://goo.gl/GTQU

ndice
A C
Access-control list 160 caching 31
ACL 160 cambio de contexto 53
activacin del planificador 73 cancelacin 79
afinidad al procesador 96 asncrona ....................................................79
ajuste en diferido ..................................................79
mejor ........................................................138 cilindro 142
peor ...........................................................139 cdigo
primer .......................................................138 absoluto ....................................................103
API 24 reubicable .................................................103
Application Programming Interface 24 cola
rbol de procesos 54 dispositivo ..................................................51
archivo 30, 143 entrada ......................................................101
mapeado en memoria ...............................121 eventos ........................................................51
asignacin de memoria contigua 138 planificacin ...............................................51
asignador 83 preparados ..................................................51
atmica 78 trabajo .........................................................51
comprobador de coherencia 164
B comunicacin
balanceo de carga 97
directa .........................................................60
bit de
indirecta ......................................................61
modificado ................................................123
condicin de carrera 74
modo ...........................................................35
conjunto de trabajo 129
proteccin .................................................110
consumidor 75
referencia ..................................................124
control de E/S 148
vlido ................................................111, 114
copia durante la escritura 119
bloque de
copy-on-write 119
control de archivo .............................149, 151
cuanto 89
control de arranque ...................................149
control de proceso ......................................50 D
control de volumen ...................................149 demonio 65
inicio .........................................................149 descriptor de archivo 153
bloqueo desplazamiento 107
compartido ................................................163 direccin
exclusivo ..................................................163 absoluta ....................................................103
c)buffering 31, 61 fsica ...................................................37, 104
automtico ..................................................62 reubicable .................................................103
capacidad cero ............................................61 virtual .................................................37, 104
capacidad ilimitada .....................................62 direccionamiento
capacidad limitada ......................................62 asimtrico ...................................................60
pginas ......................................................125 simtrico .....................................................60
buzones 61 directorio 155
ndice
actual ........................................................156 G
archivos de usuario ...................................155 gestin
dispositivo ................................................150 almacenamiento secundario .......................31
maestro de archivos ..................................155 archivos ......................................................30
raz ............................................................156 E/S ..............................................................31
dispositivo memoria ..............................................29, 101
intercambio ...............................................116 procesos ................................................28, 47
GPT 146
E guid partition table 146
enlace 157
comunicaciones ..........................................59 H
duro ..........................................................157 herencia de la prioridad 94
simblico ..................................................157 hilo 66
enlazado librera ........................................................68
dinmico ...................................................104 modelo ............................................................
esttico ......................................................104 dos niveles .............................................73
envejecimiento 91 muchos a muchos ..................................72
muchos a uno .........................................70
espacio de direcciones uno a uno ...............................................71
disperso .....................................................112 ncleo .........................................................68
fsico ...........................................................37 usuario ........................................................68
virtual .................................................36, 103 hiperpaginacin 127
espera ocupada 78
estructura I
capas ...........................................................40 identificador de proceso 53
microkernel ................................................42 inodo 150
modular ......................................................44 instrucciones privilegiadas 35
sencilla ........................................................39 intercambio 53, 114
excepcin 27, 34 espacio ......................................................116
interfaz programacin de aplicaciones 23
F inversin de la prioridad 94
Fair Scheduling 92
FCB 149, 150 s. J
FCFS 87, 89 journaling 165
fichero 30 K
file kernel 3
control block .....................................149, 151
descriptor ..................................................153 L
handler ......................................................153 latencia de asignacin 83
fragmentacin least frequently used 125
externa ......................................................139 least recently used 124
interna ...............................................109, 139 LFU 125
franjas 146 librera
170
compartida ................................................106 most frequently used 125
del sistema ..................................................25 muerte por inanicin 90
estndar ......................................................24 multimedia class scheduler service 99
lista de control de acceso 160 multiprocesamiento
llamadas al sistema 26 asimtrico ...................................................96
LRU 124 simtrico .....................................................96
mutex 77
M
maillox 61 N
mainframe 4 nombre de ruta 156
manejador de archivo 153 absoluto ....................................................156
marcos 107 relativo ......................................................156
master boot record 146 not recently used 124
master file table 150 NRU 124
MBR 146 ncleo 3
memoria expropiable .................................................94
compartida ..................................................58 nmero
flash ..........................................................143 mgico ......................................................154
virtual ........................................................113 marco ........................................................107
memory-management unit 37 pgina .......................................................107
MFD 155
MFT 150 P
P2P 9
MFU 125
page-table
microkernel 42
base register ..............................................110
migracin
length register ...........................................112
comandada ..................................................97
pgina 107
solicitada ....................................................97
compartida ................................................113
minidiscos 146
paginacin 107
MMCSS 99
bajo demanda ............................................113
MMU 37
pura ......................................................115
modelo paginador 114
conjunto de trabajo ...................................129 particionado dinmico 138
localidad ...................................................129 particiones 146
modo paso de mensajes 59
dual .............................................................35 asncrono ....................................................62
kernel ..........................................................35 con bloqueo ................................................62
privilegiado ................................................35 sin bloqueo .................................................62
sistema ........................................................35 sncrono ......................................................62
supervisor ...................................................35 PCB 50
usuario ........................................................35 peer-to-peer 9
mdulo de organizacin de archivos 148 PIC 105
monoltico 39
ndice
PID 53 PTLR 112

pista 142 puertos 61
planificacin punto de
apropiativa ..................................................82 cancelacin .................................................79
colas multinivel ....................................87, 91 expropiacin ...............................................94
colas multinivel realimentadas ...................91 montaje .....................................................151
cooperativa .................................................82
equitativa ....................................................92 R
RAID 144
expropiativa ................................................82
divisin .....................................................145
multiprocesador ..........................................95
fakeRAID .................................................146
no expropiativa ...........................................82
hostRAID .................................................146
round-robin ...........................................87, 89
niveles ......................................................144
tiempo real ..................................................92
software ....................................................146
planificador 52
real-time
corto plazo ............................................52, 81
hard .............................................................11
CPU ..................................................6, 52, 81
soft ..............................................................11
equitativo ponderado ..................................92
red 32
largo plazo ..................................................52
redundant array of inexpensive disks 144
medio plazo ................................................53
reemplazo
multiprocesador ..........................................95
global ........................................................126
trabajos ...................................................6, 52
local ..........................................................126
position-independent code 105
reentrante 79
POSIX 24
RR 87, 89
prepaginado 131
proceso 28, 48 S
cooperativo .................................................57 seccin crtica 74
estado ..........................................................49 sector 142
hijo ..............................................................53 arranque ....................................................149
independiente .............................................57 seguridad en hilos 80
limitado por la CPU ...................................86 semforo 77
limitado por la E/S .....................................86 semntica de coherencia 161
padre ...........................................................53 seal 64
process asncrona ....................................................81
control block ...............................................50 sncrona ......................................................80
identifier .....................................................53 sesin de archivo 162
productor 75 sistema
programa 28, 49 archivos ....................................................143
aplicacin .............................................34, 47 basados en registro ..............................165
sistema ........................................................47 bsico de archivos ....................................148
proteccin 32 batch .............................................................5
PTBR 110 cliente-servidor .............................................9
172
empotrados .................................................10 contenidos del volumen ............................150
escritorio .......................................................8 maestra de archivos ..................................150
informtico ...................................................1 marcos ......................................................108
lgico de archivos ....................................149 pginas ......................................................107
mano ...........................................................11 tasa
multiprocesador ..........................................95 fallos de pgina .........................................118
multiprogramado ..................................6, 101 procesamiento ............................................83
operativo ...................................................1, 3 temporizador 38
procesamiento por lotes ................................5 terminacin en cascada 57
redes entre iguales ........................................9 thread-safe 80
tiempo compartido ...............................7, 101 thread-specific data 78
tiempo real ..................................................10 tiempo
sistema operativo acceso a la memoria .................................117
de red ..........................................................10 acceso efectivo .........................................117
distribuido ..................................................10 ejecucin ....................................................84
SJF 87 espera ..........................................................84
SMP 96 fallo de pgina ..........................................117
socket 65 respuesta .....................................................84
dominio UNIX ...........................................66 tiempo real
soft updates 164 estricto ..................................................11, 92
spinlock 78 flexible ..................................................11, 93
spooling 31 volumen ....................................................144
SRTF 87 transaccin 165
stripe 145 TSD 78
stub 105 tubera 63
superbloque 150
swap 116 U
UFD 155
swapping 53, 114
utilidades del sistema 34
T
tabla V
volumen 144
archivos abiertos .......................................150
gestin ..............................................146, 147

Sistemas Operativos

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

Sistemas Operativos

Cargado por

Copyright:

Formatos disponibles

Sistemas Operativos

Curso acadmico 2014/2015

2. Estructura de los sistemas operativos 11

4. Gestin de memoria 105

5. Gestin del almacenamiento 185

Figura 5.2: Estructura lgica de un disco magntico.......................................................................142

1.1. Funciones del sistema operativo

Los programas de aplicacin procesadores de textos, hojas de clculo, compiladores,

usuario usuario usuario usuario

editor juego compilador ... base

programas del sistema y aplicaciones

Figura 1.1: Vista abstracta de los componentes de un sistema informtico.

1.1.1. Punto de vista del sistema informtico

1. Gestor de los recursos de sistema informtico.

1.1.2. Punto de vista del usuario

En otros casos un usuario se sienta frente a un terminal1 conectado a un mainframe (vase el

1.2. Definicin de sistema operativo

1.3. Tipos de sistemas operativos

3 Ms informacin sobre el caso en http://goo.gl/u1tf.

Figura 1.2: Disposicin de la memoria en un sistema de procesamiento por lotes.

a) Sistemas de procesamiento por lotes

El sistema operativo permaneca siempre residente en memoria (vase la Figura 1.2).

5 Mas informacin sobre la forma de trabajo con tarjetas perforadas en http://goo.gl/S9FTOk.

5. El sistema operativo ejecuta en la CPU unos de los trabajos en memoria.

6. Si el trabajo en la CPU requiere E/S, en lugar de mantener a la CPU ocupada intilmente, el

8. El proceso se repite mientras hayan trabajos que ejecutar.

La planificacin de trabajos. Su responsabilidad es elegir cual es el siguiente trabajo que

c) Sistemas de tiempo compartido

Los sistemas de tiempo compartido se caracterizan por tener:

Un sistema de interaccin directa entre el usuario y el sistema. Por ejemplo, un terminal.

Un sistema multiprogramado dnde la conmutacin es tan frecuente que el usuario puede

mecanismos de sincronizacin (vase el apartado 3.3.3) y comunicacin (vase el apartado

1.3.2. Sistemas de escritorio

1.3.3. Sistemas distribuidos

a) Tipos de sistemas informticos distribuidos

En los sistemas de redes entre iguales o P2P (peer-to-peer) clientes y servidores no se

b) Sistemas operativos para sistemas distribuidos

Los sistemas operativos distribuidos crean en el usuario la ilusin de estar en un slo

1.3.4. Sistemas de tiempo real

1.3.5. Sistemas de mano

1.4. Historia de los sistemas operativos

1.4.1. 1 Generacin (1945-55)

Slo hardware, sin lenguajes de programacin.

1.4.2. 2 Generacin (1955-64)

Sistema operativo bsico. Se utilizan lenguajes de programacin.

1.4.3. 3 Generacin (1965-1968)

Ms lenguajes de programacin y multiprogramacin.

Figura 1.4: Instalacin de un mainframe IBM 702.

Fue el primero en hacer los dispositivos de almacenamiento de acceso aleatorio un

Anunciado en 1964, fue liberado en 1966 con un ao de retraso. Los motivos

Aparecen los programas interactivos y las mquinas virtuales.

Primer sistema operativo en proporcionar un sistema de archivos jerrquico, un

Elimin la separacin entre el espacio de direcciones de los procesos y los archivos. En

VM/CMS. Es un sistema de IBM utilizado en los mainframe System/360, System/370,

El desarrollo comenz en 1965 y la primera versin estuvo disponible a primeros de

VM es una mquina virtual que proporciona a cada usuario la sensacin de tener su

CMS es un sistema monousuario diseado para operar fundamentalmente encima de

Figura 1.6: Miniordenador DEC PDP-7.

La autora del mismo se le atribuye a un grupo de programadores, liderados por Ken

La primer versin, como muchos otros sistemas operativos anteriores, estaba

AT&T, la compaa matriz de Bell Labs, no poda competir en la industria de los

Una de las ms importantes versiones de UNIX fue desarrollada por la Universidad de

VMS. Es un sistema operativo diseado originalmente por Digital Equipment Corporation