Documentos de Académico
Documentos de Profesional
Documentos de Cultura
CARRETERO, Jesus - Sistemas Operativos PDF
CARRETERO, Jesus - Sistemas Operativos PDF
ISBN: 84-481-3001-4
Depsito legal: M. 13.413-2001
Prlogo XV
3. PROCESOS 77
3.1. Concepto de proceso 78
3.2. Multitarea 79
3.2.1. Base de la multitarea 80
3.2.2. Ventajas de la multitarea 82
3.2.3. Grado de multiprogramacin y necesidades de memoria principal 82
3.3. Informacin del proceso 84
3.3.1. Estado del procesador 84
3.3.2. Imagen de memoria del proceso 85
3.3.3. Informacin del BCP 90
3.3.4. Tablas del sistema operativo 91
3.4. Formacin de un proceso 93
6. INTERBLOQUEOS 309
6.1. Los interbloqueos: una historia basada en hechos reales 310
6.2. Los interbloqueos en un sistema informtico 311
6.2.1. Tipos de recursos 311
7. ENTRADA/SALIDA 351
7.1. Introduccin 352
7.2. Caracterizacin de los dispositivos de E/S 354
7.2.1. Conexin de un dispositivo de E/S a una computadora 354
7.2.2. Dispositivos conectados por puertos o proyectados en memoria 355
7.2.3. Dispositivos de bloques y de caracteres 356
7.2.4. E/S programada o por interrupciones 357
7.2.5. Mecanismos de incremento de prestaciones 361
7.3. Arquitectura del sistema de entrada/salida 363
7.3.1. Estructura y componentes del sistema de E/S 363
7.3.2. Software de E/S 364
7.4. Interfaz de aplicaciones 369
7.5. Almacenamiento secundario 373
7.5.1. Discos 374
7.5.2. El manejador de disco 379
7.5.3. Discos en memoria 384
7.5.4. Fiabilidad y tolerancia a fallos 385
7.6. Almacenamiento terciario 387
7.6.1. Tecnologa para el almacenamiento terciario 388
7.6.2. Estructura y componentes de un sistema de almacenamiento
terciario 389
7.6.3. Estudio de caso: Sistema de almacenamiento de altas prestaciones
(HPSS) 391
7.7. El reloj 393
7.7.1. El hardware del reloj 393
7.7.2. El software del reloj 394
Bibliografa 709
ndice 721
Los sistemas operativos son una parte esencial de cualquier sistema de computacin, por lo que
todos los planes de estudio de informtica incluyen uno o ms cursos sobre sistemas operativos.
La mayora de libros de sistemas operativos usados en estos cursos incluyen gran cantidad de
teora general y aspectos de diseo, pero no muestran claramente cmo se usan.
Este libro est pensado como un texto general de sistemas operativos, pudiendo cubrir
tanto la parte introductoria como los aspectos de diseo de los mismos. En l se tratan todos los
aspectos fundamentales de los sistemas operativos, tales como procesos, gestin de memoria,
comunicacin y sincronizacin de procesos, entrada/salida, sistemas de archivos y seguridad y
proteccin. Adems, en cada tema, se muestra la interfaz de programacin de los sistemas
operativos POSIX y Win32, con ejemplos de uso de las mismas. Esta solucin permite que el lector
no slo conozca los principios tericos, sino cmo se aplican en sistemas operativos reales.
Comparando esta situacin con la del mundo real se observaban considerables diferencias:
Demanda de los estudiantes para tener apoyo en las cuestiones tericas con ejemplos
prcticos.
Necesidad de conocer los sistemas operativos desde el punto de vista de programacin de
sistemas.
Visin generalista del diseo de los sistemas operativos, estudiando distintos sistemas.
Esta situacin obligaba a los autores a mezclar textos generales sobre sistemas operativos con
otros libros que estudiaban sistemas operativos concretos y la forma de programarlos. Por esta
razn, entre- otras, el cuerpo de los apuntes, mencionado anteriormente, fue creciendo y
modernizndose hasta llegar a este libro.
El libro est organizado en doce temas, cuyo ndice se muestra a continuacin. Su contenido cubre
todos los aspectos de gestin de una computadora, desde la plataforma hardware hasta los
sistemas distribuidos. Adems, se incluyen tres apndices.
Los temas son los siguientes:
En este tema se explica qu es un sistema operativo, cules son sus funciones principales, los
tipos de sistemas operativos existentes actualmente y cmo se activa un sistema operativo.
Tambin se introduce brevemente la estructura del sistema operativo y de sus componentes
principales (procesos, memoria, archivos, comunicacin, etc.), que se describen en detalle en
captulos posteriores. Adems, se ponen dos ejemplos concretos, como son LINUX y Windows NT.
Para terminar, se muestra la interfaz de usuario y de programador del sistema operativo.
Procesos
Gestin de memoria
cmo se genera dicho modelo y diversos esquemas de gestin de memoria, incluyendo la memoria
virtual. Este tema est relacionado con el Captulo 7, debido a que la gestin de la memoria virtual
se apoya en los discos como medio auxiliar de almacenamiento de la imagen de los procesos que
no cabe en memoria principal. Al final del tema se muestran los servicios de gestin de memoria
existentes en POSIX y Win32 y algunos ejemplos de uso de los mismos.
Los procesos no son entidades aisladas, sino que en muchos casos cooperan entre s y compiten
por los recursos. El sistema operativo debe ofrecer mecanismos de comunicacin y sincronizacin
de procesos concurrentes. En este tema se muestran los principales mecanismos usados en
sistemas operativos, tales como tuberas, semforos o el paso de mensajes, as como algunos
aspectos de implementacin de los mismos. Al final del tema se muestran los servicios de
comunicacin y sincronizacin existentes en POSIX y Win32 y algunos ejemplos de uso de los
mismos.
Interbloqueos
Entrada/salida
El procesador de una computadora necesita relacionarse con el mundo exterior. Esta relacin se
lleva a cabo mediante los dispositivos de entrada/salida (E/S) conectados a la computadora. El
sistema operativo debe ofrecer una interfaz de acceso a dichos dispositivos y gestionar los detalles
de bajo nivel de los mismos. En este tema se muestran aspectos del hardware y el software de
E/S, estudiando una amplia gama de dispositivos, tales como los de almacenamiento secundario y
terciario, los relojes o el terminal. Al final del tema se muestran los servicios de entrada/salida
existentes en POSIX y Win32 y algunos ejemplos de uso de los mismos.
El sistema operativo debe proporcionar al usuario mecanismos de alto nivel para acceder a la
informacin existente en los dispositivos de almacenamiento. Para ello, todos los sistemas
operativos incluyen un sistema de gestin de archivos y directorios. El archivo es la unidad
fundamental de almacenamiento que maneja el usuario. El directorio es la unidad de estructuracin
del conjunto de archivos. En este tema se muestran los conceptos fundamentales de archivos y
directorios, la estructura de sus gestores y los algoritmos internos usados en los mismos. Al igual
que en otros temas, se muestran los servicios de archivos y directorios existentes en POSIX y
Win32 y algunos ejemplos de uso de los mismos.
Seguridad y proteccin
Un sistema de computacin debe ser seguro. El usuario debe tener la confianza de que las
acciones internas o externas del sistema no van a ser un peligro para sus datos, aplicaciones o
para las actividades de otros usuarios. El sistema operativo debe proporcionar mecanismos de
proteccin
entre los distintos procesos que ejecutan en un sistema y entre los distintos sistemas que estn
conectados entre s. En este tema se exponen los conceptos de seguridad y proteccin, posibles
problemas de seguridad, mecanismos de diseo de sistemas seguros, los niveles de seguridad
que puede ofrecer un sistema y los controles existentes para verificar si el estado del sistema es
seguro. Adems, se estudian los mecanismos de proteccin que se pueden usar para controlar el
acceso a los distintos recursos del sistema, Al final del tema se muestran los servicios de
proteccin existen en POSIX y Win32 y algunos ejemplos de uso de los mismos.
Los sistemas de computacin actuales raramente estn aislados. Es habitual que estn
conectados formando conjuntos de mquinas que no comparten la memoria ni el reloj, es decir,
sistemas distribuidos. Este tema presenta una breve introduccin a dichos sistemas, estudiando las
caractersticas de los sistemas distribuidos, sus problemas de diseo, su estructura y sus distintos
elementos (redes, comunicacin, memoria distribuida, sistemas de archivo distribuido, etc.).
Tambin se muestran distintas tcnicas de diseo de aplicaciones cliente-servidor en sistemas
distribuidos.
Este captulo muestra en detalle los aspectos de LINUX desarrollados a lo largo del libro. Para ello
se describe, tema por tema, cmo es la arquitectura del sistema operativo LINUX, cmo son los
procesos de LINUX, sus mecanismos de comunicacin y seguridad, etc.
Este captulo muestra en detalle los aspectos de Windows NT desarrollados a lo largo del libro.
Para ello se describe, tema por tema, cmo es la arquitectura del sistema operativo Windows NT,
cmo son los procesos de Windows NT, su sistema de E/S, sus mecanismos de comunicacin y
seguridad, etctera.
Tabla de llamadas al sistema de POSIX y Win32. Para cada funcin del sistema se muestra la
llamada POSIX y la de Win32 que lleva a cabo dicha funcin, junto a un breve comentario de la
misma.
Materiales suplementarios
Existe una pgina Web con materiales suplementarios para el libro, situada en la direccin:
http: //arcos.inf.uc3m.es/ La misma informacin se encuentra duplicada en:
http://datsi.fi. upm. es/ ssoo-va.
En esta pgina Web se puede encontrar el siguiente material:
Es un placer para nosotros poder presentar este texto a las personas interesadas en los sistemas
operativos, su diseo y su programacin. La elaboracin de este texto ha supuesto un arduo
trabajo para nosotros, tanto por la extensin de la obra como por los ejemplos prcticos incluidos
en la misma. Adems, se ha hecho un esfuerzo importante para tratar de unificar la terminologa
usada en distintos pases de habla hispana. Con todo, creemos que el resultado final hace que el
esfuerzo realizado haya merecido la pena.
El esfuerzo realizado por mostrar los dos sistemas operativos ms actuales, LINUX y
Windows NT, ha dado como resultado final un texto didctico y aplicado, que puede ser usado
tanto en cursos de introduccin como de diseo de sistemas operativos. En el libro se incluyen
ejemplos que muestran el uso de las llamadas al sistema de POSIX y Win32. Dichos ejemplos han
sido cuidadosamente compilados y enlazados en los dos entornos en que estaban disponibles:
Visual C y gcc.
Nos gustara mostrar nuestro agradecimiento a todas las personas que han colaborado en
este texto con su ayuda y sus comentarios. Este agradecimiento se dirige especialmente a
Francisco Rosales Garca, Alejandro Caldern Mateos y Jos Mara Prez Menor por su ayuda en
la compilacin de los programas de ejemplo y en algunos proyectos de sistemas operativos.
La computadora es una mquina destinada a procesar datos. En una visin esquemtica, como
la que muestra la Figura 1.1, este procesamiento involucra dos flujos de informacin: el de
datos y el de instrucciones. Se parte del flujo de datos que han de ser procesados. Este flujo de
datos es tratado mediante un flujo de instrucciones de maquina, generado por la ejecucin de
un programa, y produce el flujo de datos resultado.
Para llevar a cabo la funcin de procesamiento, una computadora con arquitectura von
Neuman est compuesta por los cuatro componentes bsicos representados en la Figura 1.2.
La memoria principal se construye con memoria RAM y memoria ROM. En ella han de
residir los datos a procesar, el programa mquina (Aclaracin 1.1) a ejecutar y los resultados.
La memoria est formada por un conjunto de celdas idnticas. Mediante la informacin
de direccin se selecciona de forma nica la celda sobre la que se quiere realizar el acceso,
pudiendo ser ste de lectura o de escritura. En las computadoras actuales es muy frecuente
que el direccionamiento se realice a nivel de byte, es decir, que las direcciones 0, 1, 2,...
identifiquen los bytes 0, 1, 2,... Sin embargo, el acceso se realiza sobre una palabra de varios
bytes (tpi ente de 4 o de 8 bytes) cuyo primer byte se sita en la direccin utilizada.
ACLARACIN 1.1
Se denomina programa mquina (o cdigo) al conjunto de instrucciones mquina que tiene por
objeto que la computadora realice una determinada funcin. Los programas escritos en
cualesquiera de los lenguajes de programacin han de convertirse en programas mquina para
poder ser ejecutados por la computadora
La unidad de control tiene asociados una serie de registros, entre los que cabe destacar:
el contador de programa (PC, program counter), que indica la direccin de la siguiente
instruccin de mquina a ejecutar, el puntero de pila (SP, snack pointer), que sirve para
manejar cmodamente una pila en memoria principal, el registro de instruccin (RL), que
permite almacenar la instruccin de maquina a ejecutar, y el registro de estado (RE), que
almacena diversa informacin producida por la ejecucin de alguna de las ltimas instrucciones
del programa (bits de estado aritmticos) e informacin sobre la forma en que ha de
comportarse la computadora (bits de interrupcin, nivel de ejecucin, etc.).
Finalmente, la unidad de entrada/salida (E/S) se encarga de hacer la transferencia de
informacin entre la memoria principal (o los registros) y los perifricos. La entrad salida se
puede hacer bajo el gobierno de la unidad de control (E/S programada) o de forma
independiente (DMA), como se ver en la Seccin 1.7.
Se denomina procesador, o unidad central de proceso (UCP), al conjunto de la unidad
aritmtica y de control. Actualmente, el procesador suele construirse en un nico circuito
integrado.
Desde el punto de vista de los sistemas operativos, nos interesa ms profundizar en el funcio-
namiento interno de la computadora que en los componentes fsicos que la constituyen.
El modelo de programacin a bajo nivel de una computadora se caracteriza por los siguientes
aspectos, que se muestran grficamente en la Figura 1.3:
ACLARACIN 1.2
Es muy frecuente que las computadoras incluyan el mapa de E/S dentro del mapa de memoria.
En este caso, se reserva una parte del mapa de memoria para realizar la E/S.
ADVERTENCIA 1.1
Algunas computadoras tienen una instruccin HALT que hace que la unidad de control se
detenga hasta que llega una interrupcin. Sin embargo, esta instruccin es muy poco utilizada,
por lo que a efectos prcticos podemos considerar que la unidad de control no para nunca de
realizar la secuencia de lectura de instruccin, incremento de PC y ejecucin de la instruccin.
Podemos decir, por tanto, que lo nico que sabe hacer la computadora es repetir a
gran veloci- dad esta secuencia. Esto quiere decir que, para que realice algo til, se ha de tener
adecuadamente cargados en memoria un programa mquina con sus datos y hemos de
conseguir que el contador de programa apunte a la instruccin mquina inicial del programa.
El esquema de ejecucin lineal es muy limitado, por lo que se aaden unos mecanismos que
permiten alterar esta ejecucin lineal. En esencia todos ellos se basan en algo muy simple:
modifi- can el contenido del contador de programa, con lo que se consigue que se salte o
bifurque a otro segmento del programa o a otro programa (que, lgicamente, tambin ha de
residir en memoria).
Como se ha indicado anteriormente, la unidad de control tiene asociada una serie de registros
denominamos de control y estado. Estos registros dependen de la arquitectura de la
computadora muchos de ellos se refieren a aspectos que se analizarn a lo largo del texto, por
lo que no se intentar explicar aqu su funcin. Entre los ms importantes se pueden encontrar
los siguientes:
1.3. INTERRUPCIONES
A nivel fsico, una interrupcin se solicita activando una seal que llega a la unidad de control.
El agente generador o solicitante de la interrupcin ha de activar la mencionada seal cuando
necesite que se le atienda, es decir, que se ejecute un programa que le atienda.
Ante la solicitud de una interrupcin, siempre y cuando est habilitado ese tipo de interrupcin,
la unidad de control realiza un ciclo de aceptacin de interrupcin. Este ciclo se lleva a cabo
en cuanto termina la ejecucin de la instruccin maquina que se est ejecutando y consiste en
las siguiente. operaciones:
Las interrupciones se pueden generar por diversas causas, que se pueden clasificar de la
siguiente forma:
ADVERTENCIA 1.2
En este caso no existe un agente externo que suministre el vector necesario para entrar en la
tabla de interrupciones. Ser la propia unidad de control del procesador la que genere este
vector.
1.4. EL RELOJ
El trmino reloj se aplica a las computadoras con tres acepciones diferentes, si bien
relacionadas, como se muestra en la Figura 1.7. Estas tres acepciones son las siguientes:
ADVERTENCIA 1.3
En el caso de UNIX se cuentan segundos y se toma como referencia las 0 horas del 1 de enero
de 1970. si se utiliza una palabra de 32 bits, el mayor nmero que se puede almacenar es el
2.147.483.647, que se corresponde a las 3h 14m y 7s de enero de 2038. esto significa que, a
partir de ese instante, el contador tomar el valor de 0 y la fecha volver a ser el 1 de enero de
1970.
Dado que la memoria de alta velocidad tiene un precio elevado y un tamao reducido, la
memoria de la computadora se organiza en forma de una jerarqua como la mostrada en la
Figura 1.8. En esta jerarqua se utilizan memorias permanentes de alta capacidad y baja
velocidad, como son los cos, para almacenamiento permanente de la informacin. Mientras
que se emplean memorias semiconductores de un tamao relativamente reducido, pero de alta
velocidad, para almacenar la informacin que se est utilizando en un momento determinado.
Tiempo de acierto.
Penalizacin de fallo.
Tasa de aciertos (Hrk) del nivel k.
1.5.3. Coherencia
1.5.4. Direccionamiento
RECORDATORIO 1.1
Aqu conviene incluir una aclaracin. Dado que las memorias principales se direccional a nivel
de byte pero se acceden a nivel de palabra, la direccin siguiente no es la direccin actual mas
1. Para palabras de 4 bytes la direccin siguiente es la actual mas 4.
En un sistema sin memoria virtual, el sistema operativo divide la memoria principal en trozos y
asigna uno a cada uno de los programas que estn ejecutando en un instante determinado. La
Figura 1.13 muestra el reparto tpico de la memoria para el caso de un solo programa o de
varios programas. Observe que el espacio asignado a un programa consiste en una zona de
memoria principal
contigua, es decir, no se asignan varios trozos disjuntos de memoria a un mismo programa. Por
el contrario, como se ver ms adelante, en los sistemas con memoria virtual no es necesario
que los
espacios de memoria asignados a los programas sean contiguos.
La memoria virtual utiliza dos niveles de la jerarqua de memoria: la memoria principal y una
memoria de respaldo (que suele ser el disco, aunque puede ser una memoria expandida).
Sobre memoria de respaldo se establece un mapa uniforme de memoria virtual. Las
direcciones generadas por el procesador se refieren a este mapa virtual, pero, sin embargo, los
accesos reales se realiza sobre la memoria principal.
Para su funcionamiento, la memoria virtual exige una gestin automtica de la parte de la
jerarqua de memoria formada por los niveles de memoria principal y de disco.
Insistimos en que la gestin de la memoria virtual es automtica y la realiza el sistema
operativo con ayuda del hardware de la mquina. Como muestra la Figura 1.14, esta gestin
incluye toda la memoria principal y una parte del disco, que sirve de respaldo a la memoria
virtual.
Los aspectos principales en los que se basa la memoria virtual son los siguientes:
Las direcciones generadas por las instrucciones mquina, tanto para referirse a datos como a
otras instrucciones, estn referidas al espacio virtual, es decir, forman parte del mapa de
memoria virtual. En este sentido se suele decir que el procesador genera direcciones virtuales
Los fallos de pgina son atendidos por el sistema operativo (Prestaciones 1.1)
que se encarga de realizar la adecuada migracin de pginas, para traer la pgina requerida
por el programa a un marco de pgina. Se denomina paginacin al proceso de migracin
necesario para atender los fallos de pagina.
Finalmente, conviene resaltar que el tamao del espacio virtual suele ser muy
grande. En la actualidad se emplean direcciones de 32, 48 o hasta 64 bits, lo que significa
espacios virtuales de 232, 248 y 264 bytes. Dado que los programas requieren en general
mucho menos espacio, una de las funciones que realiza el sistema operativo es la asignacin
de espacio virtual a los programas para su ejecucin. El programa no podr utilizar todo el
espacio virtual sino que ha de restringirse a la zona o zonas que le asigne el sistema operativo.
La Figura 1.15 muestra que el espacio virtual reservado al programa A puede estar en una
nica zona o puede estar dividido en varias zonas, que se denominan segmentos.
.
Sin embargo, los programas estn compuestos por varios elementos, como son el
propio programa objeto, la pila y los bloques de datos. Adems, tanto la pila como los bloques
de datos han de poder crecer. Por ello, un esquema de tabla de un nivel obliga a dejar grandes
huecos de memoria virtual sin utilizar , pero que estn presentes en la tabla con el consiguiente
desperdicio de espacio.
Por ello se emplean esquemas de tablas de pginas de ms de un nivel. La Figura
1.18 muestra el caso de tabla de pginas de dos niveles. Con este tipo de tabla, la memoria
asignada esta compuesta por una serie de bloques de memoria virtual, es decir, por unos
segmentos. Cada segmento est formado por una serie contigua de byte. que puede variar su
tamao, siempre y cuando no choque con otro segmento. La direccin se divide en tres pres.
La primera identifica el segmento de memoria donde esta la informacin que se desea acceder.
Con este valor se entra en una subtabla de segmentos, que contiene un puntero por segmento,
puntero que indica el comienzo de la subtabla de paginas del segmento. Con la segunda parte
de la direccin se entra en la subtabla de pginas seleccionada. Esta subtabla es similar a la
tabla mostrada en la Figura 1.18, lo que permite obtener el marco en el que est la informacin
deseada.
Obsrvese que se ha aadido a cada subtabla su tamao. De esta forma se detectan las llama-
das violaciones de memoria, producidas cuando el programa en ejecucin intenta acceder
una direccin que no pertenezca a los espacios asignados por el sistema operativo.
La ventaja del diseo con varios niveles es que permite una asignacin de memoria ms
flexible que con un solo nivel, puesto que se pueden asignar bloques de memoria virtual
disjuntos, por lo que pueden crecer de forma a independiente. Adems, la tabla de pginas no
tiene espacios vacos, por lo que ocupa solamente el espacio imprescindible.
Las computadoras actuales suelen proporcionar tablas de varios niveles, algunos llegan asta
cuatro, con lo que se consigue una mayor flexibilidad en la asignacin de espacio de memoria.
La Figura 1.19 muestra un ejemplo de traduccin mediante tabla de pginas de dos niveles. El
segmento direccionado es el 5, por lo que hay que leer la entrada 5 de la tabla de segmentos.
Con ello se obtiene la direccin donde comienza la tabla de pginas de este segmento. La
pgina direccionada es la 3, por lo que entramos en el elemento 3 de la tabla anterior. En esta
tabla encontramos que el marco es el Hex4A24 (Advertencia 1.5), por lo que se puede formar
la direccin fsica en la que se encuentra la informacin buscada.
Traduccin de direcciones
Finalmente, hay que destacar que la encargada de mantener la informacin de que pgina
estn sucias es la MMU. En efecto, al mismo tiempo que hace la traduccin, en caso de que
acceso sea de escritura marca a esa pagina como sucia (Advertencia 1.6).
Como se ver en el Captulo 2, los sistemas operativos permiten que existan varios programa
activos al tiempo. De estos programas solamente puede haber uno en ejecucin en cada
instante, encargndose el sistema operativo de ir poniendo en ejecucin uno detrs de otro de
forma ordenada. Sin embargo, cada uno de los programas ha de tener asignado un espacio de
memoria, por lo que ha de tener su propia tabla de pginas.
La MMU ha de utilizar la tabla de paginas correspondiente al programa que est en
ejecucin. Para ello, como muestra la Figura 1.21, el procesador tiene un registro
identificador de espacio de direccionamiento (RIED). Este registro contiene la direccin en
la cual est almacenada la tabla de ndices o segmentos del programa. Cuando el sistema
operativo pone en ejecucin un programa ha de actualizar el valor del RIED para que apunte a
la tabla de pginas adecuada.
1.7. ENTRADA-SALIDA
1.7.1. Perifricos
El registro de control sirve para indicarle al controlador las operaciones que ha de realizar.
Los distintos bits de este registro indican distintas accione que ha de realizar el perifrico.
El disco magntico
El disco magntico es, para el sistema operativo, el perifrico ms importante, puesto que sirve
de espacio de intercambio a la memoria virtual y sirve de almacenamiento permanente para
los programa y los datos, encargndose el sistema operativo de la gestin de este tipo de
dispositivo.
Para entender la forma en que el sistema operativo trata a los discos magnticos es
necesario conocer las caractersticas de los mismos, entre las que destacaremos tres:
organizacin de la informacin, tiempo de acceso y velocidad de transferencia.
La organizacin de la informacin del disco se realiza en contenedores de tamao fijos
denominados sectores (tamaos tpicos del sector son 256, 512 o 1.024 bytes). Como muestra
Figura 1.23, el disco se divide en pistas que, a su vez, se dividen en sectores.
Las operaciones se realizan a nivel de sector, es decir, no se puede escribir o leer una
palabra o byte individual: hay que escribir o leer de golpe uno o varios sectores.
El tiempo de acceso de estos dispositivos viene dado por el tiempo que tardan en
Posicionar el brazo en la pista deseada, esto es, por el tiempo de bsqueda, ms el tiempo
que tarda la informacin de la pista en pasar delante de la cabeza por efecto de la rotacin del
disco, esto es, mas la
El disco magntico requiere que se lea o escriba un bloque de informacin (uno o varios
sectores), por lo que se denomina dispositivo de bloques. Existen otros dispositivos de bloques
como las cintas magnticas, los DVD, los CD y los controladores de red. Todos ellos se
caracterizan por tener un tiempo de acceso importante comparado con el tiempo de
transferencia de una palabra, por lo que interesa amortizar este tiempo de acceso transfiriendo
bastantes palabras.
Otros dispositivos como el teclado se denominan de caracteres. puesto que la operacin bsica
de acceso es de un carcter. Estos dispositivos se cauterizan por ser lentos y por no tener un
tiempo de acceso apreciablemente mayor que el tiempo de transferencia de una palabra.
Los perifricos son sensiblemente ms lentos que el procesador, por ejemplo, durante el
tiempo que se tarda en acceder a una informacin almacenada en un disco, un procesador
moderno es capaz de ejecutar varios millones de instrucciones de mquina (Prestaciones 1.3).
Es, por tanto, muy conveniente que mientras se est esperando a que se complete una
operacin de E/S el procesador est ejecutando un programa til y no un bucle de espera.
controlador del perifrico, operacin que puede hacerse mediante unas cuantas instrucciones
de salida, Dado que el controlador es un dispositivo electrnico, estas escrituras se pueden
hacer a la velocidad de procesador, sin esperas intermedias.
n= O
while n < m
read registro_control
if (registro_control = datoAisponible)
read registro_datos
store en memoria principal
n=n+ 1
endi f
endwhile
Observe que, hasta que se disponga del primer dato, el bucle puede ejecutarse cerca del milln
de veces y que, entre dato y dato, se repetir varias decenas de veces. Al llegar a completar
nmero m de datos a leer, se termina la operacin de E/S.
Se denomina espera activa cuando un programa queda en un bucle hasta que ocurra un
evento. La espera activa consume tiempo del procesador, por lo que es muy poco
recomendable cuando el tiempo de espera es grande en comparacin con el tiempo de
ejecucin de una instruccin
En caso de utilizar E/S con interrupciones, el procesador, tras enviar la orden al controlador del
perifrico, puede dedicarse a ejecutar otro programa. Cuando el controlador disponga de un
dato generar una interrupcin. La rutina de interrupcin deber hacer la lectura del dato y su
almacenamiento en memoria principal, lo cual conlleva un cierto tiempo del procesador. En
este caso se dice que se hace espera pasiva, puesto que el programa que espera el evento no
esta ejecutndose la interrupcin se encarga de <<despertar >> al programa cuando ocurre el
evento.
Finalmente, en caso de utilizar E/S por DMA, el controlador se encarga directa de ir
transfiriendo los datos del perifrico a memoria sin molestar al procesador. Una vez terminada
la transferencia de todos los datos, genera una interrupcin de forma que se sepa que ha
terminado (Recordatorio 1.2).
Puede observarse que la solucin que presenta la mxima concurrencia y que descarga al
mximo al procesador es la de E/S por DMA. Por otro lado, es la que exige una mayor
inteligencia por parte del controlador.
Un aspecto fundamental de esta concurrencia es su explotacin. En efecto, de nada sirve
descargar al procesador del trabajo de E/S si durante ese tiempo no tiene nada til que hacer.
Ser una funcin importante del sistema operativo el explotar esta concurrencia la E/S y el
procesador, haciendo que este ultimo tenga trabajo til el mayor tiempo posible.
1.8. PROTECCIN
Como veremos mas adelante, una de las funciones del sistema operativo es la proteccin de
unos usuarios contra otros: ni por malicia ni por descuido un usuario deber acceder a la
informacin de otro.
La proteccin hay que comprobarla en tiempo de ejecucin, por lo que se ha de basar en
mecanismos hardware. En esta seccin se analizaran estos mecanismos para estudiar ms
adelante cmo los aplica el sistema operativo. Se analizara en primer lugar los mecanismos de
proteccin que ofrece el procesador para pasar seguidamente a los mecanismos de proteccin
de memoria.
Los mecanismos de proteccin del procesador se basan en los niveles de ejecucin del mismo.
En nivel de ejecucin de ncleo se pueden ejecutar todas las instrucciones de maquina y se
pueden acceder a todos los registros y a la totalidad de los mapas de memoria y de E/S. Sin
embargo, en modo usuario se ejecuta un subconjunto de las instrucciones y se limitan los
registros y los mapas accesibles.
Uno de los objetivos prioritarios de proteccin son los perifricos. En efecto, prohibiendo el
acceso directo de los usuarios a los perifricos se impide que puedan acceder a la informacin
almacenada por otros usuarios en esos perifricos. Por esta razn, toda la E/S es accesible
solamente en nivel de ncleo, nivel que debe estar reservado al sistema operativo.
Para evitar que un programa de usuario pueda poner el procesador en nivel de ncleo,
no existe ninguna instruccin mquina que realice este cambio (Advertencia 1.7). Sin embargo,
existe la instruccin mquina inversa, que cambia de nivel de ncleo a nivel de usuario. Esta
instruccin es utilizada por el sistema operativo antes de dejar que ejecute un programa de
usuario.
espacio. de memoria asignados por el sistema operativo a ese programa. La MMU, al mismo
tiempo que realiza la traduccin de cada direccin, comprueba que no se sobrepase el lmite
de ninguna de las tablas involucradas. En caso de sobrepasarse, generara una excepcin de
violacin de memoria, para que el sistema operativo realice la accin correctora oportuna.
Dada la insaciable apetencia por mquinas de mayor potencia de proceso, cada vez es mas
corriente encontrarse con computadoras que incluyen ms de un procesador. Esta situacin
tiene una repercusin inmediata en el sistema operativo, que ha de ser capaz de explotar
adecuadamente todos estos procesadores.
Las dos arquitecturas para estas computadoras son la de multiprocesador y la de
multicomputadora, que se analizan seguidamente.
Multiprocesador
Como muestra la Figura 1.27, un multiprocesador es una mquina formada por un conjunto
procesadores que comparten el acceso a una memoria principal comn.
Cada procesador ejecuta su propio programa, debiendo todos ellos compartir la memoria
principal comn.
Una ventaja importante de esta solucin es que el acceso a datos comunes por parte de varios
programas es muy sencillo, puesto que utilizan la misma memoria principal. El mayor
inconveniente es el limitado nmero de procesadores que se pueden incluir sin incurrir en el
problema de saturar el ancho de banda de la memoria comn (un lmite tpico es el de 16
procesadores).
Multicomputadora
La multicomputadora es una mquina compuesta por varios nodos, estando cada nodo
formado un procesador, su memoria principal y, en su caso, elementos de E/S. La Figura 1.28
muestra esquema global de estas computadoras.
Al contrario que en los multiprocesadores, en estas mquinas los programas de do:
procesadores no pueden compartir datos en memoria principal. Sin embargo, no existe la
limitacin anterior en cuanto al nmero de procesadores que e pueden incluir, Buena prueba de
ello es que existen mquinas con varios miles de procesadores.
En esta seccin se plantea en primer lugar el concepto de maquina desnuda para pasar
acto seguido a introducir el concepto de sistema operativo y sus principales funciones.
Las funciones clsica, del sistema operativo se pueden agrupar en las tres
categoras siguientes:
Como muestra la Figura 2.1, el sistema operativo esta formado conceptualmente por
tres capas principales. La capa m : cercana al hardware se denomina ncleo (kernel) y
es la que gestiona los recursos hardware del sistema y la que suministra otra la
funcionalidad bsica del sistema operativo. Esta capa ha de ejecutar en nivel ncleo,
mientras que las otras pueden ejecutar en niveles menos permisivos.
Figura 2.1. Niveles del sistema operativo.
En una computadora actual suelen coexistir varios programas, del mismo o de varios
usuarios, ejecutndose simultneamente. Estos programas compiten por los recursos de
la computadora, siendo el sistema operativo el encargado de arbitrar su asignacin y
uso. Como complemento a la gestin de recursos, el sistema operativo ha de garantizar
la proteccin de unos programas frente a otros y ha de suministrar informacin sobre el
uso que se hace de los recursos.
a) Asignacin de recursos
b) Proteccin
El sistema operativo ha de garantizar la proteccin entre los usuarios del sistema. Ha de
asegurar la confidencialidad de la informacin y que unos trabajos no interfieran con
otros. Para conseguir este
36 Sistemas operativos. Una visin aplicada
objetivo ha de impedir que unos programas puedan acceder a los recursos asignados a
otros programas.
c) Contabilidad
d) Ejecucin de programas
b) rdenes de E/S
Los servicios de E/S ofrecen una gran comodidad y proteccin al proveer a los programas
de operaciones de lectura, escritura y modificacin del estado de los perifricos. En
efecto, la programacin de las operaciones de E/S es muy compleja y dependiente del
hardware especfico de cada perifrico. Los servicios del si tema operativo ofrecen un alto
nivel de abstraccin de forma que el programador de aplicaciones no tenga que
preocuparse de esos detalles.
e) Operaciones sobre archivos
Los archivos ofrecen un nivel de abstraccin mayor que el de las rdenes de E/S,
permitiendo operaciones tales como creacin, borrado, renombrado, apertura, escritura y
lectura de chivos.
Observe que muchos de los servicios son parecidos a las operaciones de E/S y terminan
concretndose en este tipo de operaciones.
Adems de analizar detalladamente todas las ordenes que recibe, para comprobar que se
pueden realizar , el sistema operativo se encarga de tratar todas las condiciones de error
que detecte el hardware.
Entre las condiciones de error que pueden aparecer destacaremos las siguientes:
errores en las operaciones de E/S, errores de paridad en los accesos a memoria o en los
buses y errores de ejecucin en los programas, como desbordamientos, violaciones de
memoria, cdigos de instruccin prohibidos, etc.
El mdulo del sistema operativo que permite que los usuarios dialoguen de forma
interactiva con el sistema es el intrprete de mandatos o shell.
El shell se comporta como un bucle infinito que est repitiendo constantemente la
siguiente secuencia:
Espera una orden del usuario. En el caso de interfaz textual, el shell est pendiente
de lo que escribe el usuario en la lnea de mandatos. En las interfaces grficas est
pendiente de los eventos del apuntador (ratn) que manipula el usuario, adems, de los
del teclado.
Analiza la orden y, en caso de ser correcta, la ejecuta, para lo cual emplea los
servicios del sistema operativo.
Concluida la orden vuelve a la espera.
El dialogo mediante interfaz textual exige que el usuario memorice la sintaxis de los
mandatos, con la agravante de que son distintos para cada sistema operativo (p. ej.: para
listar el contenido de un chivo en MS-DOS e emplea el mandato type, pero en UNIX se
usa el mandato cat ). Por esta razn cada vez son ms populares los intrpretes de
mandatos con interfaz grfica, como el de Windows NT.
Archivos de mandatos
Casi todos los intrpretes de mandatos pueden ejecutar archivos de mandatos, llamados
shell scripts. Estos chivos incluyen varios mandatos totalmente equivalentes a los
mandatos que se introducen en el terminal. Adems, para realizar funciones complejas,
pueden incluir mandatos especiales de control del flujo de ejecucin, como puede ser el
goto, el for o el if, as como etiquetas para identificar lneas de mandatos,
Para ejecutar un archivo de mandatos basta con invocarlo de igual forma que un
mandato estndar del intrprete de mandatos.
Los usuarios se organizan en grupos (p. ej.: en una universidad se puede crear un
grupo para los alumnos de cada curso y otro para los profesores). Todo usuario debe
pertenecer a un grupo. Los grupos tambin se emplean en la proteccin del sistema,
puesto que los derechos de un usuario son los suyos propios ms los del grupo al que
pertenezca. Por ejemplo, UNIX asigna un identificador gid (group identtfier) a cada
grupo.
El arranque de una computadora actual tiene dos fases: la fase de arranque hardware y la
fase arranque del sistema operativo. La Figura 2.2 resume las actividades ms
importantes que se realizan en el arranque de la computadora.
Figura 2.2. Operaciones realizadas en el arranque de la computadora.
Arranque hardware
En el caso de una computadora de tipo PC, la memoria ROM contiene, adems del
programa iniciador, software de E/S denominado BIOS (basic input-output system). La
BIOS de una computadora la proporciona el fabricante y suele contener procedimientos
para leer y escribir de leer caracteres del teclado y escribir en la pantalla.
El programa cargador del sistema operativo tiene por misin traer a memoria principal
algunos los componentes del sistema operativo. Una vez cargados estos componentes, se
pasa a la fase iniciacin, que incluye las siguientes operaciones:
Comprobacin del sistema. Se completan las pruebas del hardware realizadas por
dar ROM y se comprueba que el sistema de archivos tiene un estado coherente.
Esta operacin exige revisar todos los directorios, lo que supone un largo tiempo de
procesamiento.
Se establecen las estructuras de informacin propias del sistema operativo, tales
como tabla de procesos, las tablas de memoria y las de E/S. El contenido de estas
tablas se describir a lo largo del libro,
Se carga en memoria principal aquella parte del sistema operativo que ha de estar
siempre memoria, parte que se denomina sistema operativo residente.
Se crea un proceso de inicio o login por cada terminal definido en el sistema, as
como una serie de procesos auxiliares y de demonios (p. ej.; el demonio de
impresin o el demonio comunicaciones).
Figura 2.4. El sistema operativo se encuentra almacenado en una unidad de disco.
Introduccin a los sistemas operativos 41
Todos estos componentes ofrecen una serie de servicios a travs de una interfaz de
llamadas sistema. Como se muestra en la Figura 2.5, un sistema operativo puede incluir
ms de una interfaz de servicios (en la figura se han considerado las interfaces Win32 y
POSIX, interfaces que ser
descritas a lo largo del presente libro). En este caso, los programas podrn elegir sobre
qu interfaz quieren ejecutar, pero no podrn mezclar servicios de varias interfaces. Se
dice, en este caso, que sistema operativo presenta al usuario varias mquinas virtuales.
De igual forma, el sistema operativo puede incluir varios intrpretes de mandatos,
unos textuales y otros grficos, pudiendo el usuario elegir el que mas le interese. Sin
embargo, hay que observar que no se podrn mezclar mandatos de varios intrpretes.
En las secciones siguientes de este capitulo se van a describir, de forma muy breve,
cada uno de los componentes anteriores, pero antes se van a describir las distintas
formas que tienen los sistemas operativos de estructurar dichos componente.
Un sistema operativo de este tipo no tiene una estructura clara y bien definida. Todos sus
componentes se encuentran integrados en un nico programa (el sistema operativo) que
ejecuta en un nico espacio de direcciones. En este tipo de sistemas todas las funciones
que ofrece el sistema operativo se ejecuta en un modo ncleo.
Estos sistemas operativos han surgido, normalmente, de sistemas operativos
sencillos y pequeos a los que se les ha ido aadiendo un nmero mayor de
funcionalidades. Esto les ha hecho evolucionar y crece hasta convertirlos en programas
grandes y complejos formados por muchas funciones situadas todas ellas en un mismo
nivel. Ejemplos claros de este tipo de sistemas son MS-DOS y UNIX. Ambos comenzaron
siendo pequeos sistemas operativos, que fueron hacindose cada vez mas grandes
debido a la gran popularidad que adquirieron.
Introduccin a los sistemas operativos 43
En un sistema por capas, el sistema operativo se organiza como una jerarqua de capas,
donde cada capa ofrece una interfaz clara y bien definida a la capa superior y solamente
utiliza los servicios que le ofrece la capa inferior.
La principal ventaja que ofrece este tipo de estructuras es la modularidad y la
ocultacin de la informacin. Una capa no necesita conocer como se ha implementado
la capa sobre la que se construye, nicamente necesita conocer la interfaz que ofrece.
Esto facilita enormemente la depuracin y verificacin del sistema, puesto que las capas
se pueden ir construyendo y depurando por separado.
Este enfoque lo utilizo por primera vez el sistema operativo THE [Dijkstra, 1968], un
sistema operativo sencillo que estaba formado por seis capas, como se muestra en la
Figura 2.6. Otro ejemplo de sistema operativo diseado por capas es el OS/2 [Deitel,
1994], descendiente de MS-DOS.
b) Modelo cliente-servidor
No hay una definicin clara de las funciones que debe llevar a cabo un microncleo.
La mayora incluyen la gestin de interrupciones, gestin bsica de procesos y de
memoria y servicios bsicos de comunicacin entre procesos. Para solicitar un servicio en
este tipo de sistemas, como por ejemplo crear un proceso, el proceso de usuario (proceso
denominado cliente) solicita el servicio al servidor del sistema operativo correspondiente,
en este caso al servidor de procesos. A su vez, el proceso servidor puede requerir los
servicios de otros servidores, como es el caso del servidor de memoria. En este caso, el
servidor de procesos se convierte en cliente del servidor de memoria.
La ventaja de este modelo es la gran flexibilidad que presenta. Cada proceso
servidor slo ocupa de una funcionalidad concreta, lo que hace que cada parte pueda ser
pequea y
Esto a su vez facilita el desarrollo y depuracin de cada uno de los procesos servidores.
En cuanto a las desventajas, citar que estos sistemas presentan una mayor
sobrecarga en el tratamiento de los servicios que los sistemas monolticos. Esto se debe
a que los distintos componentes de un sistema operativo de este tipo ejecutan en
espacios de direcciones distintos, lo que hace que su activacin requiera ms tiempo.
Minix [Tanenbaum, 1998], Mach [Accetta, 1986] y Amoeba [Mullender, 1990] son
ejemplos de sistemas operativos que siguen este modelo. Windows NT tambin sigue
esta filosofa de diseo, aunque muchos de los servidores (el gestor de procesos, gestor
de E/S, gestor de memoria, etc.) se ejecutan en modo ncleo por razones de eficiencia.
memoria en los que reside el cdigo y los datos del proceso se le denomina imagen de
memoria. Observe que, durante su ejecucin, el proceso va modificando los registros del
modelo de programacin de la computadora, de acuerdo a las instrucciones de maquinas
involucradas. El contenido de los registros del modelo de programacin es lo que se
conoce como estado del procesador.
El sistema operativo mantiene por cada proceso una serie de estructuras de
informacin que permite identificar las caractersticas de ste as como los recursos que
tiene asignados. Una parte muy importante de esta estructura es el bloque de control del
proceso (BCP) que, como se ver en el Captulo 3, incluye, entre otra informacin, el
estado de los registros del proceso, cuando ste no est ejecutando. El sistema operativo
debe encargarse tambin de ofrecer una serie de servicios para la gestin de procesos y
de gestionar los posibles interbloqueos que surgen cuando los procesos acceden a
diferentes recursos.
Dependiendo del nmero de procesos y de usuarios que puedan ejecutar
simultneamente, un sistema operativo puede ser:
El sistema operativo ofrece una serie de servicios que permiten definir la vida de un
proceso. Esta vida est constituida por las siguientes fases; creacin, ejecucin y muerte
del proceso.
En general, los sistemas operativos ofrecen los siguientes servicios para la gestin de
procesos:
46 Sistemas operativos. Una visin aplicada
Crear un proceso. El proceso es creado por el sistema operativo cuando as lo
solicita otro proceso, que se convierte en el padre del nuevo. Existen dos
modalidades bsicas para crear un proceso en los sistemas operativos;
2.5.1. Servicios
El gestor de memoria ofrece una serie de servicios a los procesos. Estos son;
Los procesos son entes independientes y aislados, puesto que, por razones de
seguridad, no deben interferir unos con o os. Sin embargo, cuando se divide un trabajo
complejo e varios procesos que
48Sistemas operativos. Una visin aplicada
cooperan entre s para realizar ese trabajo, es necesario que se comuniquen para
transmitirse datos y rdenes y se sincronicen en la ejecucin de sus acciones. Por tanto,
el sistema operativo debe incluir servicios de comunicacin y sincronizacin entre
procesos que, sin romper los esquemas de seguridad, han de permitir la cooperacin
entre ellos.
El sistema operativo ofrece una serie de mecanismos bsicos de comunicacin que
permiten transferir cadenas de bytes, pero han de ser los procesos que se comunican los
que han de interpretar la cadena de bytes transferida. En este sentido, se han de poner
de acuerdo en la longitud de la informacin y en los tipos de datos utilizados.
Dependiendo del servicio utilizado, la comunicacin se limita a los procesos de una
mquina (procesos locales) o puede involucrar a procesos de mquinas distintas
(proceso. remotos). La Figura 2.9 muestra ambas situaciones.
El sistema operativo ofrece tambin mecanismos que permiten que los procesos
esperen (se bloqueen) y se despierten (continen su ejecucin) dependiendo de
determinados eventos.
De acuerdo con esto, los servicios bsicos de comunicacin, que incluyen todos los
mecanismos de comunicacin, son los siguientes;
Facilitar el manejo de los dispositivos perifricos. Para ello debe ofrecer una interfaz
sencilla, uniforme y fcil de utilizar entre los dispositivos, y gestionar los errores que
se pueden producir en el acceso a los mismos,
Ofrecer mecanismos de proteccin que impidan a los usuarios acceder sin control a
los dispositivos perifricos.
2.7.1. Servicios
El sistema operativo ofrece a los usuarios una serie de servicio, de E/S independiente de
los dispositivos, Esta independencia implica que deben emplearse los mismos servicios y
operaciones de E/S para leer, por ejemplo, datos de un disquete, de un disco duro, de un
CD-ROM o de un teclado, Los servicios de E/S estn dirigidos bsicamente a la lectura y
escritura de datos. Estos servicios pueden estar orientados a caracteres, como ocurre
con las impresoras o los terminales, o pueden estar orientados a bloques, como ocurre
con las unidades de disco. El segundo caso se diferencia del primero en que la operacin
elemental de E/S se hace sobre un bloque de informacin de un nmero fijo de caracteres
(p. ej.: sobre un bloque de 1 KB).
En general, los sistemas operativos consiguen la independencia en el acceso a los
dispositivos modelndolos como archivos especiales. La gestin de chivos y sus servicios
se describen en la siguiente seccin.
En el Captulo 7 se estudiar el software de E/S del sistema operativo, la gestin del
almacenamiento secundario y terciario, de los relojes y terminales. Tambin se
presentarn los servicios de EIS que ofrecen los sistemas operativos.
El servidor de archivos es la parte del sistema operativo que cubre una de las cuatro
clases de funciones que tiene ste en su faceta de mquina extendida. Los objetivos
fundamentales del servidor de archivos son los dos siguientes:
Facilitar el manejo de los dispositivos perifricos. Para ello ofrece una visin lgica
simplificada de los mismos en forma de chivos.
Proteger a los usuarios, poniendo limitaciones a los chivos que es capaz de
manipular cada usuario.
Los servicios que se engloban en el servidor de archivos son de dos tipos: los
servicios dirigidos al manejo de datos, o archivos, y los dirigidos al manejo de los
nombres, o directorios.
El servidor de archivos ofrece al usuario (Fig. 2.11) una visin lgica compuesta por
una serie de objetos ( chivos y directorios) identificables por un nombre lgico sobre los
que puede realiza una serie de operaciones. La visin fsica ha de incluir los detalles de
cmo estn almacenados estos objetos en los perifricos correspondientes (p. ej.: en los
discos).
Se crea el archivo
Se abre: se genera un descriptor de archivo
Se escribe y lee (el archivo puede crecer)
Se cierra Se borra
La ventaja del esquema jerrquico es que permite una gestin distribuida de los
nombres, garantizar de forma sencilla que no exista nombres repetidos. En efecto, hasta
con que los nombres relativos de cada. subdirectorio sean distintos, aunque los nombres
relativos de subdirectorios distintos sean iguales, para que no exista duplicacin de
nombres, puesto que quedarn diferencia dos por el camino hasta llegar al
correspondiente subdirectorio.
La visin fsica del sistema de directorios consiste en unas estructuras de
informacin que permiten relacionar cada nombre lgico con la descripcin fsica del
correspondiente archivo. En esencia, se trata de una tabla NOMBRE- IDENTIFICADOR
por cada subdirectorio. El NOMBRE no es mas que el nombre relativo del archivo,
mientras que el.DIENTIFICADOR es una informacin que permite localizar la descripcin
fsica del archivo.
Servicios de directorios
Un objeto directorio es bsicamente un conjunto de entradas que relacionan nombres y
archivos El servidor de archivos incluye una serie de servicios que permiten manipular
directorios. Estos son.:
Crear un directorio. Crea un objeto directorio y lo sita en el rbol de directorios
donde se especifique en el nombre, absoluto o relativo, del nuevo directorio.
Borrar un directorio. Elimina un objeto directorio de forma que nunca ms pueda
accesible y borra su entrada del rbol de directorios. Normalmente, slo se puede
borrar directorio vaco, es decir, un directorio sin entradas.
Abrir un directorio. Abre un directorio para leer los datos del mismo. Al igual que
un chivo, un directorio debe ser abierto para poder acceder a. su contenido. Esta
operacin vuelve al usuario un identificador, descriptor o manejador de directorio
de carcter temporal que permite su manipulacin.
Leer un directorio. Extrae la siguiente entrada de un directorio, abierto
previamente. Devuelve una estructura de datos como la que define la entrada de
directorios
Cerrar un directorio. Cierra un directorio, liberando el identificador devuelto en la
operacin de apertura, as como los recursos de memoria y del sistema operativo
relativos al mismo.
Introduccin a los sistemas operativos 55
2.8.3. Sistema de archivos
Se denomina sistema de archivos al conjunto de archivos incluidos en una unidad de
disco. El sistema de archivos est compuesto por los datos de los archivos, as como por
toda la informacin auxiliar que se requiere.
Se denomina rnetainformacin a toda la informacin auxiliar que es necesario
mantener en un volumen. Resumiendo y completando lo visto en las secciones anteriores,
la metainformacin est compuesta por los siguientes elementos:
Estructura fsica de los archivos (nodos-i de UNIX o FAT de MS-DOS)
Directorios (archivos que contienen las tablas nombre-puntero).
Estructura fsica del sistema de archivos (superbloque en UNIX).
Estructura de informacin de bloques y nodos-i libres (mapas de bits).
Cada sistema operativo organiza las particiones de disco de una determinada forma,
repartiendo el espacio disponible entre: el programa de carga (boot) del sistema operativo,
la metainforinacin y los datos. Normalmente, las tablas de los subdirectorios se
almacenan como archivos, por lo que compiten por los bloques de datos con los archivos
de datos.
En el Captulo 8 se estudiar en detalle la gestin de archivos y directorios,
presentando los conceptos, los servicios y los principales aspectos de implementacin.
Dado que hay muchas formas de utilizar un recurso, la lista de control de acceso, o
la de capacidades, han de incluir el modo en que se puede utilizar el recurso Ejemplos de
modos de utilizacin son los siguientes: leer, escribir, ejecutar, eliminar, test, control y
administrar.
Los servicios relacionados con la seguridad y la proteccin se centran en la
capacidad para asignar atributos de seguridad a los usuarios y a los recursos.
En el Captulo 9 se describirn todos los aspectos relacionados con la seguridad y la
proteccin y se presentarn los principales servicios.
Para concluir esta seccin, es importante resaltar que en un sistema, adems de las
interfaces disponibles para los usuarios normales, pueden existir otras especficas
destinadas a los administradores del sistema. Ms an, el propio programa (residente
normalmente en ROM) que se encarga de la carga del sistema operativo proporciona
generalmente una interfaz de usuario muy simplificada y rgida que permite al
administrador realizar operaciones tales como pruebas y diagnsticos del hardware o la
modificacin de los parmetros almacenados en la memoria RAM no voltil de la
mquina que controlan caractersticas de bajo nivel del sistema.
2.12.2. interfaces alfanumricas
La caracterstica principal de este tipo de interfaces es su modo de trabajo basado
en lneas de texto. El usuario, par dar instrucciones al sistema, escribe en su terminal un
mandato terminado con un carcter de final de lnea. Cada mandato est normalmente
estructurado corno un nombre de mandato (p. ej.: borrar) y unos argumentos (p. ej.: el.
nombre del archivo que se quiere borrar). Observe que en algunos sistemas se permite
que se introduzcan varios mandatos en una lnea. El intrprete de mandatos, que es
como se denomina tpicamente al mdulo encargado de la interfaz, lee la lnea escrita
por el usuario y lleva a cabo las acciones especificadas por la misma. Una vez
realizadas, el intrprete escribe una indicacin (prompt) en el terminal para notificar al
usuario que est listo para recibir otro mandato. Este ciclo repetitivo define el modo de
operacin de este tipo de interfaces, El usuario tendr disponibles un conjunto de
mandatos que le permitirn realizar actividades tales como manipular archivos y
directorios, controlar la ejecucin de los programas, desarrollar aplicaciones,
comunicarse con otros sistemas, obtener informacin del estado del sistema o acceder al
sistema. de ayuda interactivo.
Esta forma de operar, basada en lneas de texto, viene condicionada en parte por el
tipo de dispositivo que se usaba como terminal en los primeros sistemas de tiempo
compartido. Se trataba de teletipos que impriman la salida en papel y que, por tanto,
tenan intrnsecamente UI) funciona miento basado en lneas. La disponibilidad posterior
de terminales ms sofisticados que, aunque seguan siendo de carcter alfanumrico,
usaban una pantalla para mostrar la informacin y ofrecan, por tanto, la posibilidad de
trabajar con toda la. pantalla no cambi, sin embargo, la forma de trabajo de la interfaz
que continu siendo en modo lnea, Como reflejo de esta herencia, obsrvese que en el
mundo UNIX se usa el trmino tty (abreviatura de teletype) para referirse a un terminal,
aunque no tenga nada que ver con los primitivos teletipos. Observe que, sin embargo,
muchas aplicaciones s que se aprovecharon del. modo de trabajo en modo pantalla.
Como ejemplo, se puede
64 Sistemas operativos. Una visin aplicada
observar la evolucin de los editores en UNIX: se pas de editores en modo lnea como
el ed a editores orientados a pantalla como el vi y el emars.
A pesar de que el modo de operacin bsico apenas ha cambiado, Su estructura e
implementacin han evolucionado notablemente desde la aparicin de los primeros
sistemas de tiempo compartido hasta la actualidad. Como ya se ha comentado
anteriormente, se pas de tener el intrprete incluido en el sistema operativo a su un
mdulo externo que usa los servicios del mismo, lo proporciona una mayor flexibilidad
facilitando su modificacin o incluso su reemplazo. Dentro esta opcin existen
bsicamente dos formas de esturar el mdulo que maneja la interfaz de usuario
intrprete con mandatos internos e interprete con mandatos externos
Intrprete con mandatos internos
El intrprete de mandatos es un nico programa que contiene el cdigo para e todos los
mandatos. El intrprete, despus de leer la lnea tecleada por el usuario, determina de
qu mandato se trata y salta a la parle (le su cdigo que lleva a cabo la accin
especificada por el mandato. Si no se trata de ningn mandato, se interpreta que el
usuario quiere arrancar una determinada aplicacin, en cuyo caso el intrprete iniciar la
ejecucin del programa correspondiente en el contexto de un nuevo proceso y esperar
hasta que termine. Con esta estrategia, mostrada en el Programa 21, los mandatos son
internos al intrprete. Obsrvese que en esta seccin se est suponiendo que hay un
nico mandato en cada lnea.
_______________________________________________________________________
_
Programa 2.1. Esquema de un intrprete con mandatos internos.
Repetir Bucle
Escribir indicacin de preparado
Leer e interpretar lnea -> Obtiene operacin y argumentos
Caso operacin
Si fin
Terminar ejecucin de intrprete /
Si renombrar
Renombrar archivos segn especifican argumentos
Si borrar
Borrar archivos especificados por argumentos
Si no (No se trata de un mandato)
Arrancar programa operacin pasndole argumentos
Esperar a que termine el programa
Fin Bucle
___________________________________________________________________
_
Intrprete con mandatos externos
Existe un programa por cada mandato. El intrprete de mandatos no analiza la lnea
tecleada por el usuario, sino que directamente inicia la ejecucin del programa
correspondiente en el contexto de un nuevo proceso y espera que ste termine. Se
realiza un mismo tratamiento ya se trate de un mandato o de cualquier otra aplicacin.
Con esta estrategia, mostrada en el Programa 2.2, los mandatos son externos al
intrprete y la interfaz de usuario est compuesta por un conjunto de programas del
sistema: un programa por cada mandato ms el propio intrprete.
Introduccin a os sistemas operativos 65
_________________________________________________________________________________
_
Programa 22, Esquema de un intrprete con mandatos externos.
Repetir Bucle
Escribir indicacin de preparado
Leer e interpretar lnea > Obtiene operacin y argumentos
Si operacin = fin
Terminar ejecucin de intrprete
Si no
Arrancar programa operacin pasndoleargumentos
Esperar a que termine el programa
Fin Bucle
_________________________________________________________________________________
_
La principal ventaja de la primera estrategia es la eficiencia, ya que los mandatos los
lleva a cabo el propio intrprete sin necesidad de ejecutar programas adicionales. Sin.
embargo, el intrprete puede llegar a ser muy grande y la inclusin de un nuevo mandato,
o la modificacin de uno existente, exige cambiar el cdigo del intrprete y recompilarlo. La
segunda solucin es ms recomendable ya que proporciona un tratamiento y visin
uniforme de los mandatos del sistema y las restantes aplicaciones. El intrprete no se ve
afectado por la inclusin o la modificacin de un mandato.
En los sistemas reales puede existir tina mezcla de las dos estrategias. El intrprete
de manda tos de MS-DOS (COMMAND. COM )se enmarca dentro de la primera categora,
esto es, intrprete con mandatos internos. El motivo de esta estrategia se debe a que este
sistema operativo se dise para poder usarse en computadoras sin disco duro y, en este
tipo de sistemas, el uso de un intrprete con mandatos externos exigira que el disquete
correspondiente estuviese insertado para ejecutar un determinado mandato. Sin embargo,
dadas las limitaciones de memoria de MS-DOS, para mantener el tamao del intrprete
dentro de un valor razonable, algunos mandatos de uso poco frecuente, como por ejemplo
DISKCOPY, estn implementados como externos.
Los intrpretes de mandatos de UNIX, denominados shells, se engloban en la
categora de intrpretes con mandatos externos. Sin embargo, algunos mandatos se
tienen que implementar como internos debido a que su efecto slo puede lograrse si es el
propio intrprete el que ejecuta el mandato. As, por ejemplo, el mandato cd, que cambia el
directorio actual de trabajo del usuario usando la llamada chdir, requiere cambiar a su vez
el directorio actual de trabajo del proceso que ejecuta el intrprete, lo cual slo puede
conseguirse si el mandato lo ejecuta directamente el intrprete.
2.12.3. Interfaces grficas
El auge de las interfaces grficas de usuario (GUI, Graphical UserInterface) se debe
principalmente a la necesidad de proporcionar a los usuarios no especializados una visin
sencilla e intuitiva del sistema que oculte toda su complejidad. Esta necesidad ha surgido
por la enorme difusin de las computadoras en todos los mbitos de la vida cotidiana Sin
embargo, el desarrollo de este tipo de interfaces ms amigables ha requerido un avance
considerable en la potencia y capacidad grfica de las computadoras dada la gran
cantidad de recursos que consumen durante su operacin.
Las primer experiencias con este tipo de interfaces se remontan a Los primeros
aos de la dcada de los setenta. En Xerox PARC (un centro de investigacin de Xerox)
se desarroll lo que actualmente se considera la primera estacin de trabajo a. la que se
denomin Alto. Adems de otros muchos avances, esta investigacin estableci los
primeros pasos en el campo de los GUI.
66 Sistemas operativos. Una visin aplicada
Con la aparicin, a principios de los ochenta, de las computadoras personales
dirigidas a usuarios no especializados se acentu la necesidad de proporcionar este tipo
de interfaces. As la compaa Apple adopto muchas de las ideas de la investigacin de
Xerox PARC para lanzar su computadora personal [Macintosh, 1984] con una interfaz
grfica que simplificaba enormemente el manejo de la computadora. El otro gran
competidor en este campo, el sistema operativo MS tard bastante ms en dar este
paso. En sus primeras versiones proporcionaba una. interfaz alfanumrica similar a la de
UNIX pero muy simplificada. Como paso intermedio, hacia 1988, incluyo una interfaz
denominada. DOS-SHELL que, aunque segua siendo alfanumrica, no estaba basada
en lneas sino que estaba orientada al uso de toda la. pantalla y permita realizar
operaciones mediante mens. Por fin, ya en los noventa, lanz una interfaz. grfica,
denominada. Windows, que tomaba prestadas muchas de las ideas del Macintosh.
En el mundo UNIX. se produjo una evolucin similar. Cada fabricante inclua en su
sistema. una interfaz grfica adems de la convencional. La. aparicin del sistema de
ventanas X a mediados de los ochenta y su aceptacin generalizada, que le ha
convertido en un estndar de facto, ha permitido que la mayora de los sistemas UNIX
incluyan una interfaz grfica comn. Como resultado de este proceso, prcticamente
todas las computadoras de propsito general existentes actualmente poseen una interfaz
de usuario grfica
Hoy en da, este tipo de interfaces tiene su mayor representante en los sistemas
operativo Windows de Microsoft. En la Figura 2.18 se muestra uno de los elementos
clave de la interfaz grfica de este tipo de sistemas, el explorador de Windows.
A continuacin, se revisan las caractersticas comunes de este tipo de interfaces. En
primer lugar, todos ellos estn basados en ventanas que permiten al usuario trabajar
simultneamente en distintas actividades. Asimismo, se utilizan iconos y mens para
representar los recursos del sistema y poder realizar operaciones sobre los mismos,
respectivamente. El usuario utiliza. un ratn (o dispositivo equivalente) para interaccionar
con estos elementos. As, por ejemplo, para arrancar una:
Figura 2.19 Estructura de un sistema distribuido que utiliza un sistema operativo distribuido
3.1CONCEPTO DE PROCESO
Todos los programas, cuya ejecucin solicitan los usuarios, se ejecutan en forma de
procesos, de ah la importancia para el informtico de conocerlos en detalle. Como ya se
vio en el Captulo 2, el proceso se puede definir como un programa en ejecucin y, de
una forma un poco ms precisa, como la unidad de procesamiento gestionada por el
sistema operativo.
En el Captulo 1 se vio que para que un programa pueda ser ejecutado ha de
residir con sus datos en memoria principal. Observe que durante su ejecucin el proceso
va modificando los registros del modelo de programacin de la computadora, de acuerdo
a las instrucciones de mquina involucradas (Fig. 1.3).
El sistema operativo mantiene por cada proceso una serie de estructuras de
informacin que permiten identificar las caractersticas de ste, as como los recursos
que tiene asignados. En esta ltima categora entran los descriptores de los segmentos de
memoria asignados, los descriptores de los archivos abiertos, los descriptores de los
puertos de comunicaciones, etc.
Una parte muy importante de estas informaciones se encuentra en el llamado
bloque de control del proceso (BCP). El sistema operativo mantiene una tabla de
procesos con todos los BCP de los procesos. Por razones de eficiencia, la tabla de
procesos se construye normalmente como una estructura esttica, que tiene un
determinado nmero de BCP, todos ellos del mismo tamao. El contenido del BCP se
analizar con ms detalle en secciones posteriores; sin embargo, de manera introductoria
se puede decir que la informacin que compone un proceso es la siguiente:
Contenido de los segmentos de memoria en los que residen el cdigo y los datos
del proceso. A esta informacin se le denomina imagen de memoria o core image.
Contenido de los registros del modelo de programacin.
Contenido del BCP.
Es de destacar que el proceso no incluye informacin de E/S, puesto que sta suele
estar reservada al sistema operativo.
Jerarqua de procesos
Grupos de procesos
Los procesos forman grupos que tienen diversas propiedades. El conjunto de procesos
creados a partir de un shell puede formar un grupo de procesos. Tambin pueden formar
un grupo los procesos dependientes de un terminal.
El inters del concepto de grupo de procesos es que hay determinadas operaciones
que se pueden hacer sobre todos los procesos de un determinado grupo, como se ver al
estudiar algunos de los servicios. Un ejemplo es la posibilidad de matar a todos los
procesos pertenecientes a un mismo grupo.
3.2. MULTITAREA
Monotarea o monoproceso.
Multitarea o multiproceso.
Monousuario.
Multiusuario (tiempo compartido).
Un sistema monousuario est previsto para dar soporte a un solo usuario. Estos
sistemas pueden ser monoproceso o multiproceso. En este ltimo caso el usuario puede
solicitar varias tareas al mismo tiempo, por ejemplo, puede estar editando un archivo y,
simultneamente, puede estar accediendo a una pgina Web de la red.
El sistema operativo multiusuario da soporte a varios usuarios que trabajan
simultneamente desde varios terminales. A su vez, cada usuario puede tener activos
ms de un proceso, por lo que el sistema, obligatoriamente, ha de ser multitarea. Los
sistemas multiusuario reciben tambin el nombre de tiempo compartido, puesto que el
sistema operativo ha de repartir el tiempo de la computa-. dora entre los usuarios, para
que las tareas de todos ellos avancen de forma razonable.
Figura 3.2. Tipos de sistemas operativos en funcin del numero de procesos y usuarios
Procesos 81
Este proceso consiste en un bucle infinito que no realiza ninguna operacin til. El
objetivo de este proceso es entretener al procesador cuando no hay ninguna otra tarea.
Planificador y activador
El planificador (scheduler) forma parte del ncleo del sistema operativo. Entra en
ejecucin cada vez que se activa el sistema operativo y su misin es seleccionar el
proceso que se ha de ejecutar a continuacin.
El activador (dispatcher) tambin forma parte del sistema operativo y su funcin es
poner en ejecucin el proceso seleccionado por el planificador.
La multiprogramacin presenta varias ventajas, entre las que se pueden resaltar las
siguientes:
Todas estas ventajas hacen que, salvo para situaciones muy especiales, no se conciba
actualmente un sistema operativo que no soporte multitarea.
Procesos 83
En los sistemas con memoria virtual la situacin es ms compleja, puesto que los
procesos slo tienen en memoria principal su conjunto residente (Recordatorio 32), lo
que hace que quepan mas procesos. Sin embargo, al aumentar el nmero de procesos
disminuye el conjunto residente de cada uno, situacin que se muestra en la Figura 3.6.
Cuando el conjunto residente de un proceso se hace menor de un determinado
valor ya no representa adecuadamente al futuro conjunto de trabajo (Recordatorio 3.2)
del proceso, lo que tiene como consecuencia que se produzcan muchos fallos de pgina.
Cada fallo de pgina consume tiempo de procesador, porque el sistema operativo ha de
tratar el fallo, y tiempo de FIS, puesto que hay que hacer una migracin de pginas.
Todo ello hace que, al crecer los fallos de pginas, el sistema dedique cada vez ms
tiempo al improductivo trabajo de resolver estos fallos de pgina.
La Figura 3.7 muestra que, en un sistema con memoria virtual, el aumento del
grado de multiprogramacin conlleva primero un aumento del rendimiento del
procesador. Sin embargo, superado un determinado valor de grado de multiprogramacin
los conjuntos residentes de los procesos empiezan a ser demasiado pequeos, por lo que
el sistema baja su rendimiento al perder el tiempo paginando.
El estado del procesador (Aclaracin 3.1) est formado por el contenido de todos sus
registros, que se enumeran seguidamente:
Puntero de pila.
Registro o registros de estado.
Registros especiales. Como puede ser el RIED (registro identificador de espacio de
direccionamiento).
La imagen de memoria del proceso est formada por los espacios de memoria que est
autorizado a utilizar. Las principales caractersticas de la imagen de memoria son las
siguientes:
Se puede decir que esta solucin no se emplea. En sistemas sin memoria virtual los
segmentos no pueden crecer a menos que se deje espacio de memoria principal de
reserva; se chocara con otro proceso. Ahora bien, la memoria principal es muy cara
como para dejarla de reserva. En sistemas Con memoria virtual s se podra emplear,
pero es ms conveniente usar un modelo de varios segmentos, pues es mucho ms
flexible y se adapta mejor a las necesidades reales de los procesos.
Procesos 87
-Datos sin valor inicial. Estos datos son estticos, pero no tienen valor asignado.
por lo que no estn presentes en el archivo ejecutable. Ser el sistema operativo el
que, al cargar el proceso, rellene o no rellene esta zona de datos con valores
predefinidos.
-Datos dinmicos. Estos datos se crean y se destruyen de acuerdo a las directrices
del programa.
Los datos podrn ser de lectura-escritura o solamente de lectura.
Pila. A travs del puntero de pila, los programas utilizan una estructura dc pila
residente en memoria. En ella se almacenan, por ejemplo, los bloques de activacin de
los procedimientos llamados. La pila es una estructura dinmica, puesto que crece y
decrece segn avanza la ejecucin del proceso.
Esta solucin es ms avanzada que la anterior, al permitir que existan los segmentos que
desee el proceso. La Figura 3.10 presenta un caso de siete segmentos, que podrn ser de
texto. de pila o de datos.
Cdigo.
Datos con valor inicial.
Los datos sin valor inicial no necesitan residir en el archivo ejecutable puesto que el
sistema operativo se encargar de asignarles valor (normalmente O) cuando cree el
proceso encargado de ejecutar dicho programa.
Ejecutable de Win32
Cabecera MZ de MS-DOS.
Programa MS-DOS.
Cabecera del ejecutable.
Cabecera de Seccin 1.
Cabecera de Seccin 2.
Cabecera de Seccin 3.
...
Cuerpo de la Seccin 1.
Cuerpo de la Seccin 2.
Cuerpo de la Seccin 3.
...
4. Cabeceras de las secciones. Los datos del ejecutable en s estn contenidos en las seccio-
nes. Las secciones se componen de una cabecera y un cuerpo. En el cuerpo de la seccin
estn los datos y en la cabecera de la seccin informacin de cmo estn organiiados los
datos y de qu tipo son (de lectura, de escritura, de lectura/escritura...).
5. Cuerpos de las secciones. Despus de las cabeceras de las secciones estn los cuerpos de
las secciones, donde estn contenidos todos los datos del ejecutable. Las secciones mas
comunes son: cdigo, datos con valor inicial, datos con valor inicial de slo lectura,
datos sin valor inicial, funciones importadas, funciones exportadas, depuracon...
El BCP contiene la informacin bsica del proceso, entre la que cabe destacar la
siguiente:
Informacin de identificacin
Contiene los valores iniciales del estado del procesador o su valor en el instante en que
fue interrumpido el proceso.
Procesos 91
Como se muestra en la Figura 3.8, el sistema operativo mantiene una serie de tablas que
describen a los procesos y a los recursos del sistema. Algunos de los aspectos de estas
tablas ya se han ido comentando, pero aqu se profundizar y detallar el contenido de
las mismas.
La informacin asociada a cada proceso se encuentra parcialmente en el BCP y
parcialmente fuera de l. La decisin de incluir o no una informacin en el BCP se toma
segn dos argumentos: eficiencia y necesidad de compartir informacin.
Eficiencia
Por razones de eficiencia, es decir, para acelerar los accesos, la tabla de procesos se
construye normalmente como una estructura esttica, formada por un nmero
determinado de BCP del mismo tamao. En este sentido, aquellas informaciones que
pueden tener un tamao variable no deben incluirse en el BCP. De incluirlas habra que
reservar en cada BCP el espacio necesario para almacenar el mayor tamao que puedan
tener estas informaciones. Este espacio estara presente en todos los BCP, pero estara
muy desaprovechado en la mayora de ellos.
Un ejemplo de este tipo de informacin es la tabla de pginas, puesto que su
tamao depende dc las necesidades de memoria de los procesos, valor que es muy
variable de unos a otros. En este sentido, el BCP incluir el RIED (registro identificador
de espacio de direccionamiento) e incluso una descripcin de cada segmento (p. ej.:
incluir la direccin virtual donde comienza el segmento, su tamao, la zona reservada
para su crecimiento y el puntero a la subtabla de pginas, pero no la subtabla en s).
Compartir informacin
Figura 3.12. Tabla de archivos con los punteros de posicin y los descriptores fsicos de archivo.
Ahora bien, se puede dar el caso de que dos procesos independientes A y B abran
el mismo archivo, Imaginemos que el proceso A lee 1.000 bytes del archivo y que
seguidamente el proceso B lee 500 bytes. Est claro que el proceso B, que no tiene nada
que ver con el proceso A, espera leer los primeros 500 bytes del archivo y no los bytes 1
.000 a 1 .499. Para evitar esta situacin, el sistema operativo asignar una nueva entrada
en la tabla externa de archivos cada vez que se realice una operacin de apertura de
archivo. De esta forma, cada apertura obtiene su propio PP.
La Figura 3.12 presenta esta situacin, puesto que analizando el proceso con BCP
23 se observa que su fd 4 utiliza la entrada 2 de la tabla externa de archivos. Esta entrada
se refiere al archivo de IDFF = 345 12, que coincide con el de la entrada 4. Los tres
procesos de la figura comparten el archivo 34512, pero de forma distinta, puesto que los
de BCP 4 y 7 comparten el PP, mientas que el de BCP 23 utiliza otro puntero de posicin
(Aclaracin 3.3).
Finalmente, diremos que otra razn que obliga a que las tablas de pginas sean
externas al BCP es para permitir que se pueda compartir memoria. En este caso, como
se analizar en detalle en el Captulo 4, dos o ms procesos comparten parte de sus tablas
de pginas.
Tablas de E/S
Procesos 93
Una vez completada toda la informacin del proceso, se puede marcar como listo
para ejecutar, dc forma que el planificador, cuando lo considere oportuno, lo seleccione
para su ejecucin.
Como se puede observar en la Figura 3.4, no todos los procesos activos de un sistema
multitarea estn en la misma situacin. Se diferencian, por tanto, tres estados bsicos en
los que puede estar un proceso, estados que detallamos seguidamente:
Ejecucin. En este estado est el proceso que est siendo ejecutado por el
procesador, es decir, que est en fase de procesamiento. En esta fase el estado
del proceso reside en los registros del procesador.
Adems de los tres estados bsicos de ejecucin, listo y bloqueado, los procesos pueden
estar en los estados de espera y de suspendido. El diagrama de estados completo de un
proceso se representa en la Figura 3.15.
Los procesos entran en el sistema porque lo solicita un proceso de usuario o porque est
prevista su ejecucin hatch. Es frecuente tener una lista de procesos batch en espera
para ser ejecutados cuando se pueda. El sistema operativo ha de ir analizando dicha lista
para lanzar la ejecucin de los procesos a medida que disponga de los recursos
necesarios.
Los procesos salen del sistema cuando mueren, es decir, al ejecutar el servicio
correspondiente o al producir algn error irrecuperable.
complete una lectura de disco y que llega una interrupcin del disco. Se produce un
cambio de contexto y entra a ejecutar el sistema operativo para tratar la interrupcin. En
el caso de que la interrupcin indique que ha terminado la lectura por la que esperaba A,
el sistema operativo cambiar el estado de este proceso a listo o incluso a ejecucin si as
lo decide el planificador. El resultado final es que ha habido un cambio de estado de
proceso.
Supngase ahora que est ejecutando el proceso A y que llega una interrupcin de
teclado asociado al proceso B. Se produce el cambio de contexto, pero el proceso B
puede seguir en estado de bloqueado (no lleg el carcter de fin de lnea) y el proceso A
puede seguir en estado de ejecucin, por lo que no hay cambio de estado en ]os procesos.
Las transiciones en el estado del proceso exigen un trabajo cuidadoso por parte del
sistema operativo, para que se hagan correctamente. El aspecto ms delicado se refiere al
contenido de los registros de la computadora. Veamos detalladamente los pasos
involucrados:
LD .5,# CANT
<= En este punto llega una interrupcin y se pasa al SO
LD .1, [.5]
Procesos 97
Activacin de un proceso
El mdulo del sistema operativo que pone a ejecutar un proceso se denomina activador
o dispatcher. La activacin de un proceso consiste en copiar en los registros del
procesador el estado del procesador, que est almacenado en su BCP. De esta forma, el
proceso continuar su ejecucin en las mismas condiciones en las que fue parado. El
activador termina con una instruccin RETI (Recordatorio 3.4) de retorno de
interrupcin. El efecto de esta instruccin es restituir el registro de estado y el contador
de programa, lo cual tiene los importantes efectos siguientes:
Contador de programa.
Pila.
Registros.
Estado del proceso ligero (ejecutando, listo o bloqueado).
Todos los procesos ligeros de un mismo proceso comparten la informacin del mismo.
En concreto, comparten:
Espacio de memoria.
Variables globales.
Archivos abiertos.
Procesos hijos.
Temporizadores.
Seales y semforos.
Contabilidad.
El proceso ligero puede estar en uno de los tres estados siguientes: ejecutando, listo para
ejecutar y bloqueado. Como muestra la Figura 3.19, cada proceso ligero de un proceso
tiene su propio estado, pudiendo estar unos bloqueados, otros listos y otros en ejecucin
(Aclaracin 3.4).
El estado del proceso ser a combinacin de los estados de sus procesos ligeros.
Por ejemplo, si tiene un proceso ligero en ejecucin, el proceso est en ejecucin. Si no
tiene proceso ligeros en ejecucin, pero tiene alguno listo para ejecutar, el proceso est
en estado de listo. Finalmente, si todos sus procesos ligeros estn bloqueados, el proceso
est bloqueado. No tiene sentido el estado dc suspendido, puesto que si el proceso est
suspendido, todos sus procesos ligeros lo estarn.
3.6.2.Paralelismo
Los procesos ligeros permiten paralelizar una aplicacin, tal y como muestra la Figura
3.20. En efecto, cuando un programa puede dividirse en procedimientos que pueden
ejecutar de forma independiente, el mecanismo de los procesos ligeros permite lanzar
simultneamente la ejecucin de todos ellos. De esta forma se consigue que el proceso
avance ms rpidamente (Prestaciones 3.2).
La base de este paralelismo estriba en que, mientras un proceso ligero est bloqueado,
otro puede ejecutar.
Comparando el uso de los procesos ligeros con otras soluciones se puede decir que:
No hay paralelismo.
Utiliza llamadas al sistema bloqueantes.
Permite paralelismo.
Utiliza llamadas al sistema no bloqueantes, lo que lleva a un diseo muy
complejo y difcil de mantener.
Figura 3.20. Los procesos ligeros permiten paralelizar la ejecucin de una aplicacin.
Procesos 101
Permite paralelismo.
No comparte variables, por lo que la comunicacin puede consumir mucho
tiempo.
La utilizacin de procesos ligeros ofrece las ventajas de divisin de trabajo que dan los
procesos, pero con una mayor sencillez, lo que se traduce en mejores prestaciones. En
este sentido, es de destacar que los procesos ligeros comparten memoria directamente,
por lo que no hay que aadir ningn mecanismo adicional para utilizarla, y que la
creacin y destruccin de procesos ligeros requiere mucho menos trabajo que la de
procesos.
Las ventajas de diseo que se pueden atribuir a los procesos ligeros son las siguientes:
Hay variables globales que se comparten entre varios procesos ligeros. Dado que
cada proceso ligero ejecuta de forma independiente a los dems, es fcil que
ocurran accesos incorrectos a estas variables.
Para ordenar la forma en que los procesos ligeros acceden a los datos se emplean
mecanismos de sincronizacin, como el mutex, que se describirn en el Captulo 5.
El objetivo de estos mecanismos es impedir que un proceso ligero acceda a unos
datos mientras los est utilizando otro.
Para escribir cdigo correcto hay que imaginar que los cdigos de los otros
procesos ligeros que pueden existir estn ejecutando cualquier sentencia al mismo
tiempo que la sentencia que se est escribiendo.
3.7. PLANIFICACIN
Expulsin
La planificacin puede ser con expulsin o sin ella. En un sistema sin expulsin un
proceso conserva el procesador mientras lo desee, es decir, mientras no solicite del
sistema operativo un servicio que lo bloquee. Esta solucin minimiza el tiempo que gasta
el sistema operativo en planificar y
Procesos 130
activar procesos, pero tiene como inconveniente que un proceso puede monopolizar el
procesador (imagnese lo que ocurre si el proceso, por error, entra en un bucle infinito).
En los sistemas con expulsin, el sistema operativo puede quitar a un proceso del
estado de ejecucin aunque ste no lo solicite. Esta solucin permite controlar el tiempo
que est en ejecucin un proceso, pero requiere que el sistema operativo entre de forma
sistemtica a ejecutar para as poder comprobar si el proceso ha superado su lmite de
tiempo de ejecucin. Como sabemos, las interrupciones sistemticas del re]oj garantizan
que el sistema operativo entre a ejecutar cada pocos milisegundos, pudiendo determinar
en estos Instantes si ha de producirse un cambio dc proceso o no.
Colas de procesos
Para realizar las funciones de planificacin, el sistema operativo organiza los procesos
listos en una serie de estructuras de informacin que faciliten la bsqueda del proceso a
planificar. Es muy frecuente organizar los procesos en colas de prioridad y de tipo.
La Figura 3.23 muestra un ejemplo con 30 colas para procesos interactivos y 2
colas para procesos batuh. Las 30 colas interactivas permiten ordenar los procesos listos
interactivos segn 30 niveles dc prioridad, siendo, por ejemplo, el nivel 0 el ms
prioritario. Por su lado, las dos colas batch permiten organizar los procesos listos batch
en dos niveles de prioridad.
Se puede observar en la mencionada figura que se ha incluido una palabra
resumen. Esta palabra contiene un 1 si la correspondiente cola tiene procesos y un 0 si
est vaca. De esta forma, se acelera cl planificador, puesto que puede saber rpidamente
dnde encontrar procesos listos.
Corno muestra la Figura 3.24, las colas de procesos se construyen con unas
cabeceras y con unos punteros que estn incluidos en los BCP. Dado que un proceso est
en cada instante en una sola cola de planificacin, es necesario incluir un solo espacio de
puntero en su BCP, como muestra la Figura 3.24.
Objetivos de la planificacin
La mayora de estos objetivos son incompatibles entre s, por lo que hay que
centrar la atencin en aquel que sea de mayor inters. Por ejemplo, una planificacin que
realice un reparto equitativo del procesador no conseguir optimizar el uso del mismo.
Hay que observar que algunos objetivos estn dirigidos a procesos interactivos,
mientras que otros lo estn a procesos batch.
Cclica o Round-robin
El algoritmo cclico est diseado para hacer un reparto equitativo del tiempo del
procesador, por lo que est especialmente destinado a los sistemas de tiempo
compartido. El algoritmo se basa en el concepto de rodaja (slot) de tiempo.
Los procesos estn organizados en forma de cola circular, eligindose para su
ejecucin el proceso cabecera de la cola. Un proceso permanecer en ejecucin hasta que
ocurra una de las dos condiciones siguientes:
El proceso pasa a estado de bloqueado, porque solicita un servicio del sistema
operativo.
El proceso consume su rodaja de tiempo, es decir, lleva ejecutando el tiempo
estipulado de rodaja.
En este caso, la cola de procesos en estado de listo est ordenada de acuerdo al instante
en que los procesos pasan al estado de listo. Los que llevan ms tiempo esperando estn
ms cerca de la cabecera.
El algoritmo es sencillo, puesto que consiste en tomar para ejecutar al proceso de
la cabecera de la cola. No se plantea expulsin, por lo que el proceso ejecuta hasta que
realiza una llamada bloqueante al sistema operativo.
Es aplicable a los sistemas batch, pero no a los interactivos.
Prioridades
Este algoritmo exige conocer a priori el tiempo de ejecucin de los procesos, por lo que
es aplicable a trabajos batch repetitivos cuyo comportamiento se tenga analizado.
El algoritmo consiste en seleccionar para ejecucin al proceso listo con menor tiempo
de ejecucin. No se plantea expulsin, por lo que el proceso sigue ejecutndose mientras
lo desee.
La ventaja de este algoritmo es que produce el menor tiempo de respuesta, pero a costa
de penalizar los trabajos de mayor tiempo de ejecucin. Tambin puede sufrir de
inanicin, puesto que, en el caso de que estn continuamente apareciendo procesos con
tiempo de ejecucin pequeo, un proceso largo puede no llegar a ejecutar.
Aleatorio o lotera
Los sistemas de tiempo real se caracterizan porque los procesos tienen que ejecutar en
instantes predeterminados. Se pueden diferenciar dos tipos de procesos de tiempo real: a
plazo fijo y peridico. La diferencia estriba en que los de plazo fijo tienen que ejecutar
una vez, en un instante determinado, mientras que los peridicos deben ejecutar de forma
repetitiva cada cierto tiempo.
Como muestra la Figura 3.26, se asocia a cada proceso el instante en el que debe
ejecutar. Los procesos que no han alcanzado su tiempo de ejecucin estn en una cola de
espera, mientras que los que han alcanzado el tiempo de ejecucin pasan a las colas de
listo para ejecutar. La planificacin consiste en seleccionar de entre estos ltimos el
proceso a ejecutar.
La planificacin de tiempo real est basada en el reloj de tiempo de la computadora y su
objetivo es conseguir que no se retrase la ejecucin de los procesos. En los denominados
sistemas de tiempo real crticos, los procesos tienen asignada una franja de tiempo en la
cual deben ejecutar y. en ningn caso, se ha de rebasar el tiempo mximo sin que el
proceso complete su ejecucin.
Procesos 107
Los sistemas de tiempo real se suelen disear de forma que estn bastante
descargados, es decir, que tengan pocos procesos en estado de listo. De esta forma se
consigue que no se retrase la ejecucin de los mismos. Adems, se evitan los
mecanismos que introducen retardos en la ejecucin, como puede ser la memoria virtual,
puesto que la paginacin puede introducir retardos inadmisibles en la ejecucin.
Cuando un proceso bloqueado pasa a listo para ejecutar, el proceso se introduce al final de la
cola asociada a su prioridad.
Cuando un proceso cambia su prioridad o su poltica de planificacin, utilizando para ello los
servicios adecuados, se realiza una replanificacin. Si como resultado de sta
el proceso resulta expulsado, ste se introduce al final de la cola de procesos
de su prioridad.
Cclica: En este caso, los procesos de cada nivel de prioridad se planifican segn una
poltica de planificacin cclica con una determinada rodaja de tiempo. El
comportamiento del planificador para los procesos con este tipo de planificacin es
el siguiente:
Observe que la poltica de planificacin se realiza por proceso y, por tanto, las tres
polticas conviven en el planificador. Observe, adems, que la planificacin en POSIX es
con expulsin.
Listo. Los procesos ligeros en este estado estn listos para ejecutar.
Reserva. Un proceso ligero en este estado ser el siguiente proceso ligero a ejecutar
en un procesador determinado. Slo puede haber un proceso ligero en este estado por
procesador.
Ejecucin. El proceso ligero permanece ejecutando hasta que se cumpla alguna de
estas condiciones: el sistema operativo lo expulsa para ejecutar un proceso ligero de
mayor prioridad, la rodaja de tiempo del proceso termina o bien el proceso ligero finaliza
su ejecucin.
Bloqueado. Cuando el proceso ligero deja de estar bloqueado puede, dependiendo de
su prioridad, comenzar su ejecucin inmediatamente o pasar al estado de listo para
ejecutar.
Transicin. Un proceso ligero entra en este estado cuando est listo para ejecutar,
pero la pila que utiliza el sistema operativo para ese proceso no reside en memoria
principal. Cuando la pgina vuelva a memoria, el proceso ligero pasar al estado de listo
para ejecutar.
Finalizado. Cuando un proceso ligero finaliza su ejecucin, pasa a este estado. Una
vez terminado, el proceso ligero puede o no ser eliminado del sistema. En caso de no ser
eliminado, podra ser reutilizado de nuevo.
Procesos 109
Todos los procesos ligeros en el mismo nivel se ejecutan segn una poltica de
planificacin cclica con una determinada rodaja de tiempo (Prestaciones 3.3). En la
primera categora, todos los procesos ligeros tienen una prioridad fija. En la segunda, los
procesos comienzan su ejecucin con una determinada prioridad y sta va cambiando
durante la vida del proceso, pero sin llegar al nivel 16. Esta prioridad se modifica segn
el comportamiento que tiene el proceso durante su ejecucin. As, un proceso (situado en
el nivel de prioridades variable) ve decrementada su prioridad si acaba la rodaja de
tiempo. En cambio, si el proceso se bloquea, por ejemplo, por una peticin de E/S
bloqueante, su prioridad aumentar. Con esto se persigue mejorar el tiempo de respuesta
de los procesos interactivos que realizan E/S.
3.8.1. Seales
Las seales tienen frente al proceso el mismo comportamiento que las interrupciones
tienen frente al procesador, por lo que se puede decir que una seal es una interrupcin al
proceso.
El proceso que recibe una seal se comporta, como muestra la Figura 3.28, de la
siguiente forma:
Un proceso puede enviar una seal a otro proceso que tenga el mismo identificador de
usuario (uid), a no los que lo tengan distinto (Aclaracin 3.5). Un proceso tambin puede
mandar una seal a un grupo de procesos, que han de tener su mismo uid.
El sistema operativo tambin toma la decisin de enviar seales a los procesos cuando
ocurren determinadas condiciones. Por ejemplo, las excepciones de ejecucin programa
(el desbordamiento
Figura 3.28. Recepcin de una seal por parte de un proceso.
Procesos 111
en las Operaciones aritmticas, la divisin por cero, el intento de ejecutar una instruccin
con cdigo de operacin incorrecto o de direccionar una posicin de memoria prohibida)
las convierte el sistema operativo en seales al proceso que ha causado la excepcin.
Tipos de seales
Dado que las seales se utilizan para indicarle al proceso muchas cosas diferentes,
existen una gran variedad de ellas. A ttulo de ejemplo, se incluyen aqu tres categoras
de seales:
Excepciones hardware.
Comunicacin.
FIS asncrona.
3.8.2. Excepciones
Una excepcin es un evento que ocurre durante la ejecucin de un programa y que
requiere la ejecucin dc un fragmento de cdigo situado fuera del flujo normal de
ejecucin.
Las excepciones son generadas por el hardware o el software. Ejemplos de excepciones
hardware incluyen la divisin por cero o la ejecucin de instrucciones ilegales. Las
excepciones software incluyen aquellas detectadas y notificadas por el sistema operativo
o el propio proceso. Cuando ocurre una excepcin, tanto hardware como software, el
control es transferido al Sistema operativo, que ejecuta la rutina de tratamiento de
excepcin correspondiente. Esta rutina crea un registro de excepcin que contiene
informacin sobre la excepcin generada. Si existe un manejador para la excepcin
generada, el sistema operativo transfiere el control a dicho manejador, en caso contrario
aborta la ejecucin del proceso.
try{
Bloque donde puede producirse una excepcin
}
except{
Bloque que se ejecutar si se produce una excepcin
en el bloque anterior
}
3.9. TEMPORIZADORES
El sistema operativo mantiene en cada BCP un temporizador que suele estar expresado
en segundos. Cada vez que la rutina del sistema operativo que trata las interrupciones de
reloj comprueba que ha transcurrido un segundo, decrementa todos los temporizadores
que no estn a 0 y comprueba si han llegado a 0. Para aquellos procesos cuyo
temporizador acaba de llegar a 0, el sistema operativo notifica al proceso que el
temporizador ha vencido. En POSIX se genera una seal SIGALRN. En Win32 se
ejecuta una funcin definida por el usuario y que se asocia al temporizador.
El proceso activa el temporizador mediante un servicio en el que especifica el
nmero de segundos o milisegundos que quiere temporizar. Cuando vence la
temporizacin, recibir la correspondiente seal o se ejecutar la funcin asociada al
mismo.
Los servidores y los demonios son dos tipos de procesos muy frecuentes y que tienen
unas caractersticas propias que se analizan seguidamente.
Un servidor es un proceso que est pendiente de recibir rdenes de trabajo que provienen
de otros procesos, que se denominan clientes. Una vez recibida la orden, la ejecuta y
responde al peticionario con el resultado. La Figura 3.29 muestra cmo el proceso
servidor atiende a los procesos clientes.
Lectura de orden. El proceso est bloqueado esperando a que llegue una orden.
Recibida la orden, el servidor la ejecuta.
Procesos 113
De esta forma, el proceso servidor dedica muy poco tiempo a cada cliente, puesto
que el trabajo lo realiza un nuevo proceso, y puede atender rpidamente nuevas
peticiones. La Figura 3.30 muestra esta secuencia.
Esta seccin describe los principales servicios que ofrece POSIX para la gestin de
procesos, procesos ligeros y planificacin. Tambin se presentan los servicios que
permiten trabajar con seales y temporizadores
En esta seccin se describen los principales servicios que ofrece POSIX para la gestin
de procesos. Estos servicios se han agrupado segn las siguientes categoras:
Identificacin de procesos.
El entorno de un proceso.
Creacin de procesos.
Terminacin de procesos.
Procesos 115
Identificacin de procesos
POSIX identifica cada proceso por medio de un entero nico denominado identificador
de proceso de tipo pid_ti. Los servicios relativos a la identificacin de los procesos son
los siguientes:
Este servicio devuelve el identificador del proceso que realiza la llamada. Su prototipo
en C lenguaje es el siguiente:
Pid_t getpid(void);
pid ti getppid(void);
El Programa 3. 1 muestra un ejemplo de utilizacin de ambas llamadas.
_______________________________________________________________________
Programa 3.1. Programa que imprime el identificador del proceso y el identificador de
su proceso padre.
# include <sys/types.h>
#include <stdio.h>
main ( )
{
pid_id_proceso;
pid_id_padre;
id proceso = getpid ( );
id_padre = getppid ( );
Este servicio devuelve el identificador de usuario real del proceso que realiza la llamada.
Su prototipo es:
uid_t getuid(void);
uid_t geteuid(void);
Este servicio permite obtener el identificador de grupo real. El prototipo que se utiliza
para invocar este servicio es el siguiente:
_______________________________________________________________________
Programa 3.2. Programa que imprime la informacin de identificacin de un proceso.
#include <sys/types.h>
#include <stdio.h>
main ( )
El entorno de un proceso
El entorno de un proceso viene definido por una lista de variables que se pasan al mismo
en el momento de comenzar su ejecucin. Estas variables se denominan variables de
entorno y son accesibles a un proceso a travs de la variable externa environ, declarada
de la siguiente forma:
Procesos 117
Esta variable apunta a una lista de variables de entorno. Esta lista no es ms que un
vector de punteros a cadenas de caracteres de la forma nombre = valor, donde nombre
hace referencia al nombre de una variable de entorno y valor al contenido de la misma.
El Programa 3.3 imprime la lista de variables de entorno de un proceso.
_______________________________________________________________________
Programa 3.3. Programa que imprime el entorno del proceso.
#include <stdio.h>
#include <stdlib.h>
El servicio getenv permite buscar una determinada variable de entorno dentro de la lista
de variables de entorno de un proceso. La sintaxis de esta funcin es:
#include <stdio.h>
#include <stdlib.h>
main ()
Creacin de procesos
En esta seccin se describen los principales servicios POSIX relativos a la creacin de
procesos.
a) Crear un proceso
La Figura 3.32 muestra que la donacin del proceso padre se realiza copiando la
imagen de memoria y el BCP. Observe que el proceso hijo es una copia del proceso
padre en el instante en que ste solicita el servicio fork. Esto significa que los datos y la
pila del proceso hijo son los que tiene el padre en ese instante de ejecucin. Es ms, dado
que, al entrar el sistema operativo a tratar el servicio, lo primero que hace es salvar los
registros en el BCP del padre, al copiarse el BCP se copian los valores salvados de los
registros, por lo que el hijo tiene los mismos valores que el padre.
El hijo recibe un 0.
El padre recibe el identificador de proceso del hijo.
Este valor de retorno se puede utilizar mediante una clusula de condicin para
que el padre y el hijo sigan flujos de ejecucin distintos, como se muestra en la Figura
3.33.
Observe que las modificaciones que realice el proceso padre sobre sus registros e
imagen de memoria despus del FORK no afectan al hijo y, viceversa, las del hijo no
afectan al padre. Sin embargo, el proceso hijo tiene su propia copia de los descriptores
del proceso padre. Esto hace que el hijo tenga acceso a los archivos abiertos por el
proceso padre. El padre y el hijo comparten el puntero de posicin de los archivos
abiertos en el padre.
El Programa 3.5 muestra un ejemplo de utilizacin de la llamada fork. Este
programa hace uso dc la funcin de biblioteca perror que imprime un mensaje
describiendo el error de la ltima llamada ejecutada. Despus de la llamada fork, los
procesos padre e hijo imprimirn sus identificadores de proceso utilizando la llamada
getpid, y los identificadores de sus procesos padre por medio de la llamada getppid.
Observe que los identificadores del proceso padre son distintos en cada uno de los dos
procesos.
_______________________________________________________________________
Programa 3.5. Programa que crea un proceso.
#include <sys/ypes.h>
#ineclude <stdio.h>
main ()
{
120 Sistemas operativos. Una visin aplicada
pid_t pid;
pid = fork ();
switch(pid) {
case -1: /* error del fork<) *1
perror(fork)
break;
case 0: /* proceso hilo */
printf(Proceso %d; padre = %d \n, getpid, getppid();
break;
default: /* padre */
printf(Proceso %d; padre = %d \n, getpid, getppid();
_______________________________________________________________________
El cdigo del Programa 3.6 crea una cadena de n procesos como se muestra en la Figura
3.34.
_______________________________________________________________________
#include <sys/types.h>
#include <stdio.h>
main ()
{
piclit pid;
int i;
int n = 10;
}
_______________________________________________________________________
mamo
pidt pid;
mt i;
mt n = 10;
En este programa, a diferencia del anterior, es el proceso hijo el que finaliza la ejecucin
del bucle ejecutando la sentencia break, siendo el padre el encargado de crear todos los
procesos.
h) Ejecutar un programa
El servicio exec de POSIX tiene por objetivo cambiar el programa que est ejecutando
un proceso. Se puede considerar que el servicio tiene dos fases. En la primera se vaca el
proceso de casi todo su contenido, mientras que en la segunda se carga en nuevo
programa. La Figura 3.36 muestra estas dos fases.
2 N
BCP
Mapa de
memoria
o
Se
carga la nueva imagen
Objeto Tabla de procesos Se
pone PC en direccin de arranque
ejecutable Imagen
co
~ detprocaso
Se conservan los fd
Biblioteca
sistema
Recuerde que el servicio fork crea un nuevo proceso que ejecuta el mismo programa que
el
proceso padre y que el servicio exec no crea un nuevo proceso, sino que permite que un
proceso pase a ejecutar un programa distinto.
En POSIX existe una familia de funciones exec, cuyos prototipos se muestran a
continuacin:
in~ excl(char ~path, char ~arg, ...); ic execv(char *path char *argv[]); ints
execle(char *path char *arg, ...);
Procesos 1
mt execve(char *path, char *argv[] char *envp[1); mt execlp(char *file const char *arg,
...);
mt execvp<char *file, char *argv[1);
La familia de funciones exec reemplaza la imagen del proceso actual por una nueva
imagen. Esta nueva imagen se construye a partir de un archivo ejecutable. Si la llamada
se ejecuta con xito, sta no devolver ningn valor puesto que la imagen del proceso
habr sido reemplazada, en caso contrario devuelve 1.
La funcin main del nuevo programa llamado tendr la forma:
ACLARACIN 3.7
Cuando un usuario ejecuta un archivo ejecutable con el bit de modo set -user- ID, el
nuevo proceso creado tendr como identificador de usuario efectivo el identificador de
usuario del propietario del archivo ejecutable. Como se ver en el Captulo 9, este
identificador es el que se utiliza para comprobar los permisos en los accesos a
determinados recursos como son los archivos. Pr tanto, cuando se ejecuta un programa
con este bit, el nuevo proceso ejecuta con los permisos que tiene el propietario del
archivo ejecutable.
El nuevo proceso hereda del proceso que realiza la llamada los siguientes atributos:
ldcntiticador de proceso.
ldentificador del proceso padre.
ldentificador del grupo del proceso.
ldentificador de usuario real.
#include <sys/types.h>
#include <stdio.h>
mamo
pidt pid;
mt status;
pid = fork;
switch(pid)
case 1: /* error del fork(> */
exit(-1);
case O: /* proceso hijo */
execlp(ls, ls, -1 ,NULL);
perror(exec)
break;
default: /* padre */
#include <sys/types .
#include <stdio.h>
pidt pid;
char *argumentos[3];
Procesos
pid = fork<);
switch(pid)
case ~-1: /~ error del fork() */
Xit(-l)
case O: /~ proceso hijo */
execvp(argumentos[O] argumentos);
perror ( exec);
break;
default: /* padre */
printf ( Proceso padre\n);
El siguiente programa (Programa 3.10) crea un proceso que ejecuta un mandato recibido
en la lnea de argumentos.
#include <sys/types.h>
#include <stdio.h>
pid = fork;
switch<pid)
case -1: /* error del fork() */
xit(-1);
case O: /* proceso hijo */
if (execvp(argv[1], &argv[1])< O)
perror(exec)
default: /* padre */
printf (Proceso padre\n);
}
Terminacin de procesos
Cuando un programa ejecuta dentro de la funcin main la sentencia return (valor), sta es
similar a exit (valor). El prototipo de la funcin exit es:
voidexit(int status);
Estos servicios tienen por funcin finalizar la ejecucin de un proceso. Ambos reciben
como parmetro un valor que sirve para que el proceso d una indicacin de cmo ha
terminado. Como se ver ms adelante, esta informacin la puede recuperar el proceso
padre que, de esta forma, puede conocer cmo ha terminado el hijo.
La finalizacin de un proceso tiene las siguientes consecuencias:
Procesos
127
El Programa 3.11 finaliza su ejecucin utilizando la llamada exit. Cuando se llama a esta
tuncion se ejecuta la funcin fin, registrada previamente por medio de la funcin atexit.
Programa 3.11. Ejemplo de utilizacin de exit y atexit.
#include <stdio.h>
#include <stdlib.h>
void in(void)
void main(void)
if (atexit(fin) O)
perror(atexit)
exit (1)
Permite a un ~~OCCS() padre esperar hasta que termine la ejecucin de un proceso hijo
(el proceso padre se queda bloqueado hasta que termina un proceso hijo). Existen dos
formas de invocar este servicio:
pid = fork~
switch(pid)
case 1: /* error del fork() */
exit(-l)
case O: /~ proceso hijo */
mf (exeevp(argv[11, &argv[l]) <O)
perror(exec);
if (valor == O)
printfVEl mandato se ejecuto de formal normal\n);
else
if (WIFEXITED(valor))
printf(El hijo termino normalmente y su valor
devuelto fue %d\n, WEXITEDSTATUS(valor));
}
if (WIFSIGNALZD(valor))
printfVEl hijo termino al recibir la seal
%d\n, WTERMSIG(valor));
La utilizacin de los servicios fork, exec, wait y exit hace variar la jerarqua de procesos
(Fig. 3.37). Con el servicio fork aparecen nuevos procesos y con el exit desaparecen. Sin
embargo, existen algunas situaciones particulares que conviene analizar.
La primera situacin se refleja en la Figura 3.38. Cuando un proceso termina y se
encuentra con que el padre no est bloqueado en un servicio wai t, se presenta el
problema de dnde almacenar el estado de terminacin que el hijo retorna al padre. Esta
informacin no se puede almacenar en el BCP del padre, puesto que puede haber un
nmero indeterminado de hijos que hayan terminado. Por ello, la informacin se deja en
el BCP del hijo, hasta que el padre la adquiera mediante el oportuno wa it. Un proceso
muerto que se encuentra esperando el wai t del padre se dice que est en estado zombie.
El proceso ha devuelto todos sus recursos con excepcin del BCP, que contiene el pid
del padre y la palabra de estado de terminacin.
pid P
padre
pidP pidP pIdH1 pidP DidH EJ ~DD~D
EZZ1 EZZ EZ EZZIEZZ1
Figura 3.37. Uso de las llamadas fork, exec, wait y exit.
pid P
EJ
Texto
Datos
Pila
Archivos, tuberas,...
}
y
1
)
La segunda situacin se presenta en la Figura 3.39 y se refiere al caso de que un proceso
con hijos termine antes que stos. De no tomar alguna accin correctora, estos procesos
contendran su BCP una informacin obsoleta del pid del padre, puesto que ese proceso
ya no existe. La solucin adoptada en UNIX es que estos procesos hurfanos los toma
a su cargo el proceso mit. Er concreto, el proceso B de la mencionada figura pasar a
tener como padre al P~OCCSO ini,.
Para que los procesos heredados por mit acaben correctamente, y no se conviertan en
zombies,
el proceso mit est en un bucle infinito de walt.
La mayora de los intrpretes de mandatos (shells) permiten ejecutar mandatos en
huckgroi
finalizando la lnea de mandatos con el carcter &. As, cuando se ejecuta el siguiente
mandato;
ls 1 &
El shell ejecutar el mandato ls l sin esperar la terminacin del proceso que lo ejecut.
Esto
permite al intrprete de mandatos estar listo para ejecutar otro mandato, el cual puede
ejecutarse d
lnit
Proceso A
forkO
nit
nit
)
)
(
(
l~igura 3.39. En UNIX el proceso ini ~ heredo los proce.~os hilos que se quedan sin
padre.
)
)
((
II
(
Proc~sos 131
#inciude <sys/types.h>
#include <stdio.h>
main(inL argc, char **argv)
picit pid;
pu fork(>;
SW]LCh(pid>
1
3.11.2. Servicios POSIX de gestin de procesos ligeros
Cada proceso ligero en POSIX tiene asociado una serie de atributos que representan sus
propiedades. Los valores de los diferentes atributos se almacenan en un objeto atributo
de tipo pth~eadattr_t. Existen una serie de servicios que se aplican sobre el tipo anterior
y que permiten modificar los valores asociados a un objeto de tipo atributo. A
continuacin, se describen las principales funciones relacionadas con los atributos de los
procesos ligeros.
Este servicio permite iniciar un objeto atributo que se puede utilizar para crear nuevos
procesos ligeros. El prototipo de esta funcin es:
mt pthread_attr_init(pthread_attr_t *attr)
b) Destruir atributos
Destruye el objeto de tipo atributo pasado como argumento a la misma. Su prototipo es:
intpthread_attr_destroy(pthread_attr_t*attr>;
Cada proceso ligero tiene una pila cuyo tamao se puede establecer mediante esta
funcin, cuyo prototipo es el siguiente:
El prototipo del servicio que permite obtener el tamao de la pila de un proceso es:
Los servicios relacionados con la creacin e identificacin de procesos ligeros son los
siguientes:
Este servicio permite crear un nuevo proceso ligero que ejecuta una determinada
funcin. Su prototipo es:
Procegos
1
33
El primer argumento de la funcin apunta al identificador del proceso ligero que se crea,
este identificador viene determinado por el tipo pthread_t. El segundo argumento
especifica los atributos de ejecucin asociados al nuevo proceso ligero. Si el valor de
este segundo argumento es NULL, se utilizarn los atributos por defecto, que incluyen la
creacin del proceso como no independiente. El tercer argumento indica el nombre de la
funcin a ejecutar cuando el proceso ligero comienza su ejecucin. Esta funcin requiere
un solo parmetro que se especifica con el cuarto argumento, arg.
Los servicios relacionados con la terminacin de procesos ligeros son los siguientes:
La funcin suspende la ejecucin del proceso ligero llamante hasta que el proceso ligero
con identificador thid finalice su ejecucin. La funcin devuelve en el segundo
argumento el valor que pasa el proceso ligero que finaliza su ejecucin en el servicio
pthread exi t, que se ver a continuacin. nicamente se puede solicitar el servicio
pthreadlion sobre procesos ligeros creados
1
como no independientes.
b) Finalizar la ejecucin de un proceso ligero
Es anlogo al servicio exlt sobre procesos. Su prototipo es:
Incluye un puntero a una estructura que es devuelta al proceso ligero que ha ejecutado la
correspondiente llamada a pthread joln, lo que es mucho ms genrico que el parmetro
que permite el servicio walt.
La Figura 3.40 muestra una jerarqua de procesos ligeros. Se supone que el proceso
ligero A es el primario, por lo que corresponde a la ejecucin del main. Los procesos B,
C y D se han creado mediante pthread_create y ejecutan respectivamente los
procedimientos b o, c O) y d O). El proceso ligero D se ha creado como no
independiente, por lo que otro proceso puede hacer una
)
134Sistemas operativos. Una visin aplicada
pcreate Nc
5~so
ligero B
Figura 3.40. E/emplo de jerarqua de procesos ligeros.
operacin hin sobre ~1. La figura muestra que el proceso ligero C hace una operacion
/0w sobre el D, por lo que se queda bloqueado hasta que termine.
El Programa 3.14 crea dos procesos ligeros que ejecutan la funcin func. Una vez
creados se espera su finalizacin con la funcin pthreadjoin.
#include <pthread.h>
#include <st.dio.h>
void func(void)
mo i n
Proceso
ligero O
1
(
Procesos 135
/~ se espera su terminacin ~/
pthreadjoin(thl, NULL); pthreadjoin(th2, NULL);
exit (O)
Lii ~ que se muestra a continuacin (Programa 3.15) crea diez procesos ligeros
indepcndientcs. que liberan sus recursos cuando finalizan (se han creado con el atributo
PJHHEAD CREATIi_DETACHED). En este caso, no se puede esperar la terminacin
de los procesos ligeros. p~r lo que el proceso ligero principal que ejecuta el cdigo de la
funcin main debe continuar su e~ccucion en paralelo con ellos. Para evitar que el
proceso ligero principal finalice la ejecucin dc la lbncin main. lo que supone la
ejecucin del servicio exit y, por tanto, la finalizacin de todo el proceso (Aclaracin
3.8), junto con todos los procesos ligeros, el proceso ligero principal suspendc su
ejecucin durante cinco segundos para dar tiempo a la creacin y destruccin dc los
procesos ligeros que se han creado.
Progrania 3.15. Programa que crea diez procesos ligeros independientes.
VC)ii] naln))
lot 3;
pthCed t LhidIMAXTHREADS]
El siguiente programa (Programa 3.16) crea un proceso ligero por cada nmero que se
introduce. Cada proceso ligero ejecuta el cdigo de la funcin imprimir.
Programa 3.16. Programa que crea un proceso ligero por cada
nmero introducido.
#define MAX_THREADS 10
main ()
pthread_attrt attr;
pthread_t thid;
mt num;
pthread_attrinit(&attr);
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
while (1)
scanf(%d, &num); /~ espera */
pthreadcreate (&thid, &attr, imprimir, &num);
Para cada poltica de planificacin hay un rango de prioridades mnimo que toda
implementacin debe soportar. Para polticas FIFO y cclicas, debe haber al menos 32
niveles de prioridad.
La prioridad de ejecucin de los procesos y procesos ligeros se puede especificar
mediante la
estructura schedparam, que debe incluir al menos el siguiente campo, que especifica la
prioridad de planificacin:
mt schedpriority;
/~ prioridad de ejecucin del proceso */
Hay diversas funciones que permiten obtener informacin sobre los parmetros de
planificacin de un proceso. Estas son las siguientes:
Estas dos funciones devuelven los niveles de prioridad mnimo y mximo dc la poltica
de
planificacin poiicy.
Procesos 13
Lii esta scccion se presentan los principales servicios que ofrece POSIX para la gestin
de seales y teinporizadores.
El archivo de cabecera signal . h declara la lista de seales posibles que se pueden enviar
a los procesos en un sistema. A continuacin se presenta una lista de las seales que
deben incluir todas as implementaciones. La accin por defecto para todas estas seales
es la terminacin anormal de proceso.
Si una iniplernentacin soporta control de trabajos, entonces tambin debe dar soporte,
entre otras, a las siguientes seales:
La accin por defecto para la seal SIGCHLD, que indica la terminacin de un proceso
hijo. es ignorar la seal.
A continuacin, sc describen los principales servicios POSIX relativos a las seales.
Estos servicios se han agrupado de acuerdo a las siguientes categoras:
Conjuntos de seales.
Envo dc seales.
Armado de una seal.
Bloqueo de seales.
Espera de seales.
Servicios de temporizacin.
Conjuntos de seales
Como se ha indicado anteriormente, existe una serie de seales que un proceso puede
recibir durante su ejecucin. Un proceso puede realizar operaciones sobre grupos o
conjuntos de seales. Estas operaciones sobre grupos de seales utilizan conjuntos de
seal de tipo sigset~t y son las sigu lentes:
mt sigeiuptyset(sigset t *~~11)
Procdsos
141
Envo de seales
Algunas seales como SIGSEGV o SIGBUS las genera el sistema operativo cuando
ocurren ciertos errores. Otras seales se envan de unos procesos a otros utilizando el
siguiente servicio:
una seal
Enva la seal sig al proceso o grupo de procesos especificado por pid. Para que un
~fOCC5() pueda enviar una seal a otro proceso designado por pid, el identificador de
usuario efectivo o real del proceso que enva la seal debe coincidir con el identificador
real o efectivo del proceso que la recibe, a no ser que el proceso que enva la seal tenga
los privilegios adecuados, por ejemplo es un
~fOCC5() ejecutado por cl superusuario.
Si pid es mayor que cero, la seal se enviar al proceso con identificador de proceso
igual a
p~ ci. Si pid es cero, la seal se enviar a todos los procesos cuyo identificador de grupo
sea igual al dentificador de grupo del proceso que enva la seal. Si pid es negativo pero
distinto de 1, la
seal ser enviada a todos los procesos cuyo identificador de grupo sea igual al valor
absoluto de
1
p Ld. Para pid igual a 1, POSIX no especifica funcionamiento alguno.
Armado de tina seal
Esta llamada tiene tres parmetros: el nmero de seal para la que se quiere establecer el
inane jador. un puntero a una estructura de tipo struct sigaction para establecer el nuevo
manejador y un puntero a una estructura tambin del mismo tipo que almacena
informacin sobre el manejador establecido anteriormente.
La estructura sigact ion, definida en el archivo de cabecera signal .h, est formada por los
siguientes campos:
struct sigaction
void (*sahandler) ~ /*
Manejador para la seal */
slgsets samask; /* Seales bloqueadas durante la
ejecucin del manejador */
mt sa_ filags; /* opciones
especiales */
El primer argumento indica la accin a ejecutar cuando se reciba la seal. Su valor puede
ser:
Si el valor del tercer argumento es distinto de NULL, la accin previamente asociada con
la
seal ser almacenada en la posicin apuntada por oact. La funcin devuelve o en caso
de xito o
-1 si hubo algn error.
El siguiente fragmento de cdigo hace que el proceso que lo ejecute ignore la seal
SIGINT
que se genera cuando se pulsa CTLR-C.
Mscara de seales
Con esta funcin se permite bloquear un conjunto de seales de tal manera que su envo
ser
congelado hasta que se desbloqueen.
El valor del argumento how indica la manera en la cual el conjunto de seales set ser
camNado. Los posibles valores de este argumento se encuentran definidos en el archivo
de cabecera signal .h y son los siguientes:
sigset_t mask;
Procesos 143
sigfillset(&mask)
sigprocmask(SIG_SETMASK, &mask, NULL);
sigsett mask;
sigemptyset (&mask)
sigaddset(&mask, SIGSEGV>;
sigprocmask(SIG_UNBLOCK, &mask, NULL);
mt sigpending(sigset t *~~>
Espera de seales
Cuando se quiere esperar la recepcin de una seal, se utiliza el pause. Este servicio
bloquea al P~OCCS() que la invoca hasta que llegue una seal. Su prototipo es:
mt pause(void);
Este servicio no permite especificar el tipo de seal por la que se espera, por tanto,
cualquier
seal no ignorada sacar al proceso del estado de bloqueo.
Servicios de temporizacin
a) Activar un temporizador
#include <stdio.h>
#include <signal.h>
void main(void)
/* establece el manejador */
act.sa_handler = tratar_alarma; / funcin a ejecutar */ act.saflags = O; /* ninguna accin
especfica*/
for ( ; ;
alarm(3)
pause ()
/* se arma el temporizador */
/* se suspende el proceso hasta que se
reciba una seal */
El Programa 3. 1 8 muestra un ejemplo en el que un proceso temporiza la ejecucin de un
proceso hijo. El programa crea un proceso hijo que ejecuta un mandato recibido en la
lnea de mandatos y espera su finalizacin. Si el proceso hijo no termina antes de que
haya transcurrido una determinada cantidad de tiempo, el padre mata al proceso
envindole una seal mediante el servicio kill. La seal que se enva es SIGKILL, seal
que no se puede ignorar ni armar.
pidt pid;
mt status;
char **argumentos;
scruct sigaction act;
argumentos = &argv[l];
/k Se crea el proceso hijo */
pid fork;
switch <pid)
exit (O);
En el programa anterior, una vez que el proceso padre ha armado el temporizador, se
bloquea esperando la finalizacin del proceso hijo, mediante una llamada a walt. Si la
seal SIGALRM se recibe antes de que el proceso haya finalizado, el padre ejecutar la
accin asociada a la recepcin de esta seal. Esta accin se corresponde con la funcin
matarproceso, que es la que se encarga de enviar al proceso hijo la seal SIGKILL.
Cuando el proceso hijo recibe esta seal, se finaliza su ejecucin.
mt sleep(unsigned mt seconds)
146Sistemas operativos. Una visin aplicada
Esta seccin describe los principales servicios que ofrece Win32 para la gestin de
procesos, procesos ligeros y planificacin. Tambin se presentan los servicios que
permiten trabajar con excepciones y temporizadores.
Identificacin de procesos.
El entorno de un proceso.
Creacin de procesos.
Terminacin de procesos.
Identificacin de procesos
El primer argumento especifica el modo de acceso al objeto que identifica al proceso con
idcntificador Idprocess. Algunos de los posibles valores para este argumento son:
El entorno de un proceso
El Programa 3.19 ilustra el uso de esta funcin para imprimir la lista de variables de
entorno de
un proceso.
Programa 3.19. Programa que lista las variables de entorno de un proceso en Windows.
~
#include <windows.h>
#include cstdio.h>
void rnain(void)
char *lpszVar
void *lpvEnv;
lpvEnv GetEnvironinentStrizigs ~
if (lpvEnv == NULL)
printrf(Error al acceder al entorno\n)
exit<O~
148Sistemas operativos. Una visin aplicada
putchar<*lpszVar++);
putchar ( \ni;
Creacin de procesos
EOOL CreateProcess
LPCTSTR lpszlmageName,
LPTSTR lpszComrnandLine,
LPSECURITY_ATTRIBUTES lpsaProcess,
LPSECURITY_ATTRIBLJTES lpsaThread,
BOQL flnheritHandles,
DWORD fdwCreate,
LPVOID lpvEnvironrnent,
LPCTSTR lpszcurdir,
LPSTARTUPINFO lpsistartlnfo,
5 LPPROCESS_INFQRMATION
Esta funcin crea un nuevo proceso y su proceso ligero principal. El nuevo proceso
ejecuta el archivo ejecutable especificado en lpszlmageName. Esta cadena puede
especificar el nombre de un archivo con camino absoluto o relativo, pero la funcin no
utilizar el camino de bsqueda. Si lpszlmageName es NULL, se utilizar como nombre
de archivo ejecutable la primera cadena delimitada por blancos del argumento
lpszCommandLine.
El argumento lpszCommandLine especifica la lnea de mandatos a ejecutar, incluyendo
el
Procesos
149
Fi parmetro lpEnvironment apunta al bloque del entorno del nuevo proceso. Si el valor
es NULL, el nuevo proceso obtiene el entorno del proceso que realiza la llamada.
El argumento lpszcurar apunta a una cadena de caracteres que indica el directorio actual
de trabajo para el nuevo proceso. Si el valor de este argumento es NULL, el proceso
creado tendr el nhismo directorio que el padre.
El parmetro lpStartuplnfo apunta a una estructura de tipo STARTPINFO que especifica
la apariencia de la ventana asociada al nuevo proceso. Para especificar los manejadores
para la entrada, salida y error estndar deben utilizarse los campos hStdln, hStdut y
hStdErr. En este caso, el campo dwFlags de esta estructura debe contener el valor
STARTFUSESTDHANDLES
Por ltimo, en el argumento lpProcesslnformatjon puntero a una estructura de tipo
PROCESE INFORMATION, se almacenar informacin sobre el nuevo proceso creado.
Esta estructura tiene la siguiente definicin:
En los campos hProcess y hThread se almacenan los manejadores del nuevo proceso y
del proceso ligero principal de l. En dwProcessld se almacena el identificador del nuevo
proceso y en dwThreadld el identificador del proceso ligero principal del proceso creado.
FI Programa 3.20 crea un proceso que ejecuta un mandato pasado en la lnea de
argumentos. El proceso padre no espera a que finalice, es decir, el nuevo proceso se
ejecuta en background.
Programa 3.20. Programa que crea un proceso que ejecuta la lnea de mandatos pasada
como argumento.
#include <windows.h>
#include <stdio.h>
STARTUPINFO si;
PRUCESSINFORMATION pi;
i f (!Createprocess
NULL, /~ utiliza la lnea de mandatos */
150Sistemas operativos. Una visin aplicada
argv [1], NTJLL, NULL, FALSE, o, NULL, NTJLL, &s1, &pj)
/~ lnea de mandatos pasada como argumentos */ /* manejador del proceso no
heredable*/ /* manejador del thread no heredable */ /* no hereda manejadores */
/* sin flags de creacin */
/* utiliza el entorno del proceso */
/~ utiliza el directorio de trabalo del padre */
printf <Error al crear el proceso. Error: %x\n, GetLastError <)>;
ExitProcess<O>
/* el proceso acaba ~/
exit (O)
Terminacin de procesos
La llamada cierra todos los manejadores abiertos por el proceso y especifica el cdigo de
salida del proceso. Este cdigo lo puede obtener otro proceso mediante el siguiente
servicio:
Esta funcin devuelve el cdigo de terminacin del proceso con manejador hProcess. El
proceso especificado por hProcess debe tener el acceso
PROCESSQUERYINFORIVIATION (vese OpenProcess). Si el proceso todava no ha
terminado, la funcin devuelve en lpdwExitCode el valor STILL_ALIVE en caso
contrario almacenar en este valor el cdigo de terminacin.
Adems, un proceso puede finalizar la ejecucin de otro mediante el servicio:
La primera funcin bloquea al proceso hasta que el proceso con manejador hObject
finalice su ejecucin. El argumento dwTimeOut especifica el tiempo mximo de bloqueo
expresado en rnilisegundos. Un valor de O hace que la funcin vuelva inmediatamente
despus de comprobar si el proceso finaliz la ejecucin. Si el valor es INFINITE, la
funcin bloquea al proceso hasta que el
proceso acabe su ejecucin.
La segunda funcin permite esperar la terminacin de varios procesos. El argumento
cObj ects especifica el nmero de procesos (el tamao del vector 1phob~ects) por los que
se desea esperar. El argumento lphObjects es un vector con los manejadores de los
procesos sobre los que se quiere esperar. Si el parmetro fWaitAll es TRUE, entonces la
funcin debe esperar por todos los procesos, en caso contrario la funcin vuelve tan
pronto como un proceso haya acabado. El parme1ro dwTimeOut tiene el significado
descrito anteriormente.
Estas funciones, aplicadas a procesos, pueden devolver los siguientes valores:
Programa 3.21. Programa que crea un proceso que ejecuta la lnea de mandatos pasada
como argumento y espera por l.
STARTUPINFO si;
PROCESS_INFORMATION pi;
IDWORD code;
if (!Createprocess( NTJLL,
argv[l], /*
NULL,
NULL,
FALSE,
Q
NULL,
NULL,
&sj,
&pi))
utiliza la lnea de mandatos */
lnea de mandatos pasada como argumentos */ manejador del proceso no heredable*/
manejador del thread no heredable */ no hereda manejadores */
sin flags de creacin */ utiliza el entorno del proceso */
utiliza el directorio de trabajo del padre */
Los procesos ligeros son la unidad bsica de ejecucin en Windows. Los servicios de
Win32 para la gestin de procesos ligeros pueden agruparse en las siguientes categorlas:
Identificacin de procesos ligeros.
Creacin de procesos ligeros.
Terminacin de procesos ligeros.
A continuacin, se presentan los servicios incluidos en las categoras anteriores.
Identificacin de procesos ligeros
En Win32, los procesos ligeros, al igual que los procesos, se identifican mediante
identificadores de procesos ligeros y manejadores. Estos presentan las mismas
caractersticas que los identificadores y manejadores para procesos, ya descritos en la
Seccin 3.12.1.
Existen dos funciones que permiten obtener la identificacin del proceso ligero que
realiza la
llamada.
Procesos
La primera devuelve el manejador del proceso ligero que realiza la llamada y la segunda
su
identificador de proceso ligero.
Conocido el identificador de un proceso ligero, se puede obtener su manejador mediante
el
siguiente servicio:
Esta funcin crea un nuevo proceso ligero. El argumento lpsa contiene la estructura con
los atributos de seguridad asociados al nuevo proceso ligero. Su significado es el mismo
que el utilizado en la Iuncin CreateProcess. El argumento cbStack especifica el tamao
de la pila asociada al proceso ligero. Un valor de o especifica el tamao por defecto (1
MB). lpStartAddr apunta a la funcin a ser ejecutada por el proceso ligero. Esta funcin
tiene el siguiente prototipo:
DWORDWINAPI ThreadFunc(LPVOID>;
Una vez creado un proceso ligero, ste puede suspenderse mediante la funcin:
DWORD SuspendThread(HANDLE hThread);
Al igual que con los procesos en Win32, los servicios relacionados con la terminacin de
procesos ligeros se agrupan en dos categoras: servicios para finalizar la ejecucin de un
proceso ligero y
servicios para esperar la terminacin de un proceso ligero. Estos ltimos son los mismos
que los empleados para esperar la terminacin de procesos (waitForSinglebject y
WaitForMultipleObjects) y no se volvern a tratar.
Un proceso ligero puede tambin abortar la ejecucin de otro proceso ligero mediante el
servicio.
Win32 ofrece servicios para que los usuarios puedan modificar aspectos relacionados con
la prioridad y planificacin de los procesos y de los procesos ligeros. Como se describi
en la Seccin 3.7.2, la prioridad de ejecucin va asociada a los procesos ligeros, ya que
son stos las unidades bsicas de ejecucin. La clase de prioridad va asociada a los
procesos.
La prioridad de cada proceso ligero se determina segn los siguientes criterios:
La clase de prioridad de su proceso.
El nivel de prioridad del proceso ligero dentro de la clase de
prioridad de su proceso.
Las prioridades de los procesos ligeros son relativas a la prioridad base del proceso al
que pertenecen. Cuando se crea un proceso ligero, ste toma la prioridad de su proceso.
La prioridad de cada proceso ligero vara dentro del rango 2 desde la clase de prioridad
del proceso. Estos cinco valores vienen determinados por:
THREAD_PRIORITY_LOWEST.
THREAD_PRIORITY_BELOW_NORMAL.
THREAD_PRIORITY_NORMAL.
THREAD_PRIORITY_ABOVE_NORMAL.
THREAD_PRIORITY_HIGHEST.
Adems de los valores relativos anteriores, existen dos valores absolutos que son:
Como se vio en la Seccin 3.8, una excepcin es un evento que ocurre durante la
ejecucin de un
1
programa y que requiere la ejecucin de un cdigo situado fuera del flujo normal de
ejecucin. Win32 ofrece un manejo de excepciones estructurado, que permite la gestin
de excepciones software y hardware. Este manejo permite la especificacin de un bloque
de cdigo o manejador de
1~
excepcin a ser ejecutado cuando se produce la excepcin.
El manejo de excepciones en Windows necesita del soporte del compilador para llevarla
a cabo. El compilador de C desarrollado por Microsoft ofrece a los programadores dos
palabras reservadas que pueden utilizarse para construir manejadores de excepcin. Estas
son: __try y
except. La palabra reservada __try identifica el bloque de cdigo que se desea proteger
de errores. La palabra __except identifica el manejador de excepciones.
En las siguientes secciones se van a describir los tipos y cdigos de excepcin y el uso de
un rnanejador de excepcin.
1
156Sistemas operativos. Una visin aplicada
Esta funcin debe ejecutarse justo despus de producirse una excepcin. La funcin
devuelve
cl valor asociado a la excepcin. Existen muchos tipos de excepciones, algunos de ellos
son:
try
/~ bloque de cdigo a proueger */
except (expresin)
/~ manejador de excepciones ~/
El bloque de cdigo encerrado dentro de la seccin try representa el cdigo del programa
que se quiere proteger. Si ocurre una excepcin mientras se est ejecutando este
fragmento de cdigo, el sistema operativo transfiere el control al manejador de
excepciones. Este manejador se encuentra dentro de la seccin _except. La expresin
asociada a _except se evala inmediatamente despus de producirse la excepcin. La
expresin debe devolver alguno de los siguientes val ores:
1
except<GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ?
EXCEPTION_EXECUTE_HANDLER EXCEPTION_CONTINUE SEARCH)
return NULL;
Procesos
~try
7k bloque de cdigo a proteger */
except (Filtrar(GetExceptioncode())) f
/~ manejador de excepciones */
case EXCEPTION_INTDIVIDEBYZERO
return EXCEPTIQN_EXECUTEHANDLER;
3.12.5. Servicios de temporizadores
Activacin de temporizadores
Los dos primeros argumentos pueden ignorarse cuando no se est utilizando un gestor de
ventanas. El parmetro idEvent es el mismo identificador de evento proporcionado en la
funcin SetTimer. El parmetro dwTime representa el tiempo del sistema en formato
UTC (Coordinated Universal Time, tiempo universal coordinado).
La funcin SetTimer crea un temporizador peridico, es decir, si el valor de uElapse es 5
ms, la funcin lpTimerFunc se ejecutar cada 5 ms.
La siguiente funcin permite desactivar un temporizador:
BOOLKillTimer(HWNDhWnd, UINTuIdEvent);
void mamo
UINT idEvent = 2;
UINT intervalo = 10;
UINT tid;
Son muchos los libros de sistemas operativos que cubren los temas tratados en este
captulo. Algunos de ellos son iCrow)ey, 1997], IMilenkovic, 1992], lSilberchatz, 1999],
[Stallings, 1998] y lTanenbaum, 1995]. ISoloilion, 1998] describe en detalle la gestin de
procesos de Windows NT y en [IEEE, 19961 puede encontrarse una descripcin
completa de todos los servicios POSIX descritos en este captulo.
3.15. EJERCICIOS
a) Memoria virtual.
b) Proteccin de memoria.
e) Instrucciones de FIS que slo pueden ejecutarse en modo kernel.
d) Dos modos de operacin: kemel y usuario.
a) Restaurar los registros de usuario con los valores almacenados en la tabla del
proceso.
h Restaurar el contador de programa.
e) Restaurar el puntero que apunta a la tabla de pginas del proceso.
d) Restaurar la imagen de memoria de un proCeso.
a) Bloqueado a listo.
h) Ejecutando a listo.
e) Ejecutando a bloqueado
d) Listo a ejecutando.
Sea un sistema que usa un algoritmo de planificacin de ~~OCCSOS round-rohin con una rodaja de
tiempo de lOO ms. En este sistema ejecutan dos procesos. El primero no realiza
operaciones de EIS y el segundo solicita una operacin de EIS cada 50 ms. Cul ser el
porcentaje de uso de la UCP?
Considere el siguiente conjunto de procesos planificados con un algoritmo round-rohin con 1 u.t. de
rodaja. Cunto tardan en acabar todos ellos?
Proceso Llegada
Pl 2
P2
P3
Duracin
8
5
4
3
En un sistena que usa un algoritmo de planificacin de procesos round-rohin, cuntos procesos
como mximo pueden cambiar de estado cuando se produce una interrupcin del disco
que indica que se ha terminado una operacin sobre el mismo?
Se tienen los siguientes trabajos a ejecutar:
3.15. Qu sucede cuando un proceso recibe una seal? , Y cuando recibe una excepcin?
3.16. Cmo se hace en POSIX para que un proceso cree otro proceso que ejecute otro programa? Y
en W in3 2?
3.17. Qu informacin comparten un proceso y su hijo despus de ejecutar el siguiente cdigo?
if (fork() !=0)
wait (&status)
el se
execve (B, parmetros, 0)
3.18. En un sistema operativo conforme a la norma POSIX, cundo pasa un proceso a estado
zombie?
3.19. Tras la ejecucin del siguiente cdigo, cuntos procesos se habrn creado?
3.20. Cuando un proceso ejecuta una llamada fork y luego el proceso hijo un exec, qu informacin
comparten ambos procesos?
3.21. Qu diferencia existe entre bloquear una seal e ignorarla en POS IX?
3.22. Escribir un programa en lenguaje C que active unos manejadores para las seales SIGINT,
SIGQUIT y SIGILL. Las acciones a ejecutar por dichos manej adores sern:
se pide:
a) Dibujar un esquema que muestre la jerarqua de procesos que se crea cuando se ejecuta el
programa con argc igual a 3.
h) Cuntos procesos se crean si argc vale n?
3.24. Responder a las siguientes preguntas sobre las llamadas al sistema walt de POSIX y WaitFor-
SlngleObject de Win32 cuando sta se aplica sobre un manejador de proceso.
3.12.
(1
P4 3
3.13.
3.14.
8
5
164 Sistemas operativos. Una visin aplicada
sador, tanto para acceder a sus operandos como para realizar bifurcaciones en la secuencia de
ejecucin. Estas referencias tpicamente estarn incluidas en un intervalo desde 0 hasta un valor
mximo N.
Supngase, por ejemplo, un fragmento de un programa que copia el contenido de un vector
almacenado a partir de la direccin 1000 en otro almacenado a partir de la 2000, estando el
tamao del vector almacenado en la direccin 1500. El cdigo almacenado en el archivo
ejecutable, mostrado en un lenguaje ensamblador hipottico, seria el mostrado en la Figura 4.1,
donde se ha supuesto que la cabecera del ejecutable ocupa 100 bytes y que cada instruccin
ocupa 4. Observe que, evidentemente, tanto en el ejecutable como posteriormente en memoria,
se almacena realmente cdigo mquina. En esta figura y en las posteriores se ha preferido
mostrar un pseudocdigo ensamblador para facilitar la legibilidad de las mismas.
El cdigo maquina de ese programa incluye referencias a direcciones de memoria que
corresponden tanto a operandos (las direcciones de los vectores y su tamao) como a
instrucciones (la etiqueta de la bifurcacin condicional, JNZ).
En el caso de un sistema con monoprogramacin, para ejecutar este programa slo ser
necesario cargarlo a partir de la posicin de memoria 0 y pasarle el control al mismo. Observe
que, como se puede apreciar en la Figura 4.2, se esta suponiendo que el sistema operativo estar
cargado en la parte de la memoria con direcciones ms altas.
En un sistema con multiprogramacin es necesario realizar un proceso de traduccin
(reubicacin) de las direcciones de memoria a las que hacen referencia las instrucciones de un
programa (direcciones lgicas) para que se correspondan con las direcciones de memoria
principal asignadas al mismo (direcciones fsicas). En el ejemplo planteado previamente, si al
programa se le asigna una zona de memoria contigua a partir de la direccin 10000, habra que
traducir todas las direcciones que genera el programa aadindoles esa cantidad.
Este proceso de traduccin crea, por tanto, un espacio lgico (o mapa) independiente para
cada proceso proyectndolo sobre la parte correspondiente de la memoria principal de acuerdo
con una funcin de traduccin:
Dado que hay que aplicar esta funcin a cada una de las direcciones que genera el
programa, es necesario que sea el procesador el encargado de realizar esta traduccin. Como se
explic en el Capitulo 1, la funcin de traduccin la lleva a cabo concretamente un mdulo
especfico del procesador denominado unidad de gestin de memoria (MMU, Memory
Management Unit). El sistema operativo deber poder especificar a la MMU del procesador que
funcin de traduccin debe aplicar al proceso que est ejecutando en ese momento. En el
ejemplo planteado, el procesador, a instancias del sistema operativo, debera sumarle 10000 a
cada una de las direcciones que genera el programa en tiempo de ejecucin. Observe que el
programa se cargara en memoria desde el ejecutable sin realizar ninguna modificacin del
mismo y, como se muestra en la Figura 4.3, seria durante su ejecucin cuando se traduciran
adecuadamente las direcciones generadas. El sistema operativo debera almacenar asociado a
cada proceso cul es la funcin de traduccin que le corresponde al mismo y, en cada cambio de
proceso, debera indicar al procesador qu funcin debe usar para el nuevo proceso activo.
Proteccin
Compartimiento de memoria
Para cumplir el requisito de proteccin, el sistema operativo debe crear espacios lgicos
independientes y disjuntos para los procesos. Sin embargo, en ciertas situaciones, bajo la
supervisin y control del sistema operativo, puede ser provechoso que los procesos puedan
compartir memoria. Esto es, la posibilidad de que direcciones lgicas de dos o ms procesos,
posiblemente distintas entre s, se correspondan con la misma direccin fsica. Ntese que,
como puede observarse en la Figura 4.5, la posibilidad de que dos o ms procesos compartan
una zona de memoria implica que el sistema de gestin de memoria debe permitir que la
memoria asignada a un proceso no sea contigua. As, por ejemplo, una funcin de traduccin
como la comentada anteriormente, que nicamente sumaba una cantidad a las direcciones
generadas por el programa, obligara a que el espacio asignado al proceso fuera contiguo,
imposibilitando, por tanto, el poder compartir memoria.
Figura 4.6.Problemas al compartir una zona en diferentes direcciones del mapa de cada proceso.
170 Sistemasoperativos. Una visin aplicada
Otro aspecto a resaltar es que el mapa del proceso no es esttico. Durante la ejecucin de
un programa puede variar el tamao de una regin o, incluso, pueden crearse nuevas regiones o
eliminarse regiones existentes. El sistema de memoria debe controlar qu regiones estn
presentes en el mapa de memoria y cual es el tamao actual de cada una. Tmese como ejemplo
el comportamiento dinmico de la regin de pila del proceso. El gestor de memoria debe asignar
y liberar memoria para estas regiones segn evolucionen la. mismas. Este carcter dinmico del
mapa de un proceso implica la existencia de zonas dentro del mapa de memoria del proceso que
en un determinado momento de su ejecucin no pertenecen a ninguna regin y que, por tanto,
cualquier acceso a las mismas implica un error de programacin. El gestor de memoria debera
detectar cundo se produce un acceso a las mismas y, como en el caso anterior, tratarlo
adecuadamente. Con ello adems de facilitar la depuracin, se elimina la necesidad de reservar
memoria fsica para zonas del mapa que no estn asignadas al proceso en un determinado
instante sistema operativo debe almacenar por cada proceso una tabla de regiones que indique
las caractersticas de las regiones del proceso (tamao, proteccin, etc.),
De acuerdo con los aspectos que se acaban de analizar, la funcin de traduccin se
generaliza para que tenga en cuenta las situaciones planteadas pudiendo, por tanto, devolver tres
valores alternativos:
Traduccin(direccin lgica tipo de operacin)
(Direccin fsica correspondiente,
Excepcin por acceso a una direccin no asignada,
Excepcin por operacin no permitida}
Por ltimo, hay que resaltar que el mapa de memoria del propio sistema operativo, como
programa que es, tambin est organizado en regiones. Al igual que ocurre con los procesos de
usuario, el sistema de memoria debera dar soporte a las regiones del sistema operativo. As, se
detectara inmediatamente un error en el cdigo del sistema operativo, lo que facilitara su
depuracin a la gente encargada de esta ardua labor. Observe que 1a deteccin del error debera
detener inmediatamente la ejecucin del sistema operativo y mostrar un volcado de la
informacin del sistema.
Maximizar el rendimiento
Como ya se analiz en captulos anteriores, el grado de multiprogramacin del sistema
influye directamente en el porcentaje de utilizacin del procesador y, por tanto, en el
rendimiento del sistema. Adicionalmente, un mayor grado de multiprogramacin implica que
puede existir un mayor numero de usuarios trabajando simultneamente en el sistema.
El gestor de memoria debe, por tanto, realizar un reparto de la memoria entre los procesos
intentando que quepa el mayor numero de ellos en memoria y minimizando el desperdicio
inherente al reparto. Para ello, debe establecerse una poltica de asignacin adecuada. La
poltica de asignacin determina qu direcciones de memoria se asignan para satisfacer una
determinada peticin. Hay que resaltar que la propia gestin de la memoria requiere un gasto en
espacio de almacenamiento para que el sistema operativo almacene las estructura. de datos
implicadas en dicha gestin. As, ser necesario guardar la tabla de regiones y la funcin de
traduccin asociada a cada proceso (normalmente implementadas como tablas), as como una
estructura que refleje qu partes de la memoria permanecen libres y cuales estn ocupadas.
Dado que el almacenamiento de estas estructuras resta espacio de memoria para los procesos, es
importante asegurar que su consumo se mantiene en unos trminos razonables.
En los tiempos en los que 1a memoria era muy cara y, en consecuencia, los equipos
posean memoria bastante reducida, se producan habitualmente situaciones en las que las
aplicaciones se vean limitadas por el tamao de la memoria, Para solventar este problema, los
programadores usaban la tcnica de los overlays. Esta tcnica consiste en dividir el programa en
una serie de fases que se ejecutan sucesivamente, pero estando en cada momento residente en
memoria slo una fase. Cada fase se programa de manera que, despus de realizar su labor,
carga en memoria la siguiente fase y le cede el control. Es evidente que esta tcnica no
soluciona el problema de forma general dejando en manos del programador todo el trabajo.
Por ello, se ideo la tcnica de la memoria virtual, que permite proporcionar a un proceso de
forma transparente un mapa de memoria considerablemente mayor que la memoria fsica
existente en el sistema.
A pesar del espectacular abaratamiento de la memoria y la consiguiente disponibilidad
generalizada de equipos con memorias apreciablemente grandes, sigue siendo necesario que el
sistema de memoria, usando la tcnica de la memoria virtual, proporcione a los procesos
espacios lgicos ms grandes que la memoria realmente disponible. Observe que a la memoria
le ocurre lo mismo que a los armarios: cuanto ms grandes son, ms cosas metemos dentro de
ellos. La disponibilidad de memorias mayores permite a los programadores obtener beneficio
del avance tecnolgico, pudiendo incluir caractersticas ms avanzadas en sus aplicaciones o
incluso tratar problemas que hasta entonces se consideraban inabordables,
Bibliotecas de objetos
Bibliotecas dinmicas
La manera de generar el ejecutable comentada hasta ahora consiste en compilar los mdulos
fuente de la aplicacin y enlazar los mdulos objeto resultantes junto con los extrados de las
bibliotecas correspondientes. De esta forma, se podra decir que el ejecutable es autocontenido:
incluye todo el cdigo que necesita el programa para poder ejecutarse. Este modo de trabajo
presenta varias desventajas:
El archivo ejecutable puede ser bastante grande ya que incluye, adems del cdigo propio
de la aplicacin, todo el cdigo de las funciones externas que usa el programa.
174 Sistemas operativos. Una visin aplicada
Todo programa en el sistema que use una determinada funcin de biblioteca tendr una
copia del cdigo de la misma, Como ejemplo, el cdigo de la funcin printf, utilizada en
casi todos los programas escritos en C, estar almacenado en todos los ejecutables que la
usan.
Cuando se estn ejecutando simultneamente varias aplicaciones que usan una misma
funcin de biblioteca, existirn en memoria mltiples copias del cdigo de dicha funcin
aumentando el gasto de memoria.
La actualizacin de una biblioteca implica tener que volver a generar los ejecutables que
la incluyen por muy pequeo que sea el cambio que se ha realizado sobre la misma.
Supngase que se ha detectado un error en el cdigo de una biblioteca o que se ha
programado una versin ms rpida de una funcin de una biblioteca. Para poder
beneficiarse de este cambio, los ejecutables que la usan deben volver a generarse a partir
de los objetos correspondientes. Observe que esta operacin no siempre puede realizarse
ya que dichos objetos pueden no estar disponibles.
Para resolver estas deficiencias se usan las bibliotecas dinmicamente enlazadas (Dinamic
Link Libraries) o, simplemente, bibliotecas dinmicas. Por contraposicin, se denominarn
bibliotecas estticas a las presentadas hasta el momento.
Con este nuevo mecanismo, el proceso de montaje de una biblioteca de este tipo se difiere y
en vez de realizarlo en la fase de montaje se realiza en tiempo de ejecucin del programa.
Cuando en la fase de montaje el montador procesa una biblioteca dinmica, no incluye en el
ejecutable cdigo extrado de la misma, sino que simplemente anota en el ejecutable el nombre
de la biblioteca para que sta sea cargada y enlazada en tiempo de ejecucin.
Como parte del montaje, se incluye en el ejecutable un mdulo de montaje dinmico que
encargar de realizar en tiempo de ejecucin la carga y el montaje de la biblioteca cuando se
haga referencia por primera vez a algn smbolo definido en la misma. En el cdigo ejecutable
original del programa, las referencias a los smbolo de la biblioteca, que evidentemente todava
pendientes de resolver, se hacen corresponder con smbolos en el modulo de montaje dinmico.
De esta forma, la primera referencia a uno de estos smbolos produce la activacin del mdulo
que realizar en ese momento la carga de la biblioteca y el proceso de montaje necesario. Como
parte del mismo, se resolver la referencia a ese smbolo de manera que apunte al objeto real de
la biblioteca y que, por tanto, los posteriores accesos al mismo no afecten al mdulo de montaje
dinmico. Observe que este proceso de resolucin de referencias afecta al programa que hace
uso de la biblioteca dinmica ya que implica modificar en tiempo de ejecucin alguna de sus
instrucciones para que apunten a la direccin real del smbolo. Esto puede entrar en conflicto
con el tpico carcter de no modificable que tiene la regin de cdigo.
El uso de bibliotecas dinmicas resuelve las deficiencias identificadas anteriormente:
El tamao de los archivos ejecutables disminuye considerablemente ya que en ellos no se
almacena el cdigo de las funciones de bibliotecas dinmicas usadas por el programa.
Las rutinas de una biblioteca dinmica estarn almacenadas nicamente en archivo de la
biblioteca en vez de estar duplicadas en los ejecutables que las usan.
Cuando se estn ejecutando varios proceso que usan una biblioteca dinmica, stos
podrn compartir el cdigo de la misma, por lo que en memoria habr solo una copia de
la misma.
La actualizacin de una biblioteca dinmica es inmediatamente visible a los programas
que la usan sin necesidad de volver a montarlos.
Gestin de memoria 175
Con respecto a este ultimo aspecto, es importante resaltar que cuando la actualizacin
implica un cambio en la interfaz de la biblioteca (p. ej.:una de las funciones tiene un nuevo
parmetro), el programa no debera usar esta biblioteca sino la versin antigua de la misma.
Para resolver este problema de incompatibilidad, en muchos sistemas se mantiene un nmero de
versin asociado a cada biblioteca. Cuando se produce un cambio en la interfaz, se crea una
nueva versin con un nuevo nmero. Cuando en tiempo de ejecucin se procede a la carga de
una biblioteca, se busca la versin de la biblioteca que coincida con la que requiere el programa,
producindose un error en caso de no encontrarla. Observe que durante el montaje se ha
almacenado en el ejecutable el nombre y la versin de la biblioteca que utiliza el programa.
Por lo que se refiere al compartimiento del cdigo de una biblioteca dinmica entre los
procesos que la utilizan en un determinado instante, es un aspecto que hay que analizar ms en
detalle. Como se plante en la seccin anterior, si se permite que el cdigo de una biblioteca
pueda estar asociado a un rango de direcciones diferente en cada proceso, surgen problemas con
las referencias que haya en el cdigo de la biblioteca a smbolos definidos en la misma. Ante
esta situacin se presentan tres alternativas:
Establecer un rango de direcciones predeterminado y especfico para cada biblioteca
dinmica de manera que todos los procesos que la usen la incluirn en dicho rango dentro
de su mapa de memoria. Esta solucin permite compartir el cdigo de la biblioteca, pero
es poco flexible ya que limita el numero de bibliotecas que pueden existir en el sistema y
puede causar que el mapa de un proceso sea considerablemente grande presentando
amplias zonas sin utilizar.
Reubicar las referencias presentes en el cdigo de la biblioteca durante la carga de la
misma de manera que se ajusten a las direcciones que le han correspondido dentro del
mapa de memoria del proceso que la usa. Esta opcin permite cargar la biblioteca en
cualquier zona libre del mapa del proceso. Sin embargo, impide el poder compartir su
cdigo (o, al menos, la totalidad de su cdigo) al estar adaptado a la zona de memoria
donde le ha tocado vivir.
Generar el cdigo de la biblioteca de manera que sea independiente de la posicin (en
ingles se suelen usar las siglas PIC, Position Independent Code). Con esta tcnica, el
compilador genera cdigo que usa direccionamientos relativos a un registro (p. ej.: al
contador de programa) de manera que no se ve afectado por la posicin de memoria
donde ejecuta. Esta alternativa permite que la biblioteca resida en la zona del mapa que se
considere conveniente y que, adems, su cdigo sea compartido por los procesos que la
usan. El nico aspecto negativo es que la ejecucin de este tipo de cdigo es un poco
menos eficiente que el convencional (Gingell, 1987), pero, generalmente, este pequeo
inconveniente queda compensado por el resto de las ventajas.
El nico aspecto negativo del uso de las bibliotecas dinmicas es que el tiempo de ejecucin
del programa puede aumentar ligeramente debido a que con este esquema el montaje de la
biblioteca se realiza en tiempo de ejecucin. Sin embargo, este aumento es perfectamente
tolerable en la mayora de los casos y queda claramente contrarrestado por el resto de los
beneficios que ofrece este mecanismo.
Otro aspecto que conviene resaltar es que el mecanismo de bibliotecas dinmicas es
transparente al modo de trabajo habitual de un usuario. Dado que este nuevo mecanismo slo
atae a la fase de montaje, tanto el cdigo fuente de un programa como el cdigo objeto no se
en afectados por el mismo. Adems, aunque la fase de montaje haya cambiado
considerablemente, los mandatos que se usan en esta etapa son tpicamente lo mismos. De esta
forma, el usuario no detecta ninguna diferencia entre usar bibliotecas esttica. y dinmicas
excepto, evidentemente, los beneficios antes comentados.
176 Sistemas operativos. Una visin aplicada
En la mayora de los sistemas que ofrecen bibliotecas dinmicas, el sistema tiene una
versin esttica y otra dinmica de cada una de las bibliotecas predefinidas. Dados los
importantes beneficios que presentan las bibliotecas dinmicas, el montador usar por defecto la
versin dinmica, Si el usuario, por alguna razn, quiere usar la versin esttica, deber pedirlo
explcitamente.
Montaje explcito de bibliotecas dinmicas
La forma de usar las bibliotecas dinmicas que se acaba de exponer es la mas habitual: se
especifica en tiempo de montaje que bibliotecas se deben usar y se pospone la carga y el
montaje hasta el tiempo de ejecucin. Este esquema se suele denominar enlace dinmico
implcito. Sin embargo no es la nica manera de usar las bibliotecas dinmicas.
En algunas aplicaciones no se conoce en tiempo de montaje qu bibliotecas necesitar
programa. Supngase, por ejemplo, un navegador de Internet que maneja hojas que contienen
archivos en distintos formatos y que usa las funciones de varias bibliotecas dinmicas para
procesar cada uno de los posibles formatos. En principio, cada vez que se quiera dotar al
navegador de la capacidad de manejar un nuevo tipo de formato, sera necesario volver a
montarlo especificando tambin la nueva biblioteca que incluye las funciones para procesarlo.
Observe que esto sucede aunque se usen bibliotecas dinmicas.
Lo que se requiere en esta situacin es poder decidir en tiempo de ejecucin que
biblioteca dinmica se necesita y solicitar explcitamente su montaje y carga. El mecanismo de
bibliotecas dinmicas presente en Windows NT y en la mayora de las versiones de UNIX
ofrece esta funcionalidad, denominada tpicamente enlace dinmico explcito. Un programa
que pretenda usar funcionalidad deber hacer uso de los servicios que ofrece el sistema para
realizar esta solicitud explcita. Observe que, en este caso, no habra que especificar en tiempo
de montaje el nombre de la biblioteca dinmica. Pero, como contrapartida, el mecanismo de
carga y montaje de la biblioteca dinmica deja de ser transparente a la aplicacin.
Formato del ejecutable
Como parte final del proceso de compilacin y montaje, se genera un archivo ejecutable
que contiene el cdigo mquina del programa. Distintos fabricantes han usado diferentes
formatos para este tipo de archivos. En el mundo UNIX, por ejemplo, uno de los formatos ms
utilizados actualmente denominado Executable and Linkable Format (ELF). A continuacin, se
presentar de simplificada cmo es el formato tpico de un ejecutable.
Como se puede observar en la Figura 4.9, un ejecutable est estructurado como una
cabecera y un conjunto de secciones.
La cabecera contiene informacin de control que permite interpretar el contenido del
ejecutable. En la cabecera tpicamente se incluye, entre otras cosas, la siguiente informacin:
Un nmero mgico que identifica al ejecutable. As, por ejemplo, en el formato ELF,
el primer byte del archivo ejecutable debe contener el valor hexadecimal 7 f y los tres
siguientes los caracteres 'E', 'L' y 'F'.
La direccin del punto de entrada del programa, esto es, la direccin que se almacenar
inicialmente en el contador de programa del proceso.
Una tabla que describe las secciones que aparecen en el ejecutable. Por cada una de
ellas, se especifica, entre otras cosas, su tipo, la direccin del archivo donde comienza y
su tamao.
Observe que en el ejecutable no aparece ninguna seccin que corresponda con las variables
locales y parmetros de funciones. Esto se debe a que este tipo de variables presentan unas
caractersticas muy diferentes a las de Las variables globales, a saber:
Las variables globales tienen un carcter esttico. Existen durante toda la vida del
programa. Tienen asociada una direccin fija en el mapa de memoria del proceso y, por
tanto, tambin en el archivo ejecutable puesto que ste se corresponde con la imagen
inicial del proceso. En el caso de que la variable no tenga un valor inicial asignado en el
programa, no es necesario almacenarla explcitamente en el ejecutable, sino que basta
con conocer el tamao de la seccin que contiene este tipo de variables.
Las variables locales y parmetros tienen carcter dinmico. Se crean cuando se invoca
la funcin correspondiente y se destruyen cuando termina la llamada. Por tanto, estas
variables no tienen asignado espacio en el mapa inicial del proceso ni en el ejecutable.
Se crean dinmicamente usando para ello la pila del proceso. La direccin que
corresponde a una variable de este tipo se determina en tiempo de ejecucin ya que
depende de la secuencia de llamadas que genere el programa Observe que, dada la
.
Heap. La mayora de los lenguajes de alto nivel ofrecen la posibilidad de reservar espacio
en tiempo de ejecucin. En el caso del lenguaje C se usa la funcin malloc para ello. Esta
regin sirve de soporte para la memoria dinmica que reserva un programa en tiempo de
ejecucin. Comienza, tpicamente, justo despus de la regin de datos sin valor inicial (de
hecho, en algunos sistemas se considera parte de la misma) y crece en sentido contrario a
la pila (hacia direcciones crecientes), Se trata de una regin privada de lectura/escritura,
sin soporte (se rellena inicialmente a cero), que crece segn el programa vaya reservando
memoria dinmica y decrece segn la vaya liberando. Normalmente, cada programa
tendr un nico heap. Sin embargo, algunos sistemas, como Win32, permiten crear
mltiples heaps.
En la Aclaracin 4.2 se intenta clarificar algunos aspectos de la memoria dinmica.
Archivos proyectados. Cuando se proyecta un archivo, se crea una regin asociada al
mismo. Este mecanismo ser realizado con ms profundidad al final del captulo, pero, a
priori, se puede resaltar que se trata de una regin compartida cuyo soporte es el archivo
que se proyecta.
Memoria compartida. Cuando se crea una zona de memoria compartida y se proyecta,
como se analizar detalladamente en el Capitulo 4, se origina una regin asociada a la
misma. Se
trata, evidentemente, de una regin de carcter compartido, cuya proteccin la especifica el
programa a la hora de proyectarla.
Pilas de threads. Como se estudi en el Captulo 3, cada thread necesita una pila propia
que normalmente corresponde con una nueva regin en el mapa. Este tipo de regin tiene
las mismas caractersticas que la regin correspondiente a la pila del proceso.
Gestin de memoria 181
Programa 4.2. Ejemplo del problema de los punteros suelto..
int *p, *q ;
En la Figura 4.11 se muestra un hipottico mapa de memoria que contiene algunos de los
tipos de regiones comentadas en esta seccin.
Como puede apreciarse en la figura, la carga de una biblioteca dinmica implicar la
creacin de un conjunto de regiones asociadas a la misma que contendrn las distintas secciones
de la biblioteca (cdigo y datos globales).
Hay que resaltar que, dado el carcter dinmico del mapa de memoria de un proceso (se
crean y destruyen regiones, algunas regiones cambian de tamao, etc.), existirn, en un
determinado instante, zonas sin asignar (huecos) dentro del mapa de memoria del proceso.
Cualquier acceso a estos huecos representa un error y debera ser detectado y tratado por el
sistema operativo.
Por ltimo, hay que recalcar que, dado que el sistema operativo es un programa, su mapa
de memoria contendr tambin regiones de cdigo, datos y heap (el sistema operativo tambin
usa memoria dinmica).
Un esquema simple de gestin de memoria consiste en asignar a cada proceso una zona
contigua de memoria para que en ella resida su mapa de memoria. Dentro de esta estrategia
general hay diversas posibilidades. Sin embargo, dado el alcance y objetivo de este tema, la
exposicin se centrar slo en uno de estos posibles esquemas: la gestin contigua basada en
particiones dinmicas. Se trata de un esquema que se us en el sistema operativo OS/MVT de
IBM en la dcada de los sesenta.
Con esta estrategia, cada vez que se crea un proceso, el sistema operativo busca un hueco
en memoria de tamao suficiente para alojar el mapa de memoria del mismo. El sistema
operativo reservara la parte del hueco necesaria, creara en ella el mapa inicial del proceso y
establecer una funcin de traduccin tal que las direcciones que genera el programa se
correspondan con la zona asignada.
En primer lugar, se presentar qu hardware de gestin de memoria se requiere para realizar
este esquema para, a continuacin, describir cul es la labor del sistema operativo.
Hardware
Registro lmite. El procesador comprueba que cada direccin que genera el proceso no es
mayor que el valor almacenado en este registro. En caso de que lo sea, se generar una
excepcin.
184 Sistemas operativos. Una visin aplicada
Registro base. Una vez comprobado que la direccin no rebasa el limite permitido, el
procesador le sumar el valor de este registro, obtenindose con ello la direccin de
memoria fsica resultante.
Figura 4.12. Estado de la MMU durante la ejecucin del proceso 2.
Observe que los registros valla estarn desactivados cuando el procesador est en modo
privilegiado. De esta forma, el sistema operativo podr acceder a toda la memoria del sistema.
Sin embargo, a veces el sistema operativo necesitar traducir una direccin lgica de un proceso
que recibe como argumento de una llamada al sistema. En ese caso, el mismo deber aplicar a
esa direccin los registros valla.
El sistema operativo nicamente tendr que almacenar en el bloque de control de cada proceso
cuales son los valores que deben tener estos dos registros para dicho proceso. Observe que este
par de valores son los que definen la funcin de traduccin que corresponde al proceso y que,
evidente- mente, su almacenamiento apenas consume espacio. Cuando se produzca un cambio
de proceso, el sistema operativo deber cargar los registros valla del procesador con los valores
correspondiente al proceso que se va a activar.
El sistema operativo mantiene informacin sobre el estado de la memoria usando una
estructura de datos que identifica qu partes de la memoria estn libres. Tpicamente usa una
almacena la direccin inicial y el tamao de cada zona libre o hueco (vase la Aclaracin 4
analiza los distintos usos de este trmino en este entorno). Observe que en la gestin de esta
lista, cada vez que una zona pasa de ocupada a libre hay que comprobar si el nuevo espacio libre
se puede fundir con posibles zonas libres contiguas. Adems, deber mantener una tabla de
regiones para identificar qu partes de la memoria otorgada al proceso estn asignadas a
regiones y cuales estn libres.
Con esta estrategia, como muestra la figura anterior, segn se van ejecutando distintos
procesos, van quedando fragmentos en la memoria que, dado su pequeo tamao, no podran
ser asignados a ningn proceso. A este problema se le denomina fragmentacin externa y
conlleva una mala utilizacin de la memoria por la progresiva fragmentacin del espacio de
almacenamiento. Una posible solucin a este problema sera compactar la memoria moviendo
los mapas de memoria de los procesos para que
Gestin de memoria 185
queden contiguos, dejando as el espacio libre tambin contiguo Esta transferencia implicara
tambin el reajuste de los registros valla de acuerdo a la nueva posicin de cada proceso. Sin
embargo, esta compactacin es un proceso bastante ineficiente.
Poltica de asignacin de espacio
El sistema operativo debe llevar a cabo una poltica de asignacin de espacio. Cuando se precisa
crear el mapa de memoria de un proceso que ocupa un determinado tamao, esta poltica decide
cul de las zonas libres se debera usar, intentando conjugar dos aspectos: un buen
aprovechamiento de la memoria y un algoritmo de decisin eficiente.
Realmente, el problema de la asignacin dinmica de espacio es un problema ms general
que se presenta tambin fuera del mbito de la informtica. Se trata, por tanto, de un problema
ampliamente estudiado. Tpicamente, existen tres estrategias bsicas:
El mejor ajuste (best-fit). Se elige la zona libre ms pequea donde quepa el mapa del
proceso. A priori, puede parecer la mejor solucin. Sin embargo, esto no es as. Por un
lado, se generan nuevos espacios libres muy pequeos. Por otro lado, la seleccin del
mejor hueco exige comprobar cada uno de ellos o mantenerlos ordenados por tamao.
Ambas soluciones conducen a un algoritmo ineficiente,
El peor ajuste (worst-fit). Se elige el hueco ms grande, Con ello se pretende que no se
generen nuevos huecos pequeos. Sin embargo, sigue siendo necesario recorrer toda la
lista de huecos o mantenerla ordenada por tamao.
El primero que ajuste (first-fit). Aunque pueda parecer sorprendente a priori, sta suele ser
la mejor poltica. Es muy eficiente ya que basta con encontrar una zona libre de tamao
suficiente y proporciona un aprovechamiento de la memoria aceptable.
Una estrategia de asignacin interesante es el sistema buddy [Knowlton, 1965]. Est basado
en el uso de listas de huecos cuyo tamao son potencias de dos, La gestin interna de la
memoria del propio sistema operativo en UNIX 4,3 BSD y en Linux utiliza variantes de este
algoritmo. Dada su relativa complejidad, se remite al lector a la referencia antes citada.
Es interesante resaltar que estas estrategias de asignacin tambin se utilizan en la gestin
del heap, tanto en el de los procesos como en el del propio sistema operativo.
Valoracin del esquema contiguo
Una vez realizada esta presentacin de los fundamentos de los esquemas de asignacin
186 Sistemas operativos. Una visin aplicada
contigua, se puede analizar hasta qu punto cumplen los requisitos planteados al principio del
captulo:
Espacios lgicos independientes. Los registros valla realizan la reubicacin del mapa de
memoria del proceso a la zona contigua asignada.
Proteccin. El uso del registro lmite asegura que un proceso no pueda acceder a la
memoria de otros procesos o del sistema operativo, crendose, por tanto, espacios
disjuntos.
Compartir memoria. Como se coment al principio del captulo, la asignacin contigua
impide la posibilidad de que los procesos compartan memoria.
Soporte de las regiones del proceso. Con esta estrategia no es posible controlar si son
correctos los accesos que genera el programa a las distintas regiones de su mapa, ya sea
por intentar realizar una operacin no permitida (p. ej.: escribir en la regin de cdigo) o
por acceder a una zona no asignada actualmente (hueco). As mismo, no es posible evitar
que las zonas del mapa que no estn asignadas en un determinado momento no consuman
memoria, Por tanto, hay que reservar desde el principio toda la memoria que puede llegar
a necesitar el proceso durante su ejecucin, lo cual conduce a un mal aprovechamiento de
la memoria,
Maximizar el rendimiento, Como se analiz previamente, este tipo de asignacin no
proporciona un buen aprovechamiento de la memoria presentando fragmentacin externa.
Adems, no sirve de base para construir un esquema de memoria virtual.
Mapas de memoria grandes para los procesos. Este esquema no posibilita el uso de mapa
grandes, ya que quedan limitados por el tamao de la memoria fsica.
ej. debido a que se ha creado uno nuevo), se elige un proceso residente y se copia en swap su
memoria. El criterio de seleccin puede tener en cuenta aspectos tales como la prioridad del
proceso, el tamao de su mapa de memoria, el tiempo que lleva ejecutando y, principalmente.
Se debe intentar expulsar (swap out) procesos que estn bloqueados. Cuando se expulsa un
proceso no es necesario copiar toda su imagen al swap. Los huecos en el mapa no es preciso
copiarlos ya que su contenido es intrascendente. Tampoco se tiene que copiar el cdigo, ya que
se puede volver a recuperar directamente del ejecutable.
Evidentemente, un proceso expulsado tarde o temprano debe volver a activarse y cargarse
en memoria principal (swap in). Slo se deberan volver a cargar aquellos procesos que estn
listos para ejecutar. Esta readmisin en memoria se activar cuando haya espacio de memoria
disponible (p. ej.: debido a que se ha terminado un proceso) o cuando el proceso lleve un cierto
tiempo expulsado. Observe que al tratarse de un sistema de tiempo compartido, se debe repartir
el procesador entre todos los procesos. Por ello, en numerosa ocasiones hay que expulsar un
proceso para poder traer de nuevo a memoria a otro proceso que lleva expulsado un tiempo
suficiente.
En cuanto al dispositivo de swap, hay dos alternativas en la asignacin de espacio:
Preasignacin. Al crear el proceso ya se reserva espacio de swap suficiente para
albergarlo.
Sin preasignacin. Slo se reserva espacio de swap cuando se expulsa el proceso.
Un ltimo aspecto a tener en cuenta es que no debera expulsarse un proceso mientras se
estn realizando operaciones de entrada/salida por DMA vinculadas a su imagen de memoria ya
que esto causara que el dispositivo accediera al mapa de otro proceso.
4.5. MEMORIA VIRTUAL
En prcticamente todos los sistemas operativos modernos se usa la tcnica de memoria virtual.
En esta seccin se analizarn los conceptos bsicos de esta tcnica. En el Captulo 1 ya se
presentaron los fundamentos de la memoria virtual, por lo que no se volver a incidir en los
aspectos estudiados en el mismo.
Como se estudi en dicho captulo, la memoria en un sistema est organizada como una
jerarqua de niveles de almacenamiento, entre los que se mueve la informacin dependiendo de
la necesidad de la misma en un determinado instante, La tcnica de memoria virtual se ocupa de
la transferencia de informacin entre la memoria principal y la secundaria, La memoria
secundaria est normalmente soportada en un disco (o particin). Dado que, como se ver ms
adelante, la memoria virtual se implementa sobre un esquema de paginacin, a este dispositivo
se le denomina dispositivo de paginacin. Tambin se usa el trmino dispositivo de swap.
Aunque este trmino no es muy adecuado, ya que proviene de la tcnica del intercambio, por
tradicin se usa frecuentemente y se utilizar indistintamente en esta exposicin.
4.5.1. Paginacin
Como se ha analizado previamente, los sistemas de gestin de memoria basados en asignacin
contigua presentan numerosas restricciones a la hora de satisfacer los requisitos que debe
cumplir el gestor de memoria del sistema operativo. La paginacin surge como un intento de
paliar estos problemas sofisticando apreciablemente el hardware de gestin de memoria del
procesador aumentado considerablemente la cantidad de informacin de traduccin que se
almacena por e proceso.
Aunque el objetivo de este captulo no es estudiar en detalle cmo es el hardware de
gestin memoria (MMU) de los sistemas basados en paginacin, ya que es un tema que
pertenece a la materia de estructura de computadoras, se considera que es necesario presentar
algunos conceptos bsicos del mismo para poder comprender adecuadamente su
funcionamiento. Estos esquemas ya fueron presentados en el Captulo 1, por lo que en esta
seccin no se volver a incidir en los aspectos estudiados en el mismo.
Como su nombre indica, la unidad bsica de este tipo de esquema es la pgina. La pagina
corresponde con una zona de memoria contigua de un determinado tamao. Por motivos de
eficiencia en la traduccin, este tamao debe ser potencia de 2 (un tamao de pgina de 4 KB es
un valor bastante tpico).
El mapa de memoria de cada proceso se considera dividido en pginas. A su vez, la
memoria principal del sistema se considera dividida en zonas del mismo tamao que se
Gestin de memoria 189
denominan marcos de pgina. Un marco de pgina contendr en un determinado instante una
pgina de memoria de proceso. La estructura de datos que relaciona cada pgina con el marco
donde esta almacenada tabla de pginas. El hardware de gestin de memoria usa esta tabla para
traducir todas las direcciones que genera un programa. Como se analiz en el Captulo 1, esta
traduccin consiste en detectar a que pagina del mapa corresponde una direccin lgica y
acceder a la tabla de pginas para obtener el numero de marco donde est almacenada dicha
_
pgina. La direccin fsica tendr un desplazamiento con respecto al principio del marco igual
que el que tiene la direccin con respecto al principio de la pgina. La Figura 4.13 muestra
cmo es este esquema de traduccin.
Tpicamente, la MMU usa dos tablas de pginas. Una tabla de pginas de usuario para
traducir las direcciones lgicas del espacio de usuario (en algunos procesadores se corresponden
con direcciones que empiezan por un 0) y una tabla de pginas del sistema para las direcciones
lgicas del espacio del sistema (las direcciones lgicas que empiezan por un 1). Estas ltimas
slo pueden usarse cuando el procesador est en modo privilegiado.
Hay que resaltar que si se trata de un procesador con mapa comn de entrada/salida y de
memoria, las direcciones de entrada/salida tambin se accedern a travs de la tabla de pginas.
Para impedir que los procesos de usuario puedan acceder a ellas, estas direcciones de
entrada/salida estarn asociadas a direcciones lgicas del espacio del sistema.
La paginacin no proporciona un aprovechamiento ptimo de la memoria como lo hara un
esquema que permitiese que cada palabra del mapa de memoria de un proceso pudiera
corresponder con cualquier direccin de memoria. Sin embargo, esta estrategia, como se analiz
al principio del captulo, es irrealizable en la prctica dada la enorme cantidad de informacin
de traduccin que implicara. La paginacin presenta una
190 Sistemas operativos. Una visin aplicada
solucin ms realista permitiendo que cada pgina del mapa de un proceso se pueda
corresponder con cualquier marco de memoria. Este cambio de escala reduce drsticamente el
tamao de la tabla de traduccin, pero, evidentemente, proporciona un peor aprovechamiento de
la memoria, aunque mantenindose en unos trminos aceptables. Observe que con la paginacin
se le asigna a cada proceso un nmero entero de marcos de pagina, aunque, en general, su mapa
no tendr un tamao mltiplo del tamao del marco. Por tanto, se desperdiciar parte del ltimo
marco asignado al proceso, lo que correspondera con las zonas sombreadas que aparecen en la
Figura 4.14. A este fenmeno se le denomina fragmentacin interna e implica que por cada
proceso de desperdiciar, en trmino medio, la mitad de una pgina, lo cual es un valor bastante
tolerable.
Cada entrada de la tabla de paginas, adems del nmero de marco que corresponde con esa
pgina, contiene informacin adicional tal como la siguiente:
Informacin de proteccin. Un conjunto de bits que especifican qu tipo de accesos
estn permitidos. Tpicamente, se controla el acceso de lectura, de ejecucin y de
escritura.
Indicacin de pgina vlida. Un bit que especifica si esa pgina es vlida, o sea, tiene
traduccin asociada, Observe que, en el caso de que no lo sea, la informacin del nmero
del marco es irrelevante. Como se analizar ms adelante, este bit tambin se utilizar en
los esquemas de memoria virtual para indicar que la pgina no est residente en memoria
principal.
El hardware consulta esta informacin cada vez que realiza una traduccin para verificar si
el acceso es correcto. En caso contrario, genera una excepcin que activa al sistema operativo.
En la entrada de la tabla de pginas puede haber informacin adicional, tal como la siguiente:
Indicacin de pgina accedida. La MMU activa este bit indicador cuando se direccin
lgica que pertenece a esa pgina.
Indicacin de pagina modificada. La MMU activa este bit indicador cuando se escribe
una direccin lgica que pertenece a esa pgina.
Desactivacin de cache. Este bit indica que no debe usarse la cache de la memoria
principal para acelerar el acceso a las direcciones de esta pgina. En sistemas con mapa
comn de memoria y de entrada/salida, se activara en las pginas que contienen
direcciones
Gestin de memoria 191
asociadas a dispositivos de entrada/salida, ya que para estas direcciones no se debe usar la
cache sino acceder directamente al dispositivo.
La tabla de pginas hace la funcin de traduccin que se analiz al principio del captulo. El
sistema operativo mantendr una tabla de pginas para cada proceso y se encargar de notificar
al hardware.
en cada cambio de proceso qu tabla tiene que usar dependiendo del proceso que est
ejecutando, utilizando para ello el registro base de la tabla de pginas o el registro identificador
del espacio de direccionamiento (RIED). En otras palabras, el sistema operativo es el encargado
de definir la funcin de correspondencia entre paginas y marcos mediante la tabla de pginas, y
el hardware es el encargado de aplicarla. Observe que el formato de la tabla de pginas y de sus
entradas viene fijado por el procesador. Sin embargo, en algunas ocasiones el sistema operativo
quiere almacenar informacin propia, que no concierne al hardware, asociada a cada pgina. A
veces, esta informacin puede incluirse en la propia entrada de la tabla de pginas,
almacenndola en alguna parte que no usa la MMU. Sin embargo, si esto no es posible, el
sistema operativo puede usar su propia tabla de pginas para almacenar esta informacin.
El sistema operativo mantiene una nica tabla de pginas para s mismo. De esta forma,
todos los procesos comparten el sistema operativo. Cuando el sistema operativo est ejecutando
una llamada al sistema invocada por un proceso, puede acceder directamente a su propio mapa y
al del proceso.
Adems de las tablas de pginas, el sistema operativo debe usar una estructura para
almacenar el estado de ocupacin de la memoria principal. Se trata de la tabla de marcos de
pgina que permite conocer qu marcos estn libres y cuales estn ocupados.
Por ltimo, ser necesario que el sistema operativo almacene por cada proceso su tabla de
regiones que contenga las caractersticas de cada regin especificando qu rango de pginas
pertenecen a la misma.
Observe que el esquema de paginacin requiere que el sistema operativo tenga una serie de
estructuras de datos de tamao considerable para poder mantener la informacin requerida por
el mismo. Este gasto es mucho mayor que en el esquema de asignacin contigua.
Evidentemente, es el precio que hay que pagar para obtener una funcionalidad mucho mayor.
Valoracin de la paginacin
Una vez realizada esta presentacin de los fundamentos de los esquemas de paginacin, se
puede analizar cmo cumplen los requisitos planteados al principio del captulo:
Espacios lgicos independientes. Cada proceso tiene una tabla de paginas que crea un
espacio lgico independiente para el mismo. La tabla es, por tanto, una funcin de
traduccin que hace corresponder las pginas del mapa de memoria del proceso
192 Sistemas operativos. Una visin aplicada
con los marcos que tiene asignados.
Proteccin. La tabla de pginas de un proceso restringe qu parte de la memoria puede ser
accedida por el mismo, permitiendo asegurar que los procesos usan espacios disjuntos.
Compartir memoria. Bajo la supervisin del sistema operativo, que es el nico que puede
manipular las tablas de paginas, dos o mas procesos pueden tener una pgina asociada al
mismo marco de pgina. Observe que el compartimiento se realiza siempre con la
granularidad de una pgina.
Soporte de las regiones del proceso. La informacin de proteccin presente en cada
entrada de la tabla de pginas permite controlar que los accesos a la regin son del tipo
que sta requiere. Asimismo, la informacin de validez detecta cundo se intenta acceder
a huecos dentro del mapa del proceso y, adems, elimina la necesidad de gastar memoria
fsica para estos huecos.
Maximizar el rendimiento. En primer lugar, la paginacin, a pesar de la fragmentacin
interna, obtiene un buen aprovechamiento de la memoria, ya que elimina la necesidad de
que el mapa de memoria de un proceso se almacene de forma contigua en memoria
principal. As, cualquier marco que est libre se puede usar como contenedor de cualquier
pgina
de cualquier proceso. Por otro lado, y ms importante todava, la paginacin puede servir como
base para construir un esquema de memoria virtual.
Mapas de memoria grandes para los procesos. Gracias a que los huecos no consumen
espacio de almacenamiento, el sistema operativo puede crear un mapa de memoria para el
proceso que ocupe todo su espacio lgico direccionable. De esta forma, habr suficientes
huecos para que las regiones crezcan o se incluyan nuevas regiones, sin penalizar con ello
el gasto en espacio de almacenamiento. Por otro lado, y ms importante todava, la
paginacin permite implementar un esquema de memoria virtual.
Implementacin de la tabla de paginas
El esquema bsico de paginacin que acaba de describirse, aunque funciona de manera correcta
presenta serios problemas a la hora de implementarlo directamente, Estos problemas surgen
debido a la necesidad de mantener las tablas pginas en memoria principal. Esto conlleva
problemas de eficiencia y de consumo de espacio.
Por lo que se refiere a los problemas de eficiencia, dado que para acceder a la posicin de
memoria solicitada, la MMU debe consultar la entrada correspondiente de la tabla de pginas,
se producirn dos accesos a memoria por cada acceso real solicitado por el programa. Esta
sobrecargado es intolerable, ya que reducira a la mitad el rendimiento del sistema. Para
solventar este problema la MMU incluye internamente una especie de cache de traducciones
llamada TLB (Translation, Lookaside Buffer), cuyo modo de operacin se mostrar en la siguiente
seccin.
Por otro lado, existe un problema de gasto de memoria. Las tablas de pginas son muy
grandes y hay una por cada proceso activo. Como se coment previamente, la paginacin
permite construir mapas de memoria muy grandes para los procesos, ya que los huecos no
consumen espacio. Sin embargo, si se usa todo el espacio de direccionamiento, como es
deseable para conseguir que los procesos no tengan problemas de memoria durante su
ejecucin, la tabla de pginas debe tener tantas entradas como pginas hay en el espacio lgico,
aunque muchas de ellas estn marcadas como invalidas al corresponder con huecos. Para
resaltar esta circunstancia, a continuacin se plantea un ejemplo.
Sea un procesador con una direccin lgica de 32 bits, un tamao de pgina de 4 KB y tal que
cada entrada de la tabla de pginas ocupa 4 bytes. Si se le asigna a cada proceso
Gestin de memoria 193
todo el espacio direccionable, resulta un mapa de memoria de 2 32 bytes que corresponde con
2 20 pginas. La tabla de pginas de cada proceso ocupa 4 MB ( 2 20 entradas x 4bytes). Por
tanto, se requeriran 4 MB de memoria principal para cada tabla, lo que resulta en un gasto de
memoria inadmisible. Observe que
la mayora de las entradas de la tabla de pginas de un proceso estaran vacas. As, por
ejemplo si las regiones de un proceso requieren 16 MB, lo cual es una cantidad bastante
considerable, solo estaran marcadas como vlidas 4.096 entradas de las ms de un milln que
hay en la tabla de
pginas. Observe que este problema se acenta enormemente en los procesadores modernos
que usan direcciones de 64 bits.
La solucin a este problema son las tablas de paginas multinivel y las tablas invertidas.
Translation Lookaside Buffer (TLB)
Para hacer que un sistema de paginacin sea aplicable en la prctica es necesario que 1a
mayora de los accesos a memoria no impliquen una consulta a la tabla de pginas, sino que
nicamente requieran el acceso a la posicin solicitada. De esta forma, el rendimiento ser
similar al de un sistema sin paginacin.
Como se coment previamente, esto se logra mediante el uso de la TLB. Se trata de una
pequea memoria asociativa interna a la MMU que mantiene informacin sobre las ltimas
pginas accedidas, Cada entrada en la TLB es similar a la de la tabla de pginas (nmero de
marco, proteccin, bit de referencia, etc.), pero incluye tambin el numero de la pgina para
permitir realizar una bsqueda asociativa. Existen dos alternativas en el diseo de una TLB
dependiendo de si se almacenan identificadores de proceso o no.
TLB sin identificadores de proceso. La MMU accede a la TLB slo con el nmero de
pgina. Por tanto, cada vez que hay un cambio de proceso el sistema operativo debe
invalidar la TLB ya que cada proceso tiene su propio mapa.
TLB con identificadores de proceso. La MMU accede a la TLB con el nmero de
pgina y un identificador de proceso. En cada entrada de la TLB, por tanto, se almacena
tambin este identificador, La MMU obtiene el identificador de un registro del
procesador. El sistema operativo debe encargarse de asignarle un identificador a cada
proceso y de rellenar este registro en cada cambio de proceso. De esta forma, no es
necesario que el sistema operativo invalide la TLB en cada cambio de proceso, pudiendo
existir en la TLB entradas correspondientes a varios procesos.
Tradicionalmente, la TLB ha sido gestionada directamente por la MMU sin intervencin
del sistema operativo. La MMU consulta la TLB y, si se produce un fallo debido a que la
traduccin de esa pgina no est presente, la propia MMU se encarga de buscar la traduccin en
la tabla de pginas e insertarla en la TLB. De hecho, la TLB es casi transparente al sistema
operativo, que slo debe encargarse en cada cambio de proceso de solicitar a la MMU su
volcado y, en caso de que no use identificadores de proceso, su invalidacin, Observe que es
necesario realizar un volcado de la TLB a la tabla de pginas, ya que la informacin de los bits
de pgina accedida o modificada se actualizan directamente en la TLB, pero no en la tabla de
pginas.
Algunos procesadores modernos (como, por ejemplo, MIPS o Alpha) tienen un diseo
alternativo en el que se traspasa parte de la gestin de la TLB al sistema operativo. A este
esquema se le denomina TLB gestionada por software. La MMU se encarga de buscar la
traduccin en la TLB, pero si no la encuentra produce una excepcin que activa al sistema
operativo. Este se debe encargar de buscar a mano en la tabla de pginas e insertar en la TLB
la traduccin. Observe que, con este esquema, la MMU se simplifica considerablemente, ya que
no tiene que saber nada de las tablas de pginas. Adems,
194 Sistemas operativos. Una visin aplicada
proporciona mas flexibilidad, ya que el sistema operativo puede definir las tablas de pgina a su
conveniencia, sin ninguna restriccin impuesta por el hardware. Como contrapartida, el sistema
ser menos eficiente, ya que parte del proceso de traduccin se realiza por software.
Tabla de pginas multinivel
Una manera de afrontar el problema del gasto de memoria de las tablas de pginas es utilizar
tablas de pgina multinivel, Con este esquema, en vez de tener una unida tabla de pginas por
proceso, hay una jerarqua de tablas. Existe una nica tabla de paginas de primer nivel. Cada
entrada de esta tabla apunta a tablas de pginas de segundo nivel. A su vez, las tablas de pgina
de segundo nivel apuntan a tablas de pgina de tercer nivel. As, sucesivamente, por cada nivel
de la jerarqua. Las tablas de pginas del ltimo nivel apuntan directamente a marcos de pgina.
En la prctica, esta jerarqua se limita a dos o tres niveles.
A la hora de traducir una direccin lgica, el nmero de pgina contenido en la misma se
considera dividido en tantas partes como niveles existan En la Figura 4.15 se muestra cmo se
.
Otra alternativa para reducir el gasto en tablas de paginas es usar una tabla invertida. Una tabla
de pginas invertida contiene una entrada por cada marco de pgina. Cada entrada identifica qu
pgina est almacenada en ese marco y cules son sus caractersticas. Para ello, contiene el
nmero de pgina y un identificador de proceso al que pertenece la pgina. Observe que, con
este esquema hay una nica tabla de paginas cuyo tamao es proporcional al tamao de la
memoria principal. La Figura 4.17 ilustra cmo se realiza una traduccin con este esquema.
La MMU usa una TLB convencional, pero cuando no encuentra en ella la traduccin debe
acceder a la tabla invertida para encontrarla, Dado que la tabla est organizada por marcos, no
se puede hacer una bsqueda directa. En principio, se deberan acceder a todas las entradas
buscando la pgina solicitada. Para agilizar esta bsqueda, generalmente la tabla de pginas se
organiza como una tabla hash. En esta exposicin no se entrar en ms detalles sobre esta
organizacin (p. ej.: explicar cmo se resuelven las colisiones de la funcin hash).
Esta organizacin dificulta el compartimiento de memoria ya que, en principio, no se pueden
asociar dos paginas al mismo marco. Hay algunas soluciones a este problema, pero quedan
fuera del alcance de esta exposicin.
Un ltimo punto que hay que resaltar es que la tabla invertida reduce apreciablemente el
gasto de memoria en tablas, ya que slo almacena informacin de las pginas vlidas, Sin
embargo, como se analizar ms adelante, cuando se usa este esquema para implementar
memoria virtual, el sistema operativo debera mantener sus propias tablas de pagina para
guardar informacin de las pginas que no estn presentes en memoria principal.
Para terminar con la paginacin, es conveniente hacer notar que hay numerosos aspectos
avanzados sobre este tema que no se han explicado debido al alcance de esta presentacin y a
que algunos de ellos son transparentes al sistema operativo. Entre ellos,
Gestin de memoria 197
se puede destacar el tema de cmo se relaciona la paginacin con el uso de una cache de
memoria principal, ya que en l puede estar implicado el sistema operativo. Hay bsicamente
dos alternativas:
Figura 4.17. Esquema de traduccin usando una tabla de pginas invertida.
Procesadores (p. ej.: PA-RISC) que acceden a la cache usando la direccin virtual (o
parte de ella). Esto permite realizar la bsqueda en la TLB y en la cache en paralelo, pero
obliga a que el sistema operativo tenga que invalidar la cache en cada cambio de proceso
para evitar incoherencias,
Procesadores (p. ej.: Alpha) que acceden a la cache usando la direccin fsica (o parte de
ella). Con este esquema el sistema operativo no tiene que invalidar la cache, pero no
permite que el acceso a la TLB y a la cache se hagan en paralelo (aunque si el tamao de
la cache es igual al de la pgina, si se podra hacer en paralelo).
4.5.2. Segmentacin
Con la paginacin, la MMU no sabe nada sobre las distintas regiones de los procesos. Slo
entiende de paginas. El sistema operativo debe guardar para cada proceso una tabla de regiones
que especifique qu pginas pertenecen a cada regin. Esto tiene dos desventajas:
Para crear una regin hay que rellenar las entradas de las pginas pertenecientes a la
regin con las mismas caractersticas. As, por ejemplo, si se trata de una regin de
cdigo que ocupa diez pginas, habr que rellenar diez entradas especificando una
proteccin que no permita modificarlas.
Para compartir una regin, hay que hacer que las entradas correspondientes de dos
procesos apunten a los mismos marcos.
En resumen, lo que se est echando en falta es que la MMU sea consciente de la existencia
de las regiones y que permita tratar a una regin como una entidad.
La segmentacin es una tcnica hardware que intenta dar soporte directo a las regiones.
Para ello, considera el mapa de memoria de un proceso compuesto de mltiples segmentos.
Cada regin se almacenar en un segmento.
Se puede considerar que esta tcnica es una generalizacin del uso de los registros valla, pero
utilizando una pareja de registro base y registro lmite por cada segmento. La MMU maneja una
tabla de segmentos. Cada entrada de esta tabla mantiene, adems de informacin de proteccin, el
registro base y lmite correspondientes a esa regin. Una direccin lgica est formada por un
nmero de segmento y una direccin dentro del
198 Sistemas operativos. Una visin aplicada
segmento. Como se muestra en la Figura 4.18, la traduccin consiste en acceder al numero
de segmento correspondiente y usar los registros valla almacenados en dicha entrada para
detectar si el acceso es correcto y, en caso afirmativo, reubicarlo.
Dado que cada segmento se almacena en memoria de forma contigua, este esquema
presenta fragmentacin externa.
El sistema operativo mantendr una tabla de segmentos por cada proceso y en cada
cambio de proceso ir informando a la MMU de qu tabla debe usar Adems, el sistema
.
operativo debe usar una estructura de datos, similar a la utilizada con los esquemas de
asignacin contigua, para conocer qu partes de la memoria principal estn libres y cules
ocupadas.
A pesar de dar soporte directo a los segmentos, la segmentacin tal como se ha
descrito en esta seccin presenta numerosas deficiencias que hacen que prcticamente no
se use en los sistemas reales.
Valoracin de la segmentacin
A continuacin, se analiza si la segmentacin cumple los requisitos planteados al principio
del captulo:
Espacios lgico independientes. Cada proceso tiene una tabla de segmentos que
crea espacio lgico independiente para el mismo,
Proteccin. La tabla de segmentos de un proceso restringe que parte de la
memoria puede ser accedida por el mismo, permitiendo asegurar que los procesos
usan espacios disjuntos.
Compartir memoria. Bajo la supervisin del sistema operativo, que es el nico
que manipula las tablas de segmentos, dos o ms procesos pueden tener un
segmento asociado a la misma zona de memoria.
Soporte de las regiones del proceso. Este es precisamente el punto fuerte de este
sistema.
Maximizar el rendimiento. Esta es una de sus deficiencias. Por un lado, presenta
fragmentacin externa, por lo que no se obtiene un buen aprovechamiento de la
memoria. Por un lado, y mas importante todava, esta tcnica no facilita la
implementacin de esquemas de memoria virtual debido al tamao variable de los
segmentos.
Mapas de memoria grandes para los procesos. No contempla adecuadamente esta
Gestin de memoria 199
caracterstica al no permitir implementar eficientemente un sistema de memoria
virtual.
4.5.3. Segmentacin paginada
Como su nombre indica, la segmentacin paginada intenta aun lo mejor de los dos
esquemas anteriores. La segmentacin proporciona soporte directo a las regiones del
proceso y la paginacin permite un mejor aprovechamiento de la memoria y una base
para construir un esquema de memoria virtual.
Con esta tcnica, un segmento est formado por un conjunto de pgina, y, por tanto,
no tiene que estar contiguo en memoria. La MMU utiliza una tabla de segmentos, tal que
cada entrada de la tabla apunta a una tabla de paginas. La Figura 4.19 ilustra el proceso de
traduccin en este esquema.
La valoracin de esta tcnica se corresponde con la unin de los aspectos positivos de los
esquemas anteriores:
Espacios lgicos independientes. Cada proceso tiene una tabla de segmentos que
crea un espacio lgico independiente para el mismo.
Proteccin. La tabla de segmentos de un proceso restringe qu parte de la
memoria puede ser accedida por el mismo, permitiendo asegurar que los procesos
usan espacios disjuntos.
Compartir memoria. Bajo la supervisin del sistema operativo, que es el nico
que puede manipular las tablas de segmentos, dos o ms procesos pueden tener un
segmento asociado a la misma zona de memoria.
Soporte de las regiones del proceso, gracias a la segmentacin.
Maximizar el rendimiento, La paginacin proporciona un buen aprovechamiento
de la memoria y puede servir como base para construir un esquema de memoria
virtual.
Mapas de memoria grandes para los procesos. La paginacin permite implementar
un esquema de memoria virtual.
200 Sistemas operativos. Una visin aplicada
Es importante resaltar que, aunque la segmentacin paginada ofrece ms
funcionalidad que la paginacin, requiere un hardware ms complejo que, adems, no
est presente en la mayora de los procesadores. Por ello, la mayora de los sistemas
operativos estn construidos suponiendo que el procesador proporciona un esquema de
paginacin.
4.5.4. Paginacin por demanda
Una vez analizados los diversos esquemas hardware, en esta seccin se plantea
cmo construir el mecanismo de la memoria virtual tomando como base dichos
esquemas. Como se coment previamente, estos esquemas tambin pueden usarse sin
memoria virtual, ya que de por s proporcionan numerosas ventajas sobre los esquemas de
asignacin contigua. Sin embargo, en la actualidad su uso siempre est ligado a la
memoria virtual.
Como se ha analizado en las secciones anteriores, la memoria virtual se construye
generalmente sobre un esquema de paginacin, ya sea paginacin pura o segmentacin
paginada. Por tanto, las unidades de informacin que se transfieren entre la memoria
principal y la secundaria son pginas. Las transferencias desde la memoria secundaria
hacia la principal se realizan normalmente bajo demanda (paginacin por demanda).
Cuando un proceso necesita acceder a una pgina que no estn en memoria principal (a lo
que se denomina fallo de pgina), el sistema operativo se encarga de transferirla desde la
memoria secundaria. Si al intentar traer la pgina desde memoria secundaria se detecta
que no hay espacio en la memoria principal (no hay marcos libres), ser necesario
expulsar una pgina de la memoria principal y transferirla a la secundaria. Por tanto, las
transferencias desde la memoria principal hacia la secundaria se realizan normalmente
por expulsin. El algoritmo para elegir qu pgina debe ser expulsada se denomina
algoritmo de reemplazo y se analizar ms adelante.
Dado que se est usando la paginacin para construir un esquema de memoria
virtual, se puede usar indistintamente el termino de direccin lgica y el de direccin
virtual para referirse a las direcciones que genera un programa.
Para construir un esquema de memoria virtual sobre un procesador que ofrezca
paginacin, se utiliza el bit de la entrada de la tabla de paginas que indica si la pagina es
vlida. Estarn marcadas como invlidas todas las entradas correspondientes a las pginas
que no estn residentes en memoria principal en ese instante. Para estas pginas, en vez
de guardarse la direccin del marco, se almacenar la direccin del bloque del dispositivo
que contiene la pgina. Cuando se produzca un acceso a una de estas paginas, se
producir una excepcin (fallo de pgina) que activar al sistema operativo que ser el
encargado de traerla desde la memoria secundaria.
Observe que dado que se utiliza el bit validez para marcar la ausencia de una pgina
y este mismo bit tambin se usa para indicar que una pgina es realmente invlida (una
pgina que corresponde con un hueco en el mapa), es necesario que el sistema operativo
almacene informacin asociada a la pagina para distinguir entre esos dos casos.
Por ultimo, hay que comentar que algunos sistemas de memoria virtual usan la
tcnica de la prepaginacin. En un fallo de pgina no slo se traen la pgina en cuestin,
sino tambin 1as pginas adyacentes, ya que es posible que el proceso las necesite en un
corto plazo de tiempo. La efectividad de esta tcnica va a depender de si hay acierto en
esta prediccin.
Tratamiento del fallo de pgina
La paginacin por demanda esta dirigida por la ocurrencia de excepciones de fallo de
pgina que indican al sistema operativo que debe traer una pgina de memoria secundaria
a primaria puesto que un proceso la requiere. A continuacin, se especifican los pasos
tpicos en el tratamiento de un fallo de pgina:
Gestin de memoria 201
La MMU produce una excepcin y tpicamente deja en un registro especial la
direccin que caus el fallo.
Se activa el sistema operativo que comprueba si se trata de una direccin
correspondiente una pgina realmente invalida o se corresponde con una pgina
ausente de memoria. Si 1a pagina es invalida, se aborta el proceso o se le manda
una seal. En caso contrario, se realizan los pasos que se describen a continuacin.
Se consulta la tabla de marcos para buscar uno libre.
Si no hay un marco libre, se aplica el algoritmo de reemplazo para seleccionar una
pgina para expulsar El marco seleccionado se desconectar de la pgina a la que
.
Asignacin fija
Se asigna a cada proceso un numero fijo de marcos de pgina. Normalmente, este tipo de
asignacin lleva asociada una estrategia de reemplazo local. El nmero de marcos
asignados no vara, que un proceso slo usa para reemplazo los marcos que tiene
asignados.
La principal desventaja de esta alternativa es que no se adapta a las diferente,
necesidades de memoria de un proceso a lo largo de su ejecucin Una caracterstica
.
MMU como para el sistema operativo. Adems, si se trata de una regin privada, se libera
el espacio de swap asociada a la misma.
La liberacin puede deberse a una solicitud explcita (como ocurre cuando se
desproyecta un de archivo) o a la finalizacin del proceso que conlleva la liberacin de
todas sus regiones. Observe que en POSIX, el servicio exec tambin produce una
liberacin del mapa de un proceso.
Dado que este servicio se usa muy frecuentemente en los sistema UNIX y que, en la
mayora de los casos, el nuevo mapa apenas se utiliza ya que el proceso hijo realiza una
llamada exec que lo destruye, la mayora de las versiones de UNIX han optimizado esta
operacin de duplicado usando la tcnica del copy-on-write (COW).
La tcnica COW intenta realizar un duplicado por demanda. En vez de copiar la
regin original, se comparte pero marcndola de tipo COW. Mientras los procesos que
usan esta regin solo la lean, pueden seguir compartindola. Pero, cuando un proceso
intenta modificar una pgina de esta regin, se produce una excepcin y el sistema
operativo se encarga de crear una copia privada de la pgina para ese proceso.
Tpicamente, para forzar esta excepcin, se modifica la proteccin de la pgina para que
sea slo de lectura. Evidentemente, el sistema operativo almacenar en sus tablas cul es
la proteccin real de la pagina.
Observe que puede haber y varios procesos con la misma regin duplicada (p. ej.:
un proceso que ha creado tres hijos). Por tanto, asociado a cada pgina de tipo COW hay
un contador que indica cuntos procesos estn compartindola. Cada vez que se produce
una excepcin por acceso de escritura a una pgina de este tipo, el sistema operativo,
adems de crear una copia privada de la pgina para el proceso, decrementa el contador
de uso. Cuando el contador indique que slo hay un proceso asociado a la pgina, se
puede quitar la marca de COW ya que la pgina no tiene duplicados.
Como resultado de aplicar la tcnica COW, se optimiza considerablemente la
ejecucin de un servicio fork, ya que solo es necesario compartir las regiones del padre, o
sea, duplicar su tabla de pginas. Las regiones de carcter compartido son realmente
compartidas, pero en las de tipo privado se trata de un falso compartimiento mediante la
tcnica COW.
4.6. ARCHIVOS PROYECTADOS EN MEMORIA
La generalizacin de la tcnica de memoria virtual permite ofrecer a los usuarios una
forma alternativa de acceder a los archivos. Como se ha analizado en la seccin anterior,
en un sistema de memoria virtual se hacen corresponder directamente entradas de la tabla
de pginas con bloques del archivo ejecutable. La tcnica de proyeccin de archivos en
memoria plantea usar esa misma idea, pero aplicada a cualquier archivo. -El sistema
operativo va a permitir que un programa solicite que se haga corresponder una zona de su
mapa de memoria con los bloques de un archivo cualquiera, ya sea completo o una parte
del mismo. En la solicitud, el programa especifica el tipo de proteccin asociada a la
regin.
Como se puede observar en la Figura 4.23, el sistema operativo deber manipular la
tabla de paginas del proceso para que se corresponda con los bloques del archivo
proyectado.
Una vez que el archivo est proyectado, si el programa accede a una direccin de
memoria perteneciente a la regin asociada al archivo, estar accediendo al archivo. El
programa ya no tiene que usar los servicios del sistema operativo para leer (read) y
escribir (write) en el archivo. As si en el ejemplo de la figura el programa lee un byte de
la direccin de memoria 10240, estar leyendo el primer byte del archivo, mientras que, si
escribe un byte en la direccin 10241, estar escribiendo en el segundo byte del archivo.
Observe que el proyectar un archivo no implica que se le asigne memoria principal.
Simplemente, se actualizan las entradas de la tabla de pginas para que referencien al
archivo. El propio mecanismo de memoria virtual ser el que se encargue de ir trayendo a
memoria principal los bloques del archivo cuando se produzca un fallo de pagina al
intentar acceder a la regin asociada al mismo y de escribirlos cuando la pagina sea
expulsada estando modificada.
Gestin de memoria 211
En el caso de que se quiera proyectar una regin sin soporte (regin annima), en
algunos sistemas se puede especificar el valor MAP_ANOM en el parmetro indicador.
Otros sistemas UNIX ofrecen esta opcin, pero permiten proyectar el dispositivo /dev/
zero para lograr el mismo objetivo, Esta opcin se puede usar para cargar la regin de
datos sin valor inicia de una biblioteca dinmica.
Gestin de memoria 213
#include<sys/types .h>
#include <sys/stat .h>
#include<sys/rnman ,h>
#include<sys/rnman ,h>
#include <fcntl .h>
#include<stdio.h
#include <unistd .h>.
if (argc!=3) {
fprintf (stderr, "Uso: %s caracter archivo\n", argv[0]);
return(l);
}
/* Por simplicidad , se supone que el carcter a contar corresponde con el
primero del primer argumento */
carcter = argv [1] [0];
/* Se proyecta el archivo */
if ((org=mmap((caddr_t) 0, bstat.st_size, PROT_READ,
MAP_SHARED, fd, 0)) = = MAP_FAILED) {
perror("Error en la proyeccin del archivo");
close(fd);
return(l);
}
/* Se cierra el archivo */
close(fd);
/* Bucle de acceso */
p=org;
for (i=0; i<bstat,st_size; i++)
if (*p ++ = = carcter ) contador + +;
/* Se elimina la proyeccin */
munmap(org, , bstat.st_size);
/* Bucle de copia */
p = org; q = dst;
for (i=0; i<bstat.st_size; i++)
*q++ = *p++ ;
216 Sistemas operativos. Una visin aplicada
#include <windows .
#include <stdio.h>
if (argc!=3){
fprintf (stderr, "Uso: %s carcter archivo\n", argv[0]);
return(l);
}
/*Por simplicidad, se supone que el carcter a contar corresponde con el primero del
primer argumento */
carcter =argv[l] [0];
/* Abre el archivo para lectura */ -
hArch = CreateFile (argv[2], GENERIC_READ, O, NULL,
OPEN_EXISTIMO, FILEATTRIBUTE_NORMAL, NULL);
if (hArch = = INVALID_HANDLE_VALUE) {
fprintf(stderr, "No puede abrirse el archivo\n");
return(l);
}
/* se crea la proyeccin del archivo */
hProy = CreateFileMapping (hArch, NTJLL, PAGE_READONLY, O, O, NULL);
if (hProy = = INVALID_HANDLE_VALUE) {
fprintf(stderr, "No puede crearse la proyeccin \n");
return(l);
}
/* se realiza la proyeccin */
base = MapViewOfFile (hProy, FILE_MAP_READ, 0, 0, 0);
tam = GetFileSize (hArch, NULL);
/* bucle de acceso */
puntero = bas
while (puntero < base + tam)
if (*puntero++= =caracter) contador++;
printf("%d\n", contador);
/* se elimina la proyeccin y se cierra el archivo */
UnmapViewOfFile (base);
CloseHandle (hProy);
Closehandle (hArch);
return 0;
}
218 Sistemas operativos. Una visin aplicada
if (argc!=3) {
fprintf (stderr, "Uso: %s origen destino \n", argv[0]);
return(l);
}
/* se abre archivo origen */
hEnt = CreateFile (argv[l], GENERIC_READ,0, NULL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);
if (hEnt = = INVALID_HANDLE_VALUE) {
fprintf(stderr, "No puede abrirse el archivo origen \n");
return(l);
}
En este modelo todos los procesos concurrentes ejecutan sobre un nico procesador. El
sistema operativo se encarga de ir repartiendo el tiempo del procesador entre los
distintos procesos, intercalando la ejecucin de los mismos p a d as una apariencia de
ejecucin simultnea. En la Figura 5.1 se presenta un ejemplo de ejecucin de tres
procesos en un sistema multiprogramado con un nico procesador. Como puede verse,
los tres procesos van avanzando su ejecucin de forma aparentemente simultnea, pero
sin coincidir en ningn momento sus fases de procesamiento.
Multiprocesador
dado se pueden ejecutar de forma simultnea tantos procesos como procesadores haya.
En la Figura 5.2 se muestra un ejemplo de ejecucin de cuatro procesos en un multi-
procesador con dos procesadores.
Multicomputadora
Cada uno de los procesos realiza la suma de los nmeros comprendidos entre ni y
nf. Una vez calculada la suma parcial, acumulan en la variable global sumatotal el
resultado de su parcial. Vamos a suponer que estos dos procesos ejecutan de forma
concurrente en un una nica UCP. Hay que hacer notar que estos procesos ligeros
entran dentro de la clase de cooperantes que comparten el acceso a una variable global.
Para ello se va a considerar que el compilador genera para la sentencia en
suma_total =suma_total + suma el siguiente cdigo ensamblador;
Esta sentencia constituye de nuevo una seccin crtica que no puede ser ejecutada
de forma simultnea por ms de un proceso. Esta seccin debe ejecutarse de forma
atmica. Para ello los procesos deben sincronizar sus ejecuciones: unos deben esperar a
ejecutar el cdigo de la seccin crtica mientras otro lo est ejecutando.
Para resolver el problema de la seccin crtica es necesario utilizar algn
mecanismo de sincronizacin que permita a los procesos cooperar entre ellos sin
problemas. Este mecanismo debe proteger el cdigo de la seccin critica y su
funcionamiento bsico es el siguiente:
Cada proceso debe solicitar permiso para entrar en la seccin crtica, mediante
algn fragmento de cdigo que se denomina de forma genrica entrada en la
seccin crtica.
Cuando un proceso sale de la seccin critica debe indicarlo mediante otro
fragmento de cdigo que se denomina salida de la seccin crtica. Este fragmento
permitir que otros procesos entren a ejecutar el cdigo de la seccin crtica.
Cualquier solucin que se utilice para resolver este problema debe cumplir los tres
requisitos siguientes:
Espera acotada: debe haber un lmite en el nmero de veces que se permite que
los dems procesos entren a ejecutar cdigo de la seccin crtica despus de que un
proceso haya efectuado una solicitud de entrada y antes de que se conceda la
suya.
En este problema existe un determinado objeto (Fig. 5.6), que puede ser un archivo, un
registro dentro de un archivo, etc., que va a ser utilizado y compartido por una serie de
procesos con-
currentes. Algunos de estos procesos slo van a acceder al objeto sin modificarlo,
mientras que otros van a acceder al objeto para modificar su contenido. Esta
actualizacin implica leerlo, modificar su contenido y escribirlo. A los primeros
procesos se les denomina lectores y a los segundos se les denomina escritores. En este
tipo de problemas existen una serie de restricciones que han de seguirse:
Para resolver los problemas que se han planteado en la seccin anterior, y otros
muchos ms, el sistema operativo ofrece una serie de servicios que permiten a los
procesos comunicarse y sincronizarse.
Archivos.
Tuberas.
Variables en memoria compartida.
Paso de mensajes.
Seales.
Tuberas,
Semforos,
Mutex y variables condicionales,
Paso de mensajes.
Este mecanismo, sin embargo, presenta una serie de inconvenientes que hacen que
en general no sea un mecanismo de comunicacin ampliamente utilizado. Estos son:
5.3.2. Tuberas
Una operacin de escritura sobre una tubera introduce datos en orden FIFO en la
misma. La semntica de esta operacin es la siguiente:
Una operacin de lectura de una tubera obtiene los datos almacenados en la misma.
Estos datos, adems, se eliminan de la tubera. Las operaciones de lectura siguen la
siguiente semntica:
Si no hay escritores y la tubera est vaca, la operacin devuelve fin de archivo (en
este caso la operacin no bloquea al proceso).
Al igual que las escrituras, las operaciones de lectura sobre una tubera son atmicas
(Aclaracin 5.3).
Como puede apreciarse, una lectura de una tubera nunca bloquea al proceso si
hay datos disponibles en la misma.
Existen dos tipos de tuberas: sin nombre y con nombre (Aclaracin 5.4). Una
tubera sin nombre solamente se puede utilizar entre los procesos que desciendan del
proceso que cre la tubera. Una tubera con nombre se puede utilizar para comunicar
y sincronizar procesos independientes.
A continuacin se describe como solucionar algunos de los problemas de
comunicacin y sincronizacin, vistos en la Seccin 5.2, mediante el uso de tuberas.
El hecho de que las operaciones de lectura y escritura sobre una tubera sean atmicas
y que la lectura bloquee a un proceso cuando se encuentra vaca la tubera, permite que
este mecanismo sea utilizado para sincroniza procesos. Recurdese que toda
sincronizacin implica un bloqueo.
La forma de resolver el problema de la seccin crtica mediante tuberas consiste
en crear una tubera en la que se inserta inicialmente, mediante una operacin de
escritura, un dato que hace de testigo.
Una vez creada la tubera e insertado el testigo en la misma, los procesos deben
proteger el cdigo correspondiente a la seccin crtica de la siguiente forma:
Productor() {
for (;;) {
< Producir un dato >
< Escribir el dato a la tubera >
}
}
Consumidor() {
for (;;) {
< Leer un dato a la tubera >
< Consumir el dato ledo >
}
}
Aunque en las secciones anteriores se han presentado dos posibles utilizaciones de las
tuberas uso mas extendido se encuentra en la ejecucin de mandatos con tuberas. De
esta forma, se pueden conectar programas sencillos para realizar una tarea ms
compleja.
5.3.4. Semforos
wait (s) {
s = s 1;
if (s < 0)
Bloquear al proceso;
1
}
signal (s) {
s = s + 1;
if ( s <= 0 )
Desbloquear a un proceso bloqueado en la operacin wait;
}
Cuando el valor del semforo es menor o igual que cero, cualquier operacin wait
que se realice sobre el semforo bloquear al proceso. Cuando el valor del semforo es
positivo, cualquier proceso que ejecute una operacin wait no se bloquear.
El nmero de procesos, que en un instante determinado se encuentran bloqueados
en una operacin wait, viene dado por el valor absoluto del semforo si es negativo.
Cuando un proceso ejecuta la operacin signal, el valor del semforo se incrementa.
En el caso de que haya algn proceso bloqueado en una operacin wait anterior, se
desbloquear a un solo proceso.
A continuacin se presenta el uso de los semforos en la resolucin de alguno de
los problemas vistos en la Seccin 5.2.
wait (s);
Seccin crtica;
signal(s);
El valor que tiene que tomar el semforo inicialmente es 1, de esta forma solo se
permite a un nico proceso acceder a la seccin crtica. Si el valor inicial del semforo
fuera, por ejemplo, 2, entonces dos procesos podran ejecutar la llamada wait sin
bloquearse y por tanto se permitira que ambos ejecutaran de forma simultnea dentro
de la seccin crtica.
En la Figura 5.10 se representa la ejecucin de tres procesos (P0 , P1 y P2) que
intentan acceder a una seccin crtica. Los tres procesos se sincronizan utilizando un
semforo con valor inicial 1.
En este problema existen dos tipos de recursos: los elementos situados en el buffer
y los huecos donde situ nuevos elementos. Cada uno de estos recursos se representa
mediante un semforo.
Figura 5.11.Productor-consumidor con buffer circular,
240 Sistemas operativos. Una visin aplicada
Productor () {
int posicion =;
for (;;) {
Producir un dato;
wait(huecos);
buffer[posicin] = dato; /* se inserta en el buffer */
posicion = (posicion + 1) % TAMANYQ_DELBUFFER;
signal. (elementos);
}
}
Consumidor () {
int posicion O;
for(;;) {
wait(elementos);
dato = buffer[posicion]; / * se extrae del buffer */
posicion = (posicon + 1) % TAMANYO_DEL BUFFER;
signal (huecos);
Consumir el dato extraido;
}
}
En esta seccin se presenta una posible solucin al problema de los lectores escritores
empleando semforos. La estructura de los procesos lectores y escritores se muestra en
el Programa 5.4.
Lector( ) {
wait (sem_lectores);
int_lectores = n_lectores + 1;
if (n_lectores = = 1)
wait (sem_recurso);
signal (sem-lectores);
< consultar el recurso compartido >
wait (sem_lectores);
n_lectores = n_lectores _ 1;
if (n-lectores = = 0)
signal (sen_recurso);
signal(sem-lectores);
}
Escritor ( ) {
wait (sem_recurso);
/* se puede modificar el recurso */
signal(sem_recurso);
}
lock: intenta bloquear el mutex. Si el mutex ya est bloqueado por otro proceso,
el proceso que realiza la operacin se bloquea. En caso contrario se bloquea el
mutex sin bloquear al proceso.
unlock: desbloquea el mutex. Si existen procesos bloqueados en l, se
desbloquear a uno para de ellos que ser el nuevo proceso que adquiera el
mutex. La operacin unlock sobre un mutex debe ejecutarla el proceso ligero
que adquiri con anterioridad el mutex mediante la
operacion operacin lock. Esto es diferente a lo que ocurre con las
operaciones wait y signal sobre un semforo.
c_wait: bloquea al proceso que ejecuta la llamada y le expulsa del mutex dentro
del cual se ejecuta y al que est asociado la variable condicional, permitiendo
que algn otro proceso adquiera el mutex. El bloqueo del proceso y la liberacin
del mutex se realiza de forma atmica.
c_signal: desbloquea a uno o varios procesos suspendidos en la variable
condicional. El proceso que se despierta compite de nuevo por el mutex.
acceso a una seccin crtica. En este caso, es necesario un mutex para proteger la
ejecucin de dicha seccin crtica. Una vez dentro de la seccin crtica puede ocurrir
que un proceso no pueda continuar su ejecucin dentro de la misma, debido a que no se
cumple una determinada condicin, por ejemplo, se quiere insertar elementos en un
buffer comn y este se encuentra lleno. En esta situacin el proceso debe bloquearse
puesto que no puede continuar su ejecucin. Adems debe liberar el mutex para
permitir que otro proceso entre en la seccin crtica y pueda modificar la situacin que
bloque al proceso, en este caso eliminar un elemento del buffer comn para hacer
hueco.
Para conseguir este funcionamiento es necesario utilizar una o ms variables
compartidas que se utilizarn como predicado lgico y que el proceso consultar para
decidir su bloqueo o no. El fragmento de cdigo que se debe emplear en este caso es el
siguiente:
lock(m) ;
/* cdigo de la seccin crtica */
while (condicion = = FALSE)
c_wait(c, m) ;
/* resto de la seccin crtica */
unlock(m) ;
lock(m) ;
/* cdigo de la seccin crtica */
/*se modifica la condicin y sta se hace TRUE */
condicion = TRUE;
c-signal(c);
unlock (m);
En este caso, el proceso que hace cierta la condicin ejecuta la operacin c_signal
sobre la variable condicional despertando a un proceso bloqueado en dicha variable.
Cuando el proceso ligero que espera en una variable condicional se desbloquea, vuelve
a competir por el mutex. Una vez adquirido de nuevo el mutex debe comprobar si la
situacin que le despert y que le permita continuar su ejecucin sigue cumplindose,
de ah la necesidad de emplear una estructura de control de tipo while, Es necesario
volver a evaluar la condicin ya que entre el momento en el que la condicin se hizo
cierta y el instante en el que comienza a ejecutar de nuevo el proceso bloqueado en la
variable condicional puede haber ejecutado otro proceso que a su vez puede haber
hecho falsa la condicin.
El empleo de mutex y variables condicionales que se ha presentado es similar al
concepto de monitor [Hoare, 1974], y en concreto a la definicin de monitor dada para
el lenguaje Mesa [Lampson, 1980].
En la Figura 5.14 se representa de forma grafica el uso de mutex y variables
condicionales entre dos procesos tal y como se ha descrito anteriormente.
Productor-consumidor con mutex y variables condicionales
Consumidor( ) {
int pos = 0;
for(;;) (
lock(mutex);
/* acceder al buffer */
while (n_elementos = = 0) /* si buffer vacio
*/
c_wait(vacio, mutex); /* se bloquea */
dato = buffer[pos];
pos = (pos + 1) % TAMANYQ_DEL_BUFFER;
n_elementos - - ;
if (n_elementos = = (TAMANYO_DEL_BUFFER 1));
c_signal(lleno); /* buffer no vacio
*/
unlock(mutex>;
< Consumir el dato >
}
}
if (n_elementos = = 1)
c_signal (vacio); /* buffer no vaco */
Cuando el proceso consumidor elimina un elemento del buffer y ste deja de estar
lleno, despierta al proceso productor en caso de que estuviera bloqueado en la variable
condicional lleno. Para ello el proceso consumidor ejecuta:
Lector ( ) {
lock(mutex_lectores);
n_lectores++;
if (n_lectores = = 1)
lock(mutex);
unlock(mutex_lectores>;
Todos los mecanismos vistos hasta el momento necesitan que los procesos que quieren
intervenir en la comunicacin o quieren sincronizarse ejecuten en la misma mquina.
Cuando se quiere comunicar y sincronizar procesos que ejecutan en mquinas distintas
es necesario recurrir al paso mensajes. En este tipo de comunicacin los procesos
intercambian mensajes entre ellos. Es obvio que este esquema tambin puede
emplearse para comunicar y sincronizar procesos que ejecutan en la misma mquina,
en este caso los mensajes son locales a la mquina donde ejecutan los procesos
Utilizando paso de mensajes como mecanismo de comunicacin entre procesos no
es necesario recurrir a variables compartidas, nicamente debe existir un enlace de
comunicacin entre ellos. Los procesos se comunican mediante dos operaciones
bsicas:
De acuerdo con estas dos operaciones, las tuberas se pueden considerar en cierta
medida como un mecanismo de comunicacin basado en paso de mensajes. Los
procesos pueden enviar un mensaje a otro proceso por medio de una operacin de
escritura y puede recibir mensajes de otros a travs mediante una operacin de lectura.
En este caso, el enlace que se utiliza para comunicar a procesos es la propia tubera.
Existen mltiples implementaciones de sistemas con paso de mensajes. A
continuacin se describen algunos aspectos de diseo relativos a este tipo de sistemas.
Los mensajes que enva un proceso a otro pueden ser de tamao fijo o tamao
variable. En mensajes de longitud fija la implementacin del sistema de paso de
mensajes es mas sencilla, sin embargo, dificulta la tarea del programador ya que puede
obligar a ste a descomponer los mensajes grandes en mensajes de longitud fija ms
pequeos.
Flujo de datos
Nombrado
Los procesos que utilizan mensajes para comunicarse o sincronizarse deben tener
alguna forma de referirse unos a otros. En este sentido, la comunicacin puede ser
directa o indirecta.
La comunicacin es directa cuando cada proceso que desea enviar o recibir un
mensaje de otro debe nombrar de forma explcita al receptor o emisor del mensaje. En
este esquema de comunicacin, las operaciones bsicas send y receive se definen de
la siguiente manera:
receive(ANY, mensaje);
Sincronizacin
La comunicacin entre dos procesos es sncrona cuando los dos procesos han de ejecutar
los servicios de comunicacin al mismo tiempo, es decir, el emisor debe estar ejecutando
la operacin send y el receptor ha de estar ejecutando la operacin receive. La
comunicacin es asncrona en caso contrario.
En general, son tres las combinaciones ms habituales que implementan los distintos
tipos de paso de mensajes.
Almacenamiento
Este aspecto hace referencia a la capacidad del enlace de comunicaciones. El enlace y por
tanto el paso de mensajes pueden:
Una operacin de recepcin bloqueante permite bloquear al proceso que la ejecuta hasta la
recepcin del mensaje. Esta caracterstica permite emplear los mecanismos de paso de
mensajes para sincronizar procesos, ya que una sincronizacin siempre implica un
bloqueo.
Comunicacin y sincronizacin de procesos 251
Una vez que todos los procesos tienen acceso a la cola, sincronizan su acceso a la
seccin crtica ejecutando el siguiente fragmento de cdigo:
receive(cola, testigo);
< Cdigo de la seccin crtica >
send(cola, testigo);
De esta forma, el primer proceso que ejecuta la operacin receive extrae el mensaje
de la cola y la vaca, de tal manera que el resto de procesos se bloquear hasta que de
nuevo vuelva a haber un mensaje disponible en la cola. Este mensaje lo inserta el proceso
que lo extrajo mediante la operacin send. De esta forma, alguno de los procesos
bloqueados se despertar y volver a extraer el mensaje de la cola vacindola.
Productor( ) {
for(;;) {
< Producir un dato >
252 Sistemas operativos. Una visin aplicada
send(Consumidor, dato);
}
}
Consumidor( ) {
for(;;)
receive(Productor, dato);
< Consumir el dato >
}
}
wait(s) {
s = s 1;
while (s < 0)
;
}
signal (s) {
s = s + 1;
}
Esta implementacin coincide adems con la definicin original que se dio a los
semforos. En esta implementacin se debe asegurar que las modificaciones del valor
entero del semforo en las operaciones wait y signal se ejecutan de forma indivisible.
Adems, en el caso de la operacin wait la comparacin debe realzarse tambin de forma
atmica. Con esta implementacin, todo proceso que se encuentra con un valor del
semforo negativo entra en un bucle en el que evala de forma continua el valor del
semforo. A esta situacin se le denomina espera activa.
Cuando se emplea espera activa para bloquear a los procesos, stos deben ejecutar un
ciclo continuo hasta que puedan continuar . La espera activa es obviamente un problema
en un sistema multiprogramado real, ya que se desperdicia ciclos del procesador en
aquellos procesos que no puede ejecutar y que no realizan ningn trabajo til.
Para solucionar el problema que plantea la espera activa se puede modificar la
implementacin de las operaciones wait y signal, utilizando la que se vio en la Seccin
5.7.
wait (s) {
s = s 1;
if (s < 0)
Bloquear al proceso;
}
signal (s) {
s = s + 1;
if ( s <= 0)
Desbloquear a un proceso bloqueado un la operacin wait;
}
Estos conceptos, que se han visto para un semforo, se pueden aplicar de igual
forma para el resto de mecanismos de sincronizacin.
Figura 5.17. Acciones realizadas por el sistema operativo cuando se debe bloquear a un
proceso en semforo.
Comunicacin y sincronizacin de procesos 255
temp=*valor;
*valor = 1; /*True*/
return temp;
}
Figura 5.18. Acciones realizadas por el sistema operativo en una operacin signal.
256 Sistemas operativos. Una visin aplicada
while (tast-and-set(&lock))
;
<Seccin crtica >
lock = false;
llave = true;
do
swap(lock, llave);
while (llave != false);
<Seccin crtica>
lock = false;
La variable lock se comparte entre todos los procesos y su valor inicial debe ser false
.La variable llave es local a cada proceso.
Utilizando la instruccin test-and-set, un semforo vendra definido por una
estructura que almacena: el valor del semforo, la lista de procesos bloqueados y el valor
de la variable a utilizar en la instruccin anterior. La definicin de las operaciones wait y
signal en este sera la siguiente:
wait(s) {
while (test-and-set (&valors))
;
s = s 1;
if (s < 0){
valor_s = false;
Bloquear al proceso;
}
else
valor_s = false;
}
signal (s) {
while (test-and-set(&valors))
;
s = s + 1;
Comunicacin y sincronizacin de procesos 257
if ( s <= 0)
Desbloquear a un proceso bloqueado en la operacin wait;
valor_s = false;
}
5.6. INTERBLOQUEOS
Proceso P1 Proceso P2
1 wait(P); 2 wait (Q);
3 wait(Q); 4 wait(P);
.. .
signal(P>; signal(Q);
signal(Q); signal(P);
Proceso. P1 Proceso P2
.. .
receive (P2, m) receive(P1,m);
send(P2,m) send(P1,m);
En esta seccin se presentan los servicios que ofrece POSIX para los distintos
mecanismos comunicacin y sincronizacion de procesos que se han ido presentando a lo
largo del c Unicamente se van a trat los mecanismos ms adecuados p a la comunicacin
y sincronizac~ de procesos. Los servicios de sincronizacin pura incluyen los semforos,
los mutex y las var condicionales. Para comunicar procesos se pueden emplear tuberas y
colas de mensajes.
5.7.1. Tuberias
En POSIX existen tuberas sin nombre, o simplemente pipe~, y tuberas con nombre, o
FIFOS.
Un pipe no tiene nombre y, por tanto, slo puede ser utilizado entre los procesos que
hereden a travs de la llamada fork () . La Figura 5.20 muestra lajer qua de procesos que
pue utilizar un mismo pipe.
Para leer y escribir de una tubera en POSIX se utilizan descriptores de archivo. Las
tub sin nombre tienen asociados dos descriptores de archivo. Uno de ellos se emplea para
leer y el para escribir. Un FIFO slo tiene asociado un descriptor de archivo que se puede
utilizar p a escribir. A continuacin se describen los servicios POSIX relacionados con
las tuberas,
Figura 5.20. Jerarqua de proceso. que pueden compartir un mismo pipe en POSJX.
Comunicacin sincronizacin de procesos 259
Esta llamada devuelve dos descriptores de chivos (Fig. 5.21) que se utilizan como
identificadores:
En POSIX, las tuberas con nombre se conocen como FIFO. Los PIFO tienen un nombre
local que lo identifican dentro de una misma mquina. El nombre que se utiliza
corresponde con el de un archivo. Esta caracterstica permite que los PIFO puedan
utilizarse para comunicar y sincronizar procesos de la misma mquina, sin necesidad de
que lo hereden por medio de la llamada fork. El prototipo del servicio que permite cre
una tubera con nombre es el siguiente:
El servicio que permite abrir una tubera con nombre es open. Este servicio tambin se
emplea para abrir archivos. Su prototipo es el siguiente:
El primer argumento identifica el nombre del PIFO que se quiere abrir y el segundo
la forma en la que se va a acceder al PIFO. Los posibles valores de este segundo
argumento son:
Figura 5.21. Tuberas POSIX entre dos procesos.
260 Sistemas operativos. Una visin aplicada
El servicio open devuelve un descriptor de archivo que se puede utilizar para leer y
escribir del FIFO. En caso de error devuelve -1. La llamada open bloquea al proceso que
la ejecuta hasta; que haya algn otro proceso en el otro extremo del FIFO.
Este servicio cierra un descriptor de archivo asociado a una tubera con o sin nombre.
Tambin se emplea para cerrar cualquier archivo. Su prototipo es:
Permite borrar un FIFO. Esta llamada tambin se emplea para borrar archivos. Su
prototipo es:
Esta llamada pospone la destruccin del FIFO hasta que todos los procesos que lo
estn utilizando lo hayan cerrado con la funcin close. En el caso de una tubera sin
nombre, sta se destruye cuando se cierra el ltimo descriptor que tiene asociado.
La semntica del servicio write aplicado a un pipe es la que se vio en la Seccin 5.3.
En POSIX, cuando no hay lectores y se intenta escribir en una tubera, el sistema
operativo enva la seal SIGPIPE al proceso.
Al igual que las lecturas, las escrituras sobre un pipe son atmicas. En general esta
atomicidad se asegura siempre que el nmero de datos involucrados en la operacin sea
menor que el tamao del pipe.
A continuacin se van a emplear las tuberas POSIX para resolver alguno de los
problemas descritos en la Seccin 5.2,
Una vez creada la tubera e insertado el testigo en ella, los procesos deben proteger
el cdigo correspondiente a la seccin crtica de la siguiente forma:
El Programa 5.8 muestra un fragmento de ejemplo que se puede utilizar para resolver
problemas de tipo productor-consumidor mediante las tuberas que ofrece POSIX. En
este ejemplo se crea un proceso hijo por medio de la llamada fork. A continuacin, el
proceso hijo har las veces productor y el proceso padre de consumidor.
#include <stdio,h>
#include <unistd.h>
struct elemento dato; /* dato a producir */
int fildes[2]; /* tubera */
Aunque en las secciones anteriores se han presentado dos posibles utilizaciones de las
tuberas, uso ms extendido se encuentra en la ejecucin de mandatos con tuberas. A
continuacin se presenta un programa que permite ejecutar el mandato lswc. La
ejecucin de este mandato supone la ejecucin de los programas ls y wc de UNIX y su
conexin mediante una tubera. El cdigo que permite la ejecucin de este mandato es el
que se muestra en el Programa 5.9.
void main(void) {
int fd[2];
pid_t pid;
pid = fork( );
switch (pid) {
case -1: /* error */
perror(Error en el fork)
exit (0);
case 0: /* proceso hijo ejecuta ls */
close (fd[0]);
close(STDOUT_FILENO);
dup(fd [1])
close(fd [1]);
execlp(ls. ls, NULL);
perror(Error en el exec);
break;
default: /* proceso padre ejecuta wc */
close(fd [1]);
close(STDIN_FILENO);
dup(fd[0])
close(fd[0]);
execlp(wc, wc, NULL);
perror(Error en el exec);
}
}
El proceso hijo (Fig. 5.22) redirige su salida estndar a la tubera. Por su parte, el
proceso padre redirecciona su entrada estndar a la tubera. Con esto se consigue que el
proceso que ejecuta el programa ls escriba sus datos de salida en la tubera y el proceso
que ejecuta el programa wc lea sus datos de la tubera.
Los pasos que realiza el proceso hijo para redirigir su salida estndar a la tubera son
los siguientes:
Las operaciones wait y signal son dos operaciones genricas que deben particularizarse en cada
sistema operativo. A continuacin se presentan los servicios que ofrece el estndar POSIX para
trabajar con semforos.
En POSIX un semforo se identifica mediante una variable del tipo sem_t. El estndar POS IX
define dos tipos de semforos:
Semforos sin nombre. Permiten sincronizar a los procesos ligeros que ejecutan dentro
de un mismo proceso, o a los procesos que lo heredan a travs de la llamada fork.
Semforos con nombre. En este caso, el semforo lleva asociado un nombre que sigue
la convencin de nombrado que se emplea para archivos. Con este tipo de semforos se
pueden
sincronizar procesos sin necesidad de que tengan que heredar el semforo utilizando la
llamada fork.
La diferencia que existe entre los semforos con nombre y sin nombre es similar a
la que existe entre los pipes y los FIFOS.
Los servicios POSIX para manejar semforos son los siguientes:
Todos los semforos en POSIX deben iniciarse antes de su uso. La funcin sem mit permite
iniciar un semforo sin nombre. El prototipo de este servicio es el siguiente:
Con este servicio se crea y se asigna un valor inicial a un semforo sin nombre. El primer
argumento identifica la variable de tipo semforo que se quiere utilizar. El segundo argumento
indica si el semforo se puede utilizar para sincronizar procesos ligeros o cualquier otro tipo de
proceso. Si shared es O, el semforo slo puede utilizarse entre los procesos ligeros creados
dentro del proceso que inicia el semforo. Si shared es distinto de O, entonces se puede utilizar
para sincronizar procesos que lo hereden por medio de la llamada fork. El tercer argumento
representa el valor que se asigna inicialmente al semforo.
Con este servicio se destruye un semforo sin nombre previamente creado con la llamada
sem_init. Su prototipo es el siguiente:
El servicio sem_open permite crear o abrir un semforo con nombre. La funcin que se utiliza
para invocar este servicio admite dos modalidades segn se utilice para crear el semforo o
simplemente abrir uno existente. Estas modalidades son las siguientes:
Cierra un semforo con nombre, rompiendo la asociacin que tena un proceso con un
semforo. El prototipo de la funcin es:
Elimina del sistema un semforo con nombre. Esta llamada pospone la destruccin del
semforo hasta que todos los procesos que lo estn utilizando lo hayan cerrado con la funcin
sem_close. El prototipo de este servicio es:
Operacin wait
Operacin signal
Este servicio se corresponde con la operacin signal sobre un semforo. El prototipo de este
servicio es:
Los pasos que deber realizar el proceso consumidor en la solucin propuesta son los
siguientes:
Programa 5.10. Cdigo del proceso productor utilizando memoria compartida y semforos
POSIX.
#include <sys/mmap.h>
#include <stdio.h>
267 Sistemas operativos. Una visin aplicada
#include <pthread.h>
#include <semaphore.h>
sem_t *huecos;
sem_t *elementos;
int buffer; /*puntero al buffer de nmeros enteros */
void main(void){
int shd;
Programa 5.11. Cdigo del proceso consumidor utilizando memoria compartida y semforos
POSIX.
sem_t *huecos;
sem_t *elementos;
int *buffer ; /* buffer de nmeros enteros */
void main(void){
int shd;
/* se desproyecta el buffer */
munmap(buffer, MAX_BUFFER*sizeof (int));
close(shd);
En esta seccin se describen los servicios POSIX que permiten utilizar mutex y variables
condicio-nales.
Para utilizar un mutex un programa debe declarar una variable de tipo pthread mutex_t
(definido en el archivo de cabecera pthread.h) e iniciarla antes de utilizarla.
Comunicacin y sincronizacin de procesos 297
Programa 5.20, Cdigo del proceso productor utilizando semforos Win32 y memoria
compartida.
#include <windows .
#include <stdio,h>
int main(void)
{
HANDLE huecos, elementos;
HANDLE hIN, hINMap;
int *buffer;
if (buffer = NULL) {
printf (Error al proyectar el archivo. Error: %x\n,
GetLastError ( ));
return -1;
}
productor(buffer);
UnmapViewOfFile (buffer);
CloseHaridle (hlnMap);
CloseHandle (hIn);
CloseHandle (huecos);
CloseHandle (elementos);
DeleteFile ( ALMACEN);
}
298 Sistemas operativos. Una visin aplicada
/* funcin productor */
void productor(int *buffer) {
int dato; /* dato a producir */
int posicion = 0; /*posicin donde insertar el elemento */
int j;
if (buffer = NULL)
printf (Error al proyectar el archivo, Error: %x\n,
Comunicacin y sincronizacin de procesos 299
GetLastError ( );
return -1;
}
consumidor (buffer);
UrnnapViewOfFile (buffer);
CloseHandle (hlnMap);
ClosaHaudle (hIn);
CloseHandle (huecos);
CloseHandle (elementos);
}
/ * funcin consumidor */
void consumidor(int *buffer) {
int dato; /* dato a producir */
int posicion = 0; /* posicin que indica el elemento a extraer */
int j;
}
return;
}
Crear un mutex
HANDLE CreateMutex(LPSECURITY_ATTRIBUTES
lpsa,BOOLfInitialOwner,LPCTSTR lpszMutexName);
Abrir un mutex
Cerrar un mutex
Operacin lock
Crear un evento
Destruir un evento
BOOL CloseHandle(HANDLEhObject);
Notificar un evento
Para notificar un evento se pueden utilizar dos servicios:
BOOL SetEvent (HANDLE hEvent);
BOOL PulseEvent (HANDLE hEvent);
HANDLE hEvent;
hEvent = CreateEvent(NULL, /* sin atributos de seguridad */
FALSE, /* evento automtico */
WaitForsingleObject(hEvent, INFINITE>;
<Seccin crtica >
SetEvent (hEvent);
Como se dijo anteriormente, los eventos de Win32 son similares a las variables
condicionales, sin embargo, los eventos no se encuentran asociados a ningn mutex,
como ocurre con las variables condicionales. A continuacin se va a describir cmo
utilizar los mutex y los eventos de Win32 para emular el comportamiento de los mutex y
las variables condicionales,
Para implementar el siguiente fragmento de cdigo (tpico cuando se utilizan mutex
y variables condicionales):
lock(m);
/* cdigo de la seccin crtica */
while (condicion == FALSE>
c_wait(c, m);
/* resto de la seccin crtica */
unlock(m>;
WaitForSingleObject(mutex, INFINITE);
/* cdigo de la seccin crtica */
while (condicion = = FALSE) {
ReleaseMutex(mutex); /* se libera el mutex */
WaitForMultipleobjects (2, hHandles, TRUE, INFINITE);
}
/* resto de la seccin crtica */
ReleaseMutex (mutex);
HANDLE hHandles[2];
hHandles[0] = mutex;
hHandles [1] = evento;
Comunicacin y sincronizacin de procesos 303
Recurdese que una operacin c_wait sobre una variable condicional bloquea al
proceso y libera de forma atmica el mutex para permitir que otros procesos puedan
ejecutar. Utilizando eventos es necesario en primer lugar liberar la seccin crtica
(ReleaseMutex) y esperar a continuacin por el mutex y el evento
(waitForMultipleObjects).
Para implementar la siguiente estructura:
lock(m);
/* cdigo de la seccin crtica */
/*se modifica la condicin y sta se hace TRUE */
condicion = TRUE;
c_signal(c);
unlock(m);
WaitForSingleObject(mutex, INFINITE>;
/*cdigo de la seccin crtica */
/ se modifica la condicin y sta se hace TRUE */
condicion = TRUE;
SetEvent(evento);
ReleaseMutex(mutex);
5.8.5. Mailslots
Los mailslots de Win32 son parecidos a las tuberas con nombre de Win32 y a las colas
de mensajes de POSIX. Sus principales caractersticas son:
Las principales funciones relacionadas con los mailslots son las siguientes:
Crear un mailslot
Abrir un mailslot
Cerrar un mailslot
Los nicos atributos que se pueden modificar sobre un mailslot ya creado es el tiempo de
bloqueo de la operacin ReadFile. El prototipo de esta funcin es:
Para obtener los atributos asociados a un mailslot se debe utilizar la siguiente funcin:
lnterbloqueos 311
Desde el punto de vista del estudio del interbloqueo, los recursos presentes en un
sistema se pueden clasificar siguiendo varios criterios:
El recurso sigue existiendo despus de que un proceso lo use (recurso reutilizable) o rece
una vez utilizado (recurso consumible).
Los procesos pueden compartir el uso de un recurso o lo deben usar en modo exclusivo
o dedicado.
Hay un nico ejemplar de cada recurso o existen mltiples unidades de cada uno.
Es factible expropiar el recurso al proceso que lo est utilizando.
Proceso P1 Proceso P2
Solicita(C) Solicita(I)
Solicita (I) Solicita(C)
Uso de los recursos Uso de los recursos
Libera(I) Libera(C)
Libera(C) Libera(I)
Interbloqueos 313
1. P1: solcita (C)
2. P1: solcita (I)
3. P2: solcita (I) > se bloquea puesto que el recurso no est disponible
4. P1: libera (I) > se desbloquea P2 ya que el recurso ya est disponible
5. P2: solcita (C) > se bloquea puesto que el recurso no est disponible
6. P1: libera (C) > se desbloquea m2 porque el recurso ya est disponible
7. P2: libera (C)
8. P2: libera (I)
Proceso P1 Proceso P2
Solcita(C) Solcita(C)
Enviar(P2,A) Recbir(P1, 5)
Libera(C) Libera(C)
Interbloqueos 315
Hasta ahora se ha considerado que cada recurso es una entidad nica. Sin embargo, en
un sistema pueden existir mltiples instancias o ejemplares de un determinado recurso.
Una solicitud de ese recurso por parte de un proceso podra satisfacerse con cualquier
ejemplar del mismo. As, por ejemplo, en un sistema en el que haya cinco impresoras,
cuando un proceso solicita una impresora, se le podra asignar cualquier unidad que
est disponible. La existencia de mltiples unidades de un mismo recurso tambin
permite generalizar los servicios de solicitud de forma que un proceso pueda pedir
simultneamente varios ejemplares de un recurso. Evidentemente, el numero de
unidades solicitadas nunca debera ser mayor que el nmero de unidades existentes.
Las soluciones al problema del nterbloqueo que se plantearn en este captulo sern
aplicables a este modelo general en el que existe un conjunto de recursos, cada uno de
los cuales esta formado por una o ms unidades.
Observe que, a veces, puede ser discutible si dos elementos constituyen dos
instancias de un recurso o se trata de dos recursos diferentes. Incluso distintos usuarios
pueden querer tener una visin u otra de los mismos. Considrese, por ejemplo, un
equipo que tiene conectadas dos impresoras lser con la misma calidad de impresin
pero tal que una de ellas es algo mas rpida. Un usuario puede querer usar
indistintamente cualquiera de estas impresoras con lo que preferira considerarlas como
dos ejemplares del mismo recurso. Sin embargo, otro usuario que necesite con
urgencia imprimir un documento requerira verlas como dos recursos separados para
poder especificar la impresora ms rpida. Lo razonable en este tipo de situaciones
sera proporcionar a los usuarios ambas vistas de los recursos, Sin embargo, las
soluciones clsicas del nterbloqueo no contemplan esta posibilidad de un doble perfil:
o son recursos independientes o son ejemplares del mismo recurso. En esta exposicin,
por tanto, se adoptar tambin esta restriccin.
A los usuarios de un sistema operativo convencional les puede parecer que este
tipo de organizacin de los recursos no se corresponde con su experiencia de trabajo
habitual en la que, generalmente, hay que solicitar una unidad especfica de un recurso.
Sin embargo, aunque no sea de forma evidente, este tipo de situaciones se dan hasta
cierto punto en todos los sistemas operativos. Considrese el caso de la memoria. Se
trata de un nico recurso con mltiples unidades: cada palabra que forma parte de la
misma. Cuando un proceso solicita una reserva de memoria de un determinado tamao,
est solicitando el nmero de unidades de ese recurso que corresponde con dicho
tamao. Observe que en este caso existe una restriccin adicional, ya que las unidades
asignadas, sean cuales sean, deben corresponder con posiciones de memoria contiguas.
A continuacin se muestra un ejemplo de interbloqueo en el uso de la memoria.
Considrese la ejecucin de los dos procesos siguientes, suponiendo que se
dispone de 450 KB de memoria:
Proceso P1 Proceso P1
Desde el punto de vista del estudio del nterbloqueo, en un sistema se pueden distinguir
las siguientes entidades y relaciones:
Estos dos conjuntos de relaciones no pueden tomar cualquier valor sino que deben
cumplir siguientes restricciones de coherencia para que un estado de asignacin de
recursos sea vlida
Solicitud (s (R1 [U1], ... , Rn [Un])): permite que un proceso que, evidentemente,
bloqueado pida varias unidades de diferentes recursos (u1 unidades del recurso 1,
u2 des del recurso 2, etc.). Si todos los recursos solicitados estn disponibles, se
conceder la peticin, asignando al proceso dichos recursos. En caso contrario,
se bloqueara el proceso sin reservar ninguno de los recursos solicitados, aunque
algunos de ellos estn disponibles. El proceso se desbloquear cuando todos
estn disponibles (como resultado operaciones de liberacin), Observe que se
asume un modo de operacin que se podra calificar como de todo-o-nada: hasta
que no estn todos los recursos disponibles no se asigna ninguno (el Ejercicio
6.5 plantea al lector analizar las repercusiones de modificar este
comportamiento).
Liberacin (L (R1 [U1] ,..., Rn [Un])): permite que un proceso que,
evidentemente, bloqueado libere varias unidades de diferentes recursos que
tenga asignadas en ese momento. La liberacin de estos recursos puede causar
que se satisfagan solicitudes pendientes de otros procesos, provocando su
desbloqueo.
Aristas de asignacin que relacionan recursos con procesos. Una arista entre
un recurso R1 y un proceso Pj indica que el proceso tiene asignada una
unidad de dicho recurso.
Aristas de solicitud que relacionan procesos con recursos. Una arista entre un
proceso P1y un recurso Rj indica que el proceso est esperando la concesin
de una unidad de dicho recurso.
Liberacin por parte del proceso i de u1 unidades del recurso 1, u2 del recurso 2,
etc. Por cada recurso liberado j se eliminan del grafo tantas aristas desde el nodo
R1 hasta P1 como unidades se hayan dejado libres (u1),
Observe que slo se aaden aristas en el grafo durante las solicitudes, tanto si se
trata de solicitud como de asignacin. En cuanto a la eliminacin de aristas, en la
liberacin se quitan aristas de asignacin, mientras que las de solicitud se retiran en el
desbloqueo de un proceso que realiz una peticin.
A continuacin se muestran dos ejemplos del uso de un grafo de asignacin de
recursos representar un sistema.
En primer lugar, supngase que en un sistema con 3 recursos, R1 (2 unidades), R2
(3 unida y R3 (2 unidades), se ejecutan tres procesos que realizan la siguiente traza de
peticiones:
Interbloqueos
321
5. P3: solicita(R2[1])
6. P1: solicita (R2 [11 , R3 [2]) se bloquea, pues uno de los recursos no est
disponible
El grafo que representa la situacin del sistema despus de ejecutarse esa
secuencia es el siguiente:
ellos por un nico ejemplar, donde se ejecutan cuatro procesos que realizan la siguiente
traza de peticiones:
1. P1:solicita(R1)
2. P2:solicita(R2)
3. P2:solicita (R1) se bloquea, puesto que el recurso no est disponible
4. P3:solicita (R2) se bloquea, puesto que el recurso no est disponible
5. P4:solicita(R3)
6. P1:solicita (R2) se bloquea, puesto que el recurso no est disponible
Liberacin por parte del proceso i de u1 unidades del recurso 1, u2 unidades del
recurso 2, etctera. Por cada recurso liberado j se sustraen de la matriz de
asignacin las unidades liberadas: A[j, ]=A[i ,j]- Uj .
Estas estructuras son suficientes para reflejar el estado del sistema. Sin embargo,
para simplificar la especificacin de algunos algoritmos que se expondrn ms adelante
es til usar un vector de recursos disponibles D que refleje el numero de unidades de
cada recurso disponibles en un momento dado. Observe que este vector es innecesario,
ya que su valor se puede deducir directamente a partir de la matriz de asignacin A y
del vector de recursos existentes E: D [i] = E [i] - [j , i] , para j = 1, ...,p.
Para hacer ms concisa la especificacin de los algoritmos se utilizar a partir de
ahora la siguiente notacin compacta:
Dada una matriz A, el valor A [i] representa un vector que corresponde con la
fila i-sima de dicha matriz.
Dados dos vectores A y B de longitud n, se considera que A <= B si A [i] <= B
[i] para todo j = 1, ..., n.
Si se utiliza este modo de representacin para el ejemplo representado en la Figura
6.1, se obtiene como resultado las siguientes estructuras de datos:
Por lo que se refiere al ejemplo con un nico ejemplar por recurso, correspondiente a la
Figura 6.3, las matrices resultantes seran:
Una vez establecido el modelo del sistema, parece que ya es momento de intentar
definir ms formalmente el interbloqueo para poder as caracterizarlo. Una posible
definicin de interbloqueo inspirada en [Tanenbaum, 1992] seria la siguiente:
Estas cuatro condiciones no son todas de la misma ndole. Las tres primeras tienen
que ver con aspectos estticos del sistema, como que caractersticas deben tener los
recursos implicados o cmo
Interbloqueos
325
La caracterizacin del interbloqueo se basa en mirar hacia el futuro del sistema de una
manera optimista, siguiendo la idea que se expone a continuacin.
Dado un sistema con un determinado estado de asignacin de recursos, un proceso
cualquiera que no tenga peticiones pendientes (por tanto, desbloqueado) debera
devolver en un futuro ms o menos cercano todos los recursos que actualmente tiene
asignados. Esta liberacin tendra como consecuencia que uno o ms procesos que
estuvieran esperando por estos recursos se pudieran desbloquear. Los procesos
desbloqueados podran a su vez devolver ms adelante los recursos que tuvieran
asignados desbloqueando a otros procesos, y as sucesivamente. Si todos los procesos
del sistema terminan desbloqueados al final de este anlisis del futuro del sistema, el
estado actual est libre de interbloqueo. En caso contrario existir un interbloqueo en el
sistema estando implicados en el mismo lo. procesos que siguen bloqueados al final del
anlisis, A este proceso de anlisis se le suele denomina reduccin. A continuacin se
define de una forma ms precisa:
Como parte de la reduccin, el proceso devolver los recursos asignados, tanto los
que tena previamente como los que acaba de obtener, aadindolos al sistema
crendose un nuevo estado hipottico. Gracias al aporte de recursos fruto de la
reduccin por P, ese nuevo estado podr a su vez reducirse por uno o ms procesos. A
partir del concepto de reduccin se puede establecer la condicin necesaria y suficiente
p a que se produzca un interbloqueo.
La condicin necesaria y suficiente para que un sistema est libre de interbloqueos
es que exista una secuencia de reducciones del estado actual del sistema que incluya a
todos los procesos del sistema. En caso contrario, hay un interbloqueo en el que estn
implicados los procesos que no estn incluidos en la secuencia de reducciones.
Observe que, en un determinado paso de una secuencia de reduccin, podra haber
varios procesos a los que aplicar la siguiente reduccin ya que se satisfacen sus
necesidades de recursos. En esta situacin se podra elegir cualquiera de ellos, ya que
el proceso de reduccin no depende del orden. Para poder demostrar esta propiedad
slo es necesario darse cuenta de que el proceso de reduccin es acumulativo, esto es,
en cada paso de reduccin se mantienen los recursos disponibles
que haba hasta entonces, aadindose los liberados en la reduccin actual. Por tanto, si
en un determinado punto de la secuencia se cumplen las condiciones para poder aplicar
la reduccin por un proceso, stas se seguirn cumpliendo aunque se realice la
reduccin por otro proceso.
En la seccin que analiza el tratamiento de los interbloqueos basndose en la
deteccin y recuperacin se presentarn algoritmos que se basan en este principio. A
continuacin se aplicar los ejemplos planteados hasta ahora.
En el ejemplo representado en la Figura 6,2 se puede identifica la siguiente
secuencia reducciones:
Dado que la secuencia de reducciones (P3 ,P1, P2) incluye a todos los procesos, el
sistema esta libre de interbloqueos.
Por lo que se refiere al ejemplo correspondiente a la Figura 6.3, la secuencia de re-
ducciones sera la siguiente: se puede reducir el estado por P4 que no est pendiente de
ningn recurso liberndose una unidad de R3.
Slo se puede realizar esta reduccin, por tanto, existe un interbloqueo en el
sistema en el estn involucrados el resto de los procesos.
Como se ver ms adelante, la aplicacin directa de este principio lleva a
algoritmos relativamente complejos. Sin embargo, si se consideran sistemas con algn
tipo de restriccin, se reduce apreciablemente el orden de complejidad de los
algoritmos. As, en el caso de un sistema sola unidad de cada recurso, la
caracterizacin del interbloqueo se simplifica ya que las con necesarias de Coffman
son tambin suficientes.
Como se vio al principio del captulo, las tcnicas para tratar el interbloqueo pueden
clasificarse en tres categoras:
Antes de analizar en detalle cada una de ellas, es interesante comentar que este tipo
de soluciones se emplea tambin en otros mbitos diferentes como puede ser en el
equipo o en el mantenimiento de una enfermedad. As, por ejemplo, en el caso del
mantenimiento de un equipo, la estrategia basada en la deteccin y recuperacin
consistira en esperar a que determinado componente para sustituirlo, con la
consiguiente parada del sistema mientras se produce la reparacin. Una estrategia
preventiva, sin embargo, reemplazara peridicamente los componentes del equipo
para asegurar que no se averan. Observe que esta sustitucin peridica podra implicar
que se descarten en componentes que todava estn en buenas condiciones. Para paliar
esta situacin, la prediccin se basara en conocer a priori que sntomas muestra un
determinado componente cuando se est acercando al final de su vida (p. ej.,
presenta una temperatura excesiva o produce una vibracin). Esta estrategia consistira
en supervisar peridicamente el comportamiento
Lnterbloqueos 327
del componente y proceder a su sustitucin cuando aparezcan los sntomas
predeterminados. Aunque, evidentemente, este ejemplo no presenta las mismas
caractersticas que el problema de los interbloqueos, permite identificar algunas de las
ideas bsicas sobre su tratamiento como, por ejemplo, el mal uso de los recursos que
pueden implicar las tcnicas preventivas o la necesidad de un conocimiento a priori que
requieren las estrategias basadas en la prediccin.
A continuacin, se comentan los tres tipos de estrategias utilizadas para tratar el
interbloqueo:
Deteccin y recuperacin: Se podra considerar que este tipo de estrategias
conlleva una visin optimista del sistema. Los procesos realizan sus peticiones
sin ninguna restriccin pudiendo, por tanto, producirse interbloqueos. Se debe
supervisar el estado del sistema para detectar el interbloqueo mediante algn
algoritmo basado en las condiciones analizadas en la seccin anterior. Observe
que la aplicacin de este algoritmo supondr un coste que puede afectar al
rendimiento del sistema. Cuando se detecta, hay que eliminarlo mediante algn
procedimiento de recuperacin que, normalmente, conlleva una prdida del
trabajo realizado hasta ese momento por algunos de los procesos implicados.
Prevencin: Este tipo de estrategias intenta eliminar el problema de raz fijando
una serie de restricciones en el sistema sobre el uso de los recursos que aseguran
que no se pueden producir interbloqueos. Observe que estas restricciones se
aplican a todos los procesos por igual, con independencia de qu recursos use
cada uno de ellos. Esta estrategia suele implicar una infrautilizacin de los
recursos puesto que un proceso, debido a las restricciones establecidas en el
sistema, puede verse obligado a reservar un recurso mucho antes de necesitarlo.
Prediccin (en ingles, se suele usar el trmino avoidance): Esta estrategia evita el
interbloqueo basndose en un conocimiento a priori de qu recursos va a usar
cada proceso. Este conocimiento permite definir algoritmos que aseguren que no
se produce un interbloqueo. Como ocurre con las estrategias de deteccin, a la
hora de aplicar esta tcnica es necesario analizar la repercusin que tiene la
ejecucin del algoritmo de prediccin sobre el rendimiento del sistema. Adems,
como sucede con la prevencin, generalmente provoca una infrautilizacin de
los recursos.
Existe una cuarta alternativa que consiste en no realizar ningn tratamiento, o sea,
ignorar los interbloqueos. Aunque parezca sorprendente a priori, muchos sistemas
operativos usan frecuentemente esta estrategia de esconder la cabe a debajo del ala,
denominada poltica del avestruz. Esta opcin no es tan descabellada si se tiene en
cuenta, por un lado, las restricciones que se han ido identificando a lo largo del
capitulo que limitan considerablemente el tratamiento general de los interbloqueos en
un sistema real y, por otro, las consecuencias negativas que conllevan las tcnicas de
tratamiento (como la baja utilizacin de los recursos o el coste de los algoritmos de
tratamiento). Observe que ignorar el problema trae como consecuencia que, cuando se
produce un interbloqueo, los procesos implicados seguirn indefinidamente
bloqueados y, lo que puede ser ms grave todava, los recursos involucrados quedan
permanentemente inutilizables. En la Seccin 6.9 se analizar cules pueden ser las
repercusiones de esta situacin dependiendo de diversos factores.
En las siguientes secciones se estudian en detalle las tres estrategias presentadas:
deteccin y recuperacin, prevencin y prediccin.
Esta tcnica de tratamiento de los interbloqueos presenta, como su nombre indica, dos
fases:
Fase de deteccin: Debe ejecutarse un algoritmo que determine si el estado
actual del sistema esta libre de interbloqueos y que, en caso de que no lo este,
identifique qu procesos.
328 Sistemas operativos. Una visin aplicada
Mientras (D! = ) {
No hay interbloqueo
Si no
Los procesos en el conjunto P-S estn en un interbloqueo
N={P1,P2,P3,R1(2),R2(3),R3(2)}
A = {R1P1, R1P1,R2P2, P2 R1 ,R2P3, R2P3, P1 R2,P1R3, P1R3}
El resultado es el siguiente:
Es relativamente directo trasladar las ideas expuestas para el caso de una representacin
mediante un grafo a una matricial. Por ello, la exposicin que trata este caso se har de
una forma ms sucinta. Por lo que se refiere a la operacin de reduccin aplicada a una
representacin matricial, se podra definir de la siguiente forma:
Un sistema se puede reducir por un proceso Pi si los recursos disponibles satisfacen
sus necesidades:
S[i] <=D (recuerde que esta notacin compacta equivale a S[i, j] <=D[j] para j = 1, ..., r)
D = D + A[i]
Repetir {
Busca, Pi tal que S[i] <=D;
Si Encontrado {
Reducir grafo por Pi : D = D + A[i]
Aadir Pi a S;
Continuar = cierto;
}
else
Continuar = falso;
}Mientras (Continuar)
Si (S = =P)
/* si la secuencia contiene todos los procesos del sistema (P) */
No hay nterbloqueo
332 Sistemas operativos. Una visin aplicada
Si no
Los procesos en el conjunto P-S estn en un interbloqueo
El resultado es el siguiente:
1. Estado inicial: S = 0.
2. Se puede reducir por P3 ya que S[3] <= D([012]<=[002]),dando como resultado:
D = D + A[3] = [0 0 2] + [0 2 0] = [0 2 2]
D = D + A[1] = [0 2 2] + [2 0 1] = [2 2 2]
D = D + A[2] = [0 1 0] + [2 2 2] = [2 2 3]
Se puede realizar una supervisin continua del estado del sistema con respecto a
la asignacin de recursos para comprobar que est libre de interbloqueos. Observe
que un interbloqueo slo puede aparecer cuando no puede satisfacerse una peticin
de un proceso. Por tanto, slo sera necesario ejecutar el algoritmo en ese
momento. Hay que tener en cuenta tambin que el algoritmo de deteccin queda
simplificado en esta situacin puesto que, una vez que se detecte que el proceso
que realizo la peticin que activ el algoritmo no est involucrado en un
interbloqueo, se puede detener la bsqueda. Por tanto, en cuanto aparezca dicho
proceso en una secuencia de reduccin, el sistema est libre de interbloqueos. La
viabilidad de esta alternativa depender de con qu frecuencia se active el
algoritmo y del tiempo que consuma su ejecucin, que depender del numero de
procesos y recursos existentes en el sistema.
Se puede realizar una suspensin peridica. sta sera la opcin adecuada
cuando, dadas las caractersticas del sistema, la repercusin sobre el rendimiento
del sistema de la ejecucin del algoritmo por cada peticin insatisfecha fu ra
intolerable. El valor del perodo debe reflejar un compromiso entre dos factores:
debe ser suficientemente alto para que el tiempo de ejecucin del algoritmo no
afecte apreciablemente al rendimiento del sistema, pero suficientemente bajo para
que sea aceptable el tiempo que pasa entre que se produce un interbloqueo y su
deteccin. Este valor depender de las caractersticas del sistema y de las
peticiones que realizan los procesos activos en un momento dado, siendo, por
tanto, difcil de determinar. Observe que el algoritmo podra tambin activarse
cuando se detecta algn sntoma que pudiera indicar un posible interbloqueo. Por
ejemplo, cuando el grado de utilizacin del procesador baja de un determinado
umbral.
334 Sistemas operativos. Una visin aplicada
Una vez detectado un interbloqueo es necesario tomar una serie de medidas para
eliminarlo, esto es recuperar al sistema del mismo. Para ello se deberan seleccionar uno
o ms de lo: procesos implica dos y quitarles algunos de los recursos que tienen
asignados de forma que se rompa el interbloqueo Habra que hacer que los procesos
elegidos retrocedan en el tiempo su ejecucin, al menos hasta justo antes de que
solicitasen dichos recursos. Este viaje hacia atrs en el tiempo es complicado puesto
que implica restaurar el estado del proceso tal como estaba en ese instante previo. Esta
operacin solo sera factible, pero no fcil de implementar , en sistemas que tengan algn
mecanismo d puntos de recuperacin, lo que no es habitual en los sistemas de propsito
general. Observe que, su embargo, esta estrategia podra ser adecuada p a el atamiento de
interbloqueos en una base de datos con transacciones, gracias al carcter atmico de las
mismas. Dada esta dificultad, lo ms habitual e realizar un retroceso total abortando
directamente los procesos elegidos, con la consiguiente prdida del trabajo realizado por
los mismos.
El algoritmo de recuperacin, por tanto, tomara como punto de partida el conjunto
de procesos que estn implicados en interbloqueos, tal como ha determinado el algoritmo
de deteccin, e ira sucesivamente abortando procesos de este conjunto hasta que los
interbloqueos desaparezcan de sistema, Observe que despus de abortar un proceso
habra que volver a aplicar el algoritmo de deteccin para ver si siguen existiendo
interbloqueos y, en caso afirmativo, qu procesos estn implicados en los mismos.
El criterio, a la hora de seleccionar qu procesos del conjunto se abortarn, debera
intentar minimizar el coste asociado a la muerte prematura de los mismos, En esta
decisin pueden intervenir numerosos factores tales como la prioridad de lo procesos
implicados, el nmero de recursos que tiene asignados cada proceso o el tiempo que lleva
ejecutando cada proceso.
Un ltimo aspecto a destacar es que si se realiza una supervisin continua del
sistema (o sea, se aplica el algoritmo de deteccin siempre que se produce una peticin
que no puede satisfacerse), se podra tomar la decisin de abortar precisamente al
proceso que ha realizado la peticin que ha generado el interbloqueo. No es un mtodo
ptimo, ya que este proceso puede tener gran prioridad o llevar mucho tiempo
ejecutando, pero es eficiente ya que elimina la necesidad de aplicar nuevamente el
algoritmo de deteccin.
Esta condicin establece que para que se produzca un interbloqueo, los recursos
implicados en mismo deben ser de uso exclusivo. Para asegurar que no se puede
satisfacer esta condicin, habra que conseguir que todos los recursos del sistema fueran
de tipo compartido. Sin embargo, como se comen-
nterbloqueos 335
t previamente, esto no es posible puesto que hay recursos que son intrnsecamente de
carcter exclusivo. Por tanto, esta primera condicin no permite definir estrategias de
prevencin.
Esta condicin identifica que para que ocurra un interbloqueo tiene que haber procesos
que tengan asignados recursos pero que estn bloqueados esperando por otros recursos.
Una primera estrategia de prevencin basada en asegurar que no se cumple esta
condicin consistira en hacer que cada programa al principio de su ejecucin solicitase
simultneamente todos los recursos que va a necesitar. De esta forma se evita el
interbloqueo ya que el proceso slo se bloquea esperando recursos al principio cuando no
tiene ninguno asignado. Una vez satisfecha la solicitud, el programa ya no se bloqueara
en espera de recursos puesto que dispone de todos los que necesita,
Como ejemplo, supngase un programa que necesita usar cuatro recursos (A, B, C y
D) en distintos intervalos de tiempo a lo largo de su ejecucin de acuerdo con el
diagrama de la Fig a 6.8.
Siguiendo esta estrategia de prevencin, el programa debera solicitar todos los
recursos al principio, aunque realmente la mayora de ellos slo los necesite en fases
posteriores del programa, como se aprecia a continuacin:
Figura 6.8. Diagrama de uso de recursos a lo largo del tiempo del programa ejemplo.
336 Sistemas operativos. Una visin aplicada
t6 :Libera(C).
(t7.t8): slo utiliza D.
t8: Libera(D),
Esta estrategia conlleva una tasa muy baja de utilizacin de los recursos, Observe
que, por ejemplo, el recurso D est reservado desde el instante de tiempo t1 hasta el t8
aunque realmente solo se usa en el intervalo de t7 hasta t8. Adems, esta solucin retrasa
considerablemente el inicio programa, ya que ste tiene que esperar que todos los
recursos estn libres para comenzar cuando en realidad podra comenzar en cuanto
estuviese disponible el recurso A.
Una estrategia ms refinada consistira en permitir que un proceso pueda solicitar un
recurso solo si no tiene ninguno asignado. Con esta segunda alternativa, un programa
slo se vera obligado a pedir simultneamente dos recursos si se solapa en el tiempo el
uso de los mismos. En el ejemplo anterior, la solicitud del recurso D puede realizarse en
el momento que realmente se necesita puesto que dicho recurso no se usa
simultneamente con ningn otro. Sin embargo, el resto de recursos deben seguir
pidindose al principio.
Aunque esta nueva poltica supone una mejora sobre la anterior, sigue presentando
los misa problemas. As, por ejemplo, el recurso C seguir estando desaprovechado en el
intervalo de tiempo entre t1 y t4. Observe que, aunque el recurso A y el e no se usan de
forma simultanea, se piden vez puesto que el uso de ambos se solapa con el del recurso
B. Se produce, por tanto, un cie transitivo a la hora de determinar que recursos se pedirn
juntos.
Otra alternativa ms agresiva es que, ante una peticin por parte de un proceso de
un recurso que est asignado a otro, se le quite el recurso a su actual poseedor y se le
asigne al solicitante. El reemplazo de una pgina en un sistema con memoria virtual se
puede catalogar como una aplicacin de esta estrategia, ya que el proceso que causa el
fallo de pgina le est robando el marco a otro proceso,
Por ltimo, es importante recordar que la expropiacin de recursos conlleva algn
tipo de salvaguarda de informacin de estado del recurso y una posterior restauracin de
dicha informacin. Hay que tener en cuenta que estas operaciones tienen un coste que
puede afectar al rendimiento del sistema.
La ltima condicin plantea la necesidad de que exista una lista circular de dependencias
entre procesos para que exista el interbloqueo. De manera intuitiva se ha podido apreciar
en los ejemplos planteados hasta ahora que a esta situacin se llega debido a que los
procesos piden los recursos en diferente orden.
Basndose en esa idea, una estrategia de prevencin es el mtodo de las
peticiones ordenadas, Esta estrategia requiere establecer un orden total de los
recursos presentes en el sistema y fijar la restriccin de que un proceso debe pedir
los recursos que necesita en orden creciente. Observe que esta restriccin hace
que un proceso tenga que pedir algunos recursos de forma anticipada.
En el caso del ejemplo de la Figura 6.8, si el orden fijado p a los recursos es A < B
<C <D, el programa podra solicitar los recursos justo en el momento que los necesita (A
en t1, B en t2 ,C en t4 y D en t7). Sin embargo, si el orden establecido es el inverso (D < C
<B <A), el programa debera solicitar en el instante t1 sucesivamente los recursos D, C, B
y A, lo que causara una infrautilizacin de los mismos. Observe que slo sera necesario
pedir en orden aquellos recursos que se usan de forma solapada (directamente o debido a
un cierre transitivo debido a un tercer recurso). Esto es, un proceso slo podr solicitar
recursos cuyo orden sea mayor que el de los que tiene actualmente asignados. As, en el
ejemplo, la solicitud del recurso D puede realizarse en el momento en que realmente se
necesita (t7).
Un aspecto fundamental de este mtodo es asignar un orden a los recursos de manera que
se corresponda con el orden de uso ms probable por parte de la mayora de los
programas.
En el Ejercicio 6,16 se plantea al lector demostrar que este mtodo asegura que no se
produce la condicin de espera circular y, por tanto, evita el interbloqueo.
Proceso P1 Proceso P2
Solicita(C) Solicita(I)
Solicita(I) Solicita(C)
Uso de los recursos Uso de los recursos
Libera(I) Libera(C)
Libera(C) Libera(I)
338 Sistemas operativos. Una visin aplicada
Se considera que un determinado estado es seguro si, suponiendo que todos los procesos
solicitan en ese momento sus necesidades mximas, existe al menos un orden secuencial
de ejecucin de los procesos tal que cada proceso pueda obtener sus necesidades
mximas. As, para que un estado sea seguro tiene que haber, en primer lugar, un proceso
cuyas necesidades mximas puedan satisfacerse. Cuando, hipotticamente, este proceso
terminase de ejecutar devolvera todos sus recursos (o sea, sus necesidades mximas).
Los recursos disponibles en ese instante podran permitir que se satisficieran las
necesidades mximas de al menos un proceso que terminara liberando sus recursos, lo
que a su vez podra hacer que otro proceso obtuviera sus necesidades mximas.
Repitiendo este proceso, se genera u a secuencia de ejecucin de procesos tal que cada
uno de ello, puede obtener sus necesidades mximas. Si esta secuencia incluye todos los
procesos del sistema, el estado es seguro. En caso contrario es inseguro.
El lector habr podido apreciar que este proceso de anlisis mirando hacia el
futuro es similar al usado para la reduccin de un sistema en el algoritmo de deteccin
de interbloqueos. La nica diferencia es que en el algoritmo de reduccin se tienen en
cuenta slo las peticiones actuales de los procesos mientras que en este algoritmo se
consideran tambin como peticiones las necesidades mximas de cada proceso. Esta
similitud permite especificar una segunda definicin del estado seguro:
puesto que en ese momento ninguno de los dos procesos puede satisfacer sus necesidades
mximas (el primer proceso no podra obtener la impresora, ni el segundo la cinta).
Es importante resaltar que este tipo de algoritmos tienen un carcter conservador
debido a que los datos que se poseen a priori sobre el uso de recursos de cada proceso no
incluye informacin sobre la utilizacin real de los mismos. Esto puede hacer que se
consideren como inseguros estados que realmente nunca pueden llevar a un interbloqueo.
As, por ejemplo, considrese el siguiente ejemplo que tiene una estructura similar al
anterior:
Proceso P1 Proceso P2
Solicita(C) Solicita(I)
Uso del recurso C Solicita(C)
Libera(C) Uso de los recursos
Solicita(I) Libera(C)
Uso del recurso I Libera(I)
Libera(I)
En este caso no puede haber nunca interbloqueo, pero, sin embargo, la informacin
sobre el uso mximo de recursos por cada proceso es la misma que en el ejemplo
anterior. Por tanto, la situacin que corresponde con que cada proceso haya obtenido su
primer recurso se considerar como un estado inseguro.
Se puede, por tanto, afirmar que una condicin necesaria, pero no suficiente, para
que un sistema evolucione hacia un interbloqueo es que su estado actual sea inseguro.
Los algoritmos de prediccin se basan en evitar que el estado del sistema se convierta en
inseguro eliminando de esta forma la posibilidad del interbloqueo.
Una vez identificado el concepto de estado seguro es relativamente directo establecer una
estrategia de prediccin. Cada vez que un proceso realice una solicitud de recursos que
estn disponibles, se calcula provisionalmente el nuevo estado del sistema resultante de
esa peticin y se aplica el algoritmo para determinar si el nuevo estado es seguro. Si lo
es, se asignan los recursos solicitados haciendo que el estado provisional se convierte en
permanente. En caso de que no lo sea, se bloquea al proceso sin asignarle los recursos
quedando, por tanto, el sistema en el estado previo.
Dado que el sistema esta inicialmente en estado seguro, puesto que ningn recurso
est asignado, este algoritmo asegura que el sistema siempre se encuentra en un estado
seguro eliminando, por tanto, el interbloqueo.
A continuacin se plantean algoritmos de prediccin para los dos tipos de
representacin considerados: el grafo de recurso y la representacin matricial. Observe
que no se trata de algoritmos nuevos ya que, como se ha explicado previamente, se
aplican los algoritmos de deteccin de interbloqueos ya presentados. Por ello, la
exposicin de los mismos no ser exhaustiva.
Adems de las aristas de asignacin y las de solicitud, sera necesario un nuevo tipo de
arista que refleje las necesidades mximas de cada proceso:
cuenta las aristas de necesidad. Como se aprecia en la figura, no hay ciclos, por lo que el
estado es seguro y puede hacerse permanente.
Si a continuacin el segundo proceso solicita la impresora, al estar disponible, se
genera el estado provisional representado en la Figura 6.11. El grafo resultante de
transformar la arista de necesidad en una arista de asignacin presenta un ciclo, por lo
que hay un interbloqueo y el estado es inseguro. Por tanto, no se asignara el recurso y se
bloqueara al proceso restaurando el estado previo (el que corresponde con la Figura
6.10).
Observe que, como se coment previamente, esta misma situacin se producira
tambin en el ejemplo modificado de los procesos donde no podra haber interbloqueo.
Cuando se satisface una solicitud, se restarn las unidades pedida: de cada recurso
matriz de necesidad y se sumaran a la matriz de asignacin. Observe que una
peticin puede satisfacerse por el momento no altera esta matriz, slo modifica la
de solicitud mando las unidades correspondientes a la misma. En el momento que
se pueda alterar la matriz de necesidad.
Cuando se produce una liberacin de recursos, se sustraen de la matriz de
asignacin unidades liberadas y se aaden a la matriz de necesidad.
else
Continuar = falso;
} Mientras (Continuar)
Si (S = =P)
/* si la secuencia contiene todos los procesos del sistema (P) */
El estado es seguro
Si no
El estado no es seguro
1. Estado inicial: S = 0
2. Se puede reducir por P3 ya que N[3] <= D ([1 1 l]<=[2 1 1]), dando como
resultado:
D = D + A[3] = [2 1 1] + [1 0 1] = [3 1 2]
344 Sistemas operativos. Una visin aplicada
D = D + A[1] = [3 1 2] + [1 1 0] = [4 2 2]
5. Se aade el proceso a la secuencia de reduccin: S = { P3,P1} y se pasa a la
siguiente iteracin.
6. Reduccin por P2 dado que N[2] <=D([2 2 0]<= [4 2 2]),queda como resultado:
D = D +A[2] = [4 2 2] + [0 1 2] = [4 3 4]
Recursos internos del sistema. Son recursos que el sistema operativo necesita
para llevar a cabo su labor. La reserva y liberacin de este tipo de recursos se
realiza desde el cdigo del sistema operativo y, generalmente, el uso del recurso
est comprendido dentro de la ejecucin de una nica llamada al sistema. Por
tanto, el bloqueo del proceso se produce cuando ste est ejecutando dentro del
sistema operativo. Algunos ejemplos de este tipo de recursos son un semforo
interno del sistema operativo que permite controlar el acceso concurrente a la tabla
de procesos, un descriptor interno de un chivo que una llamada al sistema necesita
usar en modo exclusivo o un buffer de la cache de bloques del sistema de chivos,
Recursos de usuario. Se corresponden con recursos que usan las aplicaciones de
usuario para realizar su trabajo. La reserva y liberacin de este tipo de recursos se
hace, por tanto, desde el cdigo de las aplicaciones. Se pueden considerar como
ejemplos de este tipo de recursos un semforo utilizado por un conjunto de
procesos de usuario cooperantes para sincronizar su ejecucin o un dispositivo
dedicado como una unidad de cinta.
En este captulo se presentan los conceptos bsicos de entrada/salida (FIS), se describe brevemente el
hardware de E/S y su visin lgica desde el punto de vista del sistema operati vo, se muestra cmo se
organizan los mdulos de E/S en el sistema operativo y los servicios de E/S que proporciona ste.
El captulo tiene tres objetivos bsicos: mostrar al lector dichos conceptos desde el punto de vista del
sistema, los servicios de E/S que da el sistema operativo y los aspectos de diseo de los sistemas de
E/S. Para alcanzar este objetivo el captulo se estructura en los siguientes grandes apartados:
Introduccin.
Caracterizacin de los dispositivos de E/S.
Arquitectura del sistema de E/S.
Interfaz de aplicaciones.
Almacenamiento secundario.
Almacenamiento terciario.
El reloj.
El terminal.
La red.
Servicios de E/S.
7.1. INTRODUCCIN
El corazn de una computadora lo constituye la UCP. Esta unidad se encarga de procesar los datos y las
instrucciones para conseguir el fin deseado por una aplicacin. Ahora bien, esta unidad no servira de nada
sin otros dispositivos que almacenaran los datos y que permitieran interactuar con los usuarios y los
programadores de las computadoras. Los primeros son bsicamente dispositivos de almacenamiento
secundario (discos) y terciario (cintas y sistemas de archivo). Los segundos son los denominados
dispositivos perifricos de interfaz de usuario, porque generalmente estn fuera de la computadora y se
conectan a ella mediante cables, y son los teclados, ratones, micrfonos, cmaras y cualquier otro
dispositivo de E/S que se le ocurra conectar a una computadora. La Figura 7.1 muestra una arquitectura
tpica de una computadora personal con sus dispositivos principales de E/S.
Todos estos dispositivos de E/S se pueden agrupar en tres grandes grupos:
Dispositivos de interfaz de usuario. Se llama as a los dispositivos que permiten la comuni cacin
entre los usuarios y la computadora. Dentro de este grupo se incluyen todos los dispositivos que sirven
para proporcionar interfaz con el usuario, tanto para entrada (ratn, teclado, etc.) como para salida
(impresoras, pantalla, etc.). Existen perifricos menos habi tuales, pero ms sofisticados, tales como
un escner, lectores de huella digital, lectores de cinta magntica, instrumentos musicales digitales
(MIDI), etc.
Dispositivos de almacenamiento. Se usan para proporcionar almacenamiento no voltil de datos y
memoria. Su funcin primordial es abastecer de datos y almacenamiento a los pro gramas que se
ejecutan en la UCP. Segn su capacidad y la inmediatez con que se puede acceder a los datos
almacenados en estos dispositivos, se pueden dividir en almacenamiento secundario (discos y
disquetes) y terciario (cintas).
Dispositivos de comunicaciones. Permiten conectar a la computadora con otras computa doras a
travs de una red. Los dos tipos de dispositivos ms importantes de esta clase son los
mdem, para comunicacin va red telefnica, y las tarjetas de interfaz a la red, para conec tar la
computadora a una red de rea local.
El gran problema de todos estos dispositivos de E/S es que son muy lentos. Piense que mien tras la UCP
procesa instrucciones a casi 1 GHz y la memoria RAM tiene un tiempo de acceso de nanosegundos, los
dispositivos de E/S ms rpidos tienen una velocidad de acceso del orden de milisegundos (Fig. 7.2). Esta
diferencia en la velocidad de acceso, y el hecho de que las aplicacio nes son cada vez ms interactivas y
necesitan ms E/S, hace que los sistemas de E/S sean el cuello de botella ms importante de los sistemas de
computacin y que todos los sistemas operativos dediquen un gran esfuerzo a desarrollar y optimizar todos
los mecanismos de E/S. Piense, por ejemplo, que el mero hecho de seguir el curso de un ratn supone
inspeccionar su posicin varias veces por segundo. Igualmente, los dispositivos de comunicaciones
interrumpen continuamente el flujo de ejecucin de la UCP para comunicar la llegada de paquetes de datos.
El sistema de E/S es la parte del sistema operativo que se ocupa de facilitar el manejo de los dispositivos de
EIS ofreciendo una visin lgica simplificada de los mismos que pueda ser usada por otros componentes
del sistema operativo (como el sistema de archivos) o incluso por el usuario. Mediante esta visin lgica se
ofrece a los usuarios un mecanismo de abstraccin que oculta todos los detalles relacionados con los
dispositivos fsicos, as como del funcionamiento real de los mis mos. El sistema operativo debe controlar
el funcionamiento de todos los dispositivos de EIS para alcanzar los siguientes objetivos:
Facilitar el manejo de los dispositivos de E/S. Para ello debe ofrecer una interfaz entre los
dispositivos y el resto del sistema que sea sencilla y fcil de utilizar.
Optimizar la E/S del sistema, proporcionando mecanismos de incremento de prestaciones donde
sea necesario.
Proporcionar dispositivos virtuales que permitan conectar cualquier tipo de dispositivo fsi co sin
que sea necesario remodelar el sistema de E/S del sistema operativo.
Permitir la conexin de dispositivos nuevos de E/S, solventando de forma automtica su instalacin
usando mecanismos del tipo plug&plav.
En este captulo se caracterizan los componentes que constituyen el hardware de E/S de una computadora,
se define la arquitectura del sistema de E/S de una computadora y se estudian algunos de los componentes
ms importantes del sistema de E/S, taes como os sistemas de a to secundario y terciario, los terminales,
los relojes, los dispositivos de red, etc. Para terminar se muestran los servicios de E/S ms habituales en
sistemas operativos, con ejemplos de programacin que involucran llamadas al sistema de E/S
La visin del sistema de E/S puede ser muy distinta dependiendo del nivel de detalle necesario en su
estudio. Para los programadores, el sistema de E/S es una caja negra que lee y escribe datos en dispositivos
externos a travs de una funcionalidad bien definida. Para los fabricantes de dispositi vos, un dispositivo es
un instrumento muy complejo que incluye cientos o miles de componentes electrnicos o electromecnicos.
Los diseadores de sistemas operativos se encuentran en un lugar intermedio entre los dos anteriores. Les
interesa la funcionalidad del dispositivo, aunque a un nivel de detalle mucho ms grande que la
funcionalidad que espera el programador de aplicaciones, pero tambin les interesa conocer la interfaz
fsica de los dispositivos y su comportamiento interno para poder optimizar los mtodos de acceso a los
mismos.
En esta seccin se estudia brevemente cmo se conecta un dispositivo de E/S a una computa dora y se
lleva a cabo una caracterizacin de los dispositivos de E/S segn sus mtodos y tamao de acceso, su forma
de programacin, etc.
7.2.1. Conexin de un dispositivo de E/S a una computadora
La Figura 7.3 muestra el esquema general de conexin de perifricos a una computadora IDe Miguel,
1998]. En el modelo de un perifrico se distinguen dos elementos:
Perifricos o dispositivos de E/S. Elementos que se conectan a la unidad central de proceso a
travs de las unidades de entradalsalida. Son el componente mecnico que se conecta a la
computadora.
Controladores de dispositivos o unidades de E/S. Se encargan de hacer la transferencia de
informacin entre la memoria principal y los perifricos. Son el componente electrnico a travs
del cual se conecta el dispositivo de E/S. Tienen una conexin al bus de la computa dora y otra para
el dispositivo (generalmente mediante cables internos o externos).
Los controladores son muy variados, casi tanto como los dispositivos de E/S. Muchos de ellos, como
los de disco, pueden controlar mltiples dispositivos. Otros, como los de canales de E/S, incluyen su propia
UCP y bus para controlar la E/S por programa y evitar interrupciones en la UCP de la computadora. De
cualquier forma, en los ltimos aos ha existido un esfuerzo importante de estandarizacin de los
dispositivos, lo que permite usar un mismo controlador para dispositivos de distintos fabricantes. Un buen
ejemplo lo constituyen los dispositivos SCSI (SrnaIl Computer Svstern interftice), cuyos controladores
ofrecen una interfaz comn independientemente de que se trate de un disco, una cinta, un CD-ROM, etc.
Otro buen ejemplo son los controladores IDE (In tegrated Drive Electronics), que suelen usarse para
conectar los discos en todas las computadoras personales. En cualquier caso, y sea como sea el controlador,
su misin es convertir los datos del formato interno del dispositivo a uno externo que se ofrezca a travs de
una interfaz de programa cin bien definida.
El controlador es el componente ms importante desde el punto de vista del sistema operativo. ya que
constituye la interfaz del dispositivo con el bus de la computadora y es el componente que se ve desde la
UCP. Su programacin se lleva a cabo mediante una interfaz de muy bajo nivel que proporciona acceso a
una serie de registros del controlador (Fig. 7.3), incluidos en el mapa de E/S de la computadora, que se
pueden acceder mediante instrucciones de mquina de E/S. Hay tres registros importantes en casi todos los
controladores: registro de datos, estado y control. El re gistro de datos sirve para el intercambio de datos.
En l ir el controlador cargando los datos ledos y de l ir extrayendo los datos para su escritura en el
perifrico. Un bit del registro de estado sirve para indicar que el controlador puede transferir una palabra.
En las operaciones de lectura esto significa que ha cargado en el registro de datos un nuevo valor, mientras
que en las de escritura significa que necesita un nuevo dato. Otros bits de este registro sirven para que el
controlador indique los problemas que ha encontrado en la ejecucin de la ltima operacin de E/S. El
registro de control sirve para indicarle al controlador las operaciones que ha de realizar. Los distintos bits
de este registro indican distintas acciones que ha de realizar el perifrico. Para empezar una operacin de
E/S, la UCP tiene que escribir sobre los registros anteriores los datos de la operacin a travs de una
direccin de E/S o de memoria asignada nicamente al controlador. Este modelo vale tanto para los
terminales o la pantalla como para los discos.
Las caractersticas del controlador son muy importantes, ya que definen el aspecto del pe rifrico para
el sistema operativo. Atendiendo a las caractersticas del hardware de los dispositivos, se pueden observar
los siguientes aspectos distintivos:
Direccin de E/S. En general hay dos modelos de direccionamiento de E/S, los que usan puertos y
los que proyectan los registros en memoria.
Unidad de transferencia. Los dispositivos suelen usar unidades de transferencia de tamao fijo.
Hay dos modelos clsicos de dispositivos: de caracteres y de bloques.
Interaccin computadora-controlador. La computadora tiene que interaccionar con la
computadora para realizar las operaciones de E/S y saber cundo terminan.
Para empezar una operacin de E/S, la UCP tiene que escribir sobre los registros anteriores los datos de la
operacin a travs de una direccin de E/S o de memoria asignada nicamente al controlador. Segn se
haga de una u otra forma, se distingue entre dispositivos conectados por puertos o proyectados en memoria.
El modelo de dispositivos por puertos es clsico en las arquitecturas de Intel. En ellas, cuando se
instala un dispositivo, a su controlador se le asigna un puerto de E/S, una interrupcin
hardware y un vector de interrupcin. La Figura 7.4 muestra las direcciones de E/S asignadas a algunos de
los dispositivos de E/S de una computadora persona! con el sistema operativo Windows 2000. Para efectuar
una operacin de E/S la UCP ejecuta operaciones por o portout con la direccin de puerto del dispositivo y
con parmetros para indicar qu registro se quiere manipular. Todas las operaciones de entradalsalida
(pantalla grfica, impresoras, ratn, discos, etc.) se realizan usando esas dos instrucciones de lenguaje
mquina con los parmetros adecuados. El problema de este tipo de direccionamiento es que exige conocer
las direcciones de E/S y programar las instruc ciones especiales de E/S, lo que es significativamente distinto
del modelo de memoria de la compu tadora.
El otro modelo de direccionamiento de E/S es el modelo proyectado en memoria. Este mo delo, tpico
de las arquitecturas de Motorola, asigna a cada dispositivo de E/S un rango de di recciones de memoria a
travs de las cuales se escribe sobre los registros del controlador. En este modelo no hay instrucciones
especficas de E/S, sino que las operaciones se llevan a cabo mediante instrucciones mquina de manejo de
memoria, lo que permite gestionar un mapa nico de direccio nes de memoria. Sin embargo, para no tener
conflictos con otros accesos a memoria y para optimi zar las operaciones, se reserva una zona de memoria
fsica para asignar las direcciones de E/S.
fuerza la existencia de accesos de un tamao determinado. Un disco, por ejemplo, se divide en sectores de
512 bytes o de 1 KB, siendo un sector la unidad mnima de transferencia que el con trolador del disco
puede manejar.
Los dispositivos de caracteres, como los terminales, impresoras, tarjetas de red, mdems, etctera, no
almacenan informacin en bloques de tamao fijo. Gestionan flujos de caracteres de forma lineal y sin
ningn tipo de estructura de bloque. Un teclado es un buen ejemplo de estos dispositivos. Est conectado a
una UART (Universal Asvnchronous Receiver/Transmiter) que recibe un carcter del teclado cada vez que
se pulsa una tecla. No es posible leer un bloque de teclas de un golpe o buscar dentro del dispositivo por
ninguna unidad. Un terminal por lnea serie tambin es un dispositivo de caracteres. Su controlador se
limita a enviar al perifrico el flujo de caracteres que debe representar en la pantalla y a recibir del mismo
los caracteres tecleados por el usuario.
Un controlador de dispositivo o unidad de E/S se encarga de controlar uno o ms dispositivos de! mismo
tipo y de intercambiar informacin entre ellos y la memoria principal o unidad central de proceso de la
computadora. El controlador debe encargarse adems de sincronizar la velocidad del procesador con la del
perifrico y de detectar los posibles errores que se produzcan en el acceso a los perifricos. En el caso de un
controlador de disco, ste debe encargarse de convertir un flujo de bits procedente del disco a un bloque de
bytes detectando y corrigiendo, si es posible, los errores que se produzcan en esta transferencia. Una vez
obtenido el bloque y comprobado que se encuentra libre de errores, deber encargarse de transferirlo a
memoria principal.
La informacin entre los controladores de dispositivo y la unidad central de proceso o me moria
principal se puede transferir mediante un programa que ejecuta continuamente y lee o escribe los datos del
(al) controlador. Con esta tcnica, que se denomina E/S programada, la transferencia de informacin entre
un perifrico y el procesador se realiza mediante la ejecucin de una instruc cin de E/S. Con esta tcnica,
es el procesador el responsable de extraer o enviar datos entre el procesador y el controlador de dispositivo,
lo que provoca que el procesador tenga que esperar mientras se realiza la transferencia entre el perifrico y
el controlador. Dado que los perifricos son sensiblemente ms lentos que el procesador, ste deber
esperar una gran cantidad de tiempo hasta que se complete la operacin de E/S. En este caso no existe
ningn tipo de concurrencia entre la E/S y el procesador ya que ste debe esperar a que finalice la
operacin.
Aunque esta tcnica es muy antigua, ya que proviene del tiempo en que los controladores no tenan
interrupciones, actualmente los canales de E/S y algunos multiprocesadores usan esta tcnica para evitar
que lleguen a la UCP de la computadora muchas interrupciones de E/S. En ambos casos, la tcnica es la
misma: dedicar una UCP especial para la E/S. La forma de hacerlo es muestrear continuamente los
registros de estado de los controladores para ver si estn disponibles y, en ese caso, leer o escribir los
registros. Imagine un canal de E/S al que hay conectados mltiples buses de E/S que, a su vez, tienen
mltiples dispositivos de E/S. Si la UCP quiere escribir en uno de ellos, debe mirar su registro de estado
hasta que los bits indiquen que no est ocupado. Cuando esto ocurra, escribir un bloque en los registros del
controlador y esperar hasta que los bits de estado indiquen que est disponible. Imagine que quiere leer de
otro controlador, deber esperar a que los bits de estado le indiquen que est disponible, programar la
operacin y esperar a que se indique que los datos estn disponibles. Evidentemente, incluso aunque la
UCP est controlando varios dispositivos de E/S, siempre existe prdida de ciclos debido a la existencia de
las esperas. Sin embargo, existen situaciones en que esto no es as. En algunos sistemas de tiempo real,
como por
ejemplo un satlite, la velocidad de E/S es tan rpida (byte/microsegundos) que sera imposible efectuarla
con interrupciones, debido al coste de tratar cada interrupcin. En estos casos, la E/S programada es la
tcnica de eleccin.
Un bucle de E/S programada en la que se controlan las lecturas y escrituras sobre mltiples dispositivos
podra tener la estructura que se muestra en el Programa 7. 1. Como se puede observar, el bucle hace un
muestreo de todos los dispositivos en orden, siempre que tengan peticiones de E/S pendientes. Este criterio
de muestreo se puede alterar usando una prioridad distinta para cada dispo sitivo, por ejemplo.
Con E/S programada el procesador tiene que esperar hasta que el controlador est listo para recibir o
enviar datos, y mientras tanto no realiza ningn trabajo til. Empleando E/S dirigida por interrupciones el
procesador enva la orden de E/S al controlador de dispositivo y no espera a que ste se encuentre listo para
enviar o transmitir los datos, sino que se dedica a otras tareas hasta que llega una interrupcin del
dispositivo que indica que se ha realizado la operacin solicitada.
El modelo de interrupciones est ntimamente ligado a la arquitectura del procesador. Casi todas las
UCP actuales incluyen interrupciones vectorizadas y enmascarables. Es decir, un rango de interrupciones
entre 0 y 255, por ejemplo, alguna de las cuales se pueden inhibir temporalmente para no recibir
interrupciones de su vector correspondiente. Cada interrupcin se asigna a un dis positivo, o un rango de
ellos en caso de un controlador SCSI o una cadena de dispositivos tipo daisv chain, que usa el vector
correspondiente para indicar eventos de E/S a la UCP. Cuando se programa una operacin en un
dispositivo, como por ejemplo una bsqueda en un disco, ste contesta con un ACK indicando que la ha
recibido, lo que no significa que haya terminado. En este caso existe concurrencia entre la E/S y el
procesador, puesto que ste se puede dedicar a ejecutar cdigo de otro proceso, optimizando de esta forma
el uso del procesador. Al cabo de un cierto tiempo, cuando el disco ha efectuado la bsqueda y las cabezas
del disco estn sobre la posicin deseada, genera una interrupcin (poniendo un 1 en el vector
correspondiente). La rutina de tratamiento de la interrup cin se encargar de leer o enviar el dato al
controlador. Obsrvese que tanto la tabla de interrupcio nes como la rutina de tratamiento de la interrupcin
se consideran parte del sistema operativo. Esto suele ser as por razones de seguridad; en concreto, para
evitar que los programas que ejecuta un usuario puedan perjudicar a los datos o programas de otros
usuarios. Vase el Captulo 1 para ver ms en detalle cmo se trata una interrupcin.
Las computadoras incluyen varias seales de solicitud de interrupcin, cada una de las cuales tiene una
determinada prioridad. En caso de activarse al tiempo varias de estas seales, se tratar la de mayor
prioridad, quedando las dems a la espera de ser atendidas. Adems, la computadora incluye un mecanismo
de inhibicin selectiva que permite detener todas o determinadas seales de interrup cin. Las seales
inhibidas no son atendidas hasta que pasen a estar desinhibidas. La informacin de inhibicin de las
interrupciones suele incluirse en la parte del registro de estado que solamente es modificable en nivel de
ncleo, por lo que su modificacin queda restringida al sistema operativo.
Quin asigna las interrupciones a los dispositivos? Normalmente, el sistema operativo se hace cargo de
esa asignacin cuando instala el dispositivo. Ahora bien, tambin suele existir la posibilidad de que el
administrador fije las interrupciones manualmente (Advertencia 7.1). La Fi gura 7.5 muestra la asignacin
de interrupciones a dispositivos en un PC con Windows 2000.
ADVERTENCIA 7.1
Nunca asigne interrupciones manualmente si no tiene experiencia con el sistema
operativo y la arquitec tura de la computadora. Si origina conflictos entre
interrupciones, varios dispositivos usarn el mismo
Quien proporciona la rutina de tratamiento de interrupcin? Las rutinas de nterrupc suelen tener
dos partes: una genrica y otra particular para el dispositivo.La parte genrica pernite:
1. Capturar la interrupcin.
2. Salvaguardar el estado del procesador.
3. Activar la rutina de manejo de la interrupcin.
4. Indicar al planificador que debe poner lista para ejecutar la rutina particular.
5. Desactivar la interrupcin (Advertencia 7.2).
ADVERTENCIA 7.2
Es importante desactivar las interrupciones despus de activar su tratamiento para evitar que
se presenten nuevas interrupciones antes de terminar el tratamiento y perder alguna de ellas.
Un caso especial en la arquitectura Intel es la controladora grfica, que se encarga de gestionar la salida
a los dispositivos de mapas de bits (pantallas grficas). Estas controladoras suelen tener su propia memoria,
sobre la cual se llevan a cabo las operaciones de E/S. Aunque la memoria de la controladora se escribe
tambin a partir de un puerto de E/S, sus prestaciones son muy altas (na nosegundos), por lo que el
tratamiento de las operaciones de E/S se desva del estndar en el sistema operativo, ya que estos
dispositivos no interrumpen, por lo que se efecta E/S programada.
Observe que aunque la controladora grfica tiene asociada una direccin de E/S en la Figura 7.4, no tiene
una interrupcin asociada en la Figura 7.5.
Los pasos a seguir en una operacin de E/S con DMA son los siguientes:
1. Programacin de la operacin de E/S. Se indica al controlador la operacin, los datos a transferir y
la direccin de memoria sobre la que se efectuar la operacin.
2. El controlador contesta aceptando la peticin de E/S.
3. El controlador le ordena al dispositivo que lea (para operacin de lectura) una cierta
cantidad de datos desde una posicin determinada del dispositivo a su memoria interna. 7.3.
4. Cuando los datos estn listos, el controlador los copia a la posicin de memoria que tiene en sus
registros, incrementa dicha posicin de memoria y decrementa el contador de datospendientes de
transferir.
5. Los pasos 3 y 4 se repiten hasta que no quedan ms datos por leer.
6. Cuando el registro de contador est a cero, el controlador interrumpe a la UCP para in dicar que la
operacin de DMA ha terminado.
Canales de EIS con DMA
Un canal de E/S se puede mejorar si se incluye el concepto de DMA que permite al controlador ejecutar
instrucciones de E/S. Con estos sistemas, las instrucciones de EIS se almacenan en me moria principal y
son ejecutadas ordenando al procesador del canal que ejecute un programa en memoria. Dicho programa se
encarga de designar dispositivos y zonas de memoria de E/S.
Hay dos tipos principales de canales de E/S: canal selector y canal multiplexor. Ambos pueden
interaccionar con varios dispositivos de E/S, pero mientras el canal selector slo puede transferir datos de
un dispositivo a la vez, el canal multiplexor puede transferir datos de varios dispositivos simultneamente.
Las caches de datos, tan populares en sistemas operativos, han irrumpido en el mundo de los controadores
de disco con mucha fuerza. La idea es aprovechar la memoria interna de los controladores para leer los
datos por adelantado, evitando muchas operacines de usqueda en el disco y sobre todo los tiempos de
latencia necesarios para esperar a que los datos pasen de nuevo bajo las cabezas del disco [Biswas, 19931.
La proximidad espacial permite optimizar la E/S en el mbito de controlador, ya que en lugar de leer un
sector, o un grupo de ellos, se leen pistas enteras en cada vuelta de disco, lo que permite traer mltiples
bloques de datos en una nica operacin. En los canales de E/S, donde suele haber mucha memoria interna,
se guardan en memoria varias pistas por cada dispositivo de E/S.
Estos mecanismos permiten optimizar mucho la E/S, especialmente en operaciones de lectura con un
comportamiento conocido. Para evitar afectar al rendimiento de las operaciones que no responden a
patroues de proximidad espacial predecibles, los controladores incluyen instrucciones para desactivar este
mecanismo, siempre que el sistema operativo lo crea conveniente.
El sistema de entradalsalida est construido como un conjunto de manejadores apilados, cada uno de los
cuales est asociado a un dispositivo de entradalsalida (archivos, red, etc.). Ofrece a las aplicaciones y
entornos de ejecucin servicios genricos que permiten manejar los objetos de en trada/salida del sistema.
A travs de ellos se puede acceder a todos los manejadores de archivos y de dispositivos tales como discos,
cintas, redes, consola, tarjetas de sonido, etc.
En esta seccin se estudia la estructura y los componentes del sistema de E/S y el software del sistema de
/S.
7.3.1. Estructura y componentes del sistema de E/S
La arquitectura del sistema de entrada/salida (Fig. 7.7) es compleja y est estructurada en capas, cada una
de las cuales tiene una funcionalidad bien definida:
Interfaz del sistema operativo para entrada/salida. Proporciona servicios de E/S sncrona y
asncrona a las aplicaciones y una interfaz homognea para poderse comunicar con losmanejadores
de dispositivo ocultando los detalles de bajo nivel.
Sistemas de archivos. Proporcionan una interfaz homognea, a travs del sistema de ar chivos
virtuales, para acceder a todos los sistemas de archivos que proporciona el sistema operativo (FFS,
SV, NTFS, FAT, etc.). Permite acceder a los manejadores de los dispositi vos de almacenamiento
de forma transparente, incluyendo en muchos casos, como NFS o NTFS, accesos remotos a travs
de redes. En algunos sistemas, como Windows NT, los servidores para cada tipo de sistema de
archivos se pueden cargar y descargar dinmica- mente como cualquier otro manejador.
Gestor de redes. Proporciona una interfaz homognea para acceder a todos los sistemas de red que
proporciona el sistema operativo (TCP/IP, Novell, etc.). Adems, permite acceder a
los manejadores de cada tipo de red particular de forma transparente.
Gestor de bloques. Los sistemas de archivos y otros dispositivos lgicos con acceso a nivel de
bloque se suelen limitar a traducir las operaciones del formato del usuario al de bloques que
entiende el dispositivo y se las pasan a este gestor de bloques. El gestor de bloques admite
nicamente operaciones a nivel de bloque e interacciona con la cache de bloques para optimi zar la
E/S.
Gestor de cache. Optimiza la entradalsalida mediante la gestin de almacenamiento inter medio en
memoria para dispositivos de E/S de tipo bloque [ 1985]. Aunque en el Captulo 8 se comenta con
ms detalle la estructura de la cache de bloques, es importante saber que su tamao vara
dinmicamente en funcin de la memoria RAM disponible y que los bloques se escriben a los
dispositivos segn una poltica bien definida, que en UNIX y WINDOWS NT es la de escritura
retrasada.
Manejadores de dispositivo. Proporcionan operaciones de alto nivel sobre los dispositivos y las
traducen en su mbito interno a operaciones de control de cada dispositivo particular. Como ya se
ha dicho, los manejadores se comunican con los dispositivos reales mediante puertos o zonas de
memoria especiales.
Cada uno de los componentes anteriores se considera un objeto del sistema, por lo que habi tualmente
todos los sistemas operativos permiten modificar el sistema operativo de forma esttica o dinmica para
reemplazar, aadir o quitar manejadores de dispositivos. Sin embargo, habitualmen te, y por razones de
seguridad, no se permite a las aplicaciones de usuario acceder directamente a los dispositivos, sino a travs
de la interfaz de llamadas al sistema operativo.
Una vez examinada la arquitectura de E/S de una computadora y las tcnicas posibles de transferen cia
entre el procesador y los perifricos, en esta seccin se va a presentar la forma en la que estructura el
sistema operativo el software de gestin de E/S. Este software se organiza en una serie de capas que se
muestran en la Figura 7.8. Estas capas se corresponden, en general, con los niveles de la arquitectura de
E/S.
Como puede verse en dicha figura, los procesos de usuario emiten peticiones de entrada/salida al
sistema operativo. Cuando un proceso solicita una operacin de E/S, el sistema operativo prepara dicha
operacin y bloquea al proceso hasta que se recibe una interrupcin del controlador del dispositivo
indicando que la operacin est completa. Las peticiones se procesan de forma estruc turada en las
siguientes capas:
Manejadores de interrupcin.
Manejadores de dispositivos o drivers.
Software de EIS independiente de los dispositivos. Este software est formado por la parte de alto
nivel de los manejadores, el gestor de cache, el gestor de bloques y el servidor de archivos.
Interfaz del sistema operativo. Llamadas al sistema que usan las aplicaciones de usuario.
El uso de capas conlleva la realizacin de varias copias de datos, alguna de las cuales son inevita bles.
En algunos casos, la copia que se realiza en el ncleo del sistema operativo puede ser innecesaria, por lo
que existen mecanismos para acceder directamente a los controladores desde la interfaz de E/S del sistema
a los manejadores. Sin embargo, y como norma general, esa copia existe siempre.
El sistema operativo estructura el software de gestin de E/S de esta forma para ofrecer a los usuarios
una serie de servicios de E/S independientes de los dispositivos. Esta independencia implica que deben
emplearse los mismos servicios y operaciones de E/S para leer datos de un disquete, de un disco duro, de un
CD-ROM o de un teclado, por ejemplo. Como se ver ms adelante, el servicio read de POSIX puede
utilizarse para leer datos de cualquiera de los dispositi vos citados anteriormente. Adems, la estructuracin
en capas permite hacer frente a la gestin de errores que se pueden producir en el acceso a los perifricos en
el nivel de tratamiento ms adecua do. A continuacin, se describe ms en detalle cada uno de los
componentes.
Manejadores de interrupcin
Los manejadores de interrupcin se encargan de tratar las interrupciones que generan los controla dores de
dispositivos una vez que stos estn listos para la transferencia de datos o bien han ledo o escrito los datos
de memoria principal en caso de acceso directo a memoria. Para tratar dicha interrupcin se ejecuta el
correspondiente manejador de interrupcin cuyo efecto es el de salvar los registros, comunicar el evento al
manejador del dispositivo y restaurar la ejecucin de un proceso (que no tiene por qu ser el interrumpido).
En la seccin anterior se mostr ms en detalle cmo se trata una interrupcin.
Los manejadores de interrupcin suelen hacer algo ms que comunicar el evento al manejador de
dispositivo. Cuando una interrupcin ocurre muy frecuentemente, caso del reloj, o cuando la cantidad de
informacin a transferir es muy pequea, caso del teclado, sera muy costoso comunicar siempre el evento
al manejador de dispositivo asociado. En estos casos, el propio manejador de interrupcin registra la
ocurrencia del evento, bien mediante el incremento de una variable global para el reloj o la acumulacin de
caracteres en un buffer del teclado. La notificacin al manejador se hace nicamente cada cierto nmero de
ocurrencias del evento, en el caso del reloj, o activando unflag que indica que hay datos en el buffer del
teclado.
Manejadores de dispositivos
Cada dispositivo de E/S, o cada clase de dispositivos, tiene un manejador asociado en el sistema operativo.
Dicho manejador incluye: cdigo independiente del dispositivo para proporcionar al nivel superior del
sistema operativo una interfaz de alto nivel y el cdigo dependiente del dis positivo necesario para
programar el controlador del dispositivo a travs de sus registros y man datos. La tarea de un manejador de
dispositivo es aceptar peticiones en formato abstracto, de la parte del cdigo de E/S independiente del
dispositivo, traducir dichas peticiones a trminos que entienda el controlador, enviar al mismo las rdenes
adecuadas en la secuencia correcta y esperar a que se cumplan. La Figura 7.9 muestra un diagrama de flujo
con las operaciones de un manejador.
Todos los manejadores tienen una lista de peticiones pendientes por dispositivo donde se encolan las
peticiones que llegan de niveles superiores. El manejador explora la lista de peticiones, extrae una peticin
pendiente y ordena su ejecucin. La poltica de extraccin de peticiones de la lista es dependiente de
manejador y puede ser FIFO, con pr etc. Una cz enviada la pet al controlador, el manejador se bloquea o no,
dependiendo de la velocidad del dispositivo. Para los lentos (discos) se bloquea esperando una interrupcin.
Para los rpidos (pantalla, discos RAM, etctera) responde inmediatamente. Despus de recibir el fin de
operacin, controla la existencia de errores y devuelve al nivel superior el estado de terminacin de la
operacin. Si tiene operaciones pendientes en la cola de peticiones, atiende a la siguiente, en caso de que le
toque ejecutar despus de la operacin de E!S. En caso contrario se bloquea.
En los sistemas operativos modernos, como Windows NT [Solomon, 19981, los manejadores se
agrupan en clases. Para cada clase existe un manejador genrico que se encarga de las operacio nes de E/S
para una clase de dispositivos, tales como el CD-ROM, el disco, la cinta o un teclado. Cuando se instala un
dispositivo particular, como por ejemplo el disco SEAGATE S300, se crea una instanclacin de manejador
de c eoii ius pai tiiiciro o dc c objetn. Toda la. funciones comunes al manejador de una clase se llevan a
cabo en el manejador genrico y las
particulares en el del objeto. De esta forma se crea un apilamiento de manejadores que refleja muy bien qu
operaciones son independientes del dispositivo y cules no.
peticiones para l y, si existen, las traslada a su cola de peticiones particular ordenadas segn la poltica
SCAN, por ejemplo. Este mecanismo permite optimizar la E/S al conceder a cada me canismo la
importancia que, ajuicio de los diseadores del sistema operativo, se merece. En el caso de Windows NT,
por ejemplo, el ratn es el dispositivo de E/S ms prioritario del sistema. La razn que hay detrs de esta
poltica es conseguir un sistema muy interactivo. En otros sistemas, como UNIX, las operaciones de disco
son ms prioritarias que las del ratn para poder desbloquear rpidamente a los procesos que esperan por la
E/S. Sea cual sea el criterio de planificacin, todos los sistemas de E/S planifican las actividades en varios
lugares.
Por ltimo, este nivel proporciona gestin de errores para aquellos casos que el manejador de
dispositivo no puede solucionar. Un error transitorio de lectura de un bloque se resuelve en el manejador
reintentando su lectura. Un error permanente de lectura no puede ser resuelto y debe ser comunicado al
usuario para que tome las medidas adecuadas. En general, todos los sistemas operativos incluyen alguna
forma de control de errores internos y de notificacin al exterior en caso de que esos errores no se puedan
resolver. Imagine, por ejemplo, que una aplicacin quiere leer de un dispositivo que no existe. El sistema de
E/S ver que el dispositivo no est y lo notificar a los niveles superiores hasta que el error llegue a la
aplicacin. Sin embargo, es importante resaltar que los sistemas operativos son cada vez ms robustos y
cada vez incluyen ms control y reparacin de errores, para lo cual usan mtodos de paridad, checksums,
cdigos correctores de error, etc. Adems, la informacin que proporcionan cuando hay un error es cada
vez mayor. En Windows NT, por ejemplo, existen monitores que permiten ver el comportamiento delas
operaciones de E/S.
Las aplicaciones tienen acceso al sistema de E/S a travs de las llamadas al sistema operativo relacionadas
con la gestin de archivos y con la E/S, como octl por ejemplo. En muchos casos, las aplicaciones no
acceden directamente a las llamadas del sistema, sino a utilidades que llaman al sistema en representacin
del usuario. Las principales utilidades de este estilo son:
Las bibliotecas de los lenguajes, como la libc. so de C, que traducen la peticin del usua rio a
llamadas del sistema, convirtiendo los parmetros all donde es necesario. Ejemplos de utilidades
de biblioteca en C son fread, fwrte o printf. Las bibliotecas de enlace dinmico (DLL) de
Windows. Por ejemplo, Kernel32 .dll incluye llamadas para la ges tin de archivos y otros
componentes de E/S.
Los demonios del sistema, como los de red o los spooler de las impresoras. Son programas
privilegiados que pueden acceder a recursos que las aplicaciones normales tienen vetados. As, por
ejemplo, cuando una aplicacin quiere acceder al puerto de telnet, llama al de monio de red (inetd)
y le pide este servicio. De igual forma, cuando se imprime un archivo, no se enva directamente a la
impresora, sino que se enva a un proceso spooler que lo copia a unos determinados directorios y,
posteriormente, lo imprime.
Esta forma de relacin a travs de representantes existe principalmente por razones de se guridad y de
control de acceso. Es fcil dejar que un proceso spooler, generalmente desarrollado por el fabricante del
sistema operativo y en el que se confa, acceda a la impresora de forma controlada, lo que evita problemas
de concurrencia, filtrando los accesos del resto de los usuarios.
La interfaz de E/S de las aplicaciones es la que define el modelo de E/S que ven los usuarios, por lo
que, cuando se disea un sistema operativo, hay que tomar varias decisiones relativas a la funcionalidad que
se va a ofrecer al mundo exterior en las siguientes cuestiones:
cacin, que sigue ejecutando su cdigo. Es responsabilidad de la aplicacin preguntar por el estado de la
operacin de EIS, usando una llamada al sistema especial para realizar esta consulta (alo walt), o cancelarla
si ya no le interesa o tarda demasiado (aiocancel). En Windows se puede conseguir este mismo efecto
indicando, cuando se crea el archivo, que se desea E/S no bloqueante (FILE_FLAG y usando las llamadas
ReadFileEx y WriteFileEx.
Este modelo de programacin es ms complejo, pero se ajusta muy bien al modelo de algunos sistemas
que emiten peticiones y reciben la respuesta despus de un cierto tiempo. Un programa que est leyendo
datos de varios archivos, por ejemplo, puede usarlo para hacer lectura adelantada de datos y tener los datos
de un archivo listos en memoria en el momento de procesarlos. Un programa que escuche por varios
canales de comunicaciones podra usar tambin este modelo (Consejo de programacin 7.1).
Es interesante resaltar que, independientemente del formato elegido por el usuario, el sistemaoperativo
procesa siempre las llamadas de E/S de forma no bloqueante, o asncrona, para permitir la implementacin
de sistemas de tiempo compartido.
Indicaciones de error
Las operaciones del sistema operativo pueden fallar debido a cuestiones diversas. Es importante decidir
cmo se va a indicar al usuario esos fallos.
En UNIX, por ejemplo, las llamadas al sistema que fallan devuelven l y ponen en una variable global
errno el cdigo de error. La descripcin del error se puede ver en el archivo /usr/include/sys/errno.h o
imprimirlo en pantalla mediante la funcin perrorO. A con tinuacin, se muestran algunos cdigos de error
de UNIX junto con sus descripciones
#define EPERNM 1 /* Not super-user */
#define ENOENT 2 /* No such file or directory */
#define ESRCH 3 /* No such process */
#define EINTR 4 /* interrupted system cali */
#define ElO 5 /* I/O error */
#define ENXIO 6 /* No such device or address */
#define E2BIG 7 /*k Arg iist too long */
#define ENOEXEC 8 /* Exec format error */
#define EBAOF 9 /* Bad file number */
En Windows se devuelven ms cdigos de error en las llamadas a funcin, e incluso en algu nos
parmetros de las mismas. Igualmente, se puede obtener ms informacin del error mediante la funcin
GetLastError ().
Uso de estndares
Proporcionar una interfaz de usuario estndar garantiza a los programadores la portabilidad de sus
aplicaciones, as como un comportamiento totalmente predecible de las llamadas al sistema en cuanto a
definicin de sus prototipos y sus resultados. Actualmente, el nico estndar definido para la interfaz de
sistemas operativos es POSIX (Portable Operating Systeni interface) [ 19881, basado principalmente en la
interfaz del sistema operativo UNIX. Todos los sistemas operativos modernos proporcionan este estndar
en su interfaz, bien como interfaz bsica (en el caso de UNIX y LINUX) o bien como un subsistema POSIX
(caso de Windows) que se ejecuta sobre la interfaz bsica (Win32).
No se hace ms nfasis en la interfaz POSIX porque se va estudiando a lo largo de los distintos
captulos.
En esta seccin se tratan los principales aspectos relativos a estos dos componentes, as como algunos
otros relativos a tolerancia a fallos y fiabilidad. Los componentes que conforman los nive les superiores del
sistema de E/S (sistemas de archivos y caches) se estudian en el Captulo 8.
7.5.1. Discos
Los discos son los dispositivos bsicos para llevar a cabo almacenamiento masivo y no voltil de datos.
Adems se usan como plataforma para el sistema de intercambio que usa el gestor de me moria virtual. Son
dispositivos electromecnicos (HARD DISK) u optomecnicos (CD-ROM y DVD), que se acceden a nivel
de bloque lgico por el sistema de archivos y que, actualmente, se agrupan en dos tipos bsicos, atendiendo
a la interfaz de su controlador:
Dispositivos SCSI (Small Computer System Inteiface), cuyos controladores ofrecen una interfaz
comn independientemente de que se trate de un disco, una cinta, un CD-ROM, etc. Un controlador
SCSI puede manejar hasta ocho discos y puede tener una memoria interna de varios MB.
Dispositivos IDE (Integrated Drive Electronics), que suelen usarse para conectar los discos en
todas las computadoras personales. Actualmente estos controladores se han extendido al sistema
EIDE, una mejora de IDE que tiene mayor velocidad de transferencia. Puede mane jar hasta cuatro
discos IDE. Es barato y muy efectivo.
Y a tres tipos bsicos atendiendo a su tecnologa de fabricacin:
Discos duros (Winchester). Dispositivos de gran capacidad compuestos por varias super ficies
magnetizadas y cuyas cabezas lectoras funcionan por efecto electromagntico. Actual mente su
capacidad mxima est en los 30 GB, pero se anuncian discos de 100 GB y ms.
Discos pticos. Dispositivos de gran capacidad compuestos por una sola superficie y cuyas
cabezas lectoras funcionan por lser. Actualmente su capacidad mxima est en los 700 MB. Hasta
hace muy poco, la superficie se agujereaba fsicamente y no se podan regrabar. Sin embargo,
actualmente existen discos con superficie magntica regrabables.
Discos extrables. Dispositivos de poca capacidad similares a un disco duro, pero cuyas cabezas
lectoras se comportan de forma distinta. En este tipo se engloban los disquetes (floppies), discos
ZIP y JAZZ.
Independientemente del tipo al que pertenezcan, las estructuras fsica y lgica de todos los discos son
muy similares, como se muestra a continuacin.
Todos los detalles expuestos en esta seccin, concernientes a la estructura fsica de los discos,
no son visibles desde el exterior debido a que el controlador se encarga de ofrecer una visin lgica del
dispositivo como un conjunto de bloques, segn se describe en la seccin siguiente.
Estructura lgica de los discos
Una vez que el disco ha sido formateado en el mbito fsico, se procede a crear su estructura lgica, que es
la realmente significativa para el sistema operativo. Como parte del formato fsico sc crea un sector
especial, denominado sector O, aunque no siempre es el primero del disco, que se reserva para incluir en l
la informacin de distribucin lgica del disco en subconjuntos denominados volmenes o particiones. Esta
informacin de guarda en una estructura denominada tabla de par ticiones (Fig. 7. 13). Una particin es una
porcin contigua de disco delimitada por un sector inicial y final. No existe ninguna limitacin ms para
crear particiones, si bien algunos sistemas operativos exigen tamaos de particin mnimos en algunos
casos. En el caso de la Figura 7.13, el dispositivo /dev/hda se ha dividido en dos particiones primarias
usando la utilidad fdisk de LINUX:
Una de intercambio (sivap), llamada /dev/hda
Una extendida (que tiene el sistema de archivos ext2 de LINUX), llamada /dev/hda2.
A su vez, la particin extendida se ha dividido en tres subparticiones lgicas /dev/hda5.
/dev/hda6 y /dev/hda7.
en memoria. Cuando ha terminado salta a la direccin O de memoria (donde puso el ncleo) y se arranca el
sistema operativo.
La segunda tarea importante que ) a ca ia operac de Yomia 6gko es ta detecc de os bloques lgicos
defectuosos y su inclusin en una lista de bloques defectuosos. Estos bloques no son asignados nunca por el
sistema de E/S, para lo que se marcan siempre como ocupados y no se liberan nunca. Ahora bien, cmo se
sabe que un bloque es defectuoso? Un bloque es defectuoso porque alguno de los sectores que lo componen
son defectuosos. Cmo se sabe que un sector es defectuoso? Pues se sabe porque cuando se efecta el
formateo fsico se crea una estructura de sector que contiene, al menos, tres elementos: cabecera, rea de
datos y cola. La cabecera incluye, entre otras cosas, el nmero de sector y un cdigo de paridad. La cola
suele incluir el nmero de sector y un cdigo corrector de errores (ECC, Error Correcting Code). Para
verificar el estado del sector se escribe una informacin y su ECC. A continuacin se lee y se recalcula su
ECC. Si el sector est defectuoso, ambos ECC sern distintos, lo que indica que el ECC es incapaz de
corregir los errores existentes en el sector. En ese instante, el bloque al que pertenece el sector se incluir en
la lista de bloques defectuosos.
La tercera tarea consiste en elaborar una lista de bloques de repuesto para el caso en que algn bloque del
dispositivo falle durante el tiempo de vida del mismo. Los discos estn sujetos a rozamiento, suciedad y
otros elementos que pueden daar su superficie. En este caso, algunos bloques que antes eran vlidos
pasarn a la lista de bloques defectuosos. Para evitar que se reduzca el tamao del dispositivo y para ocultar
este defecto en el mbito del controlador, se suplanta este bloque por uno de los de la lista de repuesto, que
a todos los efectos sustituye al anterior sin tener que modificar en absoluto el manejador.
7.5.2. El manejador de disco
El manejador de disco se puede ver como una caja negra que recibe peticiones de los sistemas de archivos y
del gestor de bloques y las traslada a un formato que entiende el controlador del dis positivo. Sin embargo,
el diseador de sistemas operativos debe entrar en los detalles del interior de un controlador y determinar
sus funciones principales, entre las que se incluyen:
1. Proceso de la peticin de E/S de bloques.
2. Traduccin del formato lgico a mandatos del controlador.
3. Insercin de la peticin en la cola del dispositivo, llevando a cabo la poltica de planifica cin de disco
pertinente (FIFO, SJF, SCAN, CSCAN, EDF, etc.).
4. Envo de los mandatos al controlador, programando el DMA.
5. Bloqueo en espera de la interrupcin de E/S.
6. Comprobacin del estado de la operacin cuando llega la interrupcin.
7. Gestin de los errores, si existen, y resolverlos si es posible.
8. Indicacin del estado de terminacin al nivel superior del sistema de E/S.
En LINUX y Windows NT (Fig. 7.8), el paso 1 se lleva a cabo en un manejador para la clase de dispositivo
disco, pero independiente del tipo de disco en particular, denominado manejador genrico. Sin embargo, el
paso 2 se lleva a cabo en un manejador dependiente del dispositivo, denominado manejador particular.
Cmo distingue el manejador el tipo de dispositivo y el dispositivo en particular? Los distingue porque en
la peticin de E/S viene informacin que lo indica. En el caso de UNIX y LINUX, por ejemplo, en cada
descriptor de archivo hay dos nmeros, denominados nmero primario (majornumber) y nmero secundario
(minornumber) [ 19861, que indican el tipo de dispositivo (p. ej.: disco) y el nmero de dispositivo (p. ej.: 3
para hda3). En Windows NT hay conceptos equivalentes.
A continuacin, se inserta la peticin en una cola de peticiones pendientes. Dependiendo del diseo del
manejador, existe una cola global para cada tipo de dispositivo, una cola para dispositivo particular o
ambas. De cualquier forma, una vez insertadas las peticiones en las colas, el manejador se encarga de
enviarlas al controlador cuando puede ejecutar operaciones porque este ltimo est libre y se bloquea en
espera de la interrupcin del dispositivo que indica el fin de la operacin de E/S. Esta operacin puede
terminar de forma correcta, en cuyo caso se indica al nivel superior eJ estado de terminacin, o de forma
incorrecta, en cuyo caso hay que analizar los errores para ver si se pueden resolver en el manejador o deben
comunicarse al nivel superior.
A continuacin, se estudia ms en detalle la estructura de un manejador de disco, as como las
tcnicas de planificacin de disco y de gestin de errores en el manejador de disco.
Estructura de un manejador de disco
Los manejadores de disco actuales estn compuestos en realidad por un conjunto de manejadores apilados,
como se muestra en la Figura 7.14, que refleja una estructura similar a la de los ma nejadores de disco de
LINUX [ 19961. En Windows NT esta tendencia es todava ms acusa da, ya que los manejadores estn
diseados como objetos y existe herencia de propiedades y com portamiento.
En cada nivel de la pila se lleva a cabo una funcionalidad especfica, que es ms dependiente del dispositivo
a medida que se profundiza en la jerarqua. En el caso de LINUX, el manejador de dispositivos de bloque
incluye operaciones genricas como open, close, read y write para dispositivos de tipo bloque. Este
manejador accede a dos mdulos:
Mdulo de planificacin, que se encarga de ordenar las peticiones de bloque a un dis positivo con poltica
CSCAN.
Manejador de disco, que se encarga de proporcionar una interfaz comn a todos los dis positivos y
demultiplexar las peticiones a cada tipo de dispositivo en particular.
Cuando le llega una operacin de cerrar un dispositivo, el planificador mira si tiene peticiones pendientes y
encola la peticin de desconexin del dispositivo hasta que hayan terminado. Una vez procesadas las
peticiones, el planificador las redirige al manejador de tipo de dispositivo ade cuado (IDE, CD-ROM, SCSI,
floppy, etc.), usando para ello el major number, que se encarga de llevar a cabo las operaciones especficas
para ese dispositivo y de enviarlas al dispositivo espe cfico, usando el minor number.
Uno de los manejadores de tipo de dispositivo existente en LINUX es el de dispositivos IDE, algunas de
cuyas operaciones se indican a continuacin:
bloc k_read, /* operacin de lectura de bloque */
block_write, /* operacin de escritura de bloque */
ide_octl, /* ioct1 */
ide_open, /* abrir */
ide_release, /* cerrar */
block_fsync, /* sincronizacin */
ide_check_media_change, /* comprobar el medio */
revalidate_disk, /* vuelca datos a disco */
ide_requests, /* llamadas del planificador */
Como se puede ver, el manejador proporciona muy pocas funciones de alto nivel. Adems de las tpicas de
lectura y escritura, merece la pena resaltar las de control del dispositivo (ide_ioctl), las de sincronizacin (bl
ock_f sync), las de comprobacin del medio (ide_check_medi a_change). Internamente, el manejador IDE
se estructura en dos niveles:
1. Nivel independiente de dispositivo, definido por algunas de las funciones de la interfaz.Estas
funciones acaban llamando a funciones internas de bajo nivel. Una de las ms un- portantes es la
autodeteccin de los desplazamientos de bloques en el disco a partir de los datos de la tabla de
particiones.
2. Nivel dependiente de dispositivo. Funciones de bajo nivel que se encargan de contactar con el
controlador del dispositivo. Algunas de estas funciones son:
ide_setup, que calcula los datos del disco a partir de la BIOS.
controller_busy, que comprueba si el controlador est libre u ocupado.
Status_OK, que comprueba el estado del disco.
ide_out, que emite los mandatos al controlador para escribir en el disco.
reset_controller y reset_hd, que reinician el controlador y el dispositivo respec tivamente.
recalibrate, que ordena al controlador recalibrar el motor del disco.
identify intr, que lleva a cabo el tratamiento de interrupcin.
El Programa 7.2 muestra una versin simplificada de la rutina del manejador IDE que escribe datos al
controlador del dispositivo. Observe que es similar al programa canal que se mostr en el Programa 7.1.
Consiste bsicamente en una operacin de inicio del controlador para cargar el registro de datos, la
direccin de memoria y el contador de datos. Un bucle que escribe los datos, incrementando el contador de
memoria, y una etapa de fin de escritura.
ascensor. El fundamento de la poltica bsica del ascensor, denominada SCAN, consiste en mover las
cabezas de un extremo a otro del disco, sirviendo todas las peticiones que van en ese sentido. Al volver se
sirven todas las del sentido contrario. Con esta poltica, el ejemplo anterior, en el que las cabezas estn en el
cilindro 6 con movimiento ascendente y las peticiones encoladas son 20, 2, 56 y 7, causara los siguientes
desplazamientos, asumiendo un disco de 70 cilindros:
Desplazamientos = (76) + (20 7) + (5620) +(70 56)+ (56 2)= 1 + 13 + 36 + 14 +
+54=118
Como se puede ver, el nmero de desplazamientos es menor que el FCFS, pero considerable mente mayor
que el SSF, debido fundamentalmente al ltimo desplazamiento que obliga a recorrer el disco entero. El
comportamiento de este algoritmo es ptimo cuando las peticiones se distribuyen uniformemente por todo
el disco, cosa que casi nunca ocurre. Por ello se optimiz para mejorar el tiempo de bsqueda aprovechando
una propiedad de los discos que tambin tienen los ascensores:
es mucho ms costoso subir un edificio parando que ir de un golpe de arriba abajo, o viceversa. E! ascensor
de las torres Sears de Chicago, por ejemplo, sube los 110 pisos sin parar en menos de 2 minutos, mientras
que parando dos o tres veces tarda ms de 10. Esto es lgico, porque los motores tienen que frenar, acelerar
y ajustarse al nivel de los pisos en que para el ascensor. En un disco pasa lo mismo: cuesta casi lo mismo ir
de un extremo a otro que viajar entre dos pistas. Por ello se puede mejorar el tiempo de respuesta del disco
usando una versin de la poltica del ascensor que viaje en un solo sentido. Con esta poltica, denominada
CSCAN (Cvclic Scan), las cabezas se mueven del principio al final del disco, atienden las peticiones en ese
sentido sin parar y vuelven al principio sin atender peticiones. Con esta poltica, el nmero de
desplazamientos del ejemplo anterior sera:
Desplazamientos = (76) + (207) + (5620) + (7056) + 70 + (20) = 1 + 13 + 36 +
+ 14+70+2= 136
Muy alto, como puede observar. Sin embargo el resultado es engaoso, ya que los desplaza mientos
realmente lentos, con paradas en cilindros, son 66. El tiempo de respuesta de este algoritmo es pues mucho
menor que el del SCAN y casi similar al de SSF. En dispositivos con muchas peticiones de E/S, esta
poltica tiene un rendimiento medio superior a las otras.
La poltica CSCAN todava se puede optimizar evitando el desplazamiento hasta el final del disco, es decir,
volviendo de la ltima peticin en un sentido a la primera en el otro. En el caso del ejemplo se ira de 56 a 2
con un desplazamiento rpido. Los desplazamientos del ejemplo con esta poltica, denominada LOOK [
1998], seran:
Desplazamientos = (76) + (207) + (5620) + (562) 1 + 13 + 36 + 54 = 104
donde los desplazamientos realmente lentos son 50.
El algoritmo CSCAN es el ms usado actualmente. Se usa en prcticamente todas las ver siones de UNIX,
LINUX y Windows, debido a que da el mejor rendimiento en sistemas muy cargados. Sin embargo, su
rendimiento depende mucho de la distribucin de las operaciones de E/S por el disco y de la situacin de
los bloques que se acceden con ms frecuencia. Por ello, suele ser una tcnica habitual en sistemas
operativos situar en el centro del disco aquellos datos que se acceden ms a menudo.
Estos algoritmos, sin embargo, no resuelven el problema de algunas aplicaciones modernas que requieren
un tiempo de respuesta determinado. Es el caso de las aplicaciones de tiempo real y multimedia, en las que
es importante realizar las operaciones de E/S antes de que termine un plazo
determinado (deadline). Para este tipo de sistemas se pueden usar otras tcnicas de planificacin, como la
poltica EDF (Earliest Deadline First), SCAN-EDF o SCAN-RT. Para tratar de satisfacer los requisitos de
sistemas de propsito general y los de multimedia se han propuesto algoritmos que optimi zan
simultneamente geometra y tiempo de respuesta, tales como Cello y 2-Q [ 20001.
Gestin de errores
Otra de las funciones bsicas del manejador de disco es gestionar los errores de EIS producidos en el
mbito del dispositivo. Estos errores pueden provenir de:
Las aplicaciones. Por ejemplo, peticin para un dispositivo o sector que no existe.
Del controlador. Por ejemplo, errores al aceptar peticiones o parada del controlador.
De los dispositivos. Por ejemplo, fallos transitorios o permanentes de lectura o escritura y fallos en la
bsqueda de pistas.
Algunos de ellos, como los errores transitorios, se pueden resolver en el manejador. Otros, como los errores
de aplicacin o fallos permanentes del dispositivo, no se pueden resolver y se deben comunicar al nivel
superior de E/S.
Los errores transitorios pueden ser debidos a la existencia de partculas de polvo en la su perficie del disco
cuando se efecta la operacin de E/S, a pequeas variaciones elctricas en la transmisin de datos o a
radiaciones que afecten a la memoria del controlador, entre otras cosas. Esos errores se detectan porque el
ECC de los datos no coincide con el calculado y se resuelven repitiendo la operacin de E/S. Si despus de
un cierto nmero de repeticiones no se resuelve el problema, el manejador concluye que la superficie del
disco est daada y lo comunica al nivel superior de E/S. Otro tipo de errores transitorios tiene su origen en
fallos de bsqueda debidos a que las cabezas del disco estn mal calibradas. Se puede intentar resolver este
problema recalibrando el disco, lo que puede hacerse mediante la operacin del controlador reca1bra
Los errores permanentes se tratan de distintas formas. Ante errores de aplicacin el ma nejador tiene poco
que hacer. Si se pide algo de un dispositivo o bloque que no existe, lo nico que se puede hacer es devolver
un error. Ante errores del controlador, lo nico factible es tratar de reiniciar el controlador mediante sus
instrucciones especficas para ello. Si al cabo de un cierto nmero de repeticiones no se resuelve el
problema, el manejador concluye que la superficie del disco o el controlador estn daados y lo comunica
al nivel superior de E/S. Ante errores permanen tes de la superficie del dispositivo, lo nico que se puede
hacer es sustituir el bloque por uno de repuesto, si existe una lista de bloques de repuesto, y comunicar el
error al nivel superior.
por el sistema operativo que muestra una interfaz de disco similar al de cualquier disco de dis positivo
secundario. El manejador de esos dispositivos incluye llamadas open, read, write, etc., a nivel de bloque y
se encarga de traducir los accesos del sistema de archivos a posiciones de memoria dentro del disco RAM.
Las operaciones de transferencia de datos son copias de memoria. No tienen ningn hardware especial
asociado y se implementan de forma muy sencilla. Pero tienen un problema bsico: si falla la alimentacin
se pierden todos los datos almacenados.
Los discos slidos son sistemas de almacenamiento secundario no voltiles fabricados co locando chips de
memoria RAM en placas. Las placas se conectan al bus del sistema y se acceden a la misma velocidad que
la memoria principal (nanosegundos). Hay una diferencia fundamental entre estos sistemas y los discos
RAM: tienen hardware, y puede que un controlador, propio. La interfaz sigue siendo la de un dispositivo de
bloques, encargndose el manejador de traducir pe ticiones de bloque a memoria. Las transferencias, sin
embargo, se pueden convertir en operaciones de lectura o escritura a puertos, dependiendo de la instalacin
del disco slido.
Los discos en chips son la ltima tendencia en discos slidos implementados con memoria. Combinan
memoria flash de alta densidad y una interfaz sencilla, proyectada en memoria o a travs de puertos, para
proporcionar almacenamiento secundario en un chip que se parece a una memoria ROM de 32 pines.
Usando estos sistemas se pueden crear discos de estado slido con almacena miento no voltil con una
capacidad de hasta 256 MB. Adems, estos chips se pueden combinar en placas para proporcionar varios
GB de capacidad, como por ejemplo la PCM-3840 de Advantech. Una vez instalados en el sistema, se ven
como un objeto ms del sistema de E/S que se manipula a travs del manejador correspondiente, por lo que
proporciona las mismas operaciones que cualquier otro dispositivo de almacenamiento secundario. De tal
forma que cuando se crea sobre el disco un sistema de archivos, se puede montar en el rbol de nombres sin
ningn problema.
ficiente, hay que modificar el manejador, o el gestor de bloques, para tener almacenamiento fiable, de
forma que las operaciones de escritura y de lectura sean fiables.
Una escritura fiable supone escribir en ambos discos con xito. Para ello se escribe primero en un disco.
Cuando la operacin est completa, se escribe en el segundo disco. Slo si ambas tienen xito se considera
que la operacin de escritura ha tenido xito. En caso de que una de las dos escrituras falle, se considera un
error parcial. Si ambas fallan, se considera que hay fallo total del almacenamiento estable.
En el caso de la lectura fiable, basta con que uno de los dispositivos est disponible. Ahora bien, si se
quiere verificar el estado de los datos globales, habr que leer ambos dispositivos y comparar los datos. En
caso de error, habr que elegir alguno de ellos segn los criterios definidos por el sistema o la aplicacin.
Este tipo de redundancia tiene dos problemas principales:
Desperdicia el 50 por 100 del espacio de almacenamiento.
Reduce mucho el rendimiento de las operaciones de escritura. Ello se debe a que una es critura no se
puede confirmar como vlida hasta que se ha escrito en ambos discos espejo, lo
que significa dos operaciones de escritura.
Sin embargo, tiene la ventaja de ser una tcnica barata y sencilla de implementar. Adems, si se lee
simultneamente de ambos discos, se puede incrementar mucho el rendimiento del sistema. En Windows
NT, por ejemplo, existen manejadores para proporcionar almacenamiento estable en el mbito del sistema y
de forma transparente al usuario.
Dispositivos RAID
Una tcnica ms actual para proporcionar fiabilidad y tolerancia a fallos consiste en usar dispositi vos
RAID (Redundant Array of Independent Disks) a nivel hardware [ 19951 o software EChen, 1995]. Estos
dispositivos usan un conjunto de discos para almacenar la informacin y otro conjunto para almacenar
informacin de paridad del conjunto anterior (Fig. 7.15). En el mbito fsico se ven como un nico
dispositivo, ya que existe un nico controlador para todos los discos. Este controlador se encarga de
reconfigurar y distribuir los datos como es necesario de forma transparente al sistema de FIS.
Se han descrito hasta siete niveles de RAID, pero solamente los cinco primeros estn realmen te operativos.
Estos niveles son los siguientes:
RAID 1. Son discos espejo en los cuales se tiene la informacin duplicada. Tiene los pro blemas y las
ventajas del almacenamiento estable.
RAID 2. Distribuye los datos por los discos, repartindolos de acuerdo con una unidad de distribucin
definida por el sistema o la aplicacin. El grupo de discos se usa como un disco lgico, en el que se
almacenan bloques lgicos distribuidos segn la unidad de reparto.
RAID 3. Reparte los datos a nivel de bit por todos los discos. Se puede aadir bits con cdigos correctores
de error. Este dispositivo exige que las cabezas de todos los discos estn
sincronizadas, es decir, que un nico controlador controle sus movimientos.
RAID 4. Reparto de bloques y clculo de paridad para cada franja de bloques, que se al macena en un
disco fijo. En un grupo de cinco discos, por ejemplo, los cuatro primeros seran de datos y el quinto de
paridad. Este arreglo tiene el problema de que el disco de paridad se convierte en un cuello de botella y un
punto de fallo nico.
RAID 5. Reparto de bloques y paridad por todos los discos de forma cclica. Tiene la ventaja de la
tolerancia a fallos sin los inconvenientes del RAID 4. Actualmente existen mltiples
dispositivos comerciales de este estilo y son muy populares en
fiabilidad.
La Figura 7.15 muestra un dispositivo de tipo RAID 5, donde toda la paridad se reparte por todos los discos
de forma cclica. La paridad se calcula por hardware en el controlador haciendo el X-OR de los bloques de
datos de cada franja. Esto conlieva problemas si las escrituras no llenan todos los discos de datos (escrituras
pequeas), ya que hay que leer los datos restantes para calcular la paridad. Sin embargo, los RAID
proporcionan un gran ancho de banda para lecturas y escrituras grandes (Prestaciones 7.1).
Los sistemas de almacenamiento secundario estn bien para acceso rpido a datos y programas, sin
embargo tienen tres problemas serios:
1. Poca capacidad.
2. Alto coste.
3. No se pueden extraer de la computadora.
La tecnologa de almacenamiento terciario no ha evolucionado mucho en los ltimos aos. Los dispositivos
de eleccin son los CD-ROM, los DVD y, sobre todo, las cintas magnticas. En cuanto al soporte usado, se
usan jukeboxes y sistemas robotizados para las cintas.
Los jukeboxes son torres de CD-ROM o DVD similares a las mquinas de msica que se ven en algunos
bares y salas de baile. Cuando se quiere leer algo, las cabezas lectoras suben o bajan por la torre,
seleccionan el disco adecuado y lo leen. Este mtodo es adecuado para bases de datos medianas o centros
de distribucin de msica o de pelculas. Sin embargo, estos dispositivos se usan principalmente como
discos WORM ( Write Once ReadMany), lo que significa que es difcil o costoso rescribir informacin
sobre ellos. Adems, tienen poca capacidad, ya que un CD-ROM almacena 700 MB y un DVD unos 18
GB.
Hasta ahora, la alternativa como sistema de almacenamiento son las cintas magnticas, que son ms baratas,
igual de rpidas y tienen ms capacidad (Tabla 7.1). Estas cintas se pueden mani pular de forma manual o
mediante robots que, en base a cdigos de barras, las almacenan una vez escritas y las colocan en las
cabezas lectoras cuando es necesario.
Un buen ejemplo de sistema de almacenamiento terciario lo constituye el existente en el CERN (Centro
Europeo para la Investigacin Nuclear), donde los datos de los experimentos se almacenan en cintas
magnticas que controlan un sistema de almacenamiento controlado por un robot. Cuando se va a procesar
un experimento, sus datos se cargan en el almacenamiento se cundario. La gran ventaja de este sistema es
que el un nico robot puede manipular un gran nmero
de cintas con pocas unidades lectoras. Su gran desventaja es que los datos no estn inmediatamente
disponibles para los usuarios, que pueden tener que esperar segundos u horas hasta que se instalan en el
sistema de almacenamiento secundario.
Una tecnologa novedosa para el almacenamiento secundario y terciario la constituyen las SAN (Storage
Area Networks), que son redes de altas prestaciones a las que se conectan directa mente dispositivos de
almacenamiento. Presentan una interfaz uniforme para todos los dispositivos y proporcionan un gran ancho
de banda. Actualmente empiezan a ser dispositivos de eleccin para sistemas de almacenamiento
secundarios y terciarios de altas prestaciones.
En sistemas de altas prestaciones, como el descrito ms adelante, se usan servidores de EIS
muy complejos, incluidos multiprocesadores, para crear sistemas de almacenamiento terciario cuyo tiempo
de respuesta es muy similar a los sistemas de almacenamiento secundario.
Desde el punto de vista del sistema operativo, el principal problema de estos sistemas de almacena miento
terciario es que se crea una jerarqua de almacenamiento secundario y terciario, por la que deben viajar los
objetos de forma automtica y transparente al usuario. Adems, para que los usua rios no estn
descontentos, se debe proporcionar accesos con el mismo rendimiento del nivel ms rpido y el coste
aproximado del nivel ms bajo.
La existencia de un sistema de almacenamiento terciario obliga al diseador del sistema opera tivo a tomar
cuatro decisiones bsicas relacionadas con este sistema:
Qu estructura de sistema de almacenamiento terciario es necesaria?
Cmo, cundo y dnde se mueven los archivos del almacenamiento secundario al terciario?
Cmo se localiza un archivo en el sistema de almacenamiento terciario?
Qu interfaz de usuario va a estar disponible para manejar el sistema de almacenamiento terciario?
Los sistemas de almacenamiento terciario existentes en los sistemas operativos actuales, tales como UNIX,
LINUX y Windows, tienen una estructura muy sencilla consistente en un nivel de dispositivos extrables,
tales como cintas, disquetes o CD-ROM. Estos dispositivos se tratan exacta mente igual que los
secundarios, exceptuando el hecho de que los usuarios o administradores deben insertar los dispositivos
antes de trabajar con ellos. Solamente en grandes centros de datos se pue den encontrar actualmente
sistemas de almacenamiento terciario con una estructura compleja, como la de HPSS que se estudia en la
seccin siguiente.
La cuestin de la migracin de archivos del sistema secundario al terciario, y viceversa, depende
actualmente de las decisiones del administrador (en el caso de las copias de respaldo) o de los propios
usuarios (en el caso de archivos personales). En los sistemas operativos actuales no se define ninguna
poltica de migracin a sistemas terciarios, dado que estos sistemas pueden no existir en muchas
computadoras. Sin embargo, se recomienda a los administradores tener una plani ficacin de migracin
para asegurar la integridad de los datos del sistema secundario y para migrar aquellos archivos que no se
han usado durante un perodo largo de tiempo.
La poltica de migracin define las condiciones bajo las que se copian los datos de un nivel de la jerarqua
a otro, u otros. En cada nivel de la jerarqua se puede aplicar una poltica distinta. Adems, en el mismo
nivel se puede aplicar una poltica distinta dependiendo de los datos a migrar. Imagine que se quiere mover
un archivo de usuario cuya cuenta de acceso a la computadora se ha cerrado. Las posibilidades de volver a
acceder a estos datos son pequeas, por lo que lo ms proba
Digitalizacin realizada con propsito acadmico
390 Sistemas Operativos. Una visin aplicada
ble es que la poltica los relegue al ltimo nivel de la jerarqua de EIS (p. ej.: cintas extrables). Imagine
ahora que se quiere migrar un archivo de datos del sistema que se accede con cierta frecuencia, lo ms
probable es que la poltica de migracin decida copiarlo a un dispositivo de alta integridad y disponibilidad,
como un RAID. En los sistemas automatizados, como HPSS, hay mo nitores que rastrean los archivos del
sistema de almacenamiento secundario y crean estadsticas de uso de los mismos. Habitualmente, los
archivos usados son los primeros candidatos para la poltica de migracin.
Cmo y dnde migrar los archivos depende mucho de la estructura del sistema de almacena miento
terciario. Existen dos opciones claras para mantener los archivos en almacenamiento terciario:
Usar dispositivos extrables y mantenerlos o/j-line.
Usar dispositivos extrables o no, pero mantenerlos en-une.
En el primer caso, los archivos se copian en el sistema terciario y se eliminan totalmente del secundario. En
el segundo se copian en el sistema terciario pero se mantienen enlaces simblicos desde el sistema
secundario, de forma que los archivos estn automticamente accesibles cuando se abren. Un caso especial
lo constituyen las copias de respaldo, en las que se copian los datos a un terciario extrable por cuestiones
de seguridad y no de prestaciones. En este caso, los datos siguen estando completos en el sistema
secundario de almacenamiento. Con cualquiera de las opciones, es habitual comprimir los datos antes de
copiarlos al sistema terciario, para aumentar la capacidad del mismo. La compresin se puede hacer
transparente a los usuarios incorporando herramientas de compresin al proceso de migracin.
La localizacin de archivos en un sistema de almacenamiento terciario es un aspecto muy importante de
los mismos. En un sistema operativo de una instalacin informtica convencional, lo normal es que el
usuario deba preguntar al administrador del sistema por ese archivo si ste lo ha migrado a un sistema
terciario extrable, ya que no estar en el almacenamiento secundario. En el caso de que el sistema terciario
sea capaz de montar dinmicamente los dispositivos extrables (robots de cintas,jukehoxes, etc.), se pueden
mantener enlaces desde el sistema secundario al ter ciario, por lo que se migrar el archivo
automticamente (en cuestin de segundos). Un sistema terciario de altas prestaciones como HPSS intenta
que los usuarios no puedan distinguir si los archivos estn en el sistema secundario o terciario, tanto por la
transparencia de nombres COfl1() por el rendimiento. Para ello usa servidores de nombres, localizadores de
archivos y, si es necesario, bases de datos para localizar los archivos.
La interfaz de usuario de los sistemas de almacenamiento terciario puede ser la misma que la del sistema
secundario, es decir, las llamadas al sistema de POSIX o Win32 para manejar dispositi vos de EIS. Sin
embargo, es habitual que los sistemas operativos incluyan mandatos, tales conio el tar de UNIX o el backup
de Windows, para llevar a cabo copias de archivos en dispositivos extrables de sistema terciario. Por
ejemplo:
Hace una copia de los datos del usuario jess al dispositivo de cinta rrntO de una computado ra UNIX.
Igualmente:
Hace una copia de todos los sistemas de archivos de una computadora UNIX al dispositivo de cinta rmt0.
Estos mandatos permiten hacer copias totales de tos datos o parciales, es decir, copiar slo los archivos
modificados desde la copia anterior. En los sistemas de almacenamiento terciario de alto rendimiento, como
HPSS, se encuentran interfaces muy sofisticadas para configurar y manipular los datos, como se muestra a
continuacin.
El sistema de almacenamiento de altas prestaciones (HPSS, High Performance Storage Svstern) [ 19991 es
un sistema de E/S diseado para proporcionar gestin de almacenamiento jerr quico, secundario y
terciario, y servicios para entornos con necesidades de almacenamiento me dianas y grandes. Est pensado
para ser instalado en entornos de EIS con alto potencial de creci miento y muy exigentes en trminos de
capacidad, tamao de archivos, velocidad de transferencia, nmero de objetos almacenados y nmero de
usuarios. Se distribuye como parte de IJ(I (Lfls trihuted Computing Environment).
Uno de los objetivos de diseo primarios de HPSS fue mover los archivos grandes de dis positivos de
almacenamiento secundario a sistemas terciarios, que pueden ser incluso sistemas de E/S paralelos, a
velocidades mucho ms altas que los sistemas de archivo tradicionales (cintas. jukehoxes. etc.), de forma
ms fiable y totalmente transparente al usuario. El resultado del diseo fue un sistema de almacenamiento
de altas prestaciones con las siguientes caractersti cas (Fig. 7.16):
Arquitectura distribuida a travs de redes, siempre que es posible, para proporcionar escala bilidad y
paralelismo.
Jerarquas mltiples de dispositivos que permiten incorporar todo tipo de dispositivos ac tuales (RAID,
SAN, jukebox, cintas, etc.) y experimentar con medios de almacenamiento nuevos. Los dispositivos se
agrupan en clases, cada una de las cuales tiene sus propios servicios. Existen servicios de migracin entre
clases para mover archivos de una clase de dispositivo a otra.
Transferencia de datos directa entre los clientes y los dispositivos de almacenamiento. sin copias
intermedias de memoria. Para ello se usan reubicadores de archivos que se encargan
de las transferencias de archivos de forma distribuida.
Velocidad de transferencia muy alta, debido a que los reubicadores extraen los datos directa mente de los
dispositivos y los transmiten a la velocidad de stos (p. ej.: 5() MB/segundo
para algunos RAID).
Interfaz de programacin con acceso paralelo y secuencial a los dispositivos de E/S. Diseo interno
multithread que usa un protocolo FTP (File Tran,sfer Protocol) paralelo.
Uso de componentes estandarizados que le permiten ejecutar sobre POSIX sin ninguna mo- dificacin.
Est escrito en ANSI C e incorpora varios estndares del IEEE para sistemas de
almacenamiento.
Uso de transacciones para asegurar la integridad de los datos y de Kerberos (Captulo 9) como sistema de
seguridad.
Estructura de HPSS
La Figura 7. 16 muestra una estructura muy simplificada de HPSS. Bsicamente se pueden distin guir cinco
mdulos principales en el sistema de almacenamiento terciario:
Interfaz. Utilidades para administrar y controlar el sistema de almacenamiento y para de finir polticas de
actuacin.
Servidor de nombres. Traduce nombres de usuario a identificadores de objetos HPSS, tales como
archivos o directorios. Tambin proporciona control de acceso a los objetos.
Localizador de archivos. Una vez resuelto el nombre, este mdulo se encarga de localizar el archivo
fsicamente mediante los descriptores proporcionados por el sistema de nombres.
Reubicador de archivos. Se encarga de la transferencia de datos desde el origen al destino. Interacciona
con el servidor de nombres y el localizador de archivos para determinar si el origen y el destino son
correctos. Usa un modelo de trabajadores, en el que se crea un trabajador para cada transferencia de datos,
que realiza directamente entre el dispositivo origen y el destino.
Gestor del sistema de almacenamiento terciario. Proporciona la jerarqua de objetos de
almacenamiento, traduce las peticiones de la interfaz de usuario a sus correspondientes dis positivos fsicos
y proporciona toda la funcionalidad de gestin del sistema de E/S, incluyendo instalacin, configuracin,
terminacin y accesos a dispositivos. Incluye tambin facilidades de monitorizacin que permiten conocer
la situacin del sistema de almacenamiento y la
dpon de recursos en las d clases de d Por incluye fac dades de acceso a los datos.
El sistema de almacenamiento fsico incluye volmenes fsicos y virtuales que pueden estar en
cualquier tipo de soporte (discos, RAID, cintas, robots de cintas, jukeboxes, SAN, etc.). Los vo lmenes
virtuales son internos a HPSS y se forman agrupando varios volmenes fsicos bajo una
misma entidad, sobre la cual se reparten los datos. Sobre ellos se proyectan los segmentos de
almacenamiento, entidades asociadas a una clase de almacenamiento y con localizacin de archivos
transparentes. Estas clases de almacenamiento se organizan en jerarquas a travs de las cuales pueden
migrar los archivos de acuerdo con la disponibilidad de recursos y la poltica de migracin definida.
7.7. EL RELOJ
oscilaciones producidas por un cristal de cuarzo, genera peridicamente interrupciones (a cada una de estas
interrupciones del reloj se las suele denominar en ingls tick). Este elemento est conectado generalmente a
una lnea de interrupcin de alta prioridad del procesador debido a la importancia de los eventos que
produce.
La mayora de estos temporizadores permiten programar su frecuencia de interrupcin. Tpi camente
contienen un registro interno que acta como un contador que se decrementa por cada oscilacin del cristal
generando una interrupcin cuando llega a cero. El valor que se carga en este contador determina la
frecuencia de interrupcin del temporizador, que se comporta, por tanto, como un divisor de frecuencia.
Adems de ser programable la frecuencia de interrupcin, estos dispositivos frecuentemente presentan
varios modos de operacin seleccionables. Suelen poseer un modo de un solo disparo en el que cuando el
contador llega a cero y se genera la interrupcin, el temporizador se desactiva hasta que se le reprograme
cargando un nuevo valor en el contador. Otro tpico modo de operacin es el de onda cuadrada en el que
al llegar a cero el contador y generar la interrupcin el propio temporizador vuelve a recargar el valor
original en el contador sin ninguna intervencin externa.
Hay que resaltar que generalmente un circuito de este tipo incluye varios temporizadores independientes, lo
que permite, en principio, que el sistema operativo lo use para diferentes labores. Sin embargo, en muchos
casos no todos ellos son utilizables para esta misin ya que no estn conectados a lneas de interrupcin del
procesador.
Un ejemplo tpico de este componente es el circuito temporizador 8253 que forma parte de un PC estndar.
Tiene tres temporizadores pero slo uno de ellos est conectado a una lnea de in terrupcin (en concreto, a
la lnea IRQ nmero O). Los otros estn destinados a otros usos. Por ejemplo, uno de ellos est conectado al
altavoz del equipo. La frecuencia de entrada del circuito es de 1,193 MHz. Dado que utiliza un contador
interno de 16 bits, el temporizador se puede programar en el rango de frecuencias desde 18,5 Hz (con el
contador igual a 65536) hasta 1,193 MHz (con el contador igual a 1). Cada temporizador puede
programarse de forma independiente presentando diversos modos de operacin, entre ellos, el de un solo
disparo y el de onda cuadrada.
Otro elemento hardware presente en prcticamente la totalidad de los equipos actuales es un reloj
alimentado por una batera (denominado en ocasiones reloj CMOS) que mantiene la fecha y la hora cuando
la mquina est apagada.
Dado que la labor fundamental del hardware del reloj es la generacin peridica de interrupciones, el
trabajo principal de la parte del sistema operativo que se encarga del reloj es el manejo de estas
interrupciones. Puesto que, como se analizar a continuacin, las operaciones asociadas al trata miento de
una interrupcin de reloj pueden implicar un trabajo considerable, es preciso establecer un compromiso a la
hora de fijar la frecuencia de interrupcin del reloj de manera que se consiga una precisin aceptable en la
medicin del tiempo, pero manteniendo la sobrecarga debida al trata miento de las interrupciones en unos
trminos razonables. Un valor tpico de frecuencia de interrup cin, usado en muchos sistemas UNIX, es de
100 Hz (o sea, una interrupcin cada 10 ms).
Hay que resaltar que, dado que las interrupciones del reloj son de alta prioridad, mientras se procesan no se
aceptan interrupciones de otros dispositivos menos prioritarios. Se debe, por tanto. minimizar la duracin
de la rutina de tratamiento para asegurar que no se pierden interrupciones de menor prioridad debido a la
ocurrencia de una segunda interrupcin de un dispositivo antes de que se hubiera tratado la primera. Para
evitar esta posibilidad, muchos sistemas operativos dividen el trabajo asociado con una interrupcin de reloj
en dos partes:
Gestin de temporizadores
En numerosas ocasiones un programa necesita esperar un cierto plazo de tiempo antes de realizar una
determinada accin. El sistema operativo ofrece servicios que permiten a los programas es tablecer
temporizaciones y se encarga de notificarles cuando se cumple el plazo especificado (en caso de UNIX
mediante una seal). Pero no slo los programas de usuario necesitan este meca nismo, el propio sistema
operativo tambin lo requiere. El mdulo de comunicaciones del sistema operativo, por ejemplo, requiere
establecer plazos de tiempo para poder detectar si un mensaje se pierde. Otro ejemplo es el manejador del
disquete que, una vez arrancado el motor del mismo, requiere esperar un determinado tiempo para que la
velocidad de rotacin se estabilice antes de poder acceder al dispositivo.
Dado que en la mayora de los equipos existe un nico temporizador (o un nmero muy reducido de ellos),
es necesario que el sistema operativo lo gestione de manera que sobre l puedan crearse los mltiples
temporizadores que puedan requerirse en el sistema en un determinado momento.
El sistema operativo maneja generalmente de manera integrada tanto los temporizadores de los procesos de
usuario como los internos. Para ello mantiene una lista de temporizadores activos. En cada elemento de la
lista se almacena tpicamente el nmero de unidades de tiempo (para facilitar el trabajo, generalmente se
almacena el nmero de interrupciones de reloj requeridas) que falta para que se cumpla el plazo y la
funcin que se invocar cuando ste finalice. As, en el ejemplo del disquete se corresponder con una
funcin del manejador de dicho dispositivo. En el caso de una temporizacin de un programa de usuario, la
funcin corresponder con una rutina del sistema operativo encargada de mandar la notificacin al proceso
(en UNIX, la seal).
Existen diversas alternativas a la hora de gestionar la lista de temporizadores. Una organiza cin tpica
consiste en ordenar la lista de forma creciente segn el tiempo que queda por cumplirse el plazo de cada
temporizador. Adems, para reducir la gestin asociada a cada interrupcin, el plazo de cada temporizador
se guarda de forma relativa a los anteriores en la lista. As se almacenan las unidades que quedarn
pendientes cuando se hayan cumplido todas las temporizaciones corres pondientes a elementos anteriores
de la lista. Con este esquema se complica la insercin, puesto que es necesario buscar la posicin
correspondiente en la lista y reajustar el plazo del elemento situado a
continuacin de la posicin de insercin. Sin embargo, se agiliza el tratamiento de la interrupcin 1 7.8 ya
que slo hay que modificar el elemento de cabeza, en lugar de tener que actualizar todos los
temporizadores.
En ltimo lugar hay que resaltar que generalmente la gestin de temporizadores es una de las operaciones
que no se ejecutan directamente dentro de la rutina de interrupcin sino, como se coment previamente, en
una rutina de menor prioridad. Esto se debe a que esta operacin puede conllevar un tiempo considerable
por la posible ejecucin de las rutinas asociadas a todos aquellos temporizadores que se han cumplido en la
interrupcin de reloj en curso.
Contabilidad y estadsticas
Puesto que la rutina de interrupcin se ejecuta peridicamente, desde ella se puede realizar un muestreo de
diversos aspectos del estado del sistema llevando a cabo funciones de contabilidad y estadstica. Es
necesario resaltar que, dado que se trata de un muestreo del comportamiento de una determinada variable y
no de un seguimiento exhaustivo de la misma, los resultados no son exactos, aunque si la frecuencia de
interrupcin es suficientemente alta, pueden considerarse aceptables.
Dos de las funciones de este tipo presentes en la mayora de los sistemas operativos son las siguientes:
Contabilidad del uso del procesador por parte de cada proceso.
Obtencin de perfiles de ejecucin.
Por lo que se refiere a la primera funcin, en cada interrupcin se detecta qu proceso est ejecutando y a
ste se le carga el uso del procesador en ese intervalo. Generalmente, el sistema operativo distingue a la
hora de realizar esta contabilidad si el proceso estaba ejecutando en modo usuario o en modo sistema.
Algunos sistemas operativos utilizan tambin esta informacin para implementar temporizadores virtuales,
en los que el reloj slo corre cuando est ejecutando el proceso en cuestin, o para poder establecer
lmites en el uso del procesador.
Con respecto a los perfiles, se trata de obtener informacin sobre la ejecucin de un programa que permita
determinar cunto tiempo tarda en ejedutarse cada parte del mismo. Esta informacin permite que el
programador detecte los posibles cuellos de botella del programa para poder as optimizar su ejecucin.
Cuando un proceso tiene activada esta opcin, el sistema operativo toma una muestra del valor del contador
de programa del proceso cada vez que una interrupcin en $ cuentra que ese proceso estaba ejecutando.
La acumulacin de esta informacin durante toda la ejecucin del proceso permite que el sistema operativo
obtenga una especie de histograma de las direcciones de las instrucciones que ejecuta el programa.
7.8. EL TERMINAL
Se trata de un dispositivo que permite al usuario comunicarse con el sistema y que est presente en todos
los sistemas de propsito general actuales. Est formado tpicamente por un teclado que permite introducir
informacin y una pantalla que posibilita su visualizacin.
Hay una gran variedad de dispositivos de este tipo, aunque en esta seccin se analizan los dos ms tpicos:
los terminales serie y los proyectados en memoria. Por lo que se refiere al tipo de informacin usada por el
terminal, esta exposicin se centra en la informacin de tipo texto, de jando fuera de la misma el
tratamiento de informacin grfica, puesto que la mayora de los sis temas operativos no dan soporte a la
misma.
En primer lugar se expondr cmo es el modo de operacin bsico de un terminal con indepen dencia del
tipo del mismo. A continuacin, se analizarn las caractersticas hardware de los termi nales. Por ltimo, se
estudiarn los aspectos software identificando las labores tpicas de un maneja dor de terminal.
7.8.1. Modo de operacin del terminal
El modo de operacin bsico de todos los terminales es bastante similar a pesar de su gran diversi dad. La
principal diferencia est en qu operaciones se realizan por hardware y cules por software. En todos ellos
existe una relativa independencia entre la entrada y salida.
Entrada
Cuando el usuario pulsa una tecla en un terminal, se genera un cdigo de tecla que la identifica. Este cdigo
de tecla debe convertirse en el carcter ASCII correspondiente teniendo en cuenta el estado de las teclas
modificadoras (tpicamente, Control, Shift y Alt). As, por ejemplo, si est pulsada la tecla Shift al teclear la
letra a, el carcter resultante ser A.
Salida
Una pantalla de vdeo est formada por una matriz de pixels. Asociada a la misma existe una memoria de
vdeo que contiene informacin que se visualiza en la pantalla. El controlador de vdeo es el encargado de
leer la informacin almacenada en dicha memoria y usarla para refrescar el contenido de la pantalla con la
frecuencia correspondiente. Para escribir algo en una determinada posicin de la pantalla slo es necesario
modificar las direcciones de memoria de vdeo correspon dientes a esa posicin.
Cuando un programa solicita escribir un determinado carcter ASCII en la pantalla, se debe obtener el
patrn rectangular que representa la forma de dicho carcter, lo que depender del tipo de fuente de texto
utilizado. El controlador visualizar dicho patrn en la posicin correspondiente de la pantalla.
Adems de escribir caracteres, un programa necesita realizar otro tipo de operaciones, tales
como borrar la pantalla o mover el cursor a una nueva posicin. Este tipo de operaciones estn
generalmente asociadas a ciertas secuencias de caracteres.
Cuando un programa escribe una de estas secuencias, no se visualiza informacin en la pan talla sino que se
lleva a cabo la operacin de control asociada a dicha secuencia. Tpicamente, por razones histricas, estas
secuencias suelen empezar por el carcter Escape.
Terminales serie
En este tipo de terminales, como se puede apreciar en la Figura 7.18, el terminal se presenta ante el resto
del sistema como un nico dispositivo conectado, tpicamente a travs de una lnea serie RS-232. al
controlador correspondiente denominado UART (Universal Asvnchronous Receiver Transmitter,
Transmisor-Receptor Universal Asncrono). Adems de la pantalla y el teclado, el terminal tiene algn tipo
de procesador interno que realiza parte de la gestin del terminal y que permite tambin al usuario
configurar algunas de las caractersticas del mismo. Para poder dialogar con el terminal, se deben
programar diversos aspectos de la UART tales como la velocidad de transmisin o el nmero de bits de
parada que se usarn en la transmisin.
Al igual que ocurre con los terminales proyectados en memoria, la entrada se gestiona me diante
interrupciones. Cuando se pulsa una tecla, el terminal enva a travs de la lnea serie el carcter pulsado. La
UART genera una interrupcin al recibirlo. A diferencia de los terminales proyectados en memoria, el
carcter que recoge de la UART ya es el cdigo ASCII de la tecla pulsada puesto que el procesador del
terminal se encarga de pasar del cdigo de la tecla al cdigo ASCII y de comprobar el estado de las teclas
modificadoras.
Para la visualizacin de informacin en este tipo de terminales se debe cargar el cdigo ASCII del carcter
deseado en un registro de la UART y pedir a sta que lo transmita. Una vez
transmitido, lo que puede llevar un tiempo considerable debido a las limitaciones de la transmisin serie, la
UART produce una interrupcin para indicar este hecho. Por lo que se refiere al terminal, cuando recibe el
carcter ASCII se encarga de obtener su patrn y visualizarlo en la pantalla, manejando asimismo las
secuencias de escape.
Software de entrada
Como se coment antes, la lectura del terminal est dirigida por interrupciones. En el caso de un terminal
proyectado en memoria, el manejador debe realizar ms trabajo ya que debe convertir el
cdigo de tecla en el cdigo ASCII correspondiente. Como contrapartida, este esquema propor ciona ms
flexibilidad al poder ofrecer al usuario la posibilidad de configurar esta traduccin a su conveniencia.
Una caracterstica que debe proporcionar todo manejador de terminal es el tecleado anti cipado (en
ingls, tvpe ahead). Esta caracterstica permite que el usuario teclee informacin antes de que el programa
la solicite, lo que proporciona al usuario una forma de trabajo mucho ms cmoda. Para implementar este
mecanismo, se requiere que el manejador use una zona de alma cenamiento intermedio de entrada para
guardar los caracteres tecleados hasta que los solicite un proceso.
Otro aspecto importante es la edicin de los datos de entrada. Cuando un usuario teclea unos datos puede,
evidentemente, equivocarse y se requiere, por tanto, un mecanismo que le permita corregir el error
cometido. Surge entonces la cuestin de quin se debe encargar de proporcionar esta funcin de edicin de
los datos introducidos. Se presentan, al menos, dos alternativas. Una posibilidad es que cada aplicacin se
encargue de realizar esta edicin. La otra alternativa es que sea el propio manejador el que la lleva a cabo.
Para poder analizar estas dos opciones es necesario tener en cuenta los siguientes factores:
La mayora de las aplicaciones requieren unas funciones de edicin relativamente sencillas.
No parece razonable hacer que cada programa tenga que encargarse de tratar con la edicin de su
entrada de datos. Un programador desea centrarse en resolver el problema que le concierne y, por
tanto, no quiere tener que ocuparse de la edicin.
Es conveniente que la mayora de las aplicaciones proporcionen al usuario la misma forma de
editar la informacin.
Hay aplicaciones, como por ejemplo los editores de texto, que requieren unas funciones de edicin
complejas y sofisticadas.
Teniendo en cuenta estas condiciones, la mayora de los sistemas operativos optan por una solucin que
combina ambas posibilidades:
El manejador ofrece un modo de operacin en el que proporciona unas funciones de edicin
relativamente sencillas, generalmente orientadas a lneas de texto individuales. Este suele ser el
modo de trabajo por defecto puesto que satisface las necesidades de la mayora de las aplicaciones.
En los sistemas UNIX, este modo se denomina elaborado ya que el ma nejador procesa los
caracteres introducidos.
El manejador ofrece otro modo de operacin en el que no se proporciona ninguna funcin de
edicin. La aplicacin recibe directamente los caracteres tecleados y ser la encargada
de realizar las funciones de edicin que considere oportunas. En los entornos UNIX se califica a este modo
como crudo ya que no se procesan los caracteres introducidos. Esta forma de trabajo va a ser la usada por
las aplicaciones que requieran tener control de la edicin.
Por lo que se refiere al modo orientado a lnea, hay que resaltar que una solicitud de lectura de una
aplicacin no se puede satisfacer si el usuario no ha introducido una lnea conipleta, aunque se hayan
tecleado caracteres suficientes. Observe que esto se debe a que, hasta que no se completa una lnea, el
usuario todava tiene las posibilidades de editarla usando los caracteres de edicin correspondientes.
Con respecto al modo crudo, en este caso no existen caracteres de edicin aunque, como se ver a
continuacin, pueden existir otro tipo de caracteres especiales. Cuando un programa solicita datos, se le
entregan aunque no se haya tecleado una lnea completa. De hecho, en este modo el manejador ignora la
organizacin en lneas realizando un procesado carcter a carcter.
En el modo elaborado existen unos caracteres que tienen asociadas funciones de edicin, pero stos no son
los nicos caracteres que reciben un trato especial por parte del manejador. Existe un conjunto de caracteres
especiales que normalmente no se le pasan al programa que lee del terminal, como ocurre con el resto de
los caracteres, sino que activa alguna funcin del manejador. Estos caracteres se pueden clasificar en las
siguientes categoras:
Caracteres de edicin. Tienen asociadas funcin de edicin tales como borrar el ltimo carcter tecleado,
borrar la lnea en curso o indicar el fin de la entrada de datos. Estos caracteres slo se procesan si el
terminal est en modo lnea. Supngase, por ejemplo, que el carcter backspace tiene asociada la funcin de
borrar el ltimo carcter tecleado. Cuando el usuario pulsa este carcter, el maiiejador lo detecta y no lo
encola en la zona donde almacena la lnea en curso, sino que elimina de dicha zona el ltimo carcter
encolado. Dentro de esta categora, es conveniente analizar cmo se procesa el carcter que indica el final
de una lnea. Observe que, estrictamente, un cambio de lnea implica un retorno de carro para volver al
principio de la lnea actual y un avance de la lnea para pasar a la siguiente. Sin embargo, no parece que
tenga sentido obligar a que el usuario teclee ambos caracteres. As, en los sistemas UNIX, el usuario puede
teclear tanto un retorno de carro como un carcter de nueva lnea para indicar el final de la lnea. El
manejador se encarga de mantener esta equivalencia y, por convencin, en ambos casos entrega un carcter
de nueva lnea al programa que lee del terminal.
Caracteres para el control de procesos. Todos los sistemas proporcionan al usuario algn carcter para
abortar la ejecucin de un proceso o detenerla temporalmente.
Caracteres de control de flujo. El usuario puede desear detener momentneamente la sa lida que genera
un programa para poder revisarla y, posteriormente, dejar que contine apareciendo en la pantalla. El
manejador gestiona caracteres especiales que permiten rea lizar estas operaciones.
Caracteres de escape. A veces el usuario quiere introducir como entrada de datos un ca rcter que est
definido como especial. Se necesita un mecanismo para indicar al manejador que no trate dicho carcter,
sino que lo pase directamente a la aplicacin. Para ello, gene ralmente, se define un carcter de escape cuya
misin es indicar que el carcter que viene a continuacin no debe procesarse. Evidentemente, para
introducir el propio carcter de escape habr que teclear otro carcter de escape justo antes.
Por ltimo hay que resaltar que la mayora de los sistemas ofrecen la posibilidad de cambiar
qu carcter est asociado a cada una de estas funciones o incluso desactivar dichas funciones si se
considera oportuno.
Software de salida
La salida en un terminal no es algo totalmente independiente de la entrada. Por defecto, el inane jador hace
eco de todos los caracteres que va recibiendo en las sucesivas interrupciones del teclado. As, la salida que
aparece en el terminal es una mezcla de lo que escriben los programas y del eco de los datos introducidos
por el usuario. Esta opcin se puede desactivar, en cuyo caso el manejador no escribe en la pantalla los
caracteres que va recibiendo.
A diferencia de la entrada, la salida no est orientada a lneas de texto, sino que se escriben
directamente los caracteres que solicita el programa, aunque no constituyan una lnea (Aclara cin 7.1).
El software de salida para los terminales serie es ms sencillo que para los proyectados en memoria. Esto se
debe a que en los primeros el propio terminal se encarga de realizar muchas labores liberando al manejador
de las mismas. Por ello se estudiarn estos dos casos de I separada.
Terminal serie
En este tipo de terminal la salida est dirigida por interrupciones. Cuando un programa solicita escribir una
cadena de caracteres. el manejador los copia en un espacio de almacenamiento in termedio de salida. A
continuacin, el manejador copia el primer carcter en el registro corres pondiente de la UART y le pide a
sta que lo enve al terminal. Cuando la UART genera la interrupcin de fin de transmisin, el manejador
copia en ella el segundo carcter y as sucesi vamente.
Cuando recibe el carcter a travs de la lnea serie, el propio terminal se encarga de todas las labores
implicadas con la presentacin del carcter en pantalla. Esto incluye aspectos tales como la obtencin del
patrn que representa al carcter y su visualizacin, el manejo de caracteres que tienen alguna presentacin
especial (p. ej.: el carcter campanada), la manipulacin de la posicin del cursor o el manejo e
interpretacin de las secuencias de escape.
Terminal proyectado en memoria
La salida en este tipo de terminales implica leer del espacio del proceso los caracteres que ste desea
escribir, realizar el procesado correspondiente y escribir en la memoria de vdeo el resultado del mismo. No
se requiere, por tanto, el uso de interrupciones o de un espacio de almacenamiento de salida. Si la pantalla
est en modo alfanumrico, en la memoria de vdeo se escribe el carcter a visualizar, siendo el propio
controlador de vdeo el que se encarga de obtener el patrn que lo representa. En el caso del modo grfico,
el propio manejador debe obtener el patrn y modificar la memoria de vdeo de acuerdo al mismo.
A diferencia de los terminales serie, en este caso el manejador debe encargarse de la presen tacin de los
caracteres. Para la mayora de ellos, su visualizacin implica simplemente la actua lizacin de la memoria
de vdeo. Sin embargo, algunos caracteres presentan algunas dificultades especficas como, por ejemplo, los
siguientes:
Un tabulador implica mover el cursor el nmero de posiciones adecuadas.
El carcter campanada (control-G) requiere que el altavoz del equipo genere un sonido.
El carcter de borrado debe hacer que desaparezca de la pantalla el carcter anterior.
Los caracteres de salto de lnea pueden implicar desplazar el contenido de la pantalla una lnea
hacia arriba cuando se introducen estando el cursor en la lnea inferior. El manejador debe escribir
en el registro correspondiente del controlador de vdeo para realizar esta ope racin.
Por ltimo, hay que recordar que en este tipo de terminales, el manejador debe encargarse de interpretar las
secuencias de escape, que normalmente requerirn modificar los registros del con trolador que permiten
mover el curso o desplazar el contenido de la pantalla.
7.9. LA RED
El dispositivo de red se ha convertido en un elemento fundamental de cualquier sistema inform tico. Por
ello, el sistema operativo ha evolucionado para proporcionar un tratamiento ms exhaus tivo y sofisticado
de este dispositivo.
Se trata de un dispositivo que presenta unas caractersticas especficas que generalmente im plican un
tratamiento diferente al de otros dispositivos. As, muchos sistemas operativos no propor cionan una
interfaz basada en archivos para el acceso a la red, aunque s lo hacen para el resto de dispositivos. En
Linux, por ejemplo, no hay archivos en /dev que representen a los dispositivos de red. Los manejadores de
estos dispositivos de red se activan automticamente cuando en el arranque del sistema se detecta el
hardware de red correspondiente, pero no proporcionan acceso directo a los programas de usuario.
Tpicamente, el software de gestin de red del sistema operativo se organiza en tres niveles:
Nivel de interfaz a las aplicaciones.
Nivel de protocolos. Este nivel, a su vez, puede estar organizado en niveles que se corres ponden
con la pila de protocolos.
Nivel de dispositivo red.
Con respecto al nivel superior, una de las interfaces ms usadas es la que corresponde con los sockets del
UNIX BSD, que incluso se utiliza en sistemas Windows ( Winsock). Esta interfaz, que se describir en el
Captulo 10, tiene servicios especficos que slo se usan para acceder a la red (como, por ejemplo, connect,
bind, accept y sendto), aunque usa descriptores de archivo para representar a las conexiones y permite
utilizar servicios convencionales de archivo (como read, write y close). Se puede considerar que se trata de
un nivel de sesin de OS!.
El nivel intermedio consta de una o ms capas que implementan los niveles de transporte y de red de OS! (o
los niveles TCP e IP en el caso de Internet). Este nivel se encarga tambin de funciones de encaminamiento.
En el nivel inferior estn los manejadores de los dispositivos de red que se corresponden con el nivel de
enlace de OS!. En este nivel puede haber manejadores para distintos tipos de hardware de red (Ethernet,
SLIP, etc.).
Todos estos niveles trabajan de manera independiente entre s, lo que facilita la coexistencia de distintos
protocolos y dispositivos de red. Para lograr esta independencia se definen interfaces estndar entre los
distintos niveles.
La informacin viajar del nivel superior a los inferiores como resultado de una llamada de una aplicacin
solicitando transferir un mensaje. El flujo inverso de informacin se activa con la ocurrencia de una
interrupcin del dispositivo de red que indica la llegada de un mensaje.
Segn la informacin va pasando por los distintos niveles se va aadiendo y eliminando in formacin de
control. Un aspecto fundamental para conseguir una implementacin eficiente del software de gestin de
red es intentar reducir lo mximo posible el nmero de veces que se copia la informacin del mensaje.
La Figura 7. 19 muestra cmo estn organizados los distintos niveles de software del sistema operativo que
gestiona la red.
Servicios de entrada/salida
La mayora de los sistemas operativos modernos proporcionan los mismos servicios para trabajar con
dispositivos de entrada/salida que los que usan con los archivos. Esta equivalencia es muy beneficiosa ya
que proporciona a los programas independencia del medio con el que trabajan. As, para acceder a un
dispositivo se usan los tpicos servicios para abrir, leer, escribir y cerrar archivos.
Sin embargo, en ocasiones es necesario poder realizar desde un programa alguna operacin dependiente del
dispositivo. Por ejemplo, suponga un programa que desea solicitar al usuario una contrasea a travs del
terminal. Este programa necesita poder desactivar el eco en la pantalla para
que no pueda verse la contrasefia mientras se teclea. Se requiere, por tanto, algn mecanismo para poder
realizar este tipo de operaciones dependiendo del dispositivo. Existen al menos dos posibi lidades no
excluyentes:
Permitir que este tipo de opciones se puedan especificar como indicadores en el propio servicio
para abrir el dispositivo.
Proporcionar un servicio que permita invocar estas opciones dependientes del dispositivo.
Debido al tratamiento diferenciado que se da al reloj, se presentan separadamente los servicios relacionados
con el mismo de los correspondientes a los dispositivos de entrada/salida conven cionales.
En cuanto a los servicios del reloj, se van a especificar de acuerdo a las tres categoras antes planteadas:
fecha y hora, temporizaciones y contabilidad. Con respecto a los servicios destinados a dispositivos
convencionales, se presentarn de forma genrica haciendo especial hincapi en los relacionados con el
terminal.
Servicio de fecha y hora
El servicio para obtener la fecha y hora es time, cuyo prototipo es el siguiente:
time_t time (time_t *t)
Esta funcin devuelve el nmero de segundos transcurridos desde el 1 de enero de 1970 en UTC. Si el
argumento no es nulo, tambin lo almacena en el espacio apuntado por el mismo.
Algunos sistemas UNIX proporcionan tambin el servicio gettimeofday que proporciona una precisin de
microsegundos.
La biblioteca estndar de C contiene funciones que transforman el valor devuelto por time a un formato
ms manejable (ao, mes, da, horas, minutos y segundos) tanto en UTC, la funcin gmtime, como en
horario local, la funcin localtime.
Para cambiar la hora y fecha se proporciona el servicio stime, cuyo prototipo es:
mt stime (timet *t)
Esta funcin fija la hora del sistema de acuerdo al parmetro recibido, que se interpreta como el nmero de
segundos desde el 1 de enero de 1970 en UTC. Se trata de un servicio slo disponible para el superusuario.
En algunos sistemas UNIX existe la funcin settimeofday que permite realizar la misma funcin pero con
una precisin de microsegundos.
Todas estas funciones requieren el archivo de cabecera time . h. Como ejemplo del uso de estas funciones
se presenta el Programa 7.3 que imprime la fecha y la hora en horario local.
Programa 7.3. Programa que imprime la fecha y hora actual.
#include <stdio.h>
#inciude <time.h>
mt mamo
timet tiempo;
struct tm *fecha.
tiempo= time (NULL); fechas localtime(&tiempo)
/* hay que ajustar el ao ya que lo devuelve respecto a 1900 */ printf (%02d/%02d/%04d
%02d:%02d:%02d\n,
fecha->tmmday, fecha->tm_mon, fecha->tm_year+1900, fecha->tmhour, fecha>tmmin, fecha->tmsec)
return 0;
Servicios de temporizacin
El servicio alarm permite establecer un temporizador en POSIX. El plazo debe especiflcarse en segundos.
Cuando se cumple dicho plazo, se le enva al proceso la seal SIGALRM. Slo se permite un temporizador
activo por cada proceso. Debido a ello, cuando se establece un temporizador, se desactiva automticamente
el anterior. El prototipo de esta funcin es el siguiente:
unsigned mt alarm (unsigned mt segundos);
El argumento especifica la duracin del plazo en segundos. La funcin devuelve el nmero
de segundos que le quedaban pendientes a la alarma anterior, si haba alguna pendiente. Una alarma con un
valor de cero desactiva un temporizador activo.
En POSIX existen otro tipo de temporizadores que permiten establecer plazos con una mayor
resolucin y con modos de operacin ms avanzados. Este tipo de temporizadores se activa con la funcin
setitimer.
Servicios de contabilidad
POSIX define diversas funciones que se pueden englobar en esta categora. Esta seccin va a presentar una
de las ms usadas. El servicio times que devuelve informacin sobre el tiempo de ejecucin de un proceso y
de sus procesos hijos. El prototipo de la funcin es el siguiente:
clockt times (struct tms *info)
ble Esta funcin rellena la zona apuntada por el puntero recibido como argumento con informa cin sobre
el uso del procesador, en modo usuario y en modo sistema, tanto del propio proceso como de sus procesos
hijos. Adems, devuelve un valor relacionado con el tiempo real en el sistema
de (tpicamente, el nmero de interrupciones de reloj que se han producido desde el arranque del
sistema). Observe que este valor no se usa de manera absoluta. Normalmente, se compara el valor
devuelto por dos llamadas a times realizadas en distintos instantes para determinar el tiempo real
transcurrido entre esos dos momentos.
El Programa 7.4 muestra el uso de esta llamada para determinar cunto tarda en ejecutarse un programa que
recibe como argumento. La salida del programa especifica el tiempo real, el tiempo de procesador en modo
usuario y el tiempo de procesador en modo sistema consumido por el programa especificado.
Programa 7.4. Programa que muestra el tiempo real, el tiempo en modo usuario y en modo sistema que se
consume durante la ejecucin de un programa.
#include <stdio.h> #include <unistd.h> #include <time.h> #include <sys/times.h>
int main(int argc, char *argv struct tms Infolnicio, InfoFin; clock_t tinicio, tfin; long tickporseg;
if (argc<2)
fprintf(stderr, Uso: %s programa [ argv
exit(l)
/ obtiene el nmero de interrupciones de reloj por segundo /
tickporseg= sysconf (_SC_CLK_TCK);
t_inicio= times (&Infolnicio)
if (fork()==O)
execvp(argv &argv
perror (error ej ecutando el programa)
exit(l)
wait(NULL);
t_fin= times(&InfoFin)
printt(Tiempo real: %7.2f\n, (float) (tfin t inicio) /tickporseg)
printf( de usuario: %7.2f\n,
(float) (InfoFin. tms_cutime Infolnicio.tmscutime) /tickporseg)
printf(Tiempo de sistema: %7.2f\n,
(float) (InfoFin.tmscstime Infolnicio.tms_cstime) /tickporseg)
return O;
}
Servicios de entrada/salida sobre dispositivos
Corno ocurre en la mayora de los sistemas operativos, se utilizan los mismos servicios que para acceder a
los archivos. En el caso de POSIX, por tanto, se trata de los servicios open, read, write y close. Estas
funciones se estudian detalladamente en el Captulo 8.
Es necesario, sin embargo, un servicio que permita configurar las opciones especficas de cada dispositivo o
realizar operaciones que no se pueden expresar como un read o un write (corno, por ejemplo, rebobinar una
cinta). En UNIX existe la funcin ioctl, cuyo prototipo es el siguiente:
intiocti (mt descriptor, intpeticion, ..j;
El primer argumento corresponde con un descriptor de archivo asociado al dispositivo corres pondiente. El
segundo argumento es el tipo de operacin que se pretende realizar sobre el dis positivo, que depender del
tipo de dispositivo. Los argumentos restantes, normalmente slo Uflo, especifican los parmetros de la
operacin que se pretende realizar.
El uso ms frecuente de esta funcin es para trabajar con terminales. Sin embargo, aunque esta funcin se
incluya en prcticamente todas las versiones de UNIX, el estndar POSIX no la define. En el caso del
terminal, POSIX especifica un conjunto de funciones destinadas slo a este tipo de dispositivo. Las dos ms
frecuentemente usadas son tcgetattr y tcsetattr, destinadas a obtener los atributos de un terminal y a
modificarlos, respectivamente. Sus prototipos son los siguientes:
int tcgetattr (mt descriptor, struct termios *atrjb);
int tcsetattr (mt descriptor, mt opcion, struct termios *atrib);
La funcin tcgetattr obtiene los atributos del terminal asociado al descriptor especificado. La funcin
tcsetattr modifica los atributos del terminal que corresponde al descriptor pasado como parmetro. Su
segundo argumento establece cundo se producir el cambio: inmediatamente o despus de que la salida
pendiente se haya transmitido.
La estructura termios contiene los atributos del terminal que incluye aspectos tales como el tipo de
procesado que se realiza sobre la entrada y sobre la salida, los parmetros de transmisin en el caso de un
terminal serie o la definicin de qu caracteres tienen un significado especial. Dada la gran cantidad de
atributos existentes (ms de 50), en esta exposicin no se entrar en detalles sobre cada uno de ellos,
mostrndose simplemente un ejemplo de cmo se usan estas funciones. Como ejemplo, se presenta el
Programa 7.5 que lee una contrasea del terminal desac tivando el eco en el mismo para evitar problemas
de seguridad.
Se van a presentar clasificados en las mismas categoras que se han usado para exponer los servicios
POSIX.
Servicios de fecha y hora
El servicio para obtener la fecha y hora es GetSystemTime, cuyo prototipo es el siguiente:
BOOL GetSystemTime (LPSYSTEMTIME tiempo)
Esta funcin devuelve en el espacio asociado a su argumento la fecha y hora actual en una estructura
organizada en campos que contienen el ao, mes, da, hora, minutos, segundos y mi lisegundos. Los datos
devueltos corresponden con el horario estndar UTC. La funcin GetLocal Time permite obtener
informacin segn el horario local.
La funcin que permite modificar la fecha y hora en el sistema es SetSystemTime, cuyo prototipo es:
BOOL SetSystemTime (LPSYSTEMTIME tiempo);
Esta funcin establece la hora del sistema de acuerdo al parmetro recibido que tiene la misma
estructura que el usado en la funcin anterior (desde el ao hasta los milisegundos actuales).
Como ejemplo se plantea el Programa 7.6 que imprime la fecha y hora actual en horario local.
Tiempo.wMinute, Tiempo.wSecond);
return O;
}
Servicios de temporizacin
La funcin setTimer permite establecer un temporizador con una resolucin de milisegundos. Un proceso
puede tener mltiples ternporizadores activos simultneamente. El prototipo es:
UINT SetTimer (HWND ventana, UINT evento, UINT plazo,
TIMERPROC funcion);
Esta funcin devuelve un identificador del temporizador y recibe como parmetros un iden tificador de la
ventana asociada con el temporizador (si tiene un valor nulo no se le asocia a ninguna), un identificador del
evento (este parmetro se ignora en el caso de que el temporizador no est asociado a ninguna ventana), un
plazo en milisegundos y la funcin que se invocar cuando se cumpla el plazo.
Servicios de contabilidad
En Win32 existen diversas funciones que se pueden encuadrar en esta categora. Como en el caso de
POSIX, se muestra como ejemplo el servicio que permite obtener informacin sobre el tiempo de ejecucin
de un proceso. Esta funcin es GetProcessTimes y su prototipo es el siguiente:
BOOL GetProcessTimes (HANDLE proceso, LPFILETIME t_creacion,
LPFILETIME t_fin, LPFILETIME tsistema,
LPFILETIME tusuario);
Esta funcin obtiene para el proceso especificado su tiempo de creacin y finalizacin, as como cunto
tiempo de procesador ha gastado en modo sistema y cunto en modo usuario. Todos estos tiempos estn
expresados como centenas de nanosegundos transcurridas desde el 1 de enero de 1601 almacenndose en
un espacio de 64 bits. La funcin FileTimeToSystemTime permite transformar este tipo de valores en el
formato ya comentado de ao, mes, da, hora, minutos, segundos y milisegundos.
Como ejemplo del uso de esta funcin, se presenta el Programa 7.7 que imprime el tiempo que tarda en
ejecutarse el programa que recibe como argumento especificando el tiempo real de ejecucin, as como el
tiempo de procesador en modo usuario y en modo sistema consumido por dicho programa.
Programa 7.7. Programa que muestra el tiempo real, el tiempo en modo usuario y en modo sistema que se
consume durante la ejecucin de un programa.
finclude <windows . h> #include <stdio.h>
fdefine MAX 255
mt main (mt argc, LPTSTR argv [ ])
}
int i;
BOOL result; STARTUPINFO Infolnical; PROCESS_INFORMATION InfoProc union
LONGLONG numero;
FILETIME tiempo;
TiempoCreacion, TiempoFin, TiempoTranscurrido;
FILETIME TiempoSistema, TiempoUsuario;
SYSTEMTIME TiempoReal, TiempoSistema, TiempoUsuario;
CHAR mandato
/* Obtiene la lnea de mandato saltndose el primer argumento */ sprintf(mandato,%s, argv{l]);
for (i=2; i<argc; i++)
sprintf (mandato, %s %s, mandato, argv
GetStartuplnfo(&]info
result= CreateProcess(NULL, mandato, NULL, NULL, TRUE, NORMAL PRIORITY CLASS, NULL,
NULL, &Infolnicial,
&InfoProc)
if (! result)
fprintf(stderr, error creando el proceso\n);
return(l);
WaitForSingleObject(InfoProc.hProcess, INFINITE);
GetProcessTixnes(InfoProc.hProcess, &TiempoCreacin. tiempo, &TiempoFin.tiempo, &TiempoSstema,
&TiempoUsuario);
TiempoTranscurrido numero= TiempoFin .numero TiempoCreacin numero;
FileTimeToSystemTime(&TiempoTranscurrido.tiempo, &TiempoReal); FileTimeToSystemTime
(&TiempoSistema, &TiempoSistema) FileTimeToSysteinTirne(&Tiempousuario, &TiempoUsuario); prntf
(Tiempo real: %02d:%02d:%02d:%03d\n,
TiempoReal .wHour, TiempoReal .wMinute, TiempoReal .wSecond, TiempoReal .wMilliseconds);
printf (Tiempo de usuario: %02d:%02d:%02d:%03d\n, TiempoUsuario.wHour, TiempoUsuario
.wMinute,
TiempoUsuario.wSecond, TiempoUsuario.wMilliseconds); printf (Tiempo de sistema:
%02d:%02d:%02d:%03d\n,
TiempoSistema.wHour, TiempoSistema.wMinute,
TiempoSistema.wSecond, TiempoSistema.wMilliseconds);
return O;
}
Servicios de entradalsalida
Al igual que en POSIX, para acceder a los dispositivos se usan los mismos servicios que se utilizan para los
archivos. En este caso, createFile, CloseHandie, ReadFile y WriteFile.
Sin embargo, como se ha analizado previamente, estos servicios no son suficientes para cubrir
todos los aspectos especficos de cada tipo de dispositivo. Centrndose en el caso del terminal, Win32
ofrece un servicio que permite configurar el modo de funcionamiento del mismo. Se de nomina
SetConsoleMode y su prototipo es el siguiente:
BOOL SetConsoleMode (HANDLE consola, DWORD modo);
Esta funcin permite configurar el modo de operacin de una determinada consola. Se pueden especificar,
entre otras, las siguientes posibilidades: entrada orientada a lneas (ENABLE_LINE_IN PUT), eco activo
(ENABLE_ECHO_INPUT), procesamiento de los caracteres especiales en la salida
(ENABLE_PROCESSED_OUTPUT) y en la entrada (ENABLE_PROCESSED_INPUT).
Es importante destacar que para que se tengan en cuenta todas estas opciones de configuracin hay que usar
para leer y escribir del dispositivo las funciones ReadConsole y WriteConsole, respectivamente, en vez de
utilizar ReadFile y WriteFile. Los prototipos de estas dos nuevas funciones son casi iguales que las
destinadas a archivos:
BOOL ReadConsole (HANDLE consola, LPVOID mem, DWORD a_leer,
LPDWORD leidos, LPVOID reservado);
BOOL WriteConsole (HANDLE consola, LPVOID mem, DWORD a_escribir,
LPVOID escritos, LPVOID reservado);
El significado de los argumentos de ambas funciones es el mismo que los de ReadFile y WriteFile,
respectivamente, excepto el ltimo parmetro que no se utiliza.
Como muestra del uso de estas funciones, se presenta el Programa 7.8 que lee la informacin del terminal
desactivando el eco del mismo.
Programa 7.8. Programa que lee del terminal desactivando el eco.
#include <windows . h> #include <stdio.h> #define TAMMAX 32
mt main (mt argc, LPTSTR argv E])
HANDLE entrada, salida;
DWORD ledos, escritos;
BOOL result;
BYTE clave [
entrada= CreateFile(CONIN$, GENERIC_READ GENERIC_WRITE, O, NULL, OPENALWAYS,
FILE_ATTRIBUTE NORMAL, NULL);
if (entrada == INVALID HANDLE VALUE)
fprintf (stderr, No puede abrirse la consola para lectura\n);
return(l);
}
travs de una instruccin de EIS. En los segundos, lo hace sobre direcciones de memoria asignadas
nica mente al controlador.
Segn la unidad de acceso, los dispositivos pueden ser bloques o de caracteres.
La informacin entre los controladores de dispositivo y la unidad central de proceso o memoria
principal se puede transferir mediante un programa que ejecuta con tinuamente. tcnica que se
denomina E/S programada, o programando el dispositivo y esperando a que notifi que el fin de la
operacin, tcnica que se denomina E/S por interrupciones.
El DMA supone una mejora importante al incrementar la concurrencia entre la UCP y la E/S. Con
esta tcnica, el controlador del dispositivo se encarga de efectuar la transferencia de datos a
memoria, liberando de este tra bajo a la UCP.
La arquitectura del sistema de entrada/salida es comple ja y est estructurada en capas, cada una de
las cuales tiene una funcionalidad bien definida.
El software de E/S del sistema operativo se estructura en las siguientes capas: manejadores de
interrupcin, manejadores de dispositivos o drivers, software de E/S independiente de los
dispositivos e interfaz del sistema operativo.
Cada dispositivo de E/S. o cada clase de dispositivos, tiene un manejador asociado en el sistema
operativo. Dicho manejador incluye: cdigo independiente del dispositivo para proporcionar al
nivel superior del sis tema operativo una interfaz de alto nivel y el cdigo dependiente del
dispositivo necesario para programar el controlador del dispositivo a travs de sus registros y
mandatos.
La mayor parte del sistema de E/S es software indepen diente de dispositivo.
La interfaz de E/S de las aplicaciones lo constituyen las bibliotecas de E/S y los procesos demonio.
La interfaz de E/S de las aplicaciones es la que define el modelo de E/S que ven los usuarios en
cuanto a nom bres. control de acceso, bloqueos, indicaciones de error y uso de estndares.
El sistema de almacenamiento secundario se usa para guardar los programas y datos en dispositivos
rpidos, de forma que sean fcilmente accesibles a las aplicacio nes a travs del sistema de
archivos.
Los discos son los dispositivos bsicos para llevar a cabo almacenamiento masivo y no voltil de
datos. Sus controladores ms populares son SCSI e IDE. Los dis cos pueden ser duros, pticos o
extrables.
Un disco duro es un dispositivo de gran capacidad com puesto por varias superficies magnetizadas
y cuyas ca bezas lectoras funcionan por efecto electromagntico. Su formato fsico lo orgafliLa en
cilindros, pistas y sectores.
Una particin es una porcin contigua de disco delimi tada por un sector inicial y final. La
informacin de dis tribucin lgica del disco en subconjuntos denominados volmenes o
particiones se almacena en una estructura denominada tabla de particiones.
El formato lgico de la particin crea un sistema de archivos dentro de dicha particin.
En LINUX y Windows NT existe un manejador gen rico para la clase de dispositivo disco y un
manejador dependiente del dispositivo para cada tipo de disco en particular.
En los discos es fundamental usar polticas de planifi cacin que minimicen el movimiento de
cabezas para obtener un buen rendimiento medio del disco.
La poltica de planificacin de disco CSCAN es la ms usada en todos los sistemas operativos.
Para aquellos usuarios interesados en ver otros enfoques a los sistemas de E/S. se recomiendan los libros de
Silberschatz [ 19981, Stallings IStallings. 19981 y Tanenhaum [ 19921. Todos ellos son libros generales de
sistemas operativos que muestran una panormica del sistema de E/S. Para una visin ms detallada del
sistema de E/S del sistema operativo Windows, se puede consultar el libro de Solomon [ 19981.
Para ampliar conocimientos sobre el terna de los manejadores de dispositivo y especialmente de los de los
dispositivos de almacenamiento secundario y terciario del sistema operativo UNIX, se recomiendan los
libros de Goodheart IGoodheart. 19941. Bach Bach. 19861 y lMcKusick, 19961. Para el sistema operativo
LINUX se puede consultar el libro de Beck IBeck. 19981, titulado Linux Kernel internais. Para saber ms
acerca de los manejadores del sistema operativo Windows NT, se pueden consultar los libros de Solomon
[Solomon, 19981, Nagar [Nagar, 19971 y Dekker [Dekker, 19991.
Para ver cmo es realmente el cdigo de los manejadores de dispositivo, es recomendable el libro de
sistemas operativos basado en MINIX Tanenbaum, 19971, que incluye el listado completo de este sistema
operativo.
En cuanto a los servicios de entradalsalida, en [Stevens, 19921 se presentan los servicios de POSIX y en
[Hart, 1997] los de Win32.
7.13. EJERCICIOS
7.1 Calcule las diferencias en tiempos de acceso entre los distintos niveles de la jerarqua de EIS.
Razone la respuesta.
7.2 Qu es el controlador de un dispositivo? Cules son sus funciones?
7.3 Es siempre mejor usar sistemas de E/S por inte rrupciones que programados? Por qu?
7.4 Qu ocurre cuando llega una interrupcin de EIS? Se ejecuta siempre el manejador del
dispositivo? Razone la respuesta.
7.5 Imagine un sistema donde slo hay llamadas de E/S bloqueantes. En este sistema hay 4
impresoras,3 cintas y 3 trazadores. En un momento dado hay 3 procesos en ejecucin A, B y C que
tienen la siguiente necesidad de recursos actual y futura:
I C T I C T
A l l O 1 1 2
B 1 0 1 0 1 1
C I I I 2 2 2
Determinar si el estado actual es seguro. Deter minar si las necesidades futuras se pueden satisfa
cer, usando el algoritmo del banquero. Ira todo mejor con E/S no bloqueante?
7.6 Indique dos ejemplos en los que sea mejor usar E/S no bloqueante que bloqueante.
7.7 Qu problemas plantea a los usuarios la E/S blo queante? Y la no bloqueante?
7.8 Se le ocurre alguna estructura para el sistema de E/S distinta de la propuesta en este captulo? Razone
la respuesta.
7.9 Es mejor tener un sistema de E/S estructurado por capas o monoltico? Explique las ventajas y des
ventajas de ambas soluciones?
7.10 En qu componentes del sistema de E/S se llevan a cabo las siguientes tareas?
a) Traduccin de bloques lgicos a bloques del dispositivo.
b) Escritura de mandatos al controlador del dispositivo.
c) Traducir los mandatos de E/S a mandatos del dispositivo.
d) Mantener una cache de bloques de E/S.
7.11 En que consiste el DMA? Para que sirve?
medio de bsqueda es de 6 mseg., calcule el m ximo nmero de dispositivos que el controlador podra
explotar de forma eficiente si hay un 20 por 1(X) de operaciones de bsqueda y un 80 por lOO de
transferencias, con un tamao medio de 6 KB, repartidas uniformemente por los ocho dispositivos.
7.18. Cules son las principales diferencias, desde el punto de vista del sistema operativo, entre un sis
tema de copias de respaldo y un sistema de alma cenamiento terciario complejo como HPSS?
7.19. Suponga que los dispositivos extrables, como las cintas, fueran tan caros como los discos. Tendra
sentido usar estos dispositivos en la jerarqua de almacenamiento?
7.20. Suponga un gran sistema de computacin al que se ha aadido un sistema de almacenamiento ter
ciario de alta capacidad. De qu forma se puede saber si los archivos estn en el sistema secundario o en el
terciario? Se podran integrar todo el rbol de nombres? Razone la respuesta.
7.2 1. En algunos sistemas, como por ejemplo Linux, se almacena en una variable el nmero de interrup
ciones de reloj que se han producido desde el arra nque del equipo, devolvindolo en la llamada ti mes. Si
la frecuencia de reloj es de lOO Hz y se usa una variable de 32 bits, cunto tiempo tardar en deshordarse
ese contador? Qu consecuencia puede tener ese desbordamiento?
7.22. Qu distintas cosas puede significar que una fun cin obtenga un valor elevado en un perfil de eje
cucin de un programa?
7.23. Proponga un mtodo que permita a un sistema ope rativo proporcionar un servicio que ofrezca tempo
rizaciones de una duracin menor que la resolu cin del reloj.
7.24. Algunos sistemas permiten realizar perfiles de eje cucin de! propio sistema operativo. De qu par
tes del cdigo del sistema operativo no podrn ob tener perfiles?
7.25. Escriba el pseudocdigo de una rutina de interrup cin de reloj.
7.26. Suponga un sistema que no realiza la gestin de temporizadores directamente desde la rutina
deinterrupcin sino desde una rutina que ejecuta con menor prioridad que las interrupciones de todos los
dispositivos. En qu situaciones puede tomar un valor negativo el contador de un temporiza dor?
7.27. Analice para cada uno de estos programas si en su consumo del procesador predomina el tiempo gas
tado en modo usuario o en modo sistema.
Un compilador.
Un programa que copia un archivo.
Un intrprete de mandatos que sea un programa que comprime un archivo.
Un programa que resuelve una compleja frmula matemtica.
7.28. Enumere algunos ejemplos de situaciones proble mticas que podran ocurrir si un usuario cambia la
hora del sistema retrasndola. Podra haber pro blemas si el cambio consiste en adelantarla?
7.29. Escriba el pseudocdigo de las funciones de lectu ra, escritura y manejo de interrupciones para un
terminal serie.
7.30. Lo mismo que el ejercicio anterior pero en e! caso de un terminal proyectado en memoria.
7.31. Enumere ejemplos de tipos de programas que re quieran que el terminal est en modo carcter (modo
crudo).
7.32. Escriba un programa usando servicios POSIX que lea un nico carcter del terminal.
7.33. Realice el mismo programa utilizando servicios Win32.
En este captulo se presentan los conceptos relacionados con archivos y directorios. El cap tulo
tiene tres objetivos bsicos: mostrar al lector dichos conceptos desde el punto de vista de
usuario, los servicios que da el sistema operativo y los aspectos de diseo de los sistemas de
archivos y del servidor de archivos. De esta forma se pueden adaptar los contenidos del tema a
distintos niveles de conocimiento.
Para alcanzar este objetivo el captulo se estructura en las siguientes grandes secciones:
Visin de usuario del sistema de archivos.
Archivos.
Directorios.
Servicios de archivos y directorios.
Sistemas de archivos.
El servidor de archivos.
419
Desde el punto de vista de los usuarios y las aplicaciones, los archivos y directorios son los elemen tos
centrales del sistema. Cualquier usuario genera y usa informacin a travs de las aplicaciones que ejecuta
en el sistema. En todos los sistemas operativos de propsito general, las aplicaciones y sus datos se
almacenan en archivos no voltiles, lo que permite su posterior reutilizacin. La visin que los usuarios
tienen del sistema de archivos es muy distinta de la que tiene el sistema operativo en el mbito interno.
Como se muestra en la Figura 8.1, los usuarios ven los archivos como un conjunto de informacin
estructurada segn sus necesidades o las de sus aplicaciones, mientras que el sistema operativo los
contempla como conjuntos de datos estructurados segn sus necesidades de almacenamiento y
representacin. Adems, puede darse la circunstancia de que distintos usuarios vean un mismo archivo de
forma distinta [ 19811. Un archivo de empleados, por ejemplo, puede tratarse como un conjunto de
registros indexados o como un archivo de texto sin ninguna estructura. Cuando en un sistema existen
mltiples archivos, es necesario dotar al usuario de algn mecanismo para estructurar el acceso a los
mismos. Estos mecanismos son los directorios, agrupa ciones lgicas de archivos que siguen criterios
definidos por sus creadores o manipuladores. Para facilitar el manejo de los archivos, casi todos los
sistemas de directorios permiten usar nombres lgicos, que, en general, son muy distintos de los
descriptores fsicos que usa internamente el sistema operativo.
Cualquiera que sea la visin de los archivos, para los usuarios su caracterstica principal es que no estn
ligados al ciclo de vida de una aplicacin en particular. Un archivo y un directorio tienen su propio ciclo de
vida. Para gestionar estos objetos, todos los sistemas operativos de propsito general incluyen servicios de
archivos y directorios [ 19961, junto con programas de utilidad que facilitan el uso de sus servicios [ 19841
y Horspool, 19921. El servidor de archivos es la parte del sistema operativo que se ocupa de facilitar el
manejo de los dispositivos perifricos, ofreciendo una visin lgica simplificada de los mismos en forma de
archivos. Median te esta visin lgica se ofrece a los usuarios un mecanismo de abstraccin que oculta
todos los detalles relacionados con el almacenamiento y distribucin de la informacin en los dispositivos
perifricos, as como el funcionamiento de los mismos. Para ello se encarga de la organizacin,
almacenamiento, recuperacin, gestin de nombres, coutilizacin y proteccin de los archivos de un
sistema.
8.2. ARCHIVOS
Las aplicaciones de una computadora necesitan almacenar informacin en soporte permanente, tal como
discos o cintas. Dicha informacin, cuyo tamao puede variar desde unos pocos bytes hasta
terabytes, puede tener accesos concurrentes desde varios procesos. Adems, dicha informacin tiene su
ciclo de vida que normalmente no est ligado a una nica aplicacin.
En esta seccin se va a estudiar la visin externa del sistema de archivos. Para ello se mostrar el concepto
de archivo, la gestin de nombres de archivos, las estructuras de archivo posibles, las semnticas de acceso,
las semnticas de coutilizacin y los servicios que proporcionan los sistemas operativos para gestionar
archivos.
Proteccin: informacin de control de acceso que define quin puede hacer qu sobre el archivo, la
palabra clave para acceder al archivo, el dueo del archivo, su creador, etc.
Tamao del archivo: nmero de bytes en el archivo, mximo tamao posible para el archi vo, etc.
Informacin temporal: tiempo de creacin, de ltimo acceso, de ltima actualizacin, etc. Esta
informacin es muy til para gestionar, monitorizar y proteger los sistemas de archivos.
Informacin de control del archivo: que indica si es un archivo oculto, de sistema, normal o
directorio, cerrojos, etc.
El sistema operativo debe proporcionar, al menos, una estructura de archivo genrico que d soporte a todos
los tipos de archivos mencionados anteriormente, un mecanismo de nombrado. facilidades para proteger los
archivos y un conjunto de servicios que permita explotar el almacena miento secundario y el sistema de E/S
de forma sencilla y eficiente [ 1987]. Dicha estructura debe incluir los atributos deseados para cada archivo,
especificando cules son visibles y cules estn ocultos a los usuarios. La Figura 8.2 muestra tres formas de
describir un archivo: nodo-i de UNIX, registro de MFT en Windows NT y entrada de directorio de MS-
DOS. Todas ellas sirven como mapas para acceder a la informacin del archivo en los dispositivos de
almacenamiento.
El nodo-i de UNIX [ Bach, 1986] contiene informacin acerca del propietario del archivo, de su grupo, del
modo de proteccin aplicable al archivo, del nmero de enlaces al archivo, de valores de fechas de creacin
y actualizacin, el tamao del archivo y el tipo del mismo. Adems incluye un mapa del archivo mediante
apuntadores a bloques de dispositivo que contienen datos del archi vo. A travs del mapa de bloques del
nodo-i se puede acceder a cualquiera de sus bloques con un nmero muy pequeo de accesos a disco.
Cuando se abre un archivo, su nodo-i se trae a memoria. En este proceso se incrementa la informacin del
nodo-i almacenada en el disco con datos referen tes al uso dinmico del mismo, tales como el dispositivo en
que est almacenado y el nmero de veces que el archivo ha sido abierto por los procesos que lo estn
usando.
El registro de MFT de Windows NT [Solomon, 1998] describe el archivo mediante los si guientes
atributos: cabecera, informacin estndar, descriptor de seguridad, nombre de archivo y datos (Fig. 8.2). A
diferencia del nodo-i de UNIX, un registro de Windows NT permite almacenar hasta 1,5 KB de datos del
archivo en el propio registro, de forma que cualquier archivo menor de ese tamao debera caber en el
registro. Si el archivo es mayor, dentro del registro se almacena infor macin del mapa fsico del archivo
incluyendo punteros a grupos de bloques de datos (Vclusters),
cada uno de los cuales incluye a su vez datos y punteros a los siguientes grupos de bloques. Cuando se abre
el archivo, se trae el registro a memoria. Si es pequeo, ya se tienen los datos del archivo. Si es grande hay
que acceder al disco para traer bloques sucesivos. Es interesante resaltar que en este sistema todos los
accesos a disco proporcionan datos del archivo, cosa que no pasa en UNIX. donde algunos accesos son slo
para leer informacin de control.
En el caso de MS-DOS [Patterson, 19891, la representacin del archivo es bastante ms senci lla debido
principalmente a ser un sistema operativo monoproceso y monousuario. En este caso, la informacin de
proteccin no existe, limitndose a unos atributos mnimos que permiten ocultar el archivo o ponerlo como
de slo lectura. El nombre se incluye dentro de la descripcin, as como los atributos bsicos y el tamao
del archivo en KB. Adems, se especifica la posicin del inicio del archivo en la tabla FAT (file allocation
table), donde se almacena el mapa fsico del archivo.
Un ejemplo de la primera opcin fue el sistema operativo TOPS-20, que proporcionaba distin tos tipos de
archivos en su mbito interno y ejecutaba operaciones de forma automtica dependien do del tipo de
archivo. Por ejemplo, si se modificaba un archivo con cdigo fuente Pascal, y exten sin .pas, el sistema
operativo recompilaba automticamente la aplicacin creando una nueva versin de la misma. La segunda
opcin tiene un exponente claro en UNIX, sistema operativo para el que las extensiones del nombre no son
significativas, aunque s lo sean para las aplicaciones externas. Por ello, UNIX no almacena entre los
atributos de un archivo ninguna informacin acerca del tipo del mismo, ya que este sistema operativo
proporciona un nico tipo de archivo cuyo mode lo se basa en una tira secuencial de bytes. Unicamente
distingue algunos formatos, como los archi vos ejecutables, porque en el propio archivo existe una cabecera
donde se indica el tipo del mismo mediante un nmero, al que se denomina nmero mgico. Por supuesto,
esta caracterstica est totalmente oculta al usuario. Por ejemplo, un compilador de lenguaje C [Kernighan,
1978] puede necesitar nombres de archivos con la extensin . c y la aplicacin compress puede necesitar
nom bres con la extensin . z. Sin embargo, desde el punto de vista del sistema operativo no existe ninguna
diferencia entre ambos archivos. Windows tampoco es sensible a las extensiones de archi vos, pero sobre l
existen aplicaciones del sistema (como el explorador) que permiten asociar dichas extensiones con la
ejecucin de aplicaciones. De esta forma, cuando se activa un archivo con el ratn, se lanza
automticamente la aplicacin que permite trabajar con ese tipo de archivos.
cin pueda ser interpretada. Desde el punto de vista del usuario, la informacin de un archivo puede
estructurarse como una lista de caracteres, un conjunto de registros secuencial o indexado, etctera
[Stal1ings, 1988]. Desde el punto de vista de algunas aplicaciones, como por ejemplo un compilador, un
archivo de biblioteca est formado por una serie de mdulos acompaados por una cabecera descriptiva
para cada mdulo. La Figura 8.4 muestra algunas de estas estructuras de archivo.
Una cuestin distinta es si el sistema operativo debe proporcionar funcionalidad para mltiples estructuras
de archivos en el mbito interno. A priori, un soporte ms extenso facilita las tareas de programacin de las
aplicaciones. Sin embargo, esta solucin tiene dos serios inconvenientes:
La interfaz del sistema operativo se complica en exceso.
El diseo y la programacin del propio sistema operativo son mucho ms complejos.
Es por ello que los sistemas operativos ms populares, como UNIX o Windows, proporcionan una
estructura interna de archivo y una interfaz de programacin muy sencillos pero polivalentes, permitiendo a
las aplicaciones construir cualquier tipo de estructura para sus archivos sin que el sistema operativo sea
consciente de ello. Con la estructura de archivo que proporciona POSIX, una tira secuencial de bytes,
cualquier byte del archivo puede ser accedido directamente si se conoce su desplazamiento desde el origen
del archivo. La traslacin desde estas direcciones lgicas a direc ciones fsicas de los dispositivos que
albergan el archivo es distinta en cada sistema operativo, pero se basa en el mapa del archivo almacenado
como parte de los atributos del archivo. La Figura 8.5 muestra la estructura lgica y fsica de un archivo en
el sistema operativo UNIX.
Todos los sistemas operativos deben reconocer al menos un tipo de archivo: sus propios archi vos
ejecutables. La estructura de un archivo ejecutable est ntimamente ligada a la forma de gestio nar la
memoria y la E/S en un sistema operativo. En algunos sistemas, como VMS Kenah, 19881, los archivos
ejecutables se reconocen por su extensin. En otros, como en UNIX, porque as se
indica en el nmero mgico que identifica el tipo de archivo. Aunque existen distintos fii de archivos
ejecutables, como el ELF, la Figura 8.6 muestra un ejemplo simplificado de estructura de un archivo
ejecutable en el sistema operativo UNIX IChristian, 19881. Como puede verse, el siste ma operativo espera
que dicho formato incluya, al menos, cinco secciones: cabecera, texto, datos, informacin de carga y tabla
de smbolos. Dentro de la cabecera est la informacin necesaria para que el sistema operativo pueda
interpretar la estructura del ejecutable y encontrar cada uno de sus elementos (nmero mgico, tamao de
las otras secciones, opciones de ejecucin, etc.). Cada siste ma operativo usa un nmero mgico
caracterstico para reconocer sus ejecutables.
Para poder utilizar la informacin almacenada en un archivo, las aplicaciones deben acceder a la misma y
almacenarla en memoria. Hay distintas formas de acceder a un archivo [ l9 aunque no todos los sistemas
operativos proporcionan todas ellas. Para una aplicacin, elegir ade cuadamente la forma de acceder a un
archivo suele ser un aspecto importante de diseo, ya que, en muchos casos, el mtodo de acceso tiene un
impacto significativo en el rendimiento de la misma. Dependiendo de que se pueda saltar de una posicin a
otra de un archivo, se distinguen dos mtodos de acceso principales: acceso secuencial y acceso directo.
Cuando se usa el mtodo de acceso secuencial, lo nico que se puede hacer es leer los bytes del archivo en
orden, empezando por el principio. No puede saltar de una posicin del archivo a otra o leerlo desordenado.
Si se quiere volver atrs, hay que volver al principio y releer todo el archivo hasta el punto deseado. Las
operaciones ms comunes son lecturas y escrituras. En una lectura, un proceso lee una porcin del archivo,
como resultado de la cual se actualiza el apuntador de posicin de dicho archivo a la siguiente posicin de
lectura. En una escritura, un proceso puede aadir informacin al archivo y avanzar hasta el final de los
datos nuevos. Este modo de acceso. muy fcil de implementar, se usa muy frecuentemente en aplicaciones
que necesitan leer los archi vos completos y de forma contigua, como ocurre con editores y compiladores.
La forma de acceso secuencial se basa en un modelo de archivo almacenado en cinta magntica, pero
funciona igual mente bien en dispositivos de acceso directo. El principal problema de este mtodo es su
falta de flexibilidad cuando hay que acceder de forma no secuencial a los datos. Para tratar de paliarlo, el
sistema MVS incluye archivos ISAM (Indexed Sequential Access Method), es decir, archivos se cuenciales
a partir de los cuales se crea un ndice que indica la posicin de determinados elementos y que se usa para
acceder a ellos rpidamente sin tener que estudiar todos los que hay delante de ellos. Imagine que tiene un
archivo de clientes ordenado por orden alfabtico y quiere buscar a Juan y a Pepe. Deber leer todos los
nombre y ver si son ellos. Con el mtodo ISAM existe un archivo de ndice que le dice, por ejemplo, dnde
empiezan los clientes cuyo nombre comienza por A, por B, etc. Para leer los datos de Juan puede ir
directamente a la posicin del ndice para la J y luego comparar los datos para buscar Juan dentro de ese
bloque. Observe que, en cualquier caso, es necesario leer los datos hasta Juan!
Con la llegada de los dispositivos de acceso directo (como los discos magnticos), surgi la forma de
acceso directo, o aleatorio [London, 19731, a un archivo. El archivo se considera como un conjunto de
registros, cada uno de los cuales puede ser un byte. Se puede acceder al mismo desordenadamente
moviendo el apuntador de acceso al archivo a uno u otro registro. Esta forma de acceso se basa en un
modelo de archivo almacenado en disco, ya que se asume que el dispositivo se puede mover aleatoriamente
entre los distintos bloques que componen el archivo. Para proporcio nar este mtodo de acceso a las
aplicaciones, los sistemas operativos incluyen llamadas del sistema de archivos con las que se puede
modificar la posicin dentro del archivo (seek) o en las que se puede especificar el nmero de registro o
bloque a leer o escribir, normalmente relativos al princi pio del archivo. El sistema operativo relaciona estos
nmeros relativos con nmeros absolutos en los dispositivos fsicos de almacenamiento. Este mtodo de
acceso es fundamental para la imple mentacin de muchas aplicaciones.. Las bases de datos, por ejemplo,
usan fundamentalmente archi vos de este tipo. Imagine que tiene la lista de clientes anterior en un
dispositivo que permite acceso directo. En lugar de leer los datos hasta Juan basta con leer la posicin en el
ndice y saltar hasta dicha posicin. Actualmente, todos los sistemas operativos usan esta forma de acceso,
mediante la cual se puede tambin acceder secuencialmente al archivo de forma muy sencilla, Igualmente,
sobre sistemas de acceso directo se pueden construir fcilmente otros mtodos de acceso como los de
ndice, registros de tamao fijo o variable, etc. (Prestaciones 8. 1).
El uso de cualquiera de las formas de acceso anteriores no resuelve el problema del uso concurrente de un
archivo, sobre todo en el caso de que alguno de los procesos que lo accede est modificando la informacin
existente en dicho archivo. En situaciones de coutilizacin de un archivo, las accio nes de un proceso
pueden afectar a la visin que los otros tienen de los datos o a los resultados de su aplicacin. La semntica
de coutilizacin [Levy, 19901 especifica qu ocurre cuando varios proce sos acceden de forma simultnea
al mismo archivo y especifica el momento en el que las modifica ciones que realiza un proceso sobre un
archivo pueden ser observadas por los otros. Es necesario que el sistema operativo defina la semntica de
coutilizacin que proporciona para que las aplica ciones puedan estar seguras de que trabajan con datos
coherentes. Piense qu ocurrira si varios usuarios modificasen simultneamente los mismos registros de
reservas de un tren sin ningn con trol. El estado final de la base de datos de reservas sera totalmente
impredecible. A continuacin se describen las tres semnticas de coutilizacin ms clsicas en los sistemas
operativos actuales: semntica de UNIX, de sesin y de archivos inmutables.
La semntica de UNIX consiste en que cualquier lectura de archivo vea los efectos de todas las escrituras
previas sobre ese archivo. En caso de accesos concurrentes de lectura, se deben obte ner los mismos datos.
En caso de accesos concurrentes de escritura, se escriben los datos en el orden
de llegada al sistema operativo, que puede ser distinto al que piensan los usuarios. Con esta semn- 8 tica
cada proceso trabaja con su propia imagen del archivo y no se permite que los procesos inde pendientes
compartan el apuntador de posicin dentro de un archivo. Este caso slo es posible para procesos que
heredan los archivos a travs del servicio fork. En este caso, la coutilizacin no slo afecta a los datos, sino
tambin a los metadatos del archivo, ya que una operacin de lectura o escritura modificar el apuntador de
posicin de acceso al archivo. Si los usuarios quieren estar seguros de que los datos se escriben sin
concurrencia, o en el orden correcto, deben usar cerrojos para bloquear los accesos al archivo.
El principal problema de la semntica de UNIX es la sobrecarga que genera en el sistema operativo, que
debe usar cerrojos a nivel interno, para asegurar que las operaciones de un usuario no modifican los
metadatos de otros y que las operaciones de escritura de los usuarios se realizan en su totalidad. Para relajar
esta poltica se defini la semntica de sesin [Walker, 19831, que permite que las escrituras que realiza
un proceso sobre un archivo se hagan sobre su copia y que no sean visibles para los dems procesos que
tienen el archivo abierto hasta que se cierre el archivo o se emita una orden de actualizacin de la imagen
del archivo. Slo en esas situaciones los cambios realizados se hacen visibles para futuras sesiones. El
principal problema de esta semntica es que cada archivo tiene temporalmente varias imgenes distintas,
denominadas versiones. Imagine que se estn modificando los datos de los clientes de una empresa
simultneamente en varias sedes de la misma. Cuando se termina la actualizacin en cada una de ellas se
pide actualizar la versin defini tiva. En caso de que haya procesos que han trabajado ya con el mismo
cliente, se pueden encontrar con que su copia est obsoleta sin saberlo. Es ms, pueden escribir su copia
despus y guardar los
datos obsoletos. Por ello, en caso de que un proceso necesite acceder a los datos que escribe otro proceso,
ambos deben sincronizarse explcitamente abriendo y cerrando el archivo, o forzando actualizaciones de la
versin, lo que puede ser poco eficiente en aplicaciones formadas por un conjunto de procesos cooperantes.
Este tipo de semnticas se utilizan en algunos sistemas de archi vos con versiones de archivos y en sistemas
de archivos distribuidos (Aclaracin 8. 1).
directorio contiene tantas entradas como archivos son accesibles a travs de l, siendo la funcin principal
de los directorios presentar una visin lgica simple al usuario, escondiendo los detalles de implementacin
del sistema de directorios. Un ejemplo de visin lgica del esquema de directo rios de Windows NT, en este
caso un esquema jerrquico, puede verse en la Figura 8.7, donde los archivos se representan mediante
iconos grficos y los directorios se representan mediante carpetas. Esta representacin permite visualizar
grficamente la estructura de los directorios a travs de aplicaciones del sistema, en este caso Microsoft
Explorer. Adems permiten visualizar con prefe rencia ciertos tipos de archivos, como ejecutables o
archivos de procesadores de textos, y asociarlos con aplicaciones que se ejecutan de forma automtica
cuando se pulsa con el ratn sobre dichos archivos.
Cuando se abre un archivo, el sistema operativo busca en el sistema de directorios hasta que encuentra la
entrada correspondiente al nombre del archivo. A partir de dicha entrada, el sistema operativo obtiene el
identificador interno del archivo y, posiblemente, algunos de los atributos del mismo. Esta informacin
permite pasar del nombre de usuario al objeto archivo que maneja el sistema operativo. Todas las
referencias posteriores al archivo se resuelven a travs de su descriptor (nodo-i, registro MFT, etc.).
Al igual que un archivo, un directorio es un objeto y debe ser representado por una estructura de datos. Una
cuestin importante de diseo es decidir qu informacin debera ir asociada a una entrada del directorio.
La Figura 8.8 muestra varias entradas de directorio usadas en sistemas opera tivos. Como puede verse en la
figura, hay dos alternativas principales:
Almacenar los atributos del archivo en su entrada del directorio.
Almacenar nicamente el identificador del descriptor de archivo (en UNIX, el nodo-i) y colocar los
atributos del objeto archivo dentro de la estructura de datos asociada a su des criptor.
Los sistemas operativos modernos usan la ltima solucin, porque tiene varias ventajas que la primera. Sin
embargo, existen sistemas operativos, como CPM o MS-DOS, que almacenan atribu tos del archivo en su
entrada del directorio. CP/M [ Zaks, 1980] tiene un nico directorio, en el que cada entrada incluye toda la
informacin suficiente para acceder al archivo asociado (Fig. 8.8). Por tanto, una vez encontrado el nombre
del archivo dentro del directorio, se dispone de sus atributos, su tipo y un nmero mximo de bloques de
disco asociados al archivo. Si se necesitan ms bloques de datos es necesario asignar una nueva entrada de
directorio y fijar su posicin dentro del archivo (1 a, 2. etc.) mediante el campo extendido. Esta solucin
slo permite esquemas de nombres de un nico nivel. MS-DOS [Norton, 1988] tiene entradas de directorio
de 32 bytes que contienen el nombre del archivo, sus atributos, valores de tiempos y el primer bloque de
disco del archivo. A partir de este bloque, el sistema de archivos accede a una tabla de bloques del
dispositivo (FAT), dentro de la cual puede acceder a bloques sucesivos del archivo por hallarse
encadenados mediante una lista. La principal diferencia entre esta solucin y la de CPM es que en MS-
DOS una entrada del directorio puede a su vez representar a otro directorio, con lo que se pueden definir
esquemas jerrquicos de nombres. Adems, el lmite en la extensin del archivo ya no est incluido en la
entrada del directorio, sino que depende del tamao de la FAT.
En el diseo del sistema operativo UNIX se adopt la segunda alternativa, por lo que la entrada de
directorio es una estructura de datos muy sencilla (Fig. 8.8) que contiene nicamente el nombre del archivo
asociado a ella y el identificador del descriptor de archivo, nmero de nodo-i, usado por el sistema
operativo [ 19941. Toda la informacin relativa a los atributos del archivo se almacena en su nodo-i. El uso
de una entrada de directorio como la de UNIX tiene varias ventajas:
La entrada de directorio no se ve afectada por los cambios de atributos del archivo.
Los nodos-i pueden representar a su vez directorios o archivos, con lo que se pueden cons truir esquemas
de nombres jerrquicos de forma sencilla.
Independientemente de cmo se defina la entrada de un directorio, es necesario organizar todas las entradas
de directorio para poder manejar los archivos existentes en un sistema de almacenamiento de forma sencilla
y eficiente. La forma de estructurar dichas entradas vara de unos sistemas a otros dependiendo de las
necesidades de cada sistema.
En sistemas operativos antiguos, como CP/M, se usaron estructuras de directorio de nivel nico y
directorios con dos niveles (Fig. 8.9). En la primera existe un nico directorio que contie ne todas las
entradas de archivos. Es fcil entender e implementar, pero asignar nombre a un archi vo nuevo no es fcil
por la dificultad de recordar todos los nombres o la imposibilidad de ver los de otros usuarios. En CP/M,
para evitar este problema, el nmero mximo de archivos que poda haber en un sistema de archivos estaba
significativamente limitado. Esto reduce el problema de gestin de nombres, pero limita el nmero de
archivos en un dispositivo de almacenamiento. Cuando creci la capacidad de los dispositivos de
almacenamiento, se resolvi el problema anterior extendiendo la estructura a un directorio de dos niveles,
donde cada usuario dispona de su propio directorio, reduciendo as una parte de la confusin inherente a
los directorios de nivel nico. Cuando se daba de alta un nuevo usuario en el sistema, las utilidades de
administracin del sistema
operativo creaban el directorio para los archivos del usuario con un nombre fijado con criterios internos al
sistema. Cuando el usuario entra al sistema, se le pona dentro de su directorio. Para acceder a sus archivos
poda hacer dos cosas: especificar slo el nombre del archivo relativo a su directorio (p. ej.: claves) o
especificar el nombre completo del archivo incluyendo dispositivo. directorio del usuario y nombre de
archivo (p. ej.: C: \miguel\c laves). Esta estructura mejoraba la seguridad al aislar a los usuarios, pero no se
evitaba otros problemas, tales como la gestin de nombres propios de un usuario, la imposibilidad de
agrupar los archivos de un mismo usuario con distintos criterios o el uso compartido de archivos.
Supongamos, por ejemplo, que un alumno tiene varios archivos de prcticas. Todos ellos estaran bajo el
mismo directorio, pero no podra agrupar los de las prcticas de sistemas operativos o las de arquitectura de
computadoras. Suponga ahora que la practica se lleva a cabo por un grupo de alumnos, Corno pueden
compartir los archivos de la misma? Con esta estructura sera necesario copiar los archivos en los
directorios de todos ellos, con el peligro consiguiente de incoherencias entre las distintas copias, o crear un
nuevo usuario (p. ej.: grupo-l) y poner en su directorio los archivos compartidos. Esta solucin era la
adoptada para permitir que todos los usuarios vieran las utilidades del sistema operativo sin tener que hacer
mltiples copias: crear un usuario especial, denominado sistema, en cuyo directorio se incluan dichas
utilidades con permisos de lectura y ejecucin para todos los usuarios.
A medida que la capacidad de los dispositivos se fue incrementando, fueron tambin creciendo el nmero
de archivos almacenados por los usuarios en el sistema de archivos. Con lo que el problema de la
complejidad del nombrado, paliado por la estructura de dos niveles, volvi a parecer
a nivel de usuario. Fue pues necesario generalizar la estructura de dos niveles para obtener una estructura
jerrquica ms general que permitiera a los usuarios ordenar sus archivos con criterios lgicos en sus
propios subdirectorios, sin depender de las limitaciones de los niveles de la estructura de directorios
[Organick, 1972], lo que llev a la estructura de rbol. Una estructura de rbol representa todos los
directorios y subdirectorios del sistema partiendo de un directorio raz, exis tiendo un camino nico (path)
que atraviesa el rbol desde la raz hasta un archivo determinado. Los nodos del rbol son directorios que
contiene un conjunto de subdirectorios o archivos. Las hojas del rbol son siempre archivos. Normalmente,
cada usuario tiene su propio directorio home a partir del cual se cuelgan sus subdirectorios y archivos y en
el que le sita el sistema operativo cuando entra a su cuenta. Este directorio lo decide el administrador, o
los procesos de creacin de nuevos usuarios, cuando el usuario se da de alta en el sistema y est
almacenado junto con otros datos del usuario en una base de datos o archivo del sistema operativo. En el
caso de UNIX, por ejemplo, el archivo /etc/password contiene una lnea por usuario del sistema, similar a la
siguiente:
miguel: * :Miguel: /users/miguel: /etc/bin
donde el directorio home es /users/miguel. MS-DOS y Windows NT tienen registros de usua rios que
tambin definen el directorio home.
Los usuarios pueden subir y bajar por el rbol de directorios, mediante servicios del sistema operativo,
siempre que tengan los permisos adecuados. Por ello, tanto el propio usuario como el sistema operativo
deben conocer dnde estn en cada instante. Para solventar este problema se defini el concepto de
directorio de trabajo, que es el directorio en el que un usuario se encuentra en un instante determinado.
Para crear o bonar un archivo o directorio se puede indicar su nombre relativo al directorio de trabajo o
completo desde la raz a las utilidades del sistema que llevan a cabo estas operaciones. Un problema
interesante con este tipo de estructura es cmo borrar un directorio no vaco. Hay dos soluciones posibles:
Un directorio no se bona si no est vaco. Si tiene archivos o subdirectorios, el usuario debe borrarlos
previamente. Esta es la solucin adoptada habitualmente en las llamadas a los sistemas operativos.
Un directorio, y todo el subrbol de directorios que cuelga de l, es borrado, aunque el subrbol no est
vaco. Esta solucin existe en UNIX y Windows NT, aunque no como llamada al sistema sino como
mandato de usuario. Para evitar que un usuario borre archivos por error se solicita una confirmacin del
usuario, va opcin en el mandato UNIX o confir macin en un men grfico en Windows NT. Si la
respuesta es afirmativa, se borra todo el subrbol recursivamente.
La estructura de rbol es muy general, pero no proporciona los servicios requeridos en algunos entornos.
Por ejemplo, puede ser interesante que varios programadores trabajando en el mismo proyecto compartan
archivos o subdirectorios llegando a los mismos por sus respectivos directorios de usuario para no tener
problemas de seguridad y proteccin. Esta forma de acceso no existe en la estructura de rbol porque exige
que a un archivo se llegue con nico nombre. El modelo descrito, sin embargo, rompe la relacin uno a uno
entre el nombre y el archivo, al requerir que un mismo archivo pueda ser accedido a travs de varios
caminos. Este problema puede resolverse generali zando la estructura del rbol de directorio para
convertirla en un grafo acclico (Fig. 8. 1 1) en el cual el mismo archivo o subdirectorio puede estar en dos
directorios distintos, estableciendo una relacin unvoca nombre-archivo. La forma ms habitual de
compartir archivos es crear un enlace al archivo compartido [Bach, 1986] de uno de los dos tipos
siguientes:
Fsico. Un apuntador a otro archivo o subdirectorio, cuya entrada de directorio tiene el mismo descriptor
de archivo (en UNIX, el nodo-i) que el archivo enlazado. Ambos nombres apuntan al mismo archivo.
Resolver cualquiera de los nombres de sus enlaces nos devuelve el descriptor del archivo.
Simblico. Un nuevo archivo cuyo contenido ese! nombre del archivo enlazado. Resolver el nombre del
enlace simblico no da el descriptor del destino, sino el descriptor del archivo en el que est el nombre del
destino. Para acceder al destino, hay que abrir el archivo del enlace, leer el nombre del destino y resolverlo.
Para tener constancia de los enlaces fsicos que tiene un archivo, se ha aadido un nuevo atributo al nodo-i
denominado contador de enlaces. Cuando se crea un enlace a un archivo, se incrementa en su nodo-i del
archivo un contador de enlaces fsicos. Cuando se rompe el enlace, se decrementa dicho contador. La
existencia de enlaces introduce varios problemas en este tipo de estructura de directorio:
Existen varios nombres para el mismo archivo. Si se quiere recorrer todo el rbol, es impor tante evitar los
bucles (Advertencia 8.1).
El borrado de archivos se complica, ya que un mismo archivo puede ser borrado por varios caminos. Es
necesario pues determinar cundo se puede borrar el archivo. En UNIX, el archivo no se borra hasta que no
existe ninguna referencia al mismo, lo que significa que el valor del contador de enlaces es cero. Para ello,
cuando se borra un archivo, se borra la entrada de directorio que referencia al archivo y se decrementa su
contador de enlaces. Slo en el caso de que el contador de enlaces sea cero y de que nadie tenga abierto el
archivo se borra el archivo realmente y se liberan sus recursos.
Para evitar los problemas anteriores, algunos sistemas operativos, como MS-DOS, no permi ten la
existencia de directorios compartidos o enlaces.
El nombre absoluto de un archivo proporciona todo el camino a travs del rbol de directo rios desde la
raz hasta el archivo. Por ejemplo, en UNIX, un nombre absoluto de uno de los archivos existentes en la
Figura 8.11 sera /users/mguel/claves. Este nombre indica al siste ma de archivos que a partir del directorio
raz (1) se debe atravesar el directorio users y, dentro de este ltimo, el subdirectorio miguel para llegar al
archivo claves. En MS-DOS, dicho nombre absoluto se representara como C: \users\miguel\claves. Un
nombre absoluto es autoconteni do, en el sentido de que proporciona al sistema de archivos toda la
informacin necesaria para llegar al archivo, sin que tenga que suponer o aadir ninguna informacin de
entorno del proceso o interna al sistema operativo. Algunas aplicaciones necesitan este tipo de nombres
para asegurar que sus programas funcionan independiente del lugar del rbol de directorios en que estn
situados. Por ejemplo, un compilador de lenguaje C, en una mquina que ejecuta el sistema operativo
UNIX, necesita saber que los archivos con definiciones de macros y tipos de datos estn en el directorio
/usr/include. Es necesario especificar el nombre absoluto porque no es posible saber en qu directorio del
rbol instalar cada usuario el compilador.
La Figura 8.12 muestra, para el sistema operativo UNIX, las tablas que almacenan algunos de los
directorios especificados en la Figura 8.1 1. Como puede verse, el directorio raz tiene un nme ro de nodo-
i predefinido en UNIX, el 2. A partir de sus entradas se puede interpretar cualquier nombre absoluto. Por
ejemplo, el nombre absoluto /users/miguel/claves se interpretara de la siguiente forma:
1. Se traen a memoria las entradas existentes en el archivo con nodo-i 2.
2. Se busca dentro de ellas el nombre users y se extrae su nodo-i, el 342.
3. Se traen a memoria las entradas del archivo con nodo-i 342.
4. Se busca dentro de ellas el nombre miguel y se extrae su nodo-i, el 256.
5. Se repite el proceso con este nodo-i hasta que se encuentra el archivo claves y se obtiene su nodo-i, el
758.
La interpretacin de estos nombres en MS-DOS sera similar, pero, en lugar de usar el nodo-i para acceder
a los bloques que contienen entradas de directorios, se usa la tabla FAT, por lo que los nmeros de nodo-i
reseados en el ejemplo se sustituiran por nmeros de bloques de la FAT.
Cmo se sabe cundo parar la bsqueda? Hay tres criterios bien definidos:
Se ha encontrado el archivo cuyo nombre se ha especificado, en cuyo caso se devuelve el nodo-i del
archivo.
No se ha encontrado el archivo y estamos en el ltimo subdirectorio especificado en el nombre absoluto
(miguel). Este caso devuelve error.
sistema de archivos a otro sin que sea aparente en ningn momento el nombre del dispositivo fsico o lgico
que almacena el sistema de archivos. Las dos llamadas al sistema de UNIX que realizan estas operaciones
son mount y umount [ 19851. La operacin de montado permite conectar un sistema de archivos,
almacenado en un volumen o particin, a una entrada de directorio del rbol de directorios existente. A
partir de dicha operacin, el sistema de archivos en el nuevo dispositivo aparece como un subrbol del rbol
de directorios, sin que exista diferencia con el resto del mismo. Sus archivos y directorios son accesibles a
travs del nombre lgico. Por ejemplo, para montar /dev/hda3 de forma que se construya un rbol de
directorios como el de la Figura 8.12 se ejecuta ra el siguiente mandato:
mount /dev/hda3 /users
Desmontar (umount) un sistema de archivos es sencillo. Por ejemplo, para desconectar el
dispositivo /dev/hda3 montado en el directorio /users del sistema de archivos raz bastara con ejecutar el
mandato:
umount /users
Si no se est usando ningn archivo o directorio del sistema de archivos existente en
/dev/hda3, el sistema operativo lo desconecta. A partir de ese instante, el subrbol de directorios del
dispositivo no aparecer en la jerarqua de directorios y sus datos no estarn accesibles.
Las operaciones anteriores tienen dos ventajas:
1. Ofrecen una imagen nica del sistema.
2. Ocultan el tipo de dispositivo que est montado sobre un directorio.
Sin embargo, tambin tienen inconvenientes:
1. Complican la traduccin de nombres lgicos de archivos.
2. Dan problemas cuando se quiere establecer un enlace fsico entre dos archivos. Debido a estos
problemas, en UNIX slo se puede establecer un enlace fsico entre dos archivos que se encuentran en el
mismo sistema de archivos. Nunca de un archivo a otro existente en un sistema de archivos distinto.
En la Seccin 8.6, dedicada al servidor de archivos, se explica con ms detalle cmo se imple mentan las
operaciones anteriores.
Un archivo es un tipo abstracto de datos. Por tanto, para que est completamente definido, es necesario
definir las operaciones que pueden ejecutarse sobre un objeto archivo. En general, los sistemas operativos
proporcionan operaciones para crear un archivo, almacenar informacin en l y recuperar dicha
informacin ms tarde.
En la mayora de los sistemas operativos modernos los directorios se implementan como archi vos que
almacenan una estructura de datos definida: entradas de directorios. Por ello, los servicios de archivos
pueden usarse directamente sobre directorios. Sin embargo, la funcionalidad necesaria para los directorios
es mucho ms restringida que la de los archivos, por lo que los sistemas operati vos suelen proporcionar
servicios especficos para satisfacer dichas funciones de forma eficiente y sencilla.
En esta seccin se muestran los servicios genricos ms frecuentes para archivos y directorios. A
continuacin, se estudia la concrecin de dichos servicios propuesta en el estndar POSIX [IEEE, 19881, y
en Win32, y se muestran ejemplos de uso de dichos servicios.
Usando servicios de POSIX se pueden consultar los atributos de un archivo. Estos atributos son una parte
de la informacin existente en el descriptor interno del archivo (nodo-i). Entre ellos se encuentran el
nmero de nodo-i, el sistema de archivos al que pertenece, su dispositivo, tiempos de creacin y
modificacin, nmero de enlaces fsicos, identificacin de usuario y grupo, tamao ptimo de acceso, modo
de proteccin, etc. El modo de proteccin es especialmente importante porque permite controlar el acceso
al archivo por parte de su dueo, su grupo y el resto del mundo. En POSIX, estos permisos de acceso se
especifican usando mscaras de 9 bits con el siguiente formato:
dueo grupo mundo
rwx rwx rwx
Variando los valores de estos bits, se pueden definir los permisos de acceso a un archivo. Por ejemplo, 755
indica rwxr-xr-x. En el Captulo 9 se estudia este tema con ms profundidad.
En esta seccin se describen los principales servicios de archivos descritos en el estndar POSIX [IEEE,
1988]. Estos servicios estn disponibles en prcticamente todos los sistemas operati vos modernos.
Crear un archivo
Este servicio permite crear un nuevo objeto archivo. El prototipo de la llamada es:
int creat(const char *path, modet mode)
Su efecto es la creacin de un archivo con nombre path y modo de proteccin mode. El resultado es un
descriptor de archivo interno al proceso que cre el archivo y que es el descriptor de archivo ms bajo sin
usar en su tabla de descriptores. El archivo queda abierto slo para escritura. En caso de que el archivo
exista, se trunca. En caso de que el archivo no pueda ser creado, devuelve -1 y pone el cdigo de error
adecuado en la variable errrno.
Borrar un archivo
Este servicio permite borrar un archivo indicando su nombre. Si el archivo no est referenciado por ningn
nombre ms (lo que en UNIX equivale a decir que el contador de los enlaces del nodo-i es cero) y nadie lo
tiene abierto, esta llamada libera los recursos asignados al archivo, por lo que queda inaccesible. Si el
archivo est abierto, se pospone su eliminacin hasta que todos los procesos lo hayan cerrado. El prototipo
de este servicio es:
int unlink(const char *path)
El argumento path indica el nombre del archivo a borrar.
Abrir un archivo
Este servicio establece una conexin entre un archivo y un descriptor de archivo abierto, interno al proceso
que lo ha abierto. El resultado de su ejecucin es el descriptor de archivo libre ms bajo de su tabla de
descriptores. El prototipo de la llamada es:
int open(const char *path, mt oflag, /* modo t mode */ ..) ;
El argumento path define el nombre del archivo a abrir. El argumento of lag permite especi ficar qu tipo de
operacin se quiere hacer con el archivo: lectura (O_RDONLY), escritura (O_WRONLY), lectura-escritura
(O_RDWR). aadir informacin nueva (O_ APPEND), creacin, trunca do, escritura no bloqueante, etc. En
caso de especificar creacin del archivo (O_CREAT) se debe especificar el modo de proteccin del mismo,
siendo el efecto de la llamada equivalente al servicio creat. Por ejemplo, creat (archivo, 0751) es
equivalente a operi (archivo, O_WRONLY O_CREAT (O_TRUNC, 0751). Si el archivo no existe, no se
puede abrir con las caracte rsticas especificadas o no se puede crear, la llamada devuelve -l y un cdigo de
error en la variable errno.
Cerrar un archivo
La llamada close libera el descriptor de archivo obtenido cuando se abri el archivo, dejndolo disponible
para su uso posterior por el proceso. El prototipo de la llamada es el siguiente:
int close(int fildes);
Si la llamada termina correctamente, se liberan los posibles cerrojos sobre el archivo fijados por el proceso
y se anulan las operaciones pendientes de E/S asncrona. Adems, si ningn proceso lo tiene abierto (es
decir, en UNIX el contador de aperturas del nodo-i es cero) se liberan los recursos del sistema operativo
ocupados por el archivo, incluyendo posibles proyecciones en me moria del mismo.
Leer datos de un archivo
Este servicio permite a un proceso leer datos de un archivo, que debe abrirse previamente, y copiar- los a su
espacio de memoria. El prototipo de la llamada es:
ssize_t read(int fildes, void *buf, sizet nbyte);
El descriptor de archivo se indica en fildes, la posicin de memoria donde copiar los datos se especifica en
el argumento buf y el nmero de bytes a leer se especifica en nbyte. La lectura se lleva a cabo a partir de la
posicin actual del apuntador de posicin del archivo. Si la llamada se ejecuta correctamente, devuelve el
nmero de bytes ledos realmente, que pueden ser menos que los pedidos, y se incrementa el apuntador de
posicin del archivo con esa cantidad. Si se intenta leer ms all del fin de archivo, la llamada devuelve un
cero. Si se intenta leer en una posicin interme dia de un archivo que no ha sido escrita previamente, la
llamada devuelve bytes con valor cero.
Escribir datos a un archivo
Esta llamada permite a un proceso escribir en un archivo una porcin de datos existente en el espacio de
memoria del proceso. Su prototipo es:
ssize_t write(int fildes, const void *buf, size_t nbyte);
El descriptor de archivo se indica en fildes, la posicin de memoria donde copiar los datos se especifica en
el argumento buf y el nmero de bytes a escribir se especifica en nbyte. La escritura se lleva a cabo a partir
del valor actual del apuntador de posicin del archivo. Si la llamada se ejecuta correctamente, devuelve el
nmero de bytes escritos realmente y se incrementa el valor del apuntador de posicin del archivo. Si la
escritura va ms all del fin de archivo, se incrementa el tamao del mismo. Si se especific O_APPEND
en la apertura del archivo, antes de escribir se pone el apuntador de posicin al final del archivo, de forma
que siempre se aade la informacin al final.
Cambio del apuntador de un archivo
Esta llamada permite cambiar el valor del apuntador de posicin de un archivo abierto, de forma que
posteriores operaciones de E/S se ejecuten a partir de esa posicin. Su prototipo es:
off_t lseek(int fildes, offt offset, mt whence);
El descriptor de archivo se indica en Ludes, el desplazamiento se indica en offset y el lugar de referencia
para el desplazamiento se indica en whence. Hay tres formas de indicar la posicin de referencia para el
cambio de apuntador: SEEK_SET, el valor final del apuntador es offset; SEEK CUR, el valor final del
apuntador es el valor actual ms offset; SEEK el valor final es la posicin de fin de archivo ms offset. Si la
llamada se ejecuta correctamente. devuelve el nuevo valor del apuntador de posicin del archivo. Esta
llamada permite ir ms all del fin del archivo, pero no modifica el tamao del mismo. Para que esto ocurra
hay que escribir algo en dicha posicin.
rrespondiente a la representacin de ese objeto archivo. Al igual que en POSIX, los procesos pue den
obtener manejadores de objetos estndar para entradalsalida (GetstdHandle, Set StdHand le). El objetivo
de estos descriptores estndares es poder escribir programas que sean independien tes de los archivos sobre
los que han de trabajar.
Usando servicios de Win32 se pueden consultar los atributos de un archivo. Estos atributos son una parte de
la informacin existente en el manejador del objeto. Entre ellos se encuentran el nombre, tipo y tamao del
archivo, el sistema de archivos al que pertenece, su dispositivo, tiempos de creacin y modificacin,
informacin de estado, apuntador de posicin del archivo, informacin sobre cerrojos, proteccin, etc. El
modo de proteccin es especialmente importante porque permite controlar el acceso al archivo por parte de
los usuarios. Cada objeto archivo tiene asociado un descriptor de seguridad, que se describe detalladamente
en el Captulo 9.
A continuacin, se muestran los servicios ms comunes para gestin de archivos que propor ciona Win32 [
19971. Como se puede ver, son similares a los de POSIX, si bien los prototipos de las funciones que los
proporcionan son bastante distintos.
Borrar un archivo
Este servicio permite borrar un archivo indicando su nombre. Esta llamada libera los recursos asignados al
archivo. El archivo no se podr acceder nunca ms. El prototipo de este servicio es:
BOOL DeleteFile(LPCTSTR lpszFileName);
El nombre del archivo a borrar se indica en lpszFileName. Devuelve TRUE en caso de xito o FALSE en
caso de error.
Cerrar un archivo
La llamada CloseHandie libera el descriptor de archivo obtenido cuando se abri el archivo, dejndolo
disponible para su uso posterior. El prototipo de la llamada es el siguiente:
BOOL CloseHandle(HANDLE hObject);
Si la llamada termina correctamente, se liberan los posibles cerrojos sobre el archivo fijados por el proceso,
se invalidan las operaciones pendientes y se decrementa el contador del manejador del objeto. Si el
contador del manejador es cero, se liberan los recursos ocupados por el archivo. Dv TR en caso de xito o
FALSE en caso de error.
Para ilustrar el uso de los servicios de archivos que proporciona el sistema operativo se presenta en esta
seccin el ejemplo de copia de un archivo sobre otro, pero usando llamadas de Win32.
El cdigo fuente en lenguaje C que se corresponde al ejemplo propuesto se muestra en el Programa 8.2.
Para ver ms ejemplos de programacin, consulte [ Hart, 1997] y [Andrews, 1996].
Para ilustrar el uso de las funciones de conveniencia de servicios de archivos que proporciona Win32 se
resuelve tambin en esta seccin el ejemplo de copia de un archivo sobre otro COfl la llamada CopyFile. El
cdigo fuente en lenguaje C que se corresponde al ejemplo propuesto se muestra en el Programa 8.3. Como
se puede ver, comparando con el Programa 8.2, esta funcin se encarga de abrir y crear los archivos, leer y
escribir los datos y cerrar los archivos (Prestaciones 8.2).
Programa 8.3. Copia de un archivo sobre otro usando funciones de conveniencia de Win32.
finclude <windows . h>
#include <stdio.h>
mt main (mt argc, LPCTSTR argv [
if (argc 3)
fprintf (stderr, Uso: copiar archivol archivo2 \nfl;
return -1;
if (!CopyFile (aigv argv FALSE)) {
fprintf (stderr, Error de copia: %x \n, GetLastError());
}
return O;
}
Un objeto directorio est formado bsicamente por un conjunto de entradas que relacionan nombres y
archivos y las operaciones para manejar dichas entradas. Estas entradas pueden tener diferente estructura,
pero en cualquier caso deben poder ser creadas, borradas, abiertas, cerradas y ledas. Adems, es importante
poder recorrer la estructura de directorios y cambiar nombres de archivos. En algunos sistemas, como
UNIX, se puede tambin crear y romper enlaces a archivos y directo ri os.
A continuacin, se hace una breve descripcin de los principales servicios genricos para directorios.
Crear un directorio. Crea un objeto directorio y lo sita en el lugar del rbol de directorios donde
se especifique en el nombre, absoluto o relativo, del nuevo directorio. En el caso de POSIX, se
aaden automticamente al nuevo directorio las entradas . y
Borrar un directorio. Elimina el objeto directorio de forma que nunca ms pueda ser acce sible y
borra su entrada del rbol de directorios. Habitualmente, y salvo casos especiales. slo se puede
borrar un directorio vaco (sin entradas).
Abrir un directorio. Abre el archivo que contiene el directorio para leer los datos del mismo. Al
igual que un archivo, un directorio debe ser abierto para poder manipular su contenido.
Cerrar un directorio. Cierra el archivo que contiene el directorio, liberando los recursos de
memoria y del sistema operativo relativos al mismo.
Leer un directorio. Extrae la siguiente entrada de un directorio abierto. Devuelve una es tructura
de datos como la que define la entrada de directorio. Por tanto, es especfica de cada interfaz o
sistema operativo.
Cambiar directorio. Este servicio permite al usuario cambiar su directorio de trabajo.
Enlazar. Permite acceder a un archivo o directorio existente mediante un nuevo nombre. Existe
una operacin inversa que permite desenlazar una entrada de un directorio. No estn disponibles en
todos los sistemas operativos, aunque s en el estndar POSIX.
Los servicios anteriores son los ms comunes en distintos sistemas operativos, si bien existen algunos otros
que no vamos a .describir en este libro. Se remite al lector a los manuales de cada sistema operativo en
particular para ver informacin acerca de otras llamadas.
dicha gestin, y evitar el problema de gestin de las entradas de directorio, el estndar POSIX define los
servicios especficos que debe proporcionar un sistema operativo para gestionar los di rectorios. En general,
se ajustan a los servicios genricos descritos en la seccin anterior. A conti nuacin se describen los
servicios de directorios ms comunes del estndar POSIX.
Crear un directorio
El servicio mkdir permite crear un nuevo directorio en POSIX. Su prototipo es:
int mkdir (const char *path, mode_t mode);
Esta llamada al sistema crea el directorio especificado en path con el modo de proteccin especificado en
mode. El dueo del directorio es el dueo del proceso que crea el directorio. En caso de xito devuelve un
cero. En caso de error un -1.
Borrar un directorio
El estndar POSIX permite borrar un directorio especificando su nombre. El prototipo de la llama da es:
int rmdir (const char *path);
El directorio se borra nicamente cuando est vaco. Para borrar un directorio no vaco es obligatorio borrar
antes sus entradas. Esta llamada devuelve cero en caso de xito y l en caso de error. El comportamiento
de la llamada no est definido cuando se intenta borrar el directorio raz o el directorio de trabajo. Si el
contador de enlaces del directorio es mayor que cero, se decrementa dicho contador y se borra la entrada
del directorio, pero no se liberan los recursos del mismo hasta que el contador de enlaces es cero.
Abrir un directorio
La funcin opendir abre el directorio de nombre especificado en la llamada y devuelve un identi ficador de
directorio. Su prototipo es.
DIR *opendir(const char *dirname);
El apuntador de posicin indica a la primera entrada del directorio abierto. En caso de error
devuelve NULL.
Cerrar un directorio
Un directorio abierto, e identificado por dirp, puede ser cerrado ejecutando la llamada:
int closedir (DIR *dirp);
En caso de xito devuelve O y -l en caso de error.
Leer un directorio
Este servicio permite leer de un directorio abierto, obteniendo como resultado la siguiente entrada del
mismo. Su prototipo es:
struct dirent *readdir (DIR *dirp);
En caso de error, o de alcanzar el final del directorio, devuelve NULL. Nunca devuelve entradas cuyos
nombres estn vacos.
Cambiar de directorio
Para poder viajar por la estructura de directorios, POSIX define la llamada chdir, cuyo prototipo es:
int chdir (const char *path);
El directorio destino se especifica en path. Si se realiza con xito, esta llamada cambia el directorio de
trabajo, es decir, el punto de partida para interpretar los nombres relativos. Si falla, no se cambia al
directorio especificado.
Crear un enlace a un directorio
POSIX permite que un archivo o directorio pueda ser accedido usando nombres distintos. Para ello,
proporciona las llamadas link y symlink para enlazar un archivo o directorio a otro usando enlaces fsicos o
simblicos, respectivamente. Sus prototipos son:
int link (const char *exmstmng, const char *new);
int symlink (const char *exjstjng, const char *new);
La llamada link establece un enlace fsico desde una nueva entrada de directorio, new, a un archivo ya
existente, existing. Ambos nombres deben pertenecer al mismo sistema de archivos. En caso de xito, crea
la nueva entrada de directorio, incrementa el contador de enlaces del nodo-i del directorio o archivo
existente y devuelve un cero.
La llamada syinlink establece un enlace simblico desde una nueva entrada de directorio, new, a un archivo
ya existente, existing. No es necesario que ambos nombres pertenezcan al mismo sistema de archivos. En
caso de xito, crea la nueva entrada de directorio del enlace y devuelve un cero.
En caso de error, las llamadas no crean el enlace y devuelven -1.
En esta seccin se presentan dos pequeos programas en lenguaje C que muestran las entradas de un
directorio, cuyo nombre se recibe como argumento.
El Programa 8.4 muestra dichas entradas por la salida estndar del sistema. Para ello, el pro grama ejecuta
la siguiente secuencia de acciones:
1. Muestra el directorio actual.
2. Imprime el directorio cuyo contenido se va a mostrar.
3. Abre el directorio solicitado.
4. Mientras existan entradas en el directorio, lee una entrada e imprime el nombre de la misma.
5. Cierra el directorio.
El cdigo fuente en lenguaje C que se corresponde al ejemplo propuesto se muestra en el
Programa 8.4.
Programa 8.4. Programa que muestra las entradas de un directorio usando llamadas POSIX.
#include <sys/types .h> #include <dirent .h> #include <stdio.h> #include <error.h>
*define TAMANYOALM 1024
void main (mt argc, char **argv)
DIRP *dirp; struct dirent *dp; char almacen /* Comprueba que el nmero de
En caso contrario, termina
if (argc 2)
fprintf (stderr, Uso: mi_ls directorio\n);
exit(1)
/* Obtener e imprimir el directorio actual */ getcwd (almacen, TAMANYO_ALM);
printf (Directorio actual: %s \n, almacen); /* Abrir el directorio recibido como argumento *1 dirp =
opendir (argv [ 1] );
if (drp == NULL) {
fprintf (stderr, No se pudo abrir el directorio: %s \n,
argv [ 1]);
perror ();
exit (1);
}
else
{
printf (Entradas en el directorio: %s \n. argv /* Toer el directorio entrada a entrada */
while ((dp = readdir(dirp)) MILL)
printf (%s\n, dp->d_name); /* Imprimir nombre* /
closedir (dirp);
}
exit (O);
}
Obsrvese que la ejecucin de este programa ejemplo no cambia el directorio de trabajo ac tual. Por ello, si
se usan nombres absolutos, y se tienen los permisos adecuados, se pueden ver los contenidos de cualquier
directorio sin movernos del actual. Adems del nombre, la estructura de directorio incluye otra informacin
que puede verse sin ms que aadir las instrucciones para impri mir su contenido. El mandato ls de UNIX
se implementa de forma similar al ejemplo.
El Programa 8.5 copia el contenido del directorio a un archivo, cuyo nombre se recibe como parmetro.
Para ello, ejecuta acciones similares a las del Programa 8.4, pero adems redirige el descriptor de salida
estndar hacia dicho archivo. El mandato ls > archivo de UNIX se imple menta de forma similar al ejemplo.
Esta llamada al sistema crea el directorio especificado en lpPathName con el modo de protec cin
especificado en lpSecurityAt tributes. El nombre del directorio puede ser absoluto para el dispositivo en que
est el proceso o relativo al directorio de trabajo. En caso de xito devuelve
TRUE.
Borrar un directorio
Win32 permite borrar un directorio especificando su nombre. El prototipo de la llamada es:
BOOL RemoveDirectory (LPCSTR lpszPath);
El directorio lpszpath se borra nicamente cuando est vaco. Para borrar un directorio no
vaco es obligatorio borrar antes sus entradas. Esta llamada devuelve TRUE en caso de xito.
Leer un directorio
En Win32 hay tres servicios que permiten leer un directorio: FindFirstFile, FindNextFiie y FindClose. Su
prototipos son:
HANDLE FindFirstFile (LPCSTR lpFileName,
LPWin32_FIND_DATA lpFindFileData);
BOOL FindNextFi1e(HAJ hFindFile,
LPWin32_FIND_DATA lpFindFileData);
BOOL FindClose(HANDLE hFindFile);
FindFirstFile es equivalente al opendir de POSIX. Permite obtener un manejador para buscar en un
directorio. Adems, busca la primera ocurrencia del nombre de archivo especificado en lpFileName.
FindNextFile es equivalente al readdir de POSIX, permite leer la siguiente entrada de archivo en un
directorio. FindClose es equivalente a closedir de POSIX y permite cerrar el manejador de bsqueda en el
directorio.
Para ilustrar el uso de los servicios de archivos que proporciona Win32, se resuelve en esta seccin un
ejemplo que muestra las entradas del directorio de trabajo. El cdigo fuente, en lenguaje C, del ejemplo
propuesto se muestra en el Programa 8.6.
Programa 8.6. Programa que muestra las entradas del directorio de trabajo usando llamadas Win32.
*include <windows . h>
*inclLude <direct.h> #include <stdio.h>
#define LONGITUD NOMBRE MAX_PATH + 2
mt main (mt argc, LPTSTR argv {])
BOOL Flags [ LPTSTR pSlash, pNombreArchivo; mt i, IndiceArchivo; /* Almacn para el nombre del
directorio */ TCHAR Almacenpwd [ DWORD CurDirLon; / Manejador para el directorio */ HANDLE
SearchHandle; Win32_FINDDATA FindData;
/* Obtener el nombre del directorio de trabajo *1
CurDirLon = GetCurrentDirectory (LONGITUD_NOMBRE, Almacenpwd);
if (CurDirLon == O) printf(Eallo al obtener el directorio. Error: %x\n, GetLastError ) return 1;
if (CurDirLon > LONGITUD_NOMBRE) printf( de directorio demasiado largo. Error: %x\n,
GetLastError () );
return -1;
/* Todo est bien. Leer e imprimir entradas / / Encontrar el \ del final del nombre, si lo hay. Si no, aadirlo
y restaurar el directorio de trabajo */ pSlash = strrchr (Almacenpwd, \\); if (pSlash NULL) {
*pSlash = \O;
El sistema de archivos permite organizar la informacin dentro de los dispositivos de almacena miento
secundario en un formato inteligible para el sistema operativo. Habitualmente, cuando se instala el sistema
operativo, los dispositivos de almacenamiento estn vacos. Por ello, previa mente a la instalacin del
sistema de archivos es necesario dividir fsica o lgicamente los discos en particiones o volmenes
[Pinkert, 1989]. Una particin es una porcin de un disco ala que se la dota de una identidad propia y que
puede ser manipulada por el sistema operatn() como una entidad lgica independiente. Admite formato,
instalacin de sistemas de archivos, comproba ciones, etc. Este objeto no es utilizable directamente por la
parte del sistema operativo que gestio na los archivos y directorios, que debe instalar un sistema de archivos
dentro de dicha particin (Aclaracin 8.3). Adems, en el caso de discos de arranque del sistema, los
sistemas operativos exigen que existan algunas particiones dedicadas a propsitos especficos de los
mismos, tales como arranque del sistema (particin raz), intercambio de pginas de memoria virtual
(particin de intercambio), etc. La Figura 8.13 muestra la diferencia entre particin y disco. Un disco puede
dividirse en varias particiones o puede contener una nica particin. Adems, algunos sistemas operativos
modernos permiten construir particiones extendidas que engloban varias unidades de disco.
Una vez creadas las particiones, el sistema operativo debe crear las estructuras de los sistemas de archivos
dentro de esas particiones. Para ello se proporcionan mandatos como format o mkfs al usuario. Los
siguientes mandatos de UNIX crean dos sistemas de archivos, uno para intercambio y otro para datos,
dentro de dos particiones del disco duro a: /dev/hda2 y /dev/hda3:
#mkswap -c /dev/hda2 20800
#mkfs c /dev/hda3 b 8192 123100
El tamao del sistema de archivos, por ejemplo 20800, se define en bloques. Un bloque se define como una
agrupacin lgica de sectores de disco y es la unidad de transJ mnima que usa el sistema de archivos. Se
usan para optimizar la eficiencia de la entradalsalida de los dispositi vos secundarios de almacenamiento.
Aunque todos los sistemas operativos proporcionan un tamao de bloque por defecto, en UNIX, los
usuarios pueden definir el tamao de bloque a usar dentro de un sistema de archivos mediante el mandato
mkfs. Por ejemplo, -b 8192 define un tamao de bloque de 8 KB para /dev/hda3 (Prestaciones 8.3). El
tamao de bloque puede variar de un sistema de archivos a otro, pero no puede cambiar dentro del mismo
sistema de archivos. En mu chos casos, adems de estos parmetros, se puede definir el tamao de la
agrupacin, es decir, el conjunto de bloques que se gestionan como una unidad lgica de gestin del
almacenamiento. El problema que introducen las agrupaciones, y los bloques grandes, es la existencia de
fragmentacin interna. Por ejemplo, si el tamao medio de archivo es de 6 KB, un tamao de bloque de 8
KB introduce una fragmentacin interna media de un 25 por 100. Si el tamao de bloque fuera de 32 KB, la
fragmentacin interna alcanzara casi el 80 por 100.
Todos los sistemas operativos de propsito general incluyen un componente, denominado servidor de
archivos, que se encarga de gestionar todo lo referente a los sistemas de archivos. Este componente se
estudia en detalle en la Seccin 8.6.
Cuando se crea un sistema de archivos en una particin de un disco, se crea una entidad lgica
autocontenida con espacio para la informacin de carga del sistema de operativo, descripcin de su
estructura, descriptores de archivos, informacin del estado de ocupacin de los bloques del sistema de
archivos y bloques de datos Goodheart, 1994]. La Figura 8.14 muestra las estructuras de un sistema de
archivos para MS-DOS, UNIX y Windows NT, as como la disposicin de sus distintos componentes,
alwacenado en una particin.
En UNIX, cada sistema de archivos tiene un bloque de carga (Boot) que contiene el cdigo que ejecuta el
programa de arranque del programa almacenado en la ROM de la computadora. Cuando se arranca la
mquina, el iniciador ROM lee el bloque de carga del dispositivo que almace na al sistema operativo, lo
carga en memoria, salta a la primera posicin del cdigo y lo ejecuta. Este cdigo es el que se encarga de
instalar el sistema operativo en la computadora, leyndolo desde el disco. No todos los sistemas de archivos
necesitan un bloque de carga. En MS-DOS o UNIX, por ejemplo, slo los dispositivos de sistema, es decir,
aquellos que tienen el sistema opera tivo instalado contienen un bloque de carga vlido. Sin embargo, para
mantener la estructura del sistema de archivos uniforme, se suele incluir en todos ellos un bloque reservado
para carga. El
sistema operativo incluye un nmero, denominado nmero mgico, en dicho bloque para indicar que es un
dispositivo de carga. Si se intenta cargar de un dispositivo sin nmero mgico, o con un valor errneo del
mismo, el monitor ROM lo detecta y genera un error.
A continuacin del bloque de carga est la metainformacin del sistema de archivos (superblo que, nodos-
i,...). La metainformacin describe el sistema de archivos y la distribucin de suis componentes. Suele
estar agrupada al principio del disco y es necesaria para acceder al sistema de archivos. El primer
componente de la metainformacin en un sistema de archivos UNIX es el superbloque (el Bloque de
Descripcin del Dispositivo en Windows NT), que contiene la informa cin que describe toda la estructura
del sistema de archivos. La informacin contenida en el super bloque indica al sistema operativo las
caractersticas del sistema de archivos dnde estn los distin tos elementos del mismo y cunto ocupan.
Para reducir el tamao del superbloque, slo se indica la informacin que no puede ser calculada a partir de
otra. Por ejemplo, si se indica que el tamao del bloque usado es 4 KB, que el sistema tiene 16 K nodos-i y
que el nodo-i ocupa 512 bytes, es sencillo calcular que el espacio que ocupan los nodos-i en el sistema de
archivos es 2.048 bloques. Asimis mo, si se usan mapas de bits para representar el estado de ocupacin de
los nodos-i, necesitaremos 16 KB, lo que significa que el mapa de bits de los nodos-i ocupara 4 bloques del
sistema de archivos. La Figura 8.15 muestra una parte del superbloque de un sistema de archivos de
LINUX. Como se puede ver, adems de la informacin reseada, se incluye informacin comn para todos
los sistemas de archivos que proporciona el sistema operativo y una entrada para cada tipo de archivos en
particular (MINIX, MS-DOS, ISO, NFS, SYSTEM V, UFS, genrico, etc.). En este caso se incluye
informacin de gestin tal como el tipo del dispositivo, el tamao de bloque, nme
ro mgico, tipo de archivo, operaciones sobre el superbloque y de cuota de disco y apuntadores a los tipos
de archivo que soporta. Para cada uno de ellos se incluye una estructura de datos para su superbioque
particular, el mximo tamao de archivo posible, la proteccin que se aplica al sistema de archivos, etc.
Adems, para optimizar aspectos como la bsqueda de espacio libre, se incluye informacin sobre la
situacin del primer bloque libre y del primer descriptor de archivos libre. Como ejemplo de superbloque
particular se muestra el de MINIX.
Cuando arranca la computadora y se carga el sistema operativo, el superbioque del dispositivo de carga, o
sistema de archivos raz, se carga en memoria en la tabla de superbioques. A medida que otros sistemas de
archivos son incorporados a la jerarqua de directorios (en UNIX se dice que son montados) sus
superbloques se cargan en la tabla de superbloques existente en memoria. La forma de enlazar unos con
otros se ver ms adelante.
Tras el superbioque, el sistema de archivos incluye informacin de gestin de espacio en el disco. Esta
informacin es necesaria por dos razones: para permitir al servidor de archivos imple- mentar distintas
polticas de asignacin de espacio y para reutilizar los recursos liberados para nuevos archivos y directorios.
Normalmente, los sistemas de archivos incluyen dos mapas de espa cio libre:
informacin de bloques de datos, en la que se indica si un bloque de datos esta ibre o no. En caso de que
el espacio de datos se administre con agrupaciones para optimizar la gestin de espacio libre, esta
informacin se refiere a as agrupaciones (Prestaciones .4).
Informacin de la descripcin fsica de los archivos, como nodos-i en UNIX o registros de Windows
NT, en la que se indica si un descriptor de archivo est libre o no.
Existen distintas formas de representar el espacio existente en un sistema de archivos. Las ms populares
son los mapas de bits y las listas de recursos libres. Estos mecanismos se estudian en detalle en una seccin
posterior.
Despus de los mapas de recursos del sistema de archivos, se encuentran los descriptores fsicos de
archivos. Estos descriptores, sean nodos-i de UNIX o registros de Windows NT, tienen una estructura y
tamao variable dependiendo de cada sistema operativo, segn se vio en secciones anteriores. Por ejemplo,
en LINUX ocupa 128 bytes EBokhari, 19951 y en Windows NT el registro ocupa todo un bloque de 4 KB.
El tamao del rea de descriptores de archivo es fcilmente calcula ble si se conoce el tamao del nodo-i y
el nmero de nodos-i disponibles en el sistema de archivos. Normalmente, cuando se crea un sistema de
archivos, el sistema operativo habilita un nmero de descriptores de archivo proporcional al tamao del
dispositivo. Por ejemplo, en LINUX se crea un nodo-i por cada 2 bloques de datos. Este parmetro puede
ser modificado por el usuario cuando crea un sistema de archivos, lo que en el caso de UNIX se hace con el
mandato mkfs (Advertencia 8.2).
El ltimo componente del sistema de archivos son los bloques de datos. Estos bloques, bien tratados de
forma individual o bien en grupos, son asignados a los archivos por el servidor de archivos, que establece
una correspondencia entre el bloque y el archivo a travs del descriptor del archivo. Tanto si se usan
bloques individuales como agrupaciones, el tamao de la unidad de acceso que se usa en el sistema de
archivos es uno de los factores ms importantes en el rendi miento de la entrada/salida del sistema
operativo. Puesto que el bloque es la mnima unidad de transferencia que maneja el sistema operativo,
elegir un tamao de bloque pequeo, por ejemplo 5 1 2 bytes, permite aprovechar al mximo el tamao del
disco. As, el archivo prueba de 1,2 KB ocupara 3 bloques y slo desperdiciara 1/2 bloque o el 20 por 100
del espacio de disco si todos los archivos fuesen de ese tamao. Si el bloque fuese de 32 KB, el archivo
ocupara un nico bloque y desperdiciara el 90 por 100 del bloque y del espacio de disco. Ahora bien,
transferir el archivo prueba, en el primer caso, necesitara la transferencia de 3 bloques, lo que significa
buscar cada bloque en el disco, esperar el tiempo de latencia y hacer la transferencia de datos. Con bloques
de 32 KB slo se necesitara una operacin. La Figura 8.16 muestra la relacin entre tamao de bloque,
velocidad de transferencia y porcentaje de uso del sistema de archivos, con un tamao medio de archivo de
14 KB. Como puede verse, los dos ltimos parmetros son contra dictorios, por lo que es necesario adoptar
una solucin de compromiso que proporcione rendi mientos aceptables para ambos. En el caso del
dispositivo cuyos resultados se muestran en la figura, el tamao de bloque puede estar entre 4 KB y 8 KB.
Es interesante resaltar que esta curva cambia con la tecnologa de los discos y con el tamao medio de los
archivos, que ha cambiado desde 1 KB en los sistemas UNIX de hace 15 aos hasta los 14 KB medidos en
estudios ms actuales. Adems, el uso masivo de informacin multimedia tender a incrementar mucho el
tamao medio de los archivos en un futuro prximo, por lo que es necesario evaluar los parmetros
cuidadosamente y
ajustarlos al tipo de almacenamiento que se llevar a cabo en cada dispositivo (general, cientfico,
multimedia, etc.).
Como se puede ver en la Figura 8.14, el sistema de archivos de Windows NT [ Nagar, 1997] tiene una
estructura similar al de UNIX, pero los descriptores fsicos de archivos ocupan mucho ms espacio en la
particin. Esto se debe a que los descriptores de Windows NT tienen un tamao de 4 KB y no unos pocos
bytes como en UNIX. Esta estrategia permite almacenar datos en el descriptor de archivos, lo que puede
optimizar el acceso a los archivos pequeos al evitar accesos a disco para obtener el descriptor y despus
los datos. Esta cuestin se estudia en detalle en la Seccin 8.6.
En algunos sistemas operativos se incluyen sistemas de archivos con una estructura diferente a las
presentadas en la seccin anterior. Los objetivos de estos nuevos sistemas de archivos son variados e
incluyen optimizaciones del rendimiento de la entradalsalida, incrementar la fiabilidad u ofrecer
informacin acerca de objetos internos del sistema operativo (como los procesos). La estructura de sistema
de archivos mostrada anteriormente tiene varios problemas:
La metainformacin del sistema de archivos (superbioque, nodos-i,...) est agrupada al prin 1 cipio
del disco y es nica. Ello tiene dos consecuencias. Primero, el tiempo de bsqueda de bloques es
muy largo. Segundo, si se conompe algn bloque de metainformacin, todo el sistema de archivos
queda inutilizado. El sistema FFS (fast file system) de UNIX y el EXT2 e (extended file system)
de LINUX resuelven este problema de forma similar.
El sistema de archivos no se puede extender a varias particiones de forma natural, con lo que el
tamao mximo de un archivo est limitado por la particin. Por ejemplo, en una particin de 2 GB
de UNIX, se sera el mximo tamao de archivo, aun cuando el sistema pudiera manejar archivos
de mayor tamao. Los sistemas de archivos como los de los dispositivos RAID, los sistemas de
archivos paralelos o los sistemas de archivos con bandas de Win dows NT resuelven este
problema.
No se explotan adecuadamente las distintas caractersticas de las operaciones de lectura y de
escritura con distintos tamaos. Un problema especialmente importante son las escrituras ms
pequeas que un bloque, habitualmente denominadas escrituras parciales. Para que la informacin
quede coherente, hay que leer la informacin del bloque, modificarla en memo ria y escribirla de
nuevo al disco. Dado que en los sistemas de propsito general la mayora de las escrituras son
pequeas, la estructura de sIstema de archIvos tradIcIonal es muy poco eficiente para este tipo de
operaciones. El sistema LFS (log structureed file system) resuelve este problema.
En los antiguos sistemas operativos, la informacin de los procesos estaba oculta a los usuanos y
slo se poda ver mediante mandatos del sistema operativo o usando monitores. Los sistemas
operativos modernos incluyen un sistema de archivos de tipo especial, denominado proc, dentro
del cual incluyen directorios con la informacin de cada proceso identificada mediante el pid. Estos
sistemas de archivos slo existen en memoria y se crean cuando arranca el sistema operativo. La
informacin de cada proceso se construye dinmicamente cuando es necesario.
Fast File System (FFS)
La primera version del FFS apareci en 1984 como parte del UNIX-BSD, desarrollado en la Uni versidad
de Berkeley en 1984 [ McKusick, 1984]. Actualmente se ha convertido en el formato
estndar de gran parte de versiones del sistema operativo UNIX. El objetivo de este sistema de archivos es
doble: reducir tiempos de bsqueda en el disco e incrementar la fiabilidad. Para ello se divide la particin
en varias reas, denominadas grupos de cilindros o de bloques. Cada grupo de cilindros contiene una
copia del superbioque, nodos-i y mapas de bits para los bloques de ese cilindro. La motivacin para usar
grupos de cilindros es repartir los datos y asociar a dichos datos la metainformacin correspondiente, de
forma que est ms cercana a los bloques referenciados en ella. Adems, la replicacin del superbioque
permite restaurar posibles fallos en uno de los super bloques. La Figura 8. 17 muestra la disposicin del
sistema de archivos en una particin.
Cuando se crea el sistema de archivos, el administrador debe especificar el tamao de los grupos de
cilindros, el nmero de nodos-i dentro de cada grupo y el tamao del bloque. El servidor de archivos usa
valores por defecto en otro caso. Adems de los grupos de cilindros, el FFS incluy en su momento otras
optimizaciones:
El servidor de archivos intenta asignar los bloques de un archivo cercanos a su nodo- y dentro del mismo
grupo de cilindros. Adems, los nodos-i de los archivos se intentan colocar
en el mismo grupo de cilindros que el directorio donde se encuentran.
Los nodos-i de los archivos creados se distribuyen por toda la particin, para evitar la con gestin de un
nico grupo de cilindros.
El tamao de bloque por defecto se aument de 1 KB, usado normalmente hasta ese momen to, hasta 4
KB.
Con estas optimizaciones. el FFS consigui duplicar el rendimiento del servidor de archivos que usaba
UNIX System V, la versin ms popular de UNIX del momento. Sin embargo, la funcio nalidad interna del
servidor de archivos se complic considerablemente, debido fundamentalmente a dos problemas:
Cuando se llena un grupo de bloques, hay que colocar los datos restantes en otros grupos. Ello conlleva
tener una poltica de dispersin de bloques e informacin de control extra para saber dnde estn dichos
bloques.
Al incrementar el tamao del bloque se incrementa la fragmentacin interna. En 1984, el tamao medio de
archivo en UNIX era de 1,5 KB FOusterhout, 1985}, lo que significaba que, si se dedicaba un bloque de 4
KB a un archivo, ms del 50 por 100 del bloque quedaba sin usar. Pasa solventar este problema fue
necesario introducir el concepto de fragmento de un bloque.
Un fragmento es una porcin de bloque del sistema de archivos que se puede asignar de fbi-ma
independiente. Obsrvese que cuando hay fragmentos, no siempre es cierto que la unidad mnima de
asignacin es un bloque, por lo que es necesario gestionar tambin dichos fragmentos. La gestin de
fragmentos est muy relacionada con la asignacin de bloques nuevos a un archivo. Cuando un archivo
crece, necesita ms espacio del servidor de archivos, en cuyo caso existen dos posibilidades:
El archivo no tiene ningn bloque fragmentado. En este caso, silos datos ocupan un bloque o ms,
se le asignan bloques completos. Si los datos se ajustan al tamao de los bloques, la operacin
termina aqu. En caso de que al final quede una porcin de datos menor que un bloque, se asigna al
archivo los fragmentos de bloque que necesite para almacenar dicha porcin de datos.
El archivo tiene un bloque fragmentado al final. En este caso, si los datos ocupan ms que el
tamao de bloque restante, se asigna al archivo un nuevo bloque, se copian los fragmentos al
principio del bloque y los datos restantes a continuacin. En esta situacin ya se puede aplicar el
caso 1. En caso de que los datos a almacenar no llenen un bloque, se asignan ms fragmentos al
archivo.
Observe que un archivo slo puede tener un bloque fragmentado al final, ya que el ltimo ser el nico
bloque sin llenar totalmente. Por tanto, el servidor de archivos slo debe mantener informa cin de
fragmentos para ese ltimo bloque. Para seguir la pista a los fragmentos, el FFS mantiene una tabla de
descriptores de fragmentos, en la que se indica el estado de los fragmentos en los bloques fragmentados.
Como resultado de esta evolucin, los sistemas de entradalsalida disponen actualmente de grandes
almacenes intermedios en memoria que permiten optimizar las operaciones de lectura de forma
espectacular. Esta optimizacin no se puede aplicar en la misma medida a las operaciones de escritura,
porque para mantener la fiabilidad del sistema es necesario escribir los datos a los discos, al menos, en
perodos determinados. Las escrituras parciales son especialmente ineficientes, ya que es necesario leer el
bloque afectado, modificarlo en memoria y escribirlo posteriormente a disco. La idea bsica de LFS
[Douglis, 1989] y [Ousterhout, 1989] es hacer todas las operaciones de escritura de forma secuencial en un
archivo de registro intermedio del disco y, posteriormente, escribirlas en cualquier otro formato que sea
necesario. Peridicamente, el sistema recolecta las escrituras pendientes en los almacenes de memoria, los
agrupa en un segmento nico de datos y los escribe a disco secuencialmente al final del registro.
Esta poltica permite explotar de forma ptima el ancho de banda del disco, pero presenta problemas de
rendimiento graves cuando hay que buscar elementos dentro del registro de forma aleatoria. Por ejemplo, si
se quiere leer el bloque 342 del nodo-i 45, es necesario buscar el nodo-i dentro del registro. Una vez
obtenido, se calcula la posicin del bloque de forma habitual. Como el sistema de archivos no tiene una
estructura con grupos de datos situados en lugares fijos, es imposi ble calcular la posicin del nodo-i. En el
peor de los casos, se deber recorrer el registro completo para encontrarlos. Para aliviar este problema, LFS
mantiene en el disco, y en memoria, un mapa de nodos-i, ordenados por nmero de nodo-i, a bloques del
registro. Estos detalles, y las operaciones de control de bloques libres, complican mucho las operaciones de
mantenimiento del sistema de archivos [Blackwell 1995]. Es necesario mantener informacin de control de
segmentos, un resu men de contenido por segmento y control de distintas versiones del mismo archivo.
Hasta el momento se han estudiado los archivos y directorios desde el punto de vista del usuario de un
sistema operativo. Los usuarios necesitan saber cmo se manipulan los archivos, cmo se estruc turan en
directorios, cul es el mtodo de nombrado usado por el sistema operativo, las operaciones
La importancia de una buena gestin de los archivos y directorios se ha subestimado a menudo. Desde el
punto de vista de los usuarios, los directorios son una forma de organizacin de la infor macin y los
archivos son flujos de datos de los que en general se requiere velocidad y aleatori edad en los accesos. Para
satisfacer estas demandas, los servidores de archivos tienen una estructura intema que, en general, permite
acceder a los distintos dispositivos del sistema mediante archivos de distintos tipos, escondiendo estos
detalles a los usuarios.
Un servidor de archivos est compuesto por varias capas de software [Goodheart, 1994] y [ Goscinski,
1991]. Cada capa usa las caractersticas de los niveles inferiores para crear un nivel ms abstracto, hasta
llegar a los servicios que se proporcionan a los usuarios. La Figura 8.19 muestra la arquitectura de un
servidor de archivos como el del sistema operativo LINUX.
El sistema de archivos virtual es el encargado de proporcionar la interfaz de llamadas de entrada/salida
del sistema y de pasar al mdulo de organizacin de archivos la informacin necesa ria para ejecutar los
servicios pedidos por los usuarios. Dentro de este nivel se suele incluir: manejo de directorios, gestin de
nombres, algunos servicios de seguridad, integracin dentro del servidor de archivos de distintos tipos de
sistemas de archivos y servicios genricos de archivos y directo rios. Para ello, en casi todos los sistemas
operativos se usa una estructura de informacin que incluye las caractersticas mnimas comunes a todos los
sistemas de archivos subyacentes y que enlaza con un descriptor de archivo de cada tipo particular. Por
ejemplo, en UNIX esta estructura se denomina nodo-v (por nodo virtual). El nodo virtual es un objeto que
contiene informacin genri ca til, independientemente del tipo de sistema de archivos particular al que
representa el objeto. Esta informacin incluye:
Atributos, tales como estado, informacin de proteccin, contadores de referencia, informa cin
acerca del tipo de sistema de archivos subyacente al que en realidad pertenece el objeto, etctera.
Un apuntador al nodo-i real del objeto (existente en su sistema de archivos especfico).
Un apuntador a las funciones que realmente ejecutan los servicios especficos de cada siste ma de
archivos.
La Figura 8.20 muestra la estructura de la informacin dentro de un nodo-y. Dentro del siste ma de archivos
virtuales se incluyen operaciones que son independientes del tipo de sistema de archivos, tales como el
mantenimiento de una cache de nombres, gestin de nodos virtuales, gestin de bloques en memoria, etc.
Cuando las operaciones son especficas del tipo de sistema de archivos subyacente, el sistema de archivos
virtual se limita a traducir los parmetros necesarios y a llamar a la operacin adecuada del tipo de archivos
afectado, cuyo servicio es provisto por el mdulo de organizacin de archivos.
El mdulo de organizacin de archivos proporciona el modelo del archivo del sistema opera tivo y los
servicios de archivos. Es en este nivel donde se relaciona la imagen lgica del archivo con su imagen fsica,
proporcionando algoritmos para trasladar direcciones lgicas de bloques a sus correspondientes direcciones
fsicas. Adems, en este nivel se gestiona el espacio de los sistemas de archivos, la asignacin de bloques a
archivos y el manejo de los descriptores de archivo (nodos-i de UNIX o registros de Windows NT). Puesto
que un mismo sistema operativo puede dar servicio para varios tipos de archivos, existir un mdulo de este
estilo por cada tipo de archivo soportado (UNIX, AFS. Windows NT, MS-DOS, EFS, MINIX, etc.). Dentro
de este nivel tambin se propor cionan servicios para pseudoarchi vos, tales como los del sistema de
archivos proc.
Las llamadas de gestin de archivos y de directorios particulares de cada sistema de archivos se resuelven
en el mdulo de organizacin de archivos. Para ello se usa la informacin existente en el nodo-i del archivo
afectado por las operaciones. Para realizar la entrada/salida de datos a disposi tivos de distintos tipos, este
nivel se apoya en un servidor de bloques, que proporciona entra da/salida independiente de los dispositivos
a nivel de bloques lgicos.
El servidor de bloques se encarga de emitir los mandatos genricos para leer y escribir blo ques a los
manejadores de dispositivo. La FIS de bloques de archivo, y sus posibles optimizacio -
nes, se lleva a cabo en este nivel del servidor de archivos. Las operaciones se traducen a llamadas de los
manejadores de cada tipo de dispositivo especfico y se pasan al nivel inferior del sistema de archivos. Esta
capa oculta los distintos tipos de dispositivos, usando nombres lgicos para los mismos. Por ejemplo,
/dev/hda3 ser un dispositivo de tipo hard disk (hd), cuyo nombre princi pal es a y en el cual se trabaja
sobre su particin 3. Los mecanismos de optimizacin de la FIS. como la cache de bloques, se incluye en
este nivel.
El nivel inferior incluye los manejadores de dispositivo. Existe un manejador por cada dispo sitivo, o
clase de dispositivo, del sistema. Su funcin principal es recibir rdenes de EIS de alto nivel, tal como
move_to_block 234, y traducirlas al formato que entiende el controlador del dispositivo, que es dependiente
de su hardware. Habitualmente, cada dispositivo tiene una cola de peticiones pendientes, de forma que un
manejador puede atender simultneamente a varios disposi tivos del mismo tipo. Por tanto, una de las
principales funciones de los manejadores de dispositivos es recibir las peticiones de entradalsalida y
colocarlas en el lugar adecuado de la cola de peticiones del dispositivo afectado. La poltica de insercin en
cada cola puede ser diferente, dependiendo del tipo de dispositivo o de la prioridad de los dispositivos. Para
un disco, por ejemplo, se suele usar la poltica CSCAN.
La Figura 8.21 muestra el flujo de datos en el servidor de archivos debido a una llamada read, as
omnb1snperaLzinnasna ar1aspara diibn fl El usuario ve tun vPctnr de hyte yue san
colectivamente descritos mediante un descriptor de archivo, un apuntador de posicin en el archivo y el
nmero de bytes a leer. Los datos a leer pueden no estar alineados con el principio de un bloque lgico y el
nmero de bytes pedidos puede no ser mltiplo del tamao de bloque lgico. Cuando el sistema de archivos
virtual recibe la peticin de lectura, comprueba el tipo de sistema de archivos al que pertenece el archivo (p.
ej.: FES) y llama a la rutina de lectura particular del mismo. El mdulo servidor de FFS comprueba la
direccin del apuntador y el tamao de buffer y caicu ius rnoques a leer. Como puede verse en la figura,
es habitual que slo se necesite un fragmento del bloque inicial y final de la peticin. Sin embargo, puesto
que el sistema de archivos trabaja con bloques, es necesario leer ambos bloques completos. Una vez
calculados los bloques, se enva la peticin al servidor de bloques. A continuacin se solicitan los bloques
al manejador de disco. Una vez terminada la opera cin de lectura, los bloques se copian al espacio del
usuario.
Para crear un nuevo archivo, las aplicaciones llaman al sistema de archivos virtual mediante la llamada al
sistema crea Con esta llamada, el sistema crea un descriptor virtual para el nuevo archivo, en el que incluye
la informacin de proteccin del mismo. El mdulo de organizacin de archivos del tipo requerido, a
peticin del sistema de archivos virtual, se encarga de crear un des criptor de archivo de ese tipo,
incluyendo en l la informacin recibida del nivel superior. A conti nuacin modifica la estructura de los
directorios. Para ello lee la informacin del directorio donde se quiere crear el archivo y la trae a memoria.
Para ello llama al mdulo de organizacin de archi vos correspondiente al directorio (los directorios no son
sino archivos especiales), que a su vez se encarga de llamar al gestor de bloques para leer los bloques del
directorio a memoria. Si todo es correcto, la actualiza con la entrada del nuevo directorio y la escribe
inmediatamente al disco. La escritura del directorio hace un recorrido similar al de la lectura, pero los
bloques van de memoria al disco.
En este momento ya existe el nuevo objeto archivo. En el caso de UNIX, el archivo est vaco y, por tanto,
no tiene ningn bloque asociado. En el caso de Windows NT, el archivo ya dispone de la parte de datos de
su registro para almacenar informacin vlida. El descriptor asignado al archivo es el primero que se
encuentra libre en el mapa de bits, o lista de descriptores libres, del sistema de archivos al que pertenece el
archivo creado. Para trabajar con dicho archivo es necesario empezar una sesin abriendo el archivo (open).
La implementacin de las llamada open en un sistema operativo multiproceso, como UNIX, en el que
varios procesos pueden abrir y cerrar el mismo archivo simultneamente, es ms complicada que en
sistemas operativos monoproceso como MS-DOS. Si los procesos pueden compartir un mismo archivo,
qu valor tendr en cada momento
el apuntador de posicin del archivo? Si los procesos son independientes, cada uno debe tener su propio
apuntador de posicin. Dnde se almacena dicho valor? La solucin ms obvia es ponerlo en el nodo-y
que representa al archivo, dentro de la tabla de nodos-v [Goodheart, 1994]. Dicha tabla almacena en
memoria los nodos-v de los archivos abiertos. En ella se almacena la informacin del nodo-y existente en el
disco y otra que se usa dinmicamente y que slo tiene sentido cuando el archivo est abierto. El problema
es que, si slo hay un campo de apuntador, cada operacin de un proceso afectara a todos los dems. Una
solucin a este problema podra ser la inclusin de un apuntador por proceso con el archivo abierto. Pero
entonces, cul sera el tamao del nodo-y? Y cul debera ser el nmero de apuntadores disponibles? Se
puede concluir que esa informacin no se puede incluir en el nodo-y sin crear problemas de diseo e
implementacin importantes en el sistema operativo. Parece pues necesario desacoplar a los procesos que
temporalmente usan el objeto de la representacin del objeto en s.
Una posible solucin para desacoplar a los procesos que usan el archivo de la representacin interna del
mismo podra ser incluir la informacin relativa al archivo dentro del bloque de descripcin del proceso
(BCP). En este caso, dentro del BCP de un proceso se incluira una tabla de archivos abiertos (tdaa) con
sus descriptores temporales y el valor del apuntador de posicin del archivo para ese proceso. El tamao de
esta tabla define el mximo nmero de archivos que cada proceso puede tener abierto de forma simultnea.
La Figura 8.22 muestra las tablas de descriptores de archivos abiertos por varios procesos en el sistema
operativo UNIX. El descriptor de archivo fd indica el lugar de tabla. La tdaa se rellena de forma ordenada,
de forma que siempre se ocupa la primera posicin libre de la tabla. Cuando se realiza una operacin open,
el sistema de archivos busca desde la posicin o hasta que encuentra una posicin libre, siendo sa la
ocupada. Cuando se cierra un archivo (close), se marca como nula la correspondiente posicin de la tdaa.
En los sistemas UNIX cada proceso tiene tres descriptores de archivos abiertos por defecto. Estos descrip
tores ocupan las posiciones O a 2 y reciben los siguientes nombres:
Entrada estndar, fd = O.
Salida estndar, fd = 1.
Error estndar, fd = 2.
El objetivo de estos descriptores estndar es poder escribir programas que sean independientes de los
archivos sobre los que han de trabajar. En efecto, uno de los elementos del BCP que se conserva cuando se
cambia el programa de un proceso (con el servicio POSIX exec) es la tabla de descriptores de archivo. Por
tanto, basta con que un proceso coloque adecuadamente los descripto res estndar y que luego invoque la
ejecucin del mencionado programa, para que ste utilice los archivos previamente seleccionados.
Con la daa, el nodo-i queda libre de los problemas anteriores, pero surgen problemas cuando dos o ms
procesos comparten el mismo archivo y su apuntador de posicin. Esta situacin se da cuando se ejecuta
una llamada fork con semntica POSIX, llamada de la que nace un nuevo proceso hijo que comparte con el
padre su tdaa, lo que debe incluir el apuntador de posicin de los archivos. Ahora bien, al duplicar el BCP
si el hijo y el padre hacen operaciones de EIS distintas, los apuntadores difieren porque cada uno tiene su
propio apuntador. Para solucionar este problema, algunos sistemas operativos, como UNIX, introducen una
tabla intermedia entre la tabla de archi vos del BCP y la tabla de nodos-i (Fig. 8.22). Dicha tabla incluye,
entre otras cosas:
La entrada del nodo-i del archivo abierto en la tabla de nodos-i.
El apuntador de posicin correspondiente al proceso, o procesos. que usan el archivo durante esa
sesin.
El modo de apertura del archivo.
La introduccin de esta tabla permite resolver los problemas anteriores, ya que cada proceso puede tener
sus propios descriptores de archivo, evitando tener dicha informacin en el nodo-i, y permite que varios
procesos puedan compartir no slo el mismo archivo, sino tambin el mismo apuntador de posicin dentro
de un archivo.
Un problema similar al anterior surge cuando se implementan otras llamadas. Por ejemplo, un proceso
puede bloquear todo o parte de un archivo, siendo esa informacin propia del proceso pero a su vez
compartida con sus posibles procesos hijos. Un caso similar ocurre si se permite a los procesos proyectar
archivos en memoria. Normalmente, todos estos casos se resuelven introdu ciendo nuevas tablas
intermedias que desacoplen los procesos de la descripcin del archivo en s (nodo-i), al estilo de las tablas
anteriores.
Cuando la aplicacin quiere aadir informacin al archivo, el servidor de archivos debe deci dir dos cosas:
1. Cmo hacer corresponder los bloques de disco con la imagen del archivo que tiene la aplicacin.
2. Cmo asignar bloques de disco libres para almacenar la informacin del archivo.
A continuacin, se presentan las soluciones ms frecuentes a estos dos problemas.
Una de las cuestiones ms importantes del diseo y la implementacin de un servidor de archivos es cmo
asignar los bloques de disco a un archivo y cmo hacerlos corresponder con la imagen del archivo que tiene
la aplicacin. Este problema se resuelve con lo que tradicionalmente se conoce como mecanismos de
asignacin [Koch, 1987]. En distintos sistemas operativos se han propuesto varias polticas, existiendo dos
variantes claras:
el tamao total del archivo cuando se crea, puede ser necesario buscar un nuevo hueco de bloques
consecutivos cada vez que el archivo crece [ 19891. Adems, la necesidad de buscar huecos contiguos
origina una gran fragmentacin externa en el disco, ya que hay muchos huecos no utilizables debido a la
poltica de asignacin. Sera pues necesario com pactar el disco muy frecuentemente. Debido a estas
desventajas, ningn sistema operativo moderno usa este mtodo, a pesar de que la representacin interna
del archivo es muy senci lla: basta con conocer el primer bloque del archivo y su longitud.
Asignacin de bloques no contiguos. Con este mtodo se asigna al archivo el primer bloque que se
encuentra libre. De esta forma se elimina el problema de la fragmentacin externa del disco y el de la
bsqueda de huecos. Adems, los archivos pueden crecer mientras exista espacio en el disco. Sin embargo,
este mtodo complica la implementacin de la imagen de archivo que usa el servidor de archivos. La razn
es que se pasa de un conjunto de bloques contiguos a un conjunto de bloques dispersos, debiendo conocer
dnde estn dichos blo ques y en qu orden deben recorrerse.
Para resolver el problema de mantener el mapa de bloques discontiguos de un archivo, casi todos los
sistemas operativos han propuesto usar una lista de bloques, una lista en combinacin con un ndice o un
ndice multinivel para optimizar el acceso. En una lista enlazada desde cada bloque de un archivo existe un
apuntador al siguiente bloque del mismo. En el descriptor del archivo se indica nicamente el primer
bloque del archivo. Este mtodo tiene varias desventajas:
No es adecuado para accesos aleatorios, ya que hay que leer todos los bloques para recorrer la
cadena de enlaces hasta el destino.
Puesto que el apuntador al bloque siguiente ocupa espacio (digamos 4 bytes) y estn inclui dos en
el archivo, el clculo de la longitud real del archivo es ms complicado.
La inclusin de los apuntadores en los bloques de datos hace que el tamao de stos deje de ser
mltiplo de 2 (cosa que ocurre habitualmente), complicando mucho el clculo del nme ro de
bloque en el que est un determinado byte del archivo.
Es muy poco fiable, ya que la prdida de un bloque del archivo supone la prdida de todos los datos
del archivo que van detrs de dicho bloque.
Las desventajas de la lista enlazada se pueden eliminar si se quitan los apuntadores de los bloques del
archivo y se almacenan en un ndice enlazado gestionado por el servidor de archivos. Cuando se crea un
sistema de archivos, se almacena en una parte especial del mismo una tabla que contiene una entrada por
cada bloque de disco y que est indexada por nmero de bloque. Usando esta tabla, cada vez que se crea un
archivo se incluye en su descriptor el descriptor de la tabla que apunta al primer bloque del archivo. A
medida que se asignan nuevos bloques al archivo se apunta a ellos desde la ltima entrada de la tabla
asociada al archivo. Esta es la solucin usada en la FAT (file allocation table) de los sistemas operativos
MS-DOS y OS/2, que se muestra en la Fi 8.23. La gran desventaja de esta solucin es que la FAT puede
ocupar mucho espacio si el dispositivo es grande. Por ejemplo, un disco de 4 GB, con 4 KB como tamao
de bloque, necesitara una FAT con 1 Mega entradas. Si cada entrada ocupa 4 bytes, la FAT ocupara 4
MB. Para buscar un bloque de un archivo muy disperso podra ser necesario recorrer toda la FAT y, por
tanto, tener que traer todos los bloques de la FAT a memoria. Imagine qu pasara si la computadora tuviese
ocho dispositivos como ste: se necesitaran 32 MB de memoria slo para las FAT. Este mtodo es pues
inviable si la FAT no puede estar continuamente en memoria [ 19831, lo cual ocurre en cuanto los dispo
sitivos alcanzan un tamao medio. Para aminorar este problema, los bloques se juntan en agrupa ciones, lo
que permite dividir el tamao de la FAT (Prestaciones 8.5). Si se usaran grupos de 4 bloques, el tamao de
la FAT anterior se reducira a 1 MB.
Los problemas anteriores pueden resolver estos problemas de forma eficiente mediante el uso de un ndice
multinivel cuyos bloques son apuntados desde el nodo-i que describe al objeto archi vo, como los de UNIX
y LINUX. Con esta solucin, cada archivo tiene sus bloques de ndice que incluyen apuntadores a los
bloques de disco del archivo. El orden lgico se consigue mediante la insercin de los apuntadores en orden
creciente, a partir del primero, en los bloques de ndices. Por ejemplo, el byte 5672 de un archivo,
almacenado en un sistema de archivos que usa bloques de 4 KB, se encontrar en el segundo apuntador del
ndice. La ventaja de usar ndices es que basta con traer a memoria el bloque de ndices donde est el
apuntador a los datos para tener acceso al bloque de datos. Adems, si un apuntador de bloque ocupa 4
bytes y el bloque es de 4 KB, con un nico acceso a disco tendremos 1 .024 apuntadores a bloques del
archivo. Existe sin embargo un proble ma: el espacio extra necesario para los bloques de ndices. Imagine
que un archivo tiene 1 byte. Necesita un bloque de ndices asociado a su bloque de datos. Sin embargo, slo
usa una entrada del bloque de ndices (4 bytes) y 1 byte del bloque de datos. Ese problema fue resuelto en
UNIX BSD combinando un sistema de ndices puros con un sistema de ndices multinivel, que es el que se
usa actualmente en UNIX y LINUX. La Figura 8.24 muestra un ejemplo del nodo-i de UNIX con sus
bloques de ndice. Como puede verse, cada descriptor de archivo (nodo-i) tiene varios apuntadores directos
a bloques de datos y tres apuntadores a bloques de ndices de primero, segundo y tercer nivel. Este mtodo
tiene dos ventajas:
Permite almacenar archivos pequeos sin necesitar bloques de ndices.
Permite accesos aleatorios a archivos muy grandes con un mximo de tres accesos a bloques de ndices.
Sin embargo, sigue teniendo una desventaja: hay que acceder al nodo-i para tener las direccio nes de los
bloques de disco y luego leer los datos. Los sistemas operativos tipo UNIX tratan de paliar este problema
manteniendo los nodos-i de los archivos abiertos en una tabla de memoria.
Para evitar ese acceso extra, Windows NT almacena datos en el mismo descriptor de archivo. De esta
forma, muchos archivos pequeos pueden leerse completamente con un nico acceso a o e servidor de
archivos mantiene una estructura jerrquica en forma de rbol, donde en cada bloque se almacenan datos y
apuntadores aXosb\oques s S\ el archivo es muy grande, algunos de estos bloques pueden a su vez estar
llenos de apuntadores a nuevos bloques. Este esquema permite un acceso muy rpido a los datos, ya que
cada acceso trae datos, pero complica la implementacin del modelo de archivos en el servidor de archivos
porque el primer bloque necesita un clculo de direccin especial [Nagar, 1997].
El espacio de los dispositivos debe ser asignado a los objetos de nueva creacin y a los ya existentes que
requieran ms espacio de almacenamiento. Es pues necesario conocer el estado de ocupacin de los bloques
de los dispositivos para poder realizar las operaciones de asignacin de forma efi ciente Oldehoeft, 19851.
Por ello, todos los sistemas de archivos mantienen mapas de recursos, habitualmente construidos como
mapas de bits o listas de recursos libres.
Los mapas de bits, o vectores de bits, incluyen un bit por recurso existente (descriptor de archivo, bloque o
agrupacin). Si el recurso est libre, el valor del bit asociado al mismo es 1, si est ocupado es O. Por
ejemplo, sea un disco en el que los bloques 2, 3, 4, 8, 9 y 10 estn ocupados y el resto libres, y en el que los
descriptores de archivo 2, 3 y 4 estn ocupados. Sus mapas de bits seran:
MB de bloques: 1100011100011....
La principal ventaja de este mtodo es que es fcil de implementar y sencillo de usar. Adems es muy
eficiente si el dispositivo no est muy lleno o muy fragmentado, ya que se encuentran zonas contiguas muy
fcilmente. Sin embargo, tiene dos inconvenientes importantes: es difcil e inefi ciente buscar espacio si el
dispositivo est fragmentado y el mapa de bits ocupa mucho espacio si el dispositivo es muy grande. Por
ejemplo, un sistema de archivos de 4 GB, con un tamao de bloque de 4 KB, necesita 1 MB para el mapa
de bits de bloques. Para que la bsqueda sea eficiente, los mapas de bits han de estar en memoria, ya que
sera necesario recorrer casi todo el mapa de bits para encontrar hueco para un archivo. Imagine que un
sistema tuviera montados ocho dispositivos como el anterior, necesitara 1 MB de memoria slo para los
mapas de bits. Si se aplicara una agrupacin de 4 bloques, el tamao final del mapa de cada dispositivo
sera de 256 KB (32 KB), lo que equivale a 256 KB para los ocho dispositivos. Estas cantidades, con ser
grandes, son mucho menores que los 32 MB y 8 MB que seran respectivamente necesarios con la FAT de
MS-DOS.
Las listas de recursos libres permiten resolver el problema de forma completamente distinta. La idea es
mantener enlazados en una lista todos los recursos disponibles (bloques o descriptores de archivos)
manteniendo un apuntador al primer elemento de la lista. Este apuntador se mantiene siempre en memoria.
Cada elemento de la lista apunta al siguiente recurso libre de ese tipo. Cuando el servidor de archivos
necesita recursos libres, recorre la lista correspondiente y desenlaza elemen tos, que ya no estarn libres.
Como el lector puede comprender, este mtodo no es eficiente, excep to para dispositivos muy llenos y
fragmentados, donde las listas de bloques libres son muy peque as. En cualquier otro caso, recorrer las
listas requiere mucha entrada/salida. La FAT del sistema operativo MS-DOS es una lista enlazada. La
Figura 8.25 muestra un dispositivo cuyos bloques libres se mantienen en una lista con una entrada por
bloque libre (caso A). Este mtodo se puede optimizar incluyendo dentro de la lista la direccin de un
bloque libre y el nmero de bloques consecutivos al mismo que tambin estn libres. El caso B de la Figura
8.25 muestra la lista de bloques libres del mismo dispositivo anterior optimizada de la forma descrita.
Una posible optimizacin de la gestin de bloques libres es reunir los bloques en agrupaciones y mantener
mapas de bits o listas de recursos libres para ellas. Por ejemplo, si en el dispositivo anterior se usan
agrupaciones de 64 KB (16 bloques), el mapa de bits se reduce a 8 KB. Sin embargo, esto complica la
poltica de gestin de espacio libre en el servidor de archivos [Akyurek, 1995] y [Davy, 1995]. Los sistemas
operativos UNIX, LINUX y Windows NT usan este mtodo. Igualmente, se puede usar la agrupacin de
bloques en las listas de recursos libres. Obviamente, cuando se usan agrupaciones, la mnima unidad que se
puede asignar es una agrupacin, por lo que es muy importante decidir cul va a ser el tamao de la misma.
Cuanto mayor sea, ms grande puede ser la fragmentacin interna del dispositivo. Para paliar en parte este
problema, los sistemas que usan agrupaciones suelen usar tambin el mecanismo de gestin de fragmentos
descrito en la seccin del Fast File Svstem (FFS).
Los dispositivos de entradalsalida son habitualmente ms lentos que la UCP y los CCCSOS a memo ria.
Cada acceso a un dato en memoria cuesta pocos nanosegundos, mientras que acceder a un bloque de disco
cuesta varios milisegundos. La mayora de los servidores de archivos tratan de reducir esta diferencia, de
seis rdenes de magnitud, optimizando los mecanismos de que disponen para acceder a los datos.
Prcticamente todos los parmetros del servidor de archivos son suscepti bles de optimizacin. Ya se ha
visto que la asignacin de bloques libres se puede optimizar usando grupos de bloques, que las estructuras
de datos en uso (como nodos-i o superbloques) se guardan en tablas de memoria y que la correspondencia
de los bloques lgicos con los fsicos se puede optimi zar mediante el uso de ndices de mltiple nivel.
Tambin se ha visto que existen diferentes estruc turas de sistema de archivos que permiten optimizar
distintos tipos de accesos.
Adems de los mtodos anteriores, los sistemas operativos incluyen mecanismos de incremen to del
rendimiento de la entradalsalida basados en el uso de almacenamiento intermedio de datos de
entradalsalida en memoria principal. Estos mecanismos son de dos tipos:
Discos RAM, cuyos datos estn almacenados slo en memoria LTanenbaum, 19971. Estos discos
aceptan todas las operaciones de cualquier otro sistema de archivos y son gestionados por el
usuario. Excepto por su rapidez, el usuario no percibe ninguna diferencia cori cual quier otro tipo
de disco. Estos pseudodispositivos se usan habitualmente para almacena miento temporal o para
operaciones auxiliares del sistema operativo. Su contenido es voltil, ya que se pierde cuando se
apaga el sistema.
Cache de datos, instaladas en secciones de memoria principal controladas por el sistema operativo,
donde se almacenan datos para optimizar accesos posteriores. Es importante ob servar que este
mecanismo se basa en la existencia de proximidad espacial y temporal en las referencias a los
datos de entradalsalida [ 1985]. Al igual que ocurre con las ins trucciones que ejecuta un programa,
el sistema operativo asume que los datos de uii archivo que han sido usados recientemente sern
reutilizados en un futuro prximo. 1-lay dos caches importantes dentro del servidor de archivos:
cache de nombres y cache de bloques.
Windows NT incluye otro mecanismo de incremento de prestaciones para incrementar la ca pacidad de los
dispositivos de almacenamiento. Se trata de la compresin de datos de los archivos y directorios de
usuario.
Cache de bloques
La tcnica ms habitual para reducir el acceso a los dispositivos es mantener una coleccin de bloques
ledos o escritos, denominada cache de bloques, en memoria principal durante un cierto perodo de tiempo
[Braunstein, 19891 y [Smith, 19921. Aunque los bloques estn en memoria, el servidor de archivos
considera su imagen de memoria vlida a todos los efectos, por lo que es necesario mantener la coherencia
entre dicha imagen y la del disco. Como se vio anteriormente, el flujo de datos de entradalsalida de los
dispositivos de bloque pasa siempre a travs de la cache de bloques. Cuando se lee un archivo, el servidor
busca primero en la cache. Slo aquellos bloques no encontrados se leen del dispositivo correspondiente.
Cuando se escribe un archivo, los datos se escriben primero en la cache y posteriormente, si es necesario,
son escritos al disco. La Figura 8.26
muestra un esquema del flujo de datos en el servidor de archivos cuando hay una cache de bloques. Como
puede verse, el nmero de accesos al dispositivo se reduce drsticamente si hay aciertos en la cache. La tasa
de aciertos depende mucho del comportamiento de las aplicaciones que se ejecutan sobre el sistema
operativo. Si stas no respetan la proximidad espacial o temporal de las referencias en sus patrones de
acceso, o si ejecutan peticiones de entradalsalida tan grandes que sustituyen todos los bloques de la cache
constantemente, la tasa de aciertos es tan baja que en muchas aplica ciones conviene desactivar la cache de
bloques. Esta opcin est disponible en los sistemas operati vos de propsito general ms populares, como
UNIX o Windows NT. En el caso de UNIX, si se akwe d s de. baques como si fuera de caracteres, los
accesos a este dispositivo no pasan por la cache. En Windows NT se puede especificar si se desea usar la
cache o no en la llamada de creacin y apertura del archivo.
El formato de la cache de bloques es complejo [ 1996] y [ 1994]. La mayora de los servidores de archivos
usan listas doblemente encadenadas con hashing para optimizar la bsqueda y la insercin de bloques. Estas
listas conectan estructuras de datos que contienen, entre otras cosas:
La identificacin del bloque.
Los atributos del bloque (datos, especial, etc.).
El tipo de sistema de archivos al que pertenece el bloque.
El tamao del bloque referenciado.
Un apuntador a los datos del bloque.
Esta ltima caracterstica es fundamental para permitir que la cache pueda manejar bloques de datos de
distintos tamaos. El tamao de la cache puede ser fijo o variable. En las versiones anti guas de UNIX, la
cache era una estructura definida como un vector de bloques. Sus dimensiones eran, por tanto, fijadas en la
instalacin del sistema. En los sistemas operativos modernos, la cache es una estructura dinmica y su
tamao es mayor o menor dependiendo de la memoria que deja libre el resto del sistema operativo.
Digitalizacin realizada con propsito acadmico
484 Sistemas Operativos. Una visin aplicada
La gestin de la cache se puede llevar a cabo usando varios algoritmos, pero lo habitual es comprobar si el
bloque a leer est en la cache. En caso de que no est, se lee del dispositivo y se copia a la cache. Si la
cache est llena, es necesario hacer hueco para el nuevo bloque reemplazando uno de los existentes. Existen
mltiples polticas de reemplazo que se pueden usar en una cache de bloques, tales como el FIFO (First in
First Out), segunda oportunidad, MRU (Most Recently Used), LRU (Least Recently Used), etc. La poltica
de reemplazo ms frecuentemente usada es la LRU. Esta poltica reemplaza el bloque que lleva ms tiempo
sin ser usado, asumiendo que no ser referenciado prximamente. Los bloques ms usados tienden a estar
siempre en la cache y, por tanto, no van al 1 jj d pialtica pii crear problemas de fiabilidad en el sistema de
archivos si la computadora falla. Imagine que se cre un directorio con tres archivos que estn siendo
referenciados constantemente El bloque del directorio estar siempre en la cache. Si la computado ra falla,
esa entrada de directorio se habr perdido. Imagine que el bloque se ha escrito, pero su imagen en la cache
ha cambiado antes del fallo. El sistema de archivos queda inconsistente. Por ello, la mayora de los
servidores de archivos distinguen entre bloques especiales y bloques de datos. Los bloques especiales,
tales como directorios, nodos-i o bloques de apuntadores, contienen informacin crucial para la coherencia
del sistema de archivos, por lo que es conveniente salva guardar la informacin en disco tan pronto como
sea posible. Sin embargo, con un criterio LRU puro, los bloques de este tipo que son muy usados iran a
disco con muy poca frecuencia.
Para tratar de solventar el problema anterior, el sistema de archivos puede proporcionar distin tas polticas
de escritura a disco de los bloques de la cache que tienen informacin actualizada (se dice que estn
sucios). En el caso de MS-DOS, los bloques se escriben a disco cada vez que se modifica su imagen en la
cache de bloques. Esta poltica de escritura se denomina de escritura
inmediata (write-through). Con esta poltica no hay problema de fiabilidad, pero se reduce ci rendimiento
del sistema porque si un bloque se puede volcar varias veces a disco. Imagine que un usuario escribe un
bloque byte a byte. Con poltica de escritura inmediata se escribira el bloque a disco cada vez que se
modifique un byte. En el lado opuesto est la poltica de escritura diferida (write-back), en la que slo se
escriben los datos a disco cuando se eligen para su reemplazo por falta de espacio en la cache. Esta poltica
optimiza el rendimiento, pero genera los problemas de fiabilidad anteriormente descritos. Si los bloques de
datos se gestionan con poltica LRU pura, tambin se origina un problema de fiabilidad. Imagine que se
crea un archivo pequeo cuyos blo ques se usan de forma habitual. Sus datos estarn siempre en la cache.
Si la computadora falla, los datos del archivo se habrn perdido.
Para tratar de establecer un compromiso entre rendimiento y fiabilidad, algunos sistemas ope rativos, como
UNIX, usan una poltica de escritura retrasada (delaved-write), que consiste en escribir a disco los
bloques de datos modificados en la cache de forma peridica cada cierto tiempo (30 segundos en UNIX).
De esta forma se reduce la extensin de los posibles daos por prdida de datos. En el caso de UNIX, estas
operaciones son ejecutadas por un proceso de usuario denominado sync. Adems, para incrementar todava
ms la fiabilidad, los bloques especiales se escriben inme diatamente al disco. Una consecuencia de la
poltica de escritura retrasada es que. a diferencia de MS-DOS. en UNIX no se puede quitar un disco del
sistema sin antes volcar los datos de la cache. En caso contrario se perderan datos y el sistema de archivos
se quedara inconsistente o corrupto [ 19931. Por ltimo, en algunos sistemas operativos se aplica un nuevo
criterio de escritura, denominado escritura al cierre (write-on-close). Con esta poltica, cuando se cierra un
archivo, se vuelcan al disco los bloques del mismo que tienen datos actualizados. Esta poltica suele ser
com plementaria de las otras y permite tener bloques de la cache listos para ser reemplazados sin tener que
escribir al disco en el momento de ejecutar la poltica de reemplazo, con lo que se reduce el tiempo de
respuesta de esta operacin. En la mayora de los casos, el sistema operativo ejecuta esta poltica en
background, es decir, marca los bloques y los vuelca a disco cuando tiene tiempo para ello.
Compresin de datos
Esta razn depende mucho del grado de dispersin de los datos a almacenar. Si los datos estn muy
dispersos, gran parte del archivo est lleno de ceros, la razn de compresin es alta y se reduce
considerablemente el tamao del archivo. Si los datos no son dispersos, en cuyo caso se dice que son
densos, la razn de compresin ser peor.
El gran problema de comprimir un archivo es mantener mecanismos de asignacin y de mapas de bloques
que sean compatibles con los formatos no comprimidos. Observe que el usuario puede pensar que sus datos
ocupan n KB y que un usuario experto puede incluso intentar optimizar la entrada/salida en base al tamao
de bloque. En Wiindows NT, si se compime un archivo, las peticiones que hace el usuario llegan a la cache
de bloques con el mapa de bloques como si fuera descomprimido. Es a partir de este momento donde se
incluye, y oculta, 1a compresin. Para ello, en el MFT del archivo se asignan bloques nicamente para los
que tienen datos comprimidos. Los bloques que se han comprimido se marcan como vacos y no se les
asigna bloques. De esta forma. cuando se pide el bloque 36, por ejemplo, de un archivo comprimido se mira
en el MFT si estaba lleno de ceros o no. Si lo estaba, se le devuelve al usuario un bloque lleno de ceros. En
otro caso se accede al bloque comprimido donde se encuentra el bloque 36, se descomprime y se devuelve
al usuario la parte que est pidiendo.
Windows NT proporciona la llamada al sistema GetVolumelnformatiOn para ver si un volumen est
comprimido o no. Adems, se puede ver el tamao real de un archivo comprimido usando la llamada de
Win32 GetCompressedFileSiZe (Advertencia 8.3).
Una vez descrita la arquitectura del servidor de archivos y sus mecanismos de asignacin de bloques y de
incremento de prestaciones, se puede pasar a estudiar en detalle cmo se interpreta un nombre y cmo se
resuelve dicho problema cuando para interpretar el nombre hay que pasar a un sistema de archivos
montado. Para ello se usa como caso de estudio el sistema operativo
UNIX.
La Figura 8.27 muestra un ejemplo de montaje de un sistema de archivos en un directorio de otro sistema
de archivos. Como se puede ver, en el montaje se usan dos estructuras de datos de forma primordial: la
tabla de nodos-i y la tabla de superbloques del sistema. Esta ltima tabla contiene apuntadores a los
superbloques de los sistemas de archivos montados y es fundamental para ocultar el punto de montaje de un
dispositivo, como /dev/hda3, sobre un directorio, como /home/root/distr/lib
La implementacin del montado de sistemas de archivos es sencilla cuando se dispone, como en UNIX, de
las tablas de estructuras de datos adecuadas. Cuando se monta un sistema de archivos. se trae su
superbloque a memoria y se colocan en l dos apuntadores: uno al nodo-i del directorio raz del sistema de
archivos montado y otro al nodo-i del directorio sobre el que est montado. Adems se indica en el nodo-i
del directorio sobre el que se monta que tiene un sistema de archivos colgando de l y se incluye la entrada
de la tabla de superbloques en la que se almacen el superblo que del sistema de archivos montado. En la
operacin de desmontado se desconectan dichos apun tadores [Goodheart, 1994] y [ McKusick, 1996].
El concepto de sistema de archivos montados, tal como se ha explicado aqu, no existe en Windows NT,
por lo que la solucin adoptada es muy distinta a la de UNIX. En este caso, en funcin del nombre de
dispositivo lgico al que se quiere acceder, se busca en la tabla de superblo ques y se cambia directamente
al sistema de archivos de este dispositivo. En un sistema de este estilo es tpico tener mltiples unidades
lgicas accesibles a nivel local o remoto. Una unidad logica esun dispositivo de almacenamiento sobre el
que hay instalado un sistema de archivos, bien sea de Windows o de cualquier otro tipo. El usuario, o el
programador de sistema, debe saber en qu unidad logica (C:\, D:\, E:\, J:\,...) est el archivo que busca, ya
que pueden existir archivos con el mismo nombre que slo se pueden discriminar aadiendo la unidad
lgica al nombre. C: \pepe y D: \pe por ejemplo, on irchivo digtinto En Windows NT, ia unidad es
LuIIsustancIal al nombre absoluto de un archivo. Los nombres relativos lo son siempre dentro de una
unidad lgica.
La destruccin de un sistema de archivos es a menudo mucho peor que la destruccin de una computadora.
La recuperacin de los datos de un sistema de archivos muy daado es una operacin difcil, lenta y muchas
veces imposible {Anyawun, 19861. En algunos casos, la destruccin de ciertos datos archivados, como la
lista de clientes de una empresa o su contabilidad, pueden causar un dao irreparable a la organizacin
afectada, lo que en el caso de las empresas puede llevar a la quiebra o el cese de actividades. Imagina qu
podra ocurrir si una universidad perdiera todos los expedientes de sus alumnos por un fallo del sistema de
amacenamiento? Podra costar aos recupe rarlos del soporte en pape, suponiendo que ste exista. En esta
seccin se muestra cmo afrontan los servidores de archivos estos problemas, aunque muchas soluciones a
los problemas de fiabilidad y recuperacin son externas al sistema operativo y entran en los campos de
administracin del sistema, seguridad, etc.
Existen dos razones fundamentales por las que se pueden perder los datos de un sistema de archivos:
Copias de respaldo
Si un dispositivo de almacenamiento falla, los datos se perdern irremisiblemente. Por ello es necesario
hacer copias de respaldo (backups) de los sistemas de archivo con cierta frecuencia Frish, 19961. Las
copias de respaldo consisten en copiar los datos de un dispositivo a otro de forma total o parcial. Las copias
totales suelen requerir mucho tiempo y espacio extra, por lo que una
En los sistemas donde se necesita mucha disponibilidad, se puede almacenar la informacin de forma
redundante en mltiples discos. Adems, en caso de que se necesite fiabilidad, se puede aadir informacin
de paridad para poder reconstruir los datos en caso de fallo de una unidad de almacenamiento.
La tcnica clsica de almacenamiento redundante es usar discos espejo [Tanenbaum, 1992], es decir, dos
discos que contienen exactamente lo mismo. En este caso, toda la informacin se escribe en ambos discos,
pero se lee slo de uno. En caso de que una lectura falle, siempre se tiene la otra copia de los datos. Este
tipo de redundancia tiene dos problemas principales:
Desperdicia el 50 por 100 del espacio de almacenamiento.
Las tcnicas anteriores no sirven de mucho si los sistemas de archivos quedan en estado incoherente debido
a fallos de la computadora o a operaciones inadecuadas de los usuarios. Por ejemplo, su ponga que un
usuario de un sistema UNIX apaga la computadora mediante el interruptor elctrico sin ejecutar
previamente los procedimientos de apagado del sistema operativo. En este caso, toda la informacin nueva
de los bloques de la cache modificados durante los 30 segundos anteriores se
habr perdido. Este problema es especialmente crtico si algunos de los bloques perdidos contienen datos de
directorios o nodos-i, ya que la imagen del archivo o directorio afectado existente en el disco estar
incoherente. Imagine el caso de un archivo escrito frecuentemente. Se le han asignado bloques nuevos y se
han marcado como ocupados. Su nodo-i est en la cache y el mapa de bits tambin. Si se apaga la
computadora cuando se ha escrito el nodo-i pero no el mapa de bits, habr bloques marcados como libres en
el disco que estarn asignados al nodo-i de un archivo. Este problema puede existir incluso en sistemas que
usan escritura inmediata a disco, ya que la mayora de las aplicaciones del sistema de archivos implican la
actualizacin de varias estructuras de infor macin. Para tratar de resolver este tipo de problemas, los
servidores de archivos proporcionan operaciones para comprobar, y a ser posible recuperar, la coherencia
de los datos. Estas operaciones se acceden mediante un programa de utilidad, que en el caso del sistema
operativo UNIX se denomina fsck [Foxley 1985].
3. Se comprueba que los mapas de bits de bloques se corresponden con los bloques asigna dos a archivos.
4. Se comprueba que ningn bloque est asignado a ms de un archivo.
5. Se comprueba el sistema de directorios del sistema de archivos, para ver que un mismo nodo-i no est
asignado a ms de un directorio.
Para llevar a cabo las comprobaciones del estado de los bloques, el programa lleva a cabo las siguientes
acciones:
1. Construye dos tablas, cada una con un contador para cada bloque. La primera indica las veces que un
bloque es referenciado desde los nodos-i. La segunda indica si un bloque est libre u ocupado.
2. Lee los nodos-i de cada archivo e incrementa los contadores de los bloques referenciados.
3. Lee los mapas de bits de bloques e incrementa el contador de los que estn libres.
A continuacin compara ambas tablas. La Figura 8.29 muestra varios estados posibles de los bloques de un
sistema de archivos:
1. Si el sistema de archivos est coherente, los contadores de las tablas tendrn un 1 en una u otra
tabla, pero no en ambas a la vez (caso 1 de la figura).
2. En caso contrario, puede ocurrir que un bloque ocupado no est asignado a un archivo (caso 2 de la
figura). Se dice que se es un bloque perdido o sin propietario. En este caso es posible que exista
prdida de informacin en algn archivo, por lo que la herramienta de recuperacin los almacena
en un directorio predefinido, que en UNIX es tpicamente lost+found. Si el usuario es afortunado,
la informacin le permitir recuperar los datos perdidos. A continuacin se indica que el bloque
est libre.
3. Otra anomala posible es que un bloque ocupado est referenciado desde dos archivos (caso 3 de la
figura). En este caso se dice que ste es un bloque reutilizado. La solucin correcta en este caso es
Un procedimiento similar al anterior se usa para verificar los mapas de bits de los nodos-i
(Recordatorio 8.2).
Por ltimo, la utilidad de recuperacin comprueba el estado de los directorios. Para ello usa una tabla de
contadores de nodos-i que indican los enlaces existentes a cada nodo-i. Para calcular dicho nmero, el
programa recorre todo el rbol de directorios e incrementa el contador de cada nodo-i cuando encuentra un
enlace al mismo. Cuando ha terminado, compara los contadores con el nmero de enlaces que existe en el
nodo-i almacenado en disco. Si ambos valores no coinciden, se ajusta el del nodo-i al valor calculado.
Dada la importancia que para algunos sistemas tiene la coherencia de los datos almacenados en el sistema
de archivos y la disponibilidad de los mismos, algunos servidores de archivos incluyen servicios orientados
a satisfacer estas necesidades. Aunque existen mltiples mecanismos de este tipo, los tres ms populares
son la actualizacin atmica, las transacciones y la replicacin.
Un servidor de archivos que proporciona actualizacin atmica [Goscinski, 1991], o indivisi ble, asegura a
los usuarios que sus operaciones estn libres de interferencia con las de otros usuarios y que la operacin se
realiza completamente o no tiene ningn efecto en el sistema. Esta semntica todo o nada permite asegurar
que una operacin no tenga efecto a no ser que se complete satisfacto riamente. Existen varias formas de
implementar esta semntica. Algunas muy populares son usar mecanismos de almacenamiento estable,
archivos de registro o versiones de archivos. De esta for ma, todas las operaciones se pueden ejecutar en
estado provisional, hasta que el sistema est seguro de que concluyen satisfactoriamente. En ese momento
se convierten en definitivas. En caso de fallo, se descartan las acciones provisionales.
En muchos casos no basta con asegurar al usuario que una operacin sea atmica. La razn es que el
usuario puede querer que un conjunto de operaciones relacionadas se ejecuten de forma atmica. En estos
casos, el servidor de archivos puede ofrecer servicios de transacciones [Gray, 1981]. Un servidor de
archivos transaccional permite ejecutar operaciones atmicas que agrupan a varias operaciones de
entradalsalida y que se ejecutarn con semntica todo o nada. Desde el punto de vista del usuario, una
transaccin es una secuencia de operaciones que definen un paso nico para transformar los datos de un
estado incoherente a otro. Todas las operaciones que forman parte de una transaccin se agrupan entre dos
etiquetas, tales como begin y endtrans, que
definen el principio y el fin de la operacin. Una vez ms, todo sistema con atomicidad debe ser capaz de
deshacer un conjunto de operaciones en caso de fallo. La reversibilidad es consustancial a los sistemas
atrnicos. Los servidores de archivos transaccionales deben resolver adems problemas de aislamiento de
operaciones, serializacin, control de concurrencia, etc. Todos ellos se escapan del mbito de este libro, por
lo que se refiere al lector interesado en bibliografa especfica del tema.
La replicacin es un mecanismo importante para incrementar el rendimiento de las lecturas del servidor de
archivos y la disponibilidad de los datos. Consiste en mantener varias copias de los datos y otros recursos
del sistema [Bereton, 1986]. Silos datos estn replicados, en dos servidores o dispositivos distintos, se
puede dar servicio a los usuarios aunque uno de ellos falle. Adems, si varios servidores de archivos
procesan los mismos datos, las posibilidades de error se reducen drsticamente. Sin embargo, proporcionar
replicacin transparente en los servidores de archivos no es inmediato. Para que los usuarios no sean
conscientes de que existen varias copias de los datos, el servidor de archivos debe proporcionar acceso a los
mismos a nivel lgico, y no fsico. Cuando exista una peticin de lectura, el usuario debe recibir un nico
conjunto de datos. Adems, el sistema debe asegurar que la actualizacin de los datos se lleva a cabo en
todas las rplicas en un tiempo aceptable. Para satisfacer estos requisitos se han propuesto dos modelos
arquitectnicos bsicos: copia primaria y gestin colectiva (Fig. 8.30). En el modelo de copia primaria,
todos los servicios de escritura se piden a un servidor maestro de rplicas. Este gestor se encarga de
propagar
las operaciones a los esclavos que tienen las rplicas. El mayor problema de este modelo es que el maestro
es un cuello de botella y un punto de fallo nico. Como puede verse en la figura, con este modelo todas las
escrituras deben ejecutarse en el primario, que posteriormente se encarga de actualizar las rplicas de otros
gestores. En el modelo de gestin colectiva, todos los servidores son paritarios y no existe la relacin
maestro-esclavo. Las peticiones de lectura y escritura se sirven en cualquier servidor, pero las ltimas
deben ser propagadas a todos los servidores con copia de los datos afectados. Como puede verse en la
figura, con este modelo, las escrituras pueden ir a cual quier gestor de rplicas, pero ste debe propagar las
modificaciones a todos los gestores de rplicas restantes. Este modelo es ms eficiente y tolerante a fallos,
pero su diseo e implementacin es muy complicada.
Existe mucha bibliografa sobre sistemas de archivos y directorios que puede servir como lectura
complemen taria a este libro. [Silberschatz, 1998], [ 19981 y [Tanenbaum, 1997] son libros generales de
sistemas operativos en los que se puede encontrar una explicacin completa del tema con un enfoque
docente.
[Grosshans, 1986] contiene descripciones de las estructuras de datos que maneja el sistema de archivos y
presenta aspectos de acceso a archivos. Con esta informacin, el lector puede tener una idea clara de lo que
es un archivo y de cmo valorar un sistema de archivos. [Folks, 1987] incluye abundante informacin
sobre estructuras de archivo, mantenimiento, bsqueda y gestin de archivos. [Abernathy, 1973] describe
los princi pios de diseo bsico de un sistema operativo, incluyendo el sistema de archivos. En [McKusick,
1996] se estudia el diseo del Fast File Svstem con gran detalle, as como las tcnicas de optimizacin
usadas en el mismo. [Smith, 19941 estudia la influencia de la estructura del sistema de archivos sobre el
rendimiento de las operaciones de entrada/salida. [Staelin, 1988] estudia los tipos de patrones de acceso
que usan las aplicaciones para acceder a los archivos. Esta informacin es muy importante si se quiere
8.9. EJERCICIOS
8.1. Se puede emular el mtodo de acceso aleatorio con el secuencial? Y viceversa? Explique las ven
tajas e inconvenientes de cada mtodo.
8.2. Cul es la diferencia entre la semntica de coutili zacin UNIX y la de versiones? Podra emularse la
semntica UNIX con la de versiones?
8.3. Podran establecerse enlaces al estilo de los UNIX en Windows NT? Por qu?
8.4. Es UNIX sensible a las extensiones del nombre de archivo? Lo es Windows NT?
8.5. Cul es la diferencia entre nombre absoluto y re lativo? lndique dos nombres relativos para
/users/miguel/datos. Indique el directorio respecto al que son relativos.
8.6. Cul es la ventaja de usar un grafo acclico frente a usar un rbol como estructura de los directorios?
Cul puede ser su principal problema?
8.7. En UNIX existe una aplicacin mv que permite re- nombrar un archivo. Hay alguna diferencia entre
implementarla usando link y unlink y hacerlo copiando el archivo origen al destino y luego bo rrando este
ltimo?
8.8. Modifique el Programa 8.1 para que en lugar de copiar un archivo sobre otro lea un archivo y lo saque
por la salida estndar. Su programa es equi valente al mandato cat de UNIX.
8.9. Modifique el Programa 8.2 para que en lugar de copiar un archivo sobre otro lea un archivo y lo saque
por la salida estndar. Su programa es equi valente al mandato type de Windows o MS-DOS.
8.10. Usando llamadas POSIX, programe un mandato que permita leer un archivo en porciones, especifi
cando el formato de la porcin. Para incrementar el rendimiento de su mandato, debe hacer lectura
adelantada de la siguiente porcin del archivo.
8.11. Modifique el Programa 8.4 (mijs) para que, adems de mostrar el nombre de las entradas del
directorio, muestre algo equivalente a la salida del mandato ls -l de UNIX.
8.12. Haga lo mismo que en el Ejercicio 8.11 para el Programa 8.5 del entorno Windows NT.
8.13. Qu mtodo es mejor para mantener los mapas de bloques: mapas de bits o listas de bloques libres?
Indique por qu. Cul necesita ms espacio de al macenamiento? Explquelo.
8.14. Qu problema tiene usar bloques grandes o agru paciones? Cmo puede solucionarse?
8.15. Qu es mejor en un sistema donde hay muchas escrituras: un sistema de archivos convencional o uno
de tipo LFS? Y para lecturas aleatorias?
8.16. Es conveniente mantener datos de archivo dentro del descriptor de archivo, como hace Windows
NT?
La seguridad de un sistema tiene mltiples facetas, como se muestra en la Figura 9.1, incluyendo desde aspectos
tales como la proteccin ante posibles daos fsicos de los datos (fuegos terremotos, etc.) hasta el acceso indebido a los
mismos (intrusos, fallos de confidencialidad, etc Los ataques contra la confidencialidad, la integridad o la
disponibilidad de recursos en un sistet deben prevenirse y solventarse mediante la poltica y los mecanismos de
seguridad de un sistema En el caso de un sistema informtico hay varios elementos susceptibles de sufrir dichos
ataques,) siendo suficiente proteger slo alguno de ellos o protegerlos parcialmente. Como se puede ver en Figura 9.1,
el hardware, el software y los datos de un sistema informtico pueden sufrir ataques internos o externos al sistema. Por
tanto, la seguridad debe tener en cuenta eventos externos provenientes del entorno en que opera el sistema. De nada
sirve tener mecanismos de proteccin hiten muy buenos, si el sistema operativo no es capaz de identificar a los usuarios
que acceden al sistema o si no existe una poltica de salvaguarda de datos ante la rotura de un disco.
La proteccin, sin embargo, consiste en evitar que se haga un uso indebido de los recursos que
estn dentro del mbito del sistema operativo. Para ello deben existir mecanismos y polticas que aseguren
que los usuarios slo acceden a sus propios recursos (archivos, zonas de memoria, etc.). Adems, es
necesario comprobar que los recursos slo se usan por aquellos usuarios que tienen derechos de acceso a
los mismos. Las polticas de proteccin y seguridad de hardware, software y datos deben incluirse dentro
del sistema operativo, pudiendo afectar a uno o varios componentes del mismo. En cualquier caso, el
sistema operativo debe proporcionar medios para implementar la poltica de proteccin deseada por el
usuario, as como medios de hacer cumplir dicha poltica.
La seguridad de un sistema operativo se basa principalmente en tres aspectos de diseo:
La prdida de datos puede deberse a catstrofes naturales o artificiales que afecten al sistema
(terremotos, guerras, etc.), a errores del hardware o del software de la computadora (rotura de un disco, por
ejemplo) o a errores humanos (p. ej.: borrado accidental de archivos). La proteccin frente a fallos fsicos,
para conseguir que el sistema sea fiable, est ms relacionada con la gestin de datos que con el sistema
operativo. Una solucin frecuente para estos problemas es hacer que los administradores del sistema
mantengan varias copias de los datos almacenadas en distintos lugares.
En el mbito interno del sistema operativo hay operaciones que pueden violar la confidencialidad de los
datos. Una simple asignacin de bloque de disco libre a un usuario le proporcionar el bloque con el
contenido del usuario anterior si el sistema operativo no tiene una poltica definida para este tipo de
situaciones. En estos casos, siempre hay que limpiar los recursos de los datos anteriormente existentes. Sin
embargo, controlar la confidencialidad de los datos es un problema de seguridad que sobrepasa el mbito
de los sistemas operativos, aunque una parte del problema puede resolverse en su mbito interno. De nada
sirve controlar muy bien el acceso a la base de datos de nminas, si un operador de una compaa
distribuye listas de personal con sus nminas y datos personales. Otro ejemplo es la realizacin de
transacciones comerciales a travs de Internet, en muchas de las cuales se envan nmeros de tarjeta de
crdito sin proteccin. La solucin de este tipo de problemas requiere actuaciones externas al sistema
operativo, que pueden ser incluso policiales.
El control del acceso a datos y recursos s es competencia directa del sistema operativo. Es necesario
asegurar que los usuarios no acceden a archivos para los que no tienen permisos de acceso, a cuentas de
otros usuarios o a pginas de memoria o bloques de disco que contienen informacin de otros usuarios
(aunque ya estn en desuso). Para conseguirlo hay que aplicar criterios de diseo rigurosos y ejecutar
pruebas de seguridad exhaustivas para todos los elementos del sistema, aunque se consideren seguros. El
control de acceso incluye dos problemas que estudiaremos ms adelante: autenticacin de usuarios y
proteccin frente a accesos indebidos.
A continuacin se estudian los problemas de seguridad ms importantes que conciernen al sistema
operativo, aunque el lector debe tener en cuenta que los mecanismos de proteccin del sistema operativo
slo resuelven una mnima parte de los problemas de seguridad existentes en una instalacin informtica.
Todos los sistemas operativos comerciales desarrollados hasta el momento han tenido algn problema
de seguridad. Algunos ejemplos notorios son:
500 Sistemas operativos. Una visin aplicada
Los fallos de UNIX que permitan, en su momento, que un usuario pudiera abortar un mandato con
permisos de sper usuario, como mkdir, y quedarse con la identificacin de sper-usuario.
En versiones antiguas de UNIX, cualquier usuario poda leer el archivo passwd donde se almacenaban
los usuarios y sus palabras clave cifradas. Con esta informacin se le podan aplicar a la clave todos los
algoritmos de descifrado que se quisiera hasta romperla.
En TENEX, un sistema operativo en desuso, se comprobaba la palabra clave carcter a carcter.
Cuando se cometa un error se indicaba al usuario. De esta forma era muy sencillo introducir la clave carcter
a carcter para buscar patrones vlidos hasta descifrarla completamente. Como mximo era necesario probar
todos los caracteres del alfabeto por cada carcter de la clave.
Muchos fallos no se deben al sistema de proteccin sino a la candidez de los usuarios. Poner como
palabra de acceso al sistema el nombre de su esposa, de algn hijo o la matrcula de su coche o poner " . "
en la cabecera del path (camino de bsqueda de archivos ejecutables) es postularse como candidato a un
acceso indebido.
A continuacin se describen los problemas ms frecuentes en un sistema informtico.
Algunos problemas de seguridad estn relacionados con el uso indebido, o malicioso, de programas de
un usuario [Hoffman, 1990]. Dos formas frecuentes de generar fallos de seguridad usando estas tcnicas
son el caballo de Troya y la puerta de atrs. El caballo de Troya se basa en la idea de crear un programa
para que haga cosas no autorizadas en el sistema cuando acta en el entorno adecuado. Algunos ejemplos
incluyen: un editor de texto modificado para que haga copias de los archivos a los directorios del intruso o
un programa de login modificado para grabar los nombres y palabras de acceso de los usuarios. La puerta
de atrs consiste en crear un agujero de seguridad al sistema a travs de un programa privilegiado que lo
permite. Algunos ejemplos incluyen:
Convencer a un programador de sistema para que le deje acceder con privilegios anormales.
Permitir que el diseador de un programa se reserve el acceso por medios no conocidos, tales como una
identificacin reservada.
Meter parches en un compilador para que aada cdigo no autorizado a cualquier programa.
Los problemas de seguridad generados por programas maliciosos son generalmente difciles de
detectar y corregir. En los aos sesenta dos programadores robaron varios millones de dlares en un banco
americano por el mtodo de traspasar a una cuenta suya las fracciones de centavo que se redondeaban en
las operaciones. Slo fueron detectados cuando el balance de caja empez a fallar de forma escandalosa.
Las puertas de atrs no siempre son perjudiciales o maliciosas. Pueden tener varias causas:
Se dejan a propsito para probar el sistema.
Se dejan para mantener el sistema.
Se dejan como un medio de acceso encubierto, o canal encubierto, que permite extraer informacin del
sistema sin que el dueo sea consciente de ello.
Slo este ltimo caso es realmente peligroso, si bien cualquier puerta de atrs es un peligro
potencial para la seguridad del sistema. La Figura 9.2 muestra un ejemplo de insercin de un canal
encubierto en un programa.
Seguridad y proteccin 501
Los usuarios inexpertos o descuidados son potencialmente muy peligrosos. Cosas tales como borrar
archivos no deseados, dejar abiertos los accesos al sistema durante largo tiempo o escribir la palabra clave
en un papel junto a la computadora son ms frecuentes de lo que parece.
Los problemas de seguridad debidos a usuarios descuidados deben tener atencin especial por parte
del administrador del sistema, que puede conseguir paliar muchos de ellos. Por ejemplo, ciertos mandatos,
como delete o rm (borrar archivos), se pueden configurar para pedir confirmacin de cada accin que
realizan, el acceso a un sistema se puede cerrar si se detecta que lleva un cierto tiempo inactivo, etc.
ridad, por ello los administradores siempre prefieren tener sistemas sin interferencias externas, de
forma que se pueda evitar que programas externos entren en dominios de otros usuarios [Parker, 1981]. Sin
embargo, actualmente es muy difcil tener sistemas completamente aislados. Cualquier computadora actual
tiene una unidad de disco extrable o una conexin a la red. Adems, aunque se intenten comprobar todos
los accesos desde dispositivos extemos, existe un cierto grado de apertura que no se puede evitar. El
correo electrnico, por ejemplo, puede usarse como portador de programas pequeos que posteriormente
cargan en el sistema programas ms destructores. La existencia de sistemas abiertos da lugar a cuatro
tipos principales de ataques de seguridad: virus, gusanos, rompedores de claves y bombardeos. Todos ellos
estn relacionados con la capacidad de propagacin de unos sistemas a otros, lo que permite atacar desde
sistemas remotos o enviar programas de ataque a otros sistemas.
9.2.4. Virus
Se denomina con este nombre a todos los programas que se autorreplican con fines destructivos o de
violacin de seguridad. Se llaman as por analoga con los virus que actan sobre los seres vivos. Como
ellos, necesitan de un programa que transporte el virus y de un agente que los transmita para infectar a
otros programas. En todos los casos se trata de un programa o un trozo de cdigo que se aade a otro y
que se activa cuando se ejecuta el programa portador. Cuando esto ocurre, adems de ejecutarse el
portador, se ejecuta el virus.
La Figura 9.3 muestra el proceso descrito. El fabricante de un virus genera un programa y lo
almacena en un disquete. Cuando se copia dicho archivo en una computadora y se ejecuta, el virus se
instala en el disco duro del sistema. A partir de este momento, infecta a todos los discos extrables que se
instalen en el sistema. En un determinado momento, el virus se activa y destruye los datos del sistema. Un
caso tpico de virus con caballo de Troya es el Viernes 13. Este virus slo se activa en los das que son
viernes y 13.
Figura 9.3. Instalacin y propagacin de virus.
9.2.5. Gusanos
El 2 de noviembre de 1988, R. T. Morris, un estudiante de Cornell, liber un
programa gusano en Internet. Anteriormente haba descubierto dos fallos de
seguridad en el UNIX de Berkeley que le permitan acceder a miles de mquinas
conectadas a Internet, especialmente aquellas que permitan accesos por ftp a
usuarios annimos. Aprovechando esta circunstancia, fabric un gusano que
explotaba los fallos de seguridad para acceder a sistemas remotos y, adems, se
replicaba a s mismo para acceder a ms sistemas. El gusano estaba compuesto
por dos programas: un pequeo programa de 99 lneas en C y el gusano principal.
El programa pequeo era un cargador que, una vez compilado y ejecutado en el
sistema destino, cargaba el gusano principal. El gusano lea las tablas de
encaminamiento del sistema infectado y enviaba el cargador a todos los sistemas
remotos que poda, usando para ello tres mecanismos de penetracin:
Intrprete de mandatos remoto (rsh).
Demonio del finger.
sendmail.
9.2.7. Bombardeo
Un ataque de seguridad con mucho xito en Internet es el que consiste en
llevar a cabo bombardeos masivos con peticiones de servicio o de establecimiento
de conexin a un servidor determinado. Estos ataques masivos provocan que el
servidor deniegue sus servicios a los clientes legales y pueden llegar a bloquear al
servidor. Este problema caus a principios del ao 2000 el bloqueo de servidores de
Internet famosos como yahoo o altavista. Para lograr que estos ataques tengan
xito, los atacantes se enmascaran con las direcciones e identidades de otros
usuarios (spoofing) y llevan a cabo los ataques desde mltiples clientes.
Ataques similares pueden ocurrir en cualquier computadora, ya que todas ellas
tienen recursos limitados. La tabla de procesos, por ejemplo, es crtica, ya que si se
llena, la computadora no puede crear ni siquiera el proceso de apagar el sistema. Un
usuario descuidado, o malicioso, que cree
Seguridad y proteccin 505
procesos de forma recursiva y sin lmite colapsar el sistema continuamente. Para evitarlo, los administradores
deben poner lmites, siempre que sea posible, a los recursos que cada usuario puede tener simultneamente
(nmero de procesos, impresoras, etc.).
POLTICAS DE SEGURIDAD
Los requisitos de seguridad son siempre una cuestin importante en las organizaciones. Por ejemplo,
la ley obliga a mantener como privados los datos de los clientes de una empresa. Por ello, cuando se
demuestra que se han difundido estos datos, se imponen multas a las compaas que violan la ley. Esto se
debe generalmente a que el acceso a dichos datos no est controlado o a que las reglas de acceso son tan
laxas que todos los compartimentos se encuentran entremezclados. Otro ejemplo interesante es el de la
informacin reservada. Imagine que dos bancos se quieren fusionar. Conocer esta informacin a tiempo
puede permitir hacer grandes negocios o evitar dicha fusin. Para evitar la difusin de la informacin, se
mantiene en compartimentos pequeos que requieren una acreditacin de acceso muy grande. La
existencia de un sistema seguro pasa porque exista una poltica de seguridad [Neumann, 19901 que
defina claramente la seguridad que proporciona el sistema, independientemente de los mecanismos usados
para implementarla.
Es interesante resaltar que los requisitos de seguridad varan de unos sistemas a otros, e incluso entre
usuarios distintos dentro del sistema. Imagine que una universidad tiene una computadora compartida entre
alumnos y profesores, de forma que los alumnos no puedan tener acceso a Internet pero los profesores s.
El sistema operativo de esta computadora necesita una poltica de control de acceso a los recursos segn el
usuario que solicite dichos accesos. Por eso, cuando se instala un sistema operativo en una computadora
con restricciones de seguridad, es necesario saber primero si la poltica de seguridad que ofrece dicho
sistema operativo satisface los requisitos de seguridad de la instalacin. Es decir, si es confiable. Ahora
bien, un sistema operativo slo es confiable respecto a una poltica de seguridad, es decir, a las
caractersticas de seguridad que se esperen del sistema.
Existen distintas polticas de seguridad, todas las cuales describen polticas de seguridad generales
para cualquier organizacin. A continuacin, se estudian brevemente algunas de ellas, aplicndolas al
campo de los sistemas operativos.
sta es una de las polticas ms popularmente conocidas y tambin de las ms estrictas, por lo que casi
nunca se aplica en su totalidad. Se basa en la clasificacin de todos los objetos con requisitos de seguridad en uno
de los cinco niveles de seguridad siguientes:
Desclasificado.
Restringido.
Confidencial.
Secreto.
Alto secreto.
Y en clasificar tambin a los usuarios segn el nivel al que pueden acceder [NCSC, 1985]. Segn muestra la
Figura 9.4, los cinco niveles se estructuran lgicamente como un conjunto de crculos concntricos en cuyo interior
est el alto secreto y en cuyo exterior estn los documentos pblicos (o desclasificados).
506 Sistemas operativos. Una visin aplicada
Usando esta relacin se puede decidir que un sujeto puede acceder a un objeto slo si su dominancia
es mayor. Lo que equivale a decir que el sujeto debe estar suficientemente acreditado y que su
compartimiento debe estar dentro de aquellos que tienen el acceso permitido al objeto. Imagine una
empresa con dos secciones: personal y contabilidad. El presidente tiene acceso a
Seguridad y proteccin 507
ambos y acreditacin O, mayor que los jefes de dichas secciones (compartimentos) que tienen
acreditacin 1. El jefe de personal y el presidente tienen acceso a los expedientes de los trabajadores
(clasificacin nivel 1), pero el de contabilidad no. Su acreditacin es suficiente, pero su seccin no est
dentro del compartimento de las que tienen acceso a esos documentos.
Una poltica similar a sta se us en el ncleo de seguridad del VAX, un ncleo que daba soporte de
ejecucin seguro a los sistemas operativos VMS y ULTRIX. El diseo de este ncleo tena 16 niveles, cada
uno de los cuales exportaba servicios a los niveles superiores e importaba los del nivel inmediatamente
inferior. Dichos niveles incluan desde una simulacin del hardware hasta la memoria virtual y la
entrada/salida. La Figura 9.5 muestra los dominios de seguridad del sistema operativo VMS.
Objetos.
Grupos.
Clases de conflicto.
Sistemas operativos. Una visin aplicada
Cada objeto pertenece a un nico gmpo y cada gmpo a una nica clase de conflicto. Una clase de
conflicto, sin embargo, puede incluir a varios grupos. Por ejemplo, suponga que existe informacin de tres
fabricantes de automviles (Volkswagen, Seat y General Motors) y dos bancos (BSCH y BBVA). Con la
muralla china existen 5 grupos y 2 clases de conflicto (bancos y automviles). La poltica de control de
acceso es sencilla. Una persona puede acceder a la informacin siempre que antes no haya accedido a otro
grupo de la clase de conflicto a la que pertenece la informacin a la que quiere acceder. La Figura 9.6
muestra el bloqueo de accesos para el caso en que un usuario, denominado Miguel, manipula informacin
en ambas clases de conflicto. En su primer acceso, Miguel conoce informacin de la clase de conflicto
Bancos, especficamente del BSCH. Eso le invalida para conocer ms informacin de otros grupos de esa
clase de conflicto. En el acceso 2 Miguel conoce informacin de la clase de conflicto Automocin,
especficamente de General Motors. Por tanto, para posteriores accesos podr acceder a ambas clases de
conflicto, pero slo a los grupos que ya ha accedido.
Los modelos de seguridad limitada se centran en responder formalmente las propiedades que un
sistema seguro debe satisfacer, pero introduciendo restricciones a los sistemas de seguridad multinivel.
Todos ellos se basan en dos principios:
Usan la teora general de la computacin para definir un sistema formal de reglas de proteccin.
Usan una matriz de control de acceso, en cuyas filas estn los sujetos y en cuyas columnas estn los
objetos.
Los derechos de acceso del sujeto i sobre el objeto j son los contenidos del elemento de la matriz (i, j ).
Ejemplos de modelos de este tipo son los de Graham-Denning, los de Harrison-Ruzzo-Hullman (HRU) y los
de permiso de acceso [Harrison, 1985].
Es importante resaltar que la existencia de un modelo de seguridad no es requisito obligatorio en todos
los sistemas operativos. Sin embargo, si se quiere demostrar a alguien que el sistema es confiable y seguro,
tener un modelo con validacin formal es una de las mejores formas de hacerlo. En los sistemas operativos
con un nivel de seguridad muy alto, como el ncleo de seguridad del VAX, s es obligatoria la existencia de
un modelo de seguridad formalmente verificable. Los modelos que se usan en la mayora de los sistemas
operativos actuales se basan en modelos de seguridad limitada del tipo HRU. La implementacin de una
matriz de acceso y su explotacin por filas o columnas es una de las formas ms populares de implementar
los mecanismos de proteccin en sistemas operativos de propsito general.
Se puede consultar bibliografa ms especfica de sistemas de seguridad, como [Landwher, 1981] o
[Fites, 1989] para tener una explicacin detallada de los modelos de proteccin.
Para dotar a un sistema operativo con mecanismos de seguridad es necesario disearlo para que admitan
estos mecanismos desde el principio. Incluir mecanismos de seguridad dentro de un sistema operativo
existente es muy difcil porque las repercusiones de los mecanismos de seguridad afectan prcticamente a
todos los elementos del sistema operativo. Adems, el diseo del sistema de seguridad debera ser lo
suficientemente flexible como para poder proporcionar distintas polticas de seguridad con los mecanismos
diseados.
En general, el concepto de seguridad es demasiado exigente, siendo imposible disear y construir un
sistema seguro para siempre. Por ello, en muchos sistemas se centra el diseo de seguridad en conseguir un
sistema confiable, es decir, un sistema que satisface los requisitos de seguridad de terceros o que es capaz
de generar confianza en los usuarios. Un sistema ser confiable si el conjunto de mecanismos de proteccin,
incluyendo hardware, software yfirmware, proporciona una poltica de seguridad unificada en el sistema.
Existen casos en que los usuarios confan en sistemas no totalmente seguros. Un ejemplo claro es el
automvil. Su conduccin genera multitud de accidentes por fallos mecnicos y humanos. Sin embargo,
muchas personas confan ms en su vehculo particular que en un avin, aunque todos los datos demuestran
que el avin es ms seguro.
1. Diseo abierto. El diseo del sistema debera ser pblico para disuadir a posibles curiosos. Los
mecanismos de proteccin no deben asumir la ignorancia de los posibles intrusos, reduciendo los aspectos
ocultos al mnimo. Adems, un diseo abierto puede ser estudiado y probado por cualquiera, lo que permite
tener verificaciones independientes del sistema.
2. Exigir permisos. La poltica de acceso por defecto debera ser restrictiva, es decir, denegar el acceso.
Es mejor identificar qu objetos son accesibles y cmo identificar los que no. De esta forma se tienen
mecanismos para pedir permisos de acceso a todos los objetos.
3. Privilegios mnimos. Los procesos deberan tener la menor prioridad posible que les permita acceder
a los recursos que necesitan. Se les debe conceder nicamente la prioridad necesaria para llevar a cabo su
tarea. Este principio permite limitar los daos en casos de ataques maliciosos.
4. Mecanismos econmicos. Los mecanismos de proteccin deberan ser sencillos, regulares y
pequeos. Un sistema as se puede analizar, verificar, probar y disear fcilmente.
5. Intermediacin completa. Cada intento de acceso al sistema debe ser comprobado, tanto los directos
como los indirectos. Los mecanismos de comprobacin deberan estar situados en zonas del sistema operativo
donde no puedan ser evitados. Lo lgico es que estn ocultos en los niveles inferiores del sistema. Si se relaja
este principio de diseo de forma que no se comprueben todos los accesos a un objeto, es necesario
comprobar los permisos de los usuarios de forma peridica y no slo cuando se accede al recurso por primera
vez.
6. Comparticin mnima. Los objetos compartidos pueden servir como canales de comunicacin de
informacin. Los sistemas que usan la separacin fsica o lgica de los usuarios permiten reducir el riesgo de
comparticin ilegal de objetos. La memoria virtual, por ejemplo, permite separar los espacios de memoria de
cada objeto y controlar los accesos a memoria con gran detalle. La separacin debe aplicarse cuidadosamente
cuando se asignan a un usuario objetos libres que antes fueron de otro usuario, para evitar que se conviertan
en canales de comunicacin encubiertos. Los archivos o pginas de memoria usados por un usuario y
liberados posteriormente deben ser borrados fsicamente para que otros usuarios no puedan reusar dicha
informacin por accidente o por mala fe. Imagine, por ejemplo, que un usuario crea un archivo, lo escribe y lo
borra. A continuacin, otro usuario crea un archivo y pide bloques pero no escribe. Es muy probable que se le
den bloques del usuario anterior con toda la informacin que contenan. Este fallo de seguridad ocurra en las
primeras versiones de UNIX.
7. Fciles de usar y aceptables. El esquema de proteccin debe ser aceptado por los usuarios y fcil de
usar. Por ejemplo, un anlisis de DNA sera muy fiable para identificar al usuario, pero el lector puede entender
que los usuarios de una computadora no seran muy felices si se tuviesen que hacer un anlisis de sangre
cada vez que quieren entrar al sistema. Si un mecanismo es sencillo, y no es desagradable, existen menos
probabilidades de que los usuarios traten de evitarlo.
8. Separacin de privilegios. Si se quiere disear un sistema seguro, los accesos a cada objeto deben
depender de ms de un mecanismo de proteccin. De esta forma, si se consigue violar uno de ellos, todava
quedarn los restantes mecanismos de proteccin. Tener la informacin criptografiada aade un plus de
seguridad, ya que aunque un intruso pueda acceder a la informacin todava debe ser capaz de descifrarla.
Todo lo descrito anteriormente necesita ser implementado en el sistema operativo para proporcionar
seguridad a los usuarios, por lo que el diseo de los aspectos de seguridad de un sistema operativo es una
tarea delicada [Bell, 19831. Es necesario elegir un conjunto apropiado y coherente
Seguridad y proteccin 511
Autenticacin de usuarios. Si hay que controlar los accesos basndose en la identidad individual de
cada potencial usuario del sistema, dichas identidades deben ser precisas. La existencia de identidad conlleva
la necesidad de autenticar, o verificar, esa identidad. En un sistema operativo debe existir un mtodo seguro y
fiable de identificar a los usuarios y cada usuario debe tener una identidad nica. Adems, en caso de que un
intruso consiga acceder al sistema, es necesario detectar dicha violacin. Esta caracterstica todava no existe
en muchos sistemas operativos.
Asignacin de recursos. Los objetos de un sistema operativo deben ser asignados a los procesos que
los solicitan sin que haya conflictos, violaciones de normas de seguridad, problemas de comparticin o fallos de
confidencialidad a travs de recursos reusables. Las pginas de memoria, por ejemplo, pertenecen a un
proceso o a otro dependiendo del estado de la memoria fsica. La reutilizacin de recursos puede originar fallos
de seguridad, que pueden ser maliciosos o no. Para evitar este problema, el sistema operativo debe borrar la
informacin existente dentro de un objeto antes de permitir que otro usuario lo utilice.
Control de accesos a los recursos del sistema. El dueo de un objeto tiene un cierto gradcC de libertad
para establecer quin y cmo puede acceder a un objeto. Adems, esta situacin puede cambiar
dinmicamente. Los sistemas operativos de propsito general usan este tipo de polticas discrecionales. Los
seguros usan polticas con controles obligatorios.
Control de la comparticin y la comunicacin entre procesos. Para que se puedan aplicar controles de
acceso, hay que controlar todos los accesos, incluyendo la comunicacin entre procesos y la reutilizacin de
elementos. La complejidad del sistema de seguridad aumenta a medida que existen ms formas de acceder al
sistema (memoria, archivos, puertos, redes, etctera).
Proteccin de los datos del sistema de proteccin en s mismo. Los sistemas operativos almacenan la
informacin de seguridad en recursos internos del sistema. Es necesario tener estos recursos bien protegidos
para que el acceso a los mismos no facilite violaciones de seguridad. En versiones antiguas de UNIX, el archivo
de usuarios con las claves cifradas era legible para todo el mundo. A travs de este archivo se poda conocer
las identidades de los usuarios y tratar de romper sus claves. Adems, muchos sistemas operativos registran
todos los eventos que son relevantes para la seguridad, tales como accesos, fallos de acceso, cambios de
protecciones, etc. Este registro se lleva a cabo en uno o ms archivos, que deben estar protegidos de accesos
no autorizados. La mayora de los sistemas registran el primer y ltimo acceso a un objeto, pero aun as los
registros de eventos suelen ser grandes y difciles de analizar.
La Figura 9.7 relaciona las tareas de seguridad anteriores con las funciones ms tradicionales del
sistema operativo. Como se puede ver, el control de acceso es fundamental para servicios, ; utilidades y
recursos fsicos. La autenticacin de usuarios est intrnsecamente relacionada con la [: interfaz de
usuario en un sistema operativo tradicional. Aunque en sistemas conectados a redes I tambin es
necesario autenticar a usuarios que acceden a travs de la red. La asignacin de recursos ; afecta al
reparto de tiempo de la UCP, espacio en dispositivos de E/S, espacio en memoria, etc. [s Adems de
estas funciones, el sistema operativo debe controlar que la comparticin de recursos del s sistema sea
segura.
512 Sistemas operativos. Una visin aplicada
Existen distintas tcnicas de diseo que se pueden usar para dotar a un sistema operativo con los
principios y caractersticas de seguridad descritas anteriormente. En esta seccin se describen las tres
principales:
Separacin de recursos.
Uso de entornos virtuales.
Diseo por capas.
Separacin de recursos
Una de las formas ms seguras y eficaces de evitar problemas de seguridad es separar los recursos de
los distintos usuarios o dominios, de forma que no puedan compartirlos o que la forma de compartirlos est
completamente controlada a travs de un medio de comunicacin fiable. Hay cuatro formas bsicas de
separacin entre procesos:
Fsica. Los procesos ejecutan en distintas plataformas hardware, dependiendo de sus restricciones
de seguridad. Por ejemplo, se puede instalar el software nuevo en una mquina aislada para prevenir la
extensin de virus o ejecutar los procesos con restricciones fuertes de seguridad en entornos de
computacin restringidos. Es importante resaltar que gran parte del hardware usado actualmente
proporciona separacin fsica para recursos tales como memoria, ejecucin de procesos ligeros, sistema
operativo y aplicaciones [Wiikes, 1982].
Seguridad y proteccin 513
Temporal. Ocurre cuando los procesos se ejecutan a distintas horas. Algunos sistemas operativos, como el VMS
de DEC, permiten especificar a qu horas puede ejecutar un proceso, cundo se puede acceder a un sistema
desde un terminal, etc. En sistemas grandes se permite ejecutar trabajos interactivos durante una ventana
horaria (p. ej.: de 9 a 18 horas) y a partir de esa hora slo se permite la ejecucin de trabajos por lotes (batch).
Criptogrfica. Usa la criptografa para asegurar que los datos de distintos usuarios no sean inteligibles para los
dems, aunque puedan acceder a dichos datos.
Lgica. Los sistemas proporcionan mltiples espacios lgicos de ejecucin, asignando uno a cada proceso. El
sistema operativo separa as los objetos y el contexto de un usuario de los de otro.
Los sistemas operativos multiprogramados proporcionan separacin fsica y lgica, aislando cada
proceso de los otros y permitiendo nicamente la comunicacin a travs del sistema operativo. Cada
proceso, por ejemplo, tiene su espacio de memoria virtual y su propio rbol de archivos y directorios. Para
evitar una rigidez excesiva, en algunos sistemas operativos, como UNIX, se dejan canales de comunicacin
con menos control. Por ejemplo, si un usuario quiere dar un archivo a todos los dems slo tiene que
copiarlo al directorio /tmp, al que puede acceder cualquier usuario para leer y escribir. Las separaciones
temporales o criptogrficas, en caso de estar disponibles, suelen ser discrecionales del administrador o
incluso del propio usuario.
La Figura 9.9 muestra un sistema por capas y, dentro de l, cmo afectan a cada nivel las tareas de
seguridad. Este diseo permite relajar el concepto de ncleo de seguridad, repartiendo sus funciones por
las distintas capas del sistema, ocultar datos entre niveles y reducir daos en caso de fallos de seguridad.
En cada capa del sistema se puede incluir toda la funcionalidad que afecta a los elementos de esta capa.
En caso de que haya un fallo de seguridad, slo esos elementos se vern afectados. Imagine lo que
supondra la existencia del mismo fallo de seguridad dentro de un ncleo monoltico. El fallo podra afectar a
todo el sistema sin limitacin.
Ejemplos de diseo por capas de sistemas seguros son MULTICS y la versin de seguridad del
sistema operativo VMS. En VMS, cada anillo del sistema es un dominio de ejecucin, siendo el ncleo la
capa ms interna (Fig. 9.10). Los anillos se implementan como bandas concntricas alrededor del hardware,
de tal forma que los procesos ms fiables ejecutan en niveles internos, mientras los de usuario se quedan
en las capas extemas. Los anillos se solapan, de forma que | ejecutar en un determinado anillo significa
tener los privilegios de ese nivel y los de todos los | anillos ms externos. El ncleo es la parte del sistema
operativo que ejecuta las operaciones del nivel ms bsico, tales como comunicacin, planificacin, gestin
de interrupciones, etc. Elncte@| es adems responsable de los servicios de seguridad para todo el sistema
operativo, proporcionand&J interfaces seguras para el hardware y las partes restantes del sistema
operativo.
Seguridad y proteccin 515
Figura 9.9. Diseo por capas y tareas de seguridad.
al mismo [ 1990]. En esta seccin se consideran los tres tipos de controles externos al sistema
operativo que se aplican ms frecuentemente para prevenir fallos de seguridad durante las etapas
de desarrollo y de prueba de un sistema operativo:
Prevenir todos los problemas de seguridad posibles es difcil, como veremos ms adelante. Para
tratar de detectar el mayor nmero de fallos posible es habitual usar equipos de penetracin. Su
misin consiste en llevar a cabo todos los ataques de seguridad imaginables sobre un sistema. Un
conjunto de pruebas de seguridad bien diseado es muy complejo, porque debe incluir desde
cosas muy sencillas hasta muy sofisticadas. Por ejemplo, intentar leer bloques de disco o pginas
de memoria al azar, intentar entrar en cuentas de otros usuarios, hacer las cosas que se indican
como no convenientes en los manuales, etc. Estos controles de seguridad han de ser ms
rigurosos si los sistemas esti conectados en redes por la posibilidad existente de difusin de virus
o de intento de adquisicin de palabras de acceso al sistema mediante programas que descifran
dichos cdigos (crackers).
La complejidad de las comprobaciones y el registro de los accesos aumenta en los
sistemas conectados a la red. En este caso, la seguridad del sistema se enfrenta a mltiples
puntos de ejecu cin y a canales de comunicacin expuestos. Debido a la complejidad de los
mecanismos de protec cin en sistemas distribuidos, en muchas redes de computadoras se limita
el acceso y slo se permi te el acceso a la red interna a travs de una mquina determinada,
denominada cortafuegos (firewall). Esta mquina separa dos dominios de seguridad: el fiable y el
exterior. El cortafuegos se sita entre ambos y filtra todo el trfico de la red, monitoriza y registra
las conexiones. Actualmen te, Internet se sita en el dominio de seguridad exterior, mientras que
las mquinas del dominio de seguridad fiable se aslan del exterior, estando conectadas mediante
una intranet (Fig. 9.11). Habi tualmente, slo se permite el establecimiento de comunicaciones
entre mquinas de la intranet y el mundo exterior a travs de los servicios del cortafuegos. En
algunos casos existe una zona interme dia de seguridad cuyas mquinas se pueden conectar con
las de la intranet. Por ejemplo, mquinas controladas de clientes que se conectan a los catlogos
de una compaa usando protocolos que pueden ser filtrados por el cortafuegos.
Controles de programacin
Existen distintos mtodos que se pueden aplicar durante el desarrollo de un sistema operativo para
intentar asegurar la calidad de la programacin, que lo programado se ajusta a lo diseado y la
fiabilidad del cdigo producido:
Un sistema operativo suele ser un proyecto de programacin muy grande. Los controles anteriores
son slo una pequea parte de los controles que es necesario aplicar en el desarrollo del sistema.
Adems, para que el sistema sea seguro es necesario describir claramente qu hacer, y cmo
hacer lo, en trminos de seguridad. Actualmente, existen varios estndares que describen cmo
conse guir un sistema fiable y de calidad. Los tres ms conocidos son el DoD-2167A, el SSE-CMM
y el ISO 9000.
El estndar DoD-2167A data de 1988 y permite definir requisitos uniformes aplicables a lo largo
del ciclo de vida del sistema. En cada fase del modelo se puede comprobar la calidad y seguridad
de lo desarrollado, solventando los problemas lo antes posible.
El Modelo de Madurez y Capacidad (CMM) fue publicado en el Software Engineering Institute
(SEI) en febrero de 1993. En 1995, la National Security Agency (NSA) public el Modelo de
Madurez y Capacidad para la Ingeniera de Seguridad de Sistemas (SSE-CMM). Este modelo
permite evaluar la calidad de los mtodos de seguridad usados en un sistema u organizacin.
El estndar ISO 9000 agrupa un conjunto de estndares de calidad que especifican las acciones
a tomar cuando un sistema tenga objetivos y restricciones de calidad. Uno de ellos, el 9000-1, se
aplica al desarrollo de software e identifica unos requisitos de calidad mnimos.
El sistema operativo debe llevar a cabo su parte de la poltica de seguridad del sistema liJones,
19781. Algunos de los controles de seguridad que se deben aplicar en el sistema operativo son:
9.5. CRIPTOGRAFA
En las secciones anteriores se ha mencionado varias veces la palabra criptografa en relacin con
la seguridad. Suponga que adems de ocultar informacin y controlar los accesos a la misma se
quiere hacer dicha informacin ininteligible en caso de que sea accedida. La criptografa es la
tcnica que permite codificar un objeto de manera que su significado no sea obvio. Es un medio
para mantener datos seguros en un entorno inseguro, en el cual un objeto original (O) se puede
convertir en un objeto cifrado (C) aplicando una funcin de cifrado (E). Obviamente, es necesario
que se pueda descifrar el mensaje cifrado, para volver a obtener el mensaje original aplicando una
funcin de descifrado (D), que puede ser o no la inversa de E. La Figura 9.12 muestra el proceso
de cifrado y descifrado de un mensaje.
Existen dos conceptos bsicos en criptografa: algoritmos de cifrado y claves. Ambos conceptos no
estn indisolublemente ligados, puesto que, habitualmente, un algoritmo de cifrado admite muchas
claves y una clave podra servir para muchas funciones de cifra. A continuacin, se estudian breve
mente ambos conceptos. Los lectores interesados en profundizar en el tema pueden leer los libros
de Denning [ 1992] y de Pfleeger [ 1997].
Algoritmos de cifrado
Las funciones de cifrado y descifrado permiten cifrar y descifrar un objeto mediante la aplicacin al
mismo de procedimientos, generalmente repetitivos, que permiten ocultar el contenido del objeto y
ponerlo en su forma original, respectivamente.
Los algoritmos de cifrado son muchos y variados. En general, todo diseador de un
sistema de criptografa busca algoritmos nuevos y mejores que los existentes. Sin embargo, la
mayor parte de los algoritmos convencionales de cifrado se pueden clasificar dentro de dos tipos:
sustitucin, es decir, cambiar el contenido del objeto original por otro, y transposicin, es decir,
modificar el orden del contenido del objeto original liDenning, 1982].
Los algoritmos que se basan en la sustitucin de partes del texto original por otros textos del
mismo o de otro alfabetos tienen como objetivo bsico aumentar la confusin. Se pueden dividir en
dos grandes tipos segn la complejidad del algoritmo:
Monoalfabticos. Cambian cada carcter por otro carcter o smbolo. Son muy sencillos y se
conocen desde antiguo. Los griegos y persas ya codificaban mensajes usando esta tcnica. Sin
embargo, el primer algoritmo con nombre es el denominado Julio Csar, porque se dice que fue el
primero en usarlo. Es muy sencillo, pero efectivo: cada letra del original se cambia por la que est
un cierto nmero de posiciones ms adelante. Csar usaba un despla zamiento de tres caracteres.
Ejemplo: abc -> cde.
Polialfabticos. Cambian grupos de caracteres por otros caracteres o smbolos depen diendo de
la frecuencia de su distribucin en el texto original [ 19661. Ejemplo:
abc -> 112233. El objetivo de estos algoritmos es evitar un defecto de los monoalfabtic que hace
aparente la distribucin del alfabeto del objeto original a partir del estudio d objeto codificado. El
cdigo Morse es un ejemplo muy sencillo de algoritmo polialfabti en el que cada carcter se
sustituye por una secuencia de puntos y lneas.
En 1993, el gobierno de los Estados Unidos de Amrica anunci el programa Clipper, que
incluye un conjunto de algoritmos de criptografa conocido como Skipjack. El algoritmo se mantie
ne en secreto, pero se sabe que se basa en un nuevo concepto de cifrado denominado escrutinio
de claves jiDenning, 19961. La clave se divide en varios componentes, cada uno de los cuales est
en poder de una agencia autorizada. Todos los componentes son necesarios para descifrar un
objeto, de manera que es necesario pedirlos a las respectivas agencias autorizadas. Este mtodo,
aunque muy seguro, fue muy mal recibido en su momento porque las agencias autorizadas eran
del gobierno y hubo muchas quejas respecto al control gubernamental de las comunicaciones
privadas.
Claves
Un concepto bsico en criptografa es el de clave. La clave (k) es el patrn que usan los algoritmos
de cifrado y descifrado para manipular los mensajes en uno u otro sentido. Aunque existen
sistemas criptogrficos que no usan clave (keyless cipher), el uso de claves aade ms seguridad
a los meca nismos de cifrado porque con distintas claves se pueden obtener distintos mensajes
cifrados usando la misma funcin de cifrado. De esta forma, para romper un sistema de cifrado es
necesario conocer tanto las funciones correspondientes como la clave usada para cifrar un
determinado objeto.
Obviamente, es necesario tener sistemas de criptografa en los que siempre se pueda
recuperar el objeto original a partir del objeto cifrado (o=D (k, E (k, O))). Sin embargo, dependiendo
de los pasos a aplicar para ejecutar el proceso de la Figura 9.12, los sistemas de criptografa se
pueden clasificar en dos tipos bsicos:
Simtricos. En este caso, D es la funcin inversa de E y las clave usada en ambos casos es la
misma. Tambin se denominan sistemas de clave privada. Puesto que ambos comparten la clave,
pueden trabajar de forma independiente. La simetra del proceso es muy til siempre que se
mantenga e1 secreto, ya que en ese caso se puede usar la clave como medio de autenticacin.
Sin embargo, estos mtodos tienen problemas asociados con la filtracin de las claves, su
distribucin, su debilidad criptogrfica y el nmero creciente de claves.
Asimtricos. En este caso existen claves distintas para cifrar y descifrar y la funcin de
descifrado no es exactamente inversa a la de cifrado (o=D (Kd, E (Ke, O))). La asimetra permite
reducir el nmero de claves a intercambiar entre los participantes en el proceso de cifrado.
Todos los sistemas que usan claves son sensibles a la prdida, filtracin o robo de claves [
19941. La nica solucin posible para este problema es que cuando un usuario sospeche que una
clave ha sido interceptada lo notifique a quien corresponda para que ste a su vez cambie la clave
y notifique que, a partir de un determinado instante, los mensajes codificados con la clave anterior
no son vlidos. Este mtodo es el mejor posible, aunque no es ptimo. Si un usuario tiene objetos
cifrados con una clave y le notifican que es invlida, deber recodificar los objetos con la nueva
clave y notificar a su vez la invalidez de la clave anterior.
El uso de claves tiene varias ventajas:
Sin embargo, el uso de claves tambin genera problemas importantes. En primer lugar, la
clave debe ser conocida por el codificador y el descodificador de un objeto. En segundo lugar, la
clave debe resistir los intentos de rotura, lo que significa que debe tener una cierta complejidad. En
tercer lugar, limita la comunicacin entre procesos a aquellos que conocen sus respectivas claves,
lo que obliga a establecer protocolos de intercambio de claves que permitan llevar a cabo comuni
caciones seguras, incluso aunque se ejecuten sobre canales inseguros [ 19811. Mediante estos
protocolos se puede conseguir que dos usuarios que sospechan entre s puedan comunicarse y
estar convencidos de la validez de sus contactos. Existen distintos tipos de protocolos [ 19941,
tales como los arbitrados, los adjudicados o los autocontrolados, pero la distribucin de claves es
uno de los problemas principales en todos ellos [ 19941. Segn cmo se distribu yan las claves, se
clasifican en sistemas con protocolos simtricos o asimtricos.
Los sistemas de clave privada se basan en la ocultacin de la clave de cifrado [ 19821. Se supone
que la clave es conocida nicamente por el usuario que cifra el objeto original. Estos siste mas,
que se han usado convencionalmente, ejecutan el cifrado (E) aplicando la clave (k) al objeto origen
(o) para obtener el objeto cifrado (c):
C = E (k, o)
El problema de estos sistemas es que para que alguien descifre el objeto cifrado debe
conocer la clave con que est cifrado. Hay dos soluciones para ese problema:
Propagar la clave.
Recodificar y aadir nuevas claves.
Imagine ahora que se desea que tres procesos (A, B y C) compartan objetos cifrados.
Distribuir a todos ellos la misma clave propagando la clave original no parece muy seguro. Es
mejor que cada par de procesos, por ejemplo A y B, compartan una clave kAB para cifrar sus
interacciones. Lo mismo debera hacerse para las interacciones (A, C) y (B, C). En general, para n
usuarios seran necesarias * (n 1) /2 claves, lo que hace que para un nmero grande de
usuarios sea muy difcil mantener claves confidenciales y con buenas caractersticas, debido
principalmente a dos proble mas bsicos:
Es necesario tener una base de datos de claves almacenadas en un sistema seguro, por la
imposibilidad de recordar todas ellas.
Estos sistemas violan el principio de diseo que recomienda mostrar al exterior lo ms posible
para evitar la curiosidad y los ataques de usuarios dispuestos a romper la seguridad
del sistema.
O = D (kpR, E O))
O = D E (KPR, ))
Es decir, se puede descifrar con la clave privada algo cifrado con la clave pblica y se
puede descifrar algo cifrado con la clave privada slo si se dispone de la clave pblica. Estas dos
propieda des implican que ambas claves se pueden aplicar en cualquier orden.
Con este mtodo slo se necesitan dos claves para cualquier nmero de usuarios: clave pblica y
privada. Cualquier proceso A puede enviar a B mensajes cifrados con la clave pblica de B. Slo el
proceso B podr descrifrar el mensaje, ya que es el nico que posee la clave privada, necesaria
para descifrar el mensaje cifrado con la clave pblica. Este mtodo asegura la confidencialidad,
puesto que aunque un intruso obtenga el mensaje cifrado, no podr descifrarlo. Adems, soluciona
los dos problemas principales de los sistemas de clave privada:
No es necesario intercambiar claves para poder comunicarse con un servidor de forma segura.
Muestran lo ms posible al exterior, evitando que los intrusos tengan curiosidad por conocer las
claves de los servidores.
Sistemas de clave privada, donde la posesin de la clave garantiza la autenticidad del mensa je y
su secreto.
Sistemas de sello, donde no es necesaria una clave. Se puede hacer que el usuario tenga un
sello que lo identifique, que puede ser una funcin matemtica o una tarjeta electrnica con
informacin grabada en la banda magntica.
Sistemas de clave pblica, donde la posesin de la clave de descifrado hace que slo el receptor
adecuado pueda descifrar un mensaje cifrado con su clave pblica.
Una firma digital debe ser autntica, no falsificable, no alterable y no reusable. Para
satisfacer estos requisitos, las firmas digitales pueden incluir sellos con fechas y nmeros de orden
o nmeros aleatorios. Los detalles relativos a firmas digitales se pueden estudiar en [ 1997].
La clasificacin de los sistemas de computacin segn sus requisitos de seguridad ha sido un tema
ampliamente discutido desde los aos setenta. La disparidad de criterios existentes se ha ampliado
ms con la conexin de las computadoras para formar redes de computacin que pueden
compartir recursos. Algunas de las clasificaciones existentes en la actualidad son la clasificacin
del Departa mento de Defensa (DoD) de los Estados Unidos de Amrica, el criterio alemn, el
criterio canadien se, el ITSEC o el criterio comn.
La ltima clasificacin ha sido definida conjuntamente en Estados Unidos y Canad, siendo
publicada su primera versin en 1994 [ 19941. Es un sistema complejo que todava est en fase de
elaboracin y discusin, por lo que hay muy pocos sistemas comerciales que se ajusten a esta
norma. Sin embargo, es importante resaltar que tiene grandes posibilidades de convertirse en un
estndar.
Una de las clasificaciones ms populares es la del Orange Book del Departamento de Defensa
(DoD) de Estados Unidos [ 19851. Esta clasificacin especifica cuatro niveles de seguridad:
A, B, C y D (Fig. 9.13). A continuacin, se describen estos niveles de seguridad y las
caractersticas de cada uno.
No pasan las pruebas de seguridad mnima exigida en el DoD. MS-DOS y Windows 3.1 son siste
mas de nivel D. Puesto que estn pensados para un sistema monoproceso y monousuario, no pro
porcionan ningn tipo de control de acceso ni de separacin de recursos.
La aplicacin de los mecanismos de proteccin depende del usuario, o usuarios, que tienen privile
gios sobre los mismos. Esto significa que un objeto puede estar disponible para lectura, escritura o
cualquier otra operacin, segn el libre albedro de su dueo. Casi todos los sistemas operativos
comerciales de propsito general, como UNIX, LINUX o Windows NT, se clasifican en este nivel.
Este nivel se divide a su vez en dos subniveles, dependiendo de la precisin del control de acceso:
Clase C1. Control de acceso por dominios. No hay posibilidad de establecer qu elemento de
un determinado dominio ha accedido a un objeto. UNIX pertenece a esta clase. Divide a los
usuarios en tres dominios: dueo, grupo y mundo. Se aplican controles de acceso segn los
dominios, siendo todos los elementos de un determinado dominio iguales ante el sistema de
seguridad.
Clase C2. Control de acceso individualizado. Granularidad mucho ms fina en el control de
acceso a un objeto. El sistema de seguridad del ser capaz de controlar y registrar los
accesos a cada objeto a nivel de usuario. Windows NT pertenece a esta clase.
En este nivel, los controles de acceso no son discrecionales de los usuarios o dueos de los
recursos, sino que deben existir obligatoriamente. Esto significa que todo objeto controlado debe
tener pro teccin, sea del tipo que sea. En caso de que el dueo no defina cul, el sistema de
seguridad asigna una por defecto. Este nivel se divide a su vez en tres subniveles:
Clase Bi. Etiquetas de seguridad obligatorias. Cada objeto controlado debe tener su eti queta
de seguridad. Pueden existir objetos no controlados. Este modelo de seguridad se
ajusta al de Bell-La Padula.
Clase B2. Proteccin estructurada. Todos los objetos deben estar controlados mediante un
sistema de seguridad con diseo formal y mecanismos de verificacin. Estos mecanismos permiten
probar que el sistema de seguridad se ajusta a los requisitos exigidos. Controles obligatorios, y
asignados segn el principio del menor privilegio posible, para objetos, suje tos y dispositivos.
Clase B3. Dominios de seguridad. B2 ampliado con pruebas exhaustivas para evitar cana les
encubiertos, trampas y penetraciones. Diseo probado y verificado, que usa niveles, abstracciones
de datos y ocultamiento de informacin. El sistema debe ser capaz de detectar intentos de
violaciones de seguridad, para ello debe permitir la creacin de listas de control de acceso para
usuarios o grupos que no tienen acceso a un objeto.
Para acceder a este nivel, la poltica de seguridad y los mecanismos de proteccin del sistema
deben ser verificados y certificados por un organismo autorizado para ello. Organismos de
verificacin muy conocidos son el National Computer Security Center o el TEMPEST
Clase Ai. Diseo verificado. Clase B 1 ms modelo formal del sistema de seguridad. La
especificacin formal del sistema debe ser probada y aprobada por un organismo certifica dor.
Para ello debe existir una demostracin de que la especificacin se corresponde con el modelo,
una implementacin consistente con el mismo y un anlisis formal de distintos problemas de
seguridad. El Vax Security Kernel pertenece a esta clase.
Clase Ax. Desarrollo controlado. Al ms diseo con instalaciones y personal controlados. Formas
de control no definidas. Se podran incluir requisitos de integridad de programas,
alta disponibilidad y comunicaciones seguras.
Un sistema operativo puede dar soporte de ejecucin a mltiples procesos de mltiples usuarios
que se ejecutan de forma concunente. Por ello, una de las funciones principales del sistema
operativo es proteger los recursos de cada usuario para que pueda ejecutar en un entorno seguro.
Para poder satisfacer esta funcin, todos los sistemas operativos deben tener mecanismos de
proteccin que permitan implementar distintas polticas de seguridad para los accesos al sistema I
1968] y [ .19741. Dichos mecanismos permiten controlar el acceso a los objetos del sistema permi
tindolo o denegndolo sobre la base de informacin tal como la identificacin del usuario, el tipo
de recurso, la pertenencia del usuario a un cierto grupo de personas, las operaciones que puede
hacer el usuario o el grupo con cada recurso, etc. La existencia de los mecanismos de seguridad
obliga a mantener un compromiso constante entre separacin y comparticin. Este compromiso es
ms difcil de satisfacer a medida que la granularidad de control es ms fina. En este caso es ms
difcil aislar recursos pero es ms fcil compartirlos. Es pues necesario lograr un equilibrio entre el
tipo y la intensidad de la separacin y el grado de comparticin de recursos [ 19851.
En esta seccin se estudian los distintos mecanismos de proteccin que ofrecen los sistemas
operativos de propsito general para implementar la poltica de seguridad deseada por los
usuarios. Para mostrar su uso, se aplican a archivos o directorios, aunque se pueden aplicar a
cualquier tipo de objeto. Los mecanismos de proteccin hardware, como registros valla o
arquitecturas etiquetadas [ 1992], se estudiaron en el Captulo 1, por lo que no se contemplan aqu.
Pedir informacin que slo conoce l a travs de contraseas, juegos de preguntas o algorit mos
de identificacin.
Determinar caractersticas fsicas del usuario tales como la pupila, la huella dactilar, el
DNA, la firma, etc. Es ms costoso que el mtodo anterior pero ms fiable. Actualmente 1
empiezan a ser frecuentes los sistemas de deteccin de la huella digital, la pupila o el tono de
voz de una persona.
Pedir un objeto que posee el usuario, como puede ser una firma electrnica, una tarjeta con
banda magntica o con un chip.
accede al sistema desde un terminal y dicho terminal sobrepasa un tiempo de inactividad, se expul
sa al usuario del sistema despus de uno o varios avisos de desconexin. Los sistemas ms
moder nos, especialmente los que permiten conexiones a travs de redes, intercambian claves de
forma dinmica cada cierto tiempo. Este mtodo es equivalente a pedirle al usuario que
reintroduzca su contrasea, tarjeta o caracterstica fsica cada cierto tiempo. Adems, como criterio
general de seguridad, los sistemas operativos modernos dan la posibilidad de registrar todos los
accesos al sistema, lo que permite hacer controles interactivos y a posteriori de dichos accesos.
Windows NT tiene un subsistema de seguridad encargado de autenticar a los usuarios. Cuando se
crea un nuevo usuario en el sistema, se almacena en una base de datos de seguridad una ficha
del usuario que incluye su identificador de seguridad, los grupos a los que pertenece, sus
privilegios, grupo primario y enlace con su lista de control de acceso. Cuando el usuario quiere
acceder al sistema introduce su contrasea a travs de un proceso logon. Dicha contrasea se
pasa al subsiste ma de seguridad, que verifica la identidad del usuario y, en caso positivo,
construye una ficha de acceso para el usuario. Este objeto sirve como identificador oficial del
proceso siempre que el usuario intente acceder a un recurso a partir de ese instante. La Figura
9.14 resume los atributos y servicios de este tipo de objeto, as como un ejemplo de ficha de
acceso en Windows NT.
El proceso de autenticacin
Habitualmente, cuando un usuario quiere acceder al sistema, aparece una pantalla o mensaje de
entrada. En el caso de Windows NT, la pantalla pide tres valores:
Identificacin del usuario: nombre del usuario en el sistema.
Palabra clave o contrasea: espacio para teclear la clave (el eco muestra *).
Dominio de proteccin al que pertenece el usuario.
Existen varios fallos posibles en el proceso de entrada al sistema, por lo que este proceso
debe ser robusto y no dar informacin a los intrusos. Con el paso del tiempo se ha ido dotando de
mayor robustez e integridad al proceso de autenticacin gracias, en parte, a la experiencia de
errores previos. En las primeras versiones de UNIX, por ejemplo, el proceso login se poda matar
desde el teclado. Al matarlo, el usuario se quedaba dentro del sistema con privilegios de
administrador del
Login: pepe
Error: el usuario no existe
Login:
Con este mtodo era sencillo averiguar qu usuarios haba o no en un sistema. Otro fallo
habitual era comprobar la contrasea carcter a carcter, notificando un error en cuanto fallaba el
primer carcter. Con este mtodo era muy sencillo comprobar las claves carcter a carcter hasta
dar con la clave correcta.
Actualmente, los sistemas piden todos los datos de autenticacin, verifican el proceso y
notifican el xito o error de todo el proceso.
Login: pepe
Password: * * * * * * * * * * * * *
Acceso invlido. Intntelo de nuevo.
conocido nicamente por el usuario y por el sistema operativo sobre el que se ha llegado a un
acuerdo para que sea usado como clave de acceso al sistema. Normalmente, cuando se habilita
un nuevo usuario en el sistema, ste introduce su contrasea, que puede cambiar posteriormente
tantas veces como quiera. Dicha contrasea se guarda cifrada en unos archivos especiales.
Cuando intenta acceder a su cuenta, el proceso que controla los accesos (login) pide al
usuario que teclee su contrasea. Inmediatamente, dicha contrasefia es cifrada [ 19821 y
comparada con la existente en el archivo de contraseas para ese usuario. Si las dos contraseas,
ambas cifradas, coinciden, se permite acceder al usuario. En otro caso se deniega el acceso.
Huelga decir que no deben existir copias sin cifrar de las contraseas y que mientras el usuario
teclea su contrasea hay que inhibir el eco en la pantalla para que otras personas no puedan ver
dicha palabra clave.
Este sistema es sencillo de implementar y de usar, funcionando de forma similar en todos
los sistemas operativos. Sin embargo, asumiendo que la autenticacin se basa en tupias usuario,
clave, es necesario tomar cuatro decisiones de diseo bsicas para un sistema como ste:
Asignacin de claves
Normalmente, la palabra clave es fijada por el usuario cuando entra en su cuenta y la puede
cambiar tantas veces como quiera. Sin embargo, hay situaciones en que el sistema operativo elige
la clave, o parte de la clave, de un usuario:
La asignacin discrecional de claves por parte del usuario tiene problemas asociados. Es
habi tual que los usuarios tengan contraseas fciles de adivinar, como su nombre, fecha de
nacimiento, direccin, nombre de familiares, claves que se puedan buscar fcilmente con un
diccionario o no tiene clave. Estos usuarios son presa fcil de cualquier programa rompedor de
claves, que tardar muy poco en encontrar su clave.
La longitud y el formato de las claves han ido cambiando a travs del tiempo, principalmente
debido a la deteccin de fallos asociados a las claves usadas en cada momento. La Figura 9.15
muestra una distribucin de palabras clave obtenida en un estudio realizado por Monis y
Thompson en 1979 [ 19791. Como se puede ver, la mayora de las palabras clave eran muy cortas
o fciles de adivinar. Estudios posteriores, como los de Luby [ 19891 y Spafford [ 1992], mostraron
un panorama similar. Actualmente, un buen servidor de claves trata de descartar los fallos ms
probables complicando el formato o los datos de las claves.
Observe que, tericamente, un sistema que use palabras clave con un mnimo de 6
caracteres, siendo stos los 26 alfabticos, diez numricos y diez caracteres especiales, tiene un
nmero de 466 palabras clave posibles. Si la longitud de la clave puede variar entre 6 y 10
caracteres, el nmero posible sera 466 + 46 + 468 + 46 + 46. Costara cientos de aos romper
una clave de este estilo, siempre que el usuario fuera cuidadoso y no cometiera fallos como los
mencionados anteriormente. Para aumentar la complejidad de la clave se puede hacer que el
mandato que permite cambiar la contrasea (passwd en UNIX) obligue al usuario a meter
caracteres no alfanumricos y que fuerce la existencia de contraseas de una longitud mnima
aadiendo nmeros aleatorios a la palabra clave antes de cifrarla.
Almacenamiento de claves
Es muy importante dnde se almacenan las claves para la seguridad del sistema. En el sistema
operativo UNIX, por ejemplo, las claves se almacenaban tradicionalmente en un archivo de texto
denominado / etc /passwd. En cada entrada del archivo se encontraba la identidad de un usuario y
su palabra clave cifrada, entre otras cosas, con el siguiente formato:
mguel:xsfg7.5t:Miguel Alumno: /home/users/miguel:/bin/csh
Este archivo era accesible para lectura por todo el mundo, lo que permita que cualquier usuario
pudiera ejecutar programas que lean este archivo y comparaban las palabras clave con
contraseas de uso probable o, simplemente, con listados exhaustivos de contraseas. Para paliar
este problema, actualmente las contraseas cifradas se guardan en archivos especiales que nica
mente son accesibles para el administrador. Son los denominados archivos sombra (/etc/sha dow).
El sistema operativo tiene operaciones internas para acceder a estos archivos y manipular las
contraseas. En el caso de Windows NT, se guardan en archivos que slo estn accesibles para el
administrador del sistema y que se manipulan a travs de la utilidad de administracin para gestin
de usuarios.
Se puede incrementar la seguridad del sistema cifrando todos los directorios y archivos de
palabras claves. De esta forma, aunque alguien pudiera acceder a ellos, no podra usar la informa
cin. La forma ms habitual de cifrar la palabra clave es usar funciones de sentido nico. Con este
enfoque se cifra la palabra clave, se guarda en el archivo de claves y no se descifra jams. Cuando
un usuario desea entrar al sistema se pide su clave, se cifra y se compara con la almacenada en el
archivo.
Para dificultar la deteccin de contraseas vlidas por parte de posibles intrusos se puede
configurar el sistema operativo: los sistemas operativos permiten que las contraseas de usuarios
sean vlidas nicamente durante un cierto tiempo. Evidentemente, cuanto ms corta sea la
duracin de la pala bra clave, ms difcil ser romper la seguridad del sistema. Actualmente,
muchos sistemas operati vos obligan a cambiar las claves peridicamente, por ejemplo cada 3
das, si as lo decide el admi nistrador de seguridad. Este mtodo per se no tiene por qu mejorar
la seguridad del sistema. Suponga que un usuario tiene tres claves y siempre las usa de forma
cclica. Si las tres claves son sencillas, la seguridad del sistema no ha mejorado mucho.
Para evitar la situacin anterior, empieza a ser frecuente el uso de contraseas vlidas
para un nico acceso (claves de una sola vez). Hay tres formas bsicas de implementar esta
polftica:
1. Obligar al usuario a cambiar su contrasea cada vez que entra en el sistema. Esta solucin no
limita posibles accesos futuros de intrusos, ya que stos pueden cambiar la palabra
clave a su antojo, pero permite que el usuario afectado por la violacin de seguridad lo detecte tan
pronto como quiera entrar a su cuenta y avise al administrador del sistema.
2. Asignar una funcin matemtica a cada usuario, de forma que cuando el usuario entre al
sistema se le proporcione un argumento para la funcin y se le pida que introduzca el
resultado de la funcin para dicho argumento. Las funciones matemticas a usar pueden ser muy
variadas, pero en sistemas conectados a la red suelen ser de una gran complejidad.
Es muy frecuente usar polinomios.
3. Usar libros de contraseas ordenadas segn un cierto orden numrico. Cada vez c el usuario
quiere acceder al sistema se le pide que introduzca la contrasea con un cierto
nmero de identificacin. El libro de claves es generado por el usuario y debe estar en su
posesin, sin que existan copias del mismo que no estn cifradas. Obviamente, este mto do no es
til si el intruso tiene acceso al libro de claves del usuario en versin no cifrada.
Este es el mtodo usado por el sistema Securekey.
Para poder implementar mecanismos de proteccin sobre los objetos del sistema, que pueden ser
hardware (UCP, memoria, etc.) o software (procesos, archivos, semforos, etc.), es necesario en
primer lugar disponer de identificadores nicos de usuarios y de objetos. Asumiendo que dichos
Los posibles conjuntos de objetos a los que se aplican los mecanismos de proteccin.
La relacin de operaciones que cada usuario puede hacer sobre cada conjunto de objetos.
La forma en que se define dicha relacin: por objetos, por usuarios, etc.
owner. Dueo del objeto. Suele ser su creador. El alumno Miguel, por ejemplo. Cada usua rio
tiene un identificador (u d) nico en todo el sistema. Este identificador est asociado a todos los
objetos creados por el usuario, para indicar que es su dueo.
group. Usuarios distintos del dueo que forman parte de su grupo. Los componentes del grupo
suelen estar relacionados de alguna forma, por lo que se les permite gestionar los
derechos de sus objetos con criterios comunes al grupo. Un grupo de usuarios podran ser los
alumnos de la asignatura Sistemas Operativos. Si Miguel cursa Sistemas Operativos perte nece a
este grupo. Cada grupo tiene un identificador (gid) nico en todo el sistema. Un grupo se define
especificando los uid de los usuarios que forman parte del mismo. El gid est asociado a todos los
objetos creados por cualquier usuario que pertenezca a dicho grupo.
others. El resto de los usuarios conocidos que no son el creador ni su grupo (tambin llamados
mundo). Suelen tener ms restricciones en los derechos. En una computadora
dedicada a alumnos, para Miguel el resto del mundo seran los usuarios no matriculados en
Sistemas Operativos.
Para cada dominio se permiten nicamente tres tipos de operaciones sobre un objeto:
Leer (r).
Escribir (w).
Ejecutar (x).
Adems, cada objeto tiene asociados dos bits extra para conceder permisos especiales del
dueo y del grupo al que pertenece el dueo. El primero de ellos se denomina bit setuid y el
segundo bit setgid. Estos bits permiten realizar cambios de dominio cuando se ejecutan objetos
que tienen alguno de ellos activado. Cuando un usuario A ejecuta un programa del usuario B,
almacena do en un archivo cuyos bits de setuid y setgid estn inactivos, su identificacin sigue
siendo la de A y se es el setuid del proceso. Sin embargo, si el archivo tiene el bit setuid activado,
la identidad del proceso ser la de B, aun cuando sea el usuario A el que est ejecutando el
proceso. Asimismo, si tiene activado el setgid, la identidad del grupo del proceso ser la del grupo
de B. Estos bits se pueden modificar usando la llamada al sistema chxnod. Las llamadas al sistema
setuid y setgid, que se explican en detalle en la seccin de llamadas al sistema de POSIX,
permiten cambiar de dominio a vn usuario y son utilizadas por los sistemas operativos de tipo UNIX
para permitir ceder permisos de acceso a archivos del sistema o a recursos que nunca estaran
disponibles a usuarios no privilegiados, pero que pueden ejecutar temporalmente para el desarrollo
de sus actividades en el sistema. La mayora de los intrpretes de mandatos y programas del
sistema funcionan sobre la base de este mecanismo. En UNIX, por ejemplo, el mandato mkdir
permite crear un directorio. En versiones antiguas de UNIX mkdi r no era una llamada al sistema,
por lo que era necesario ejecutar la llamada al sistema mknod, que slo poda ejecutar el
superusuario. Lo que se haca era permitir que el mandato mkdir se ejecutara con el bit setuid del
superusuario activado, por lo que cualquie ra que lo ejecutara lo haca como si fuera el
superusuario y pudiera acceder a mknod.
Existen otras formas de cambiar de dominio de proteccin en los distintos sistemas
operativos existentes. Alternativas a los bits de proteccin de UNIX son:
Colocar los programas privilegiados en un directorio especial. En este caso, el sistema ope rativo
es responsable de cambiar el setuid del proceso que ejecuta en ese directorio.
Usar programas especiales, denominados demonios, para dar servicios en dispositivos con
acceso restringido. Un ejemplo claro es el de la impresora. Ningn proceso de usuario puede
acceder a ella directamente, sino a travs del spooler, un demonio que recibe las peticiones de
impresin y las enva al dispositivo.
No permitir nunca el cambio de identidad de un proceso y ejecutar todas las operaciones
privilegiadas a travs de servicios del sistema operativo.
En cualquier caso, es necesario ser muy cuidadoso con los programas que se ejecutan de
forma privilegiada. Si un proceso del superusuario no tiene bien definidos y controlados todos los
fallos de proteccin, se puede generar una total falta de proteccin en el sistema. Algunos de los
fallos de protec cin ms famosos, como la invasin por virus o la captura de contraseas, han sido
posibles gracias a esta cesin de identidad.
Para evitar la total desproteccin del sistema, en UNIX cada proceso que se ejecuta tiene
cuatro identificadores asociados:
Para ejecutar los procesos que tienen fuertes restricciones de seguridad se exige siempre
que la identidad efectiva y la real coincidan. Un ejemplo de este tipo es el mandato mount, que
permite montar un sistema de archivos en una jerarqua de archivos ya existente.
La relacin entre dominios y objetos se puede definir de forma completa mediante una matriz de
proteccin, tambin denominada de acceso. Los dominios de proteccin son las filas de la matriz y
los objetos son las columnas de la misma. El elemento (i, i) expresa las operaciones que el dominio
puede ejecutar sobre el objeto j. Si la matriz de proteccin est completamente definida, los
mecanismos de proteccin pueden saber siempre qu hacer cuando un proceso de un dominio
solicita determinada operacin sobre un objeto.
La Figura 9.17 muestra un ejemplo de matriz de proteccin. Cada elemento muestra una
com binacin (dom_i, obj _j) y sus derechos de acceso. Los elementos vacos significan que no
hay derechos. Los dominios son un objeto ms del sistema, por lo que se incluyen tambin los
cambios de dominio permitidos. Por ejemplo, en la Figura 9.17 se muestra que se puede cambiar
de Domj a Dom_2, pero no al revs.
El modelo de matriz de proteccin, derivado del modelo terico HRU, es muy claro desde
el punto de vista conceptual, pero tiene inconvenientes para su implementacin:
Almacenar la matriz por columnas, con una lista por objeto que especifica qu operaciones puede
hacer cada dominio sobre ese objeto. La lista resultante se denomina lista de control de accesos
(ACL, Access Control List).
Almacenar la matriz por filas, con una lista por dominio que especifica qu operaciones se
pueden hacer sobre un objeto cuando se pertenece a ese dominio. La lista resultante se deno mina
lista de capacidades (capabilities).
Una forma frecuente de controlar los accesos a un objeto es usar el identificador del usuario como
criterio. Con listas de control de acceso es necesario especificar para cada dominio de proteccin,
e incluso para cada usuario, qu tipos de accesos al objeto son posibles. Para implementar esta
solu cin, a cada objeto (archivos, directorios, procesos, etc.) se le asocia una lista de pares:
(dominio, operaciones)
Usando ACL es posible especificar completamente los derechos de acceso que sobre un
objeto tiene un usuario o un grupo. Por ejemplo, el archivo Gua puede ser ledo y escrito por el
alumno miguel, que es el encargado de su mantenimiento, pero slo puede ser ledo por la alumna
elvira o la visitante mara. El archivo notas puede ser ledo por todos (*) los alumnos. Si aparece un
nuevo grupo de usuarios, por ejemplo asociado a una prctica de una asignatura, sera necesario
definir los derechos de ese grupo sobre las herramientas necesarias para dicha prctica. Por tanto,
para que este sistema funcione correctamente, es necesario que la administracin de los dominios
y de la pertenencia a los mismos sea muy rigurosa.
Sea cual sea su implementacin, las listas de control de acceso se corresponden
directamente con las necesidades de los usuarios. Cuando un usuario crea un objeto puede
especificar qu domi nios tendrn acceso al mismo y qu operaciones pueden realizar sobre el
objeto. Sin embargo, localizar la informacin relacionada con un dominio en particular puede ser
costoso si no se limita el nmero de dominios, como en UNIX. Adems, la lista de control de
accesos debe ser recorrida cada vez que se accede a un objeto, lo que puede requerir bastante
tiempo. Esto hace que la mayora de los sistemas basados en ACL slo comprueben los derechos
de acceso cuando se accede al objeto por primera vez, es decir, se abre el objeto. En caso de que
se conceda acceso al objeto, no se hacen ms comprobaciones posteriores a medida que se usa
el objeto. Esta circunstancia hace muy difcil la revocacin de derechos para los procesos que ya
tienen objetos abiertos, incluso aunque se cambie su ACL. Por tanto, las listas de control de
acceso tienen dos problemas asociados:
Estos permisos indican que los archivos datos y notas pueden ser ledos y escritos por el
dueo y slo ledos por la gente de su grupo y por otros. El archivo corrector puede ser ledo,
escrito y ejecutado por su dueo, pero el resto del mundo slo puede ejecutarlo.
En las operaciones de interfaz con el sistema operativo, estos permisos se indican con
nmeros en octal. Se usa un dgito para cada dominio y el valor de los bits de cada dgito se pone
a 1 si la
operacin es posible o a O si no lo es. Los permisos del ejemplo anterior se expresan de forma
equivalente como:
Este modelo conlleva el que haya que hacer ciertas simplificaciones en cuanto a las
operacio nes no contempladas. Por ejemplo, borrar es posible si se puede escribir en el directorio
que contie ne el objeto que se pretende eliminar, atravesar un directorio es posible si se tiene
activado el bit x, etctera.
Para permitir el cambio de dominio se pueden modificar los bits setuid y setgid asociados a
cada objeto. En el caso de que alguno de estos bits est activado, se muestran dos bits ms
asociados al objeto. En el ejemplo anterior, suponga que el archivo corrector tiene activado el
setuid. Su salida en un mandato is -la sera:
corrector Otros
Dueo Grupo x
rws x
corrector rws 5
Dueo Grupo Otros
Windows NT proporciona un sistema de seguridad algo ms sofisticado que el de UNIX. Todos los
objetos de Windows NT tienen asignados descriptores de seguridad como parte de sus fichas de
acceso. La parte ms significativa de los descriptores de seguridad es la lista de control de
accesos. Cada entrada de la ACL contiene los descriptores de seguridad de los distintos dominios
del sistema y los derechos de uso del objeto. Normalmente, slo el dueo del objeto puede
modificar los derechos de la ACL para permitir o denegar el acceso al objeto.
El criterio de asignacin de derechos en la ACL de un objeto nuevo en Windows NT es el
siguiente:
9.7.6. Capacidades
La posesin por parte de un miembro del grupo de profesores, como es juan, de una
capacidad del objeto datos le permite efectuar operaciones de lectura y escritura sobre el mismo.
Un problema asociado a las capacidades, desde el punto de vista de la implementacin, es
que estn en posesin de los usuarios y no asociadas al objeto en s, por lo que hay que
distribuirlas cuando se solicite la concesin de una capacidad por parte de un usuario. Para evitar
problemas de
seguridad, las listas de capacidades no suelen estar nunca accesibles directamente, sino que se
acceden desde mtodos controlados por el sistema operativo o el sistema de seguridad. La
mayora de los sistemas que usan capacidades se basan en el hecho de que las listas de
capacidades estn siempre dentro del espacio de memoria del sistema operativo, sin que exista
posibilidad de migrar a espacio de memoria de los procesos de usuario. Adems, las capacidades
slo pueden ser accedidas a travs de mtodos que proporciona el sistema operativo, tales como:
Crear capacidad
Destruir capacidad
Copiar capacidad
Es habitual que una capacidad no pueda ser modificada. En casi todos los sistemas es
necesa rio destruirla y crear una nueva, siguiendo un esquema de uso de una nica vez.
A nivel interno se han propuesto tres mtodos para proteger las listas de capacidades:
Arquitectura etiquetada, en la cual cada palabra de memoria tenga un bit de etiqueta adicional
diciendo si contiene o no una capacidad. En caso positivo, esa posicin de memo ria slo puede
ser modificada por procesos que ejecuten dentro del ncleo del sistema opera tivo. Esta solucin
es cara y poco adecuada para sistemas de propsito general.
Capacidades cifradas. La clave de cifrado es desconocida por los usuarios, que deben limitarse
a manipular las capacidades cifradas recibidas del sistema operativo. Este sistema
se ajusta bien a las necesidades de los sistemas operativos distribuidos.
Listas de control de acceso asociadas a cada capacidad.
El sistema operativo Amoeba [ 19861 usa capacidades para proteger puertos de mensajes
y otros objetos. La capacidad est formada por cuatro elementos (Fig. 9.19), de los cuales dos, los
derechos de acceso y el nmero aleatorio, se usan para proteccin. Los derechos de acceso
definen un bit por cada operacin permitida sobre el objeto, el nmero aleatorio permite distinguir
entre distintas versiones de la misma capacidad. Todas las capacidades se cifran antes de ser
distri buidas a los usuarios.
Las capacidades no se corresponden directamente con las necesidades de los usuarios y
son menos intuitivas que las ACL. Debido a ello, la mayora de los sistemas operativos
proporcionan ACL como mecanismo de proteccin. Sin embargo, las capacidades tienen varias
ventajas:
Son muy tiles para incluir informacin de proteccin para un proceso en particular [
19841.
El mecanismo de comprobacin de derecho es muy sencillo.
Se adaptan muy bien a sistemas distribuidos.
Su gran desventaja sigue siendo que la revocacin de accesos a un objeto puede ser
ineficiente si se desea hacerla con criterios de selectividad entre dominios o para revocar derechos
parciales.
El principal problema de las capacidades es que, en un sistema dinmico, pueden existir cientos de
capacidades concedidas para acceder a un objeto, lo que hace muy difcil su control al no existir
una estructura centralizada en el mismo objeto como la ACL. Por ello, revocar los derechos de
acceso para un objeto en particular es muy difcil, ya que el sistema debe buscar todas las
capacidades existentes sobre el mismo para aplicar la revocacin de derechos. El problema se
complica si adems se quiere tener revocacin parcial de derechos.
En sistemas operativos centralizados se han propuesto mtodos de control de capacidades
tales como seguir la pista a la situacin de las mismas, forzar su paso siempre a travs del ncleo
y mantener las capacidades en una base de datos centralizada, y restringida, limitar la propagacin
de capacidades, obligar a la readquisicin peridica de la capacidad o usar claves de versin para
cada capacidad [ 1991].
Si se implementan las capacidades como una lista de control de acceso, se puede
mantener una lista desde cada objeto a todas sus capacidades. Si hay modificaciones, se recorre
dicha lista y se aplican. Este mtodo, usado en MULTICS, es muy flexible, pero costoso de
implementar. Una variante es borrar las capacidades para un objeto peridicamente. Si un proceso
quiere utilizarlo, debe adquirir una nueva capacidad. Si se le ha denegado el acceso, no ser
capaz de conseguirla.
Con el mecanismo de claves de versin, cada objeto tiene una clave maestra,
generalmente definida como un nmero aleatorio con muchos bits, que se copia en cada nueva
capacidad subte ese objeto. Los usuarios no pueden modificar dicha clave, que deben presentar
junto a la capacidad cuando van a acceder al objeto. En ese momento, el sistema operativo
compara la clave de la capacidad y la maestra. Si no coinciden, se deniega el acceso. Para revocar
el acceso, lo nico que hay que hacer es cambiar la clave maestra existente en el objeto.
Normalmente, slo el dueo de un objeto, o el sistema operativo, puede cambiar la clave maestra
del mismo. Este mtodo, usado en el sistema operativo Amoeba, tampoco permite revocaciones
selectivas.
Cuando las capacidades se pueden ceder de unos usuarios a otros, para ceder permisos
de acceso a un objeto, es necesario mantener un grafo o rbol que muestre el patrn de
propagacin de una capacidad y que permita viajar por el rbol para revocar la capacidad en todos
los dominios de proteccin. Este mecanismo se puede implementar mediante indirecciones, de
forma que las capa cidades no apunten directamente a los objetos, sino a una tabla global
intermedia desde la cual se apunta al objeto. Para revocar las capacidades sobre un objeto slo
hay que eliminar el apuntador entre la tabla de objetos y el objeto en s. No permite revocaciones
selectivas.
En general, todos los sistemas operativos crean la informacin de proteccin cuando se crea un
objeto, por lo que no es muy frecuente encontrar servicios de creacin y destruccin de ACL o
capacidades disponibles para los usuarios. Es mucho ms frecuente que los servicios de
proteccin incluyan llamadas al sistema para cambiar caractersticas de la informacin de
proteccin o para consultar dichas caractersticas. Sin embargo, para presentar una descripcin
ms completa de ser vicios genricos, se incluyen tambin los de creacin y destruccin en la
siguiente descripcin:
El estndar POSIX define servicios que, en general, se ajustan a los servicios genricos descritos
en la seccin anterior. Sin embargo, no existen servicios especficos para crear, destruir o abrir des
criptores de proteccin. Estos se asocian a los objetos y se crean y se destruyen con dichos
objetos.
access comprueba si un archivo est accesible con unos ciertos privilegios. Tienen en cuenta el uid
y el gid real, no los efectivos. No es necesario tener el archivo abierto.
mt access (const char *path, mt amode)
chinoc3. cambia los derechos de acceso a un archivo. Slo el dueo del archivo o el superusuario
pueden ejecutar esta llamada. No es necesario tener el archivo abierto. Si algn proceso tiene el
archivo abierto, esta llamada no afectar a sus privilegios de acceso hasta que lo cierre.
El nombre del archivo se especifica en path. mode es el valor, en notacin octal, de los permisos
de acceso a instalar. Por ejemplo, los bits rwxrx-r-- se indican en octal con los nmeros 764.
Permite cambiar los bits setuid y setgid. En caso de xito devuelve un cero. En caso de error un
1.
chown cambia el propietario y el grupo de un archivo. Slo el dueo del archivo o el superusuario
pueden cambiar estos atributos. No es necesario tener el archivo abierto. Si algn proceso tiene el
archivo abierto, esta llamada no afectar a sus privilegios de acceso hasta que lo cierre.
El nombre del archivo se especifica en path. owner y group son los identificadores numri
cos del nuevo dueo y del nuevo grupo. En caso de xito devuelve un cero. En caso de error
devuelve l y no cambia nada.
Las llamadas getuid, geteuid, getgid y getegid permiten obtener los identificadores reales y
efectivos del propietario de un archivo y de su grupo. Estas llamadas son slo de consulta y no
modifican nada.
Las llamadas setuid y setgid permiten cambiar los identificadores reales del usuario y de su grupo.
A partir de ese momento, estas identidades pasan a ser la identidades efectivas de los mis mos.
Sus identidades reales slo se cambian si el usuario tiene los privilegios adecuados. En otro caso,
slo se cambia la efectiva y se mantiene la identidad real.
En caso de xito devuelven cero. En caso de error, por privilegios insuficientes o por no
existir la identidad solicitada, devuelven 1.
La llamada umask permite a un usuario definir una mscara de proteccin que ser aplicada por
defecto a todos sus objetos creados a partir de ese instante.
El parmetro cmask define el modo de proteccin por defecto. Cuando se crea un objeto y
se define su modo de proteccin, por ejemplo model, el valor efectivo de proteccin resultante para
el objeto es el resultado del OR binario exclusivo entre cmask y model. Por ejemplo:
Para ilustrar el uso de los servicios de proteccin que propQrciona POSIX, se presenta en esta
seccin dos pequeos programas, con su cdigo fuente en lenguaje C. El primero (Programa 9.1)
ejecuta la siguiente secuencia de acciones:
1. Comprueba que el archivo origen se puede leer y que la identificacin efectiva y real del
usuario son las mismas.
2. Crea el archivo destino con la mscara por defecto.
3. Copia el archivo antiguo al nuevo y restaura el modo de proteccin anterior.
4. Cambia el propietario y el grupo del archivo destino.
El Programa 9.2 permite consultar la identidad del dueo, de su grupo y los derechos de
acceso de un archivo, cuyo nombre recibe como parmetro de entrada, usando la llamada al
sistema stat. Este ejemplo no modifica nada, slo extrae los parmetros y se los muestra al
usuario. Para ello, el programa ejecuta la siguiente secuencia de acciones:
1. Ejecuta la llamada stat para el archivo solicitado y comprueba si ha recibido un error.
2. Si no le ha devuelto un error, extrae de la estructura de datos devuelta como parmetro de
salida (struct stat) la informacin pedida. El identificador del dueo est en el campo st_uid,
el de su grupo en st_gid y los permisos de acceso en st_mode.
3. Da formato a los datos obtenidos y los muestra por la salida estndar.
Windows NT tiene un nivel de seguridad C2 segn la clasificacin de seguridad del Orange Book
del DoD, lo que significa la existencia de control de acceso discrecional, con la posibilidad de
permitir o denegar derechos de acceso para cualquier objeto partiendo de la identidad del usuario
que intenta acceder al objeto. Para implementar el modelo de seguridad, Windows NT usa un
descriptor de seguridad y listas de control de acceso (ACL), que a su vez incluyen dos tipos de
entradas de control de acceso (ACE): las de permisos y las de negaciones de accesos.
Las llamadas al sistema de Win32 permiten manipular la descripcin de los usuarios, los
descriptores de seguridad y las ACL. A continuacin se describen las llamadas de Win32 ms
frecuentemente usadas.
BOOL InitializeSecurityDescriptor
(PSECURITY_DESCRIPTOR psd, DWORD dwRevision)
pAcl es la direccin de una estructura de usuario de longitud cbAcl. El ltimo parmetro debe ser
ACL_REVISION.
La ACL se debe asociar a un descriptor de seguridad, lo que puede hacerse usando la llamada
SetSecurityDescriptorDacl.
pAci es la direccin de una estructura de tipo ACL, que debe estar iniciada. El argumento
dwAclRevis ion debe ser ACLREVISION. El argumento pSid apunta a un identificador vlido de
usuario. El parmetro dwAccessMask determina los derechos que se conceden o deniegan al usua
rio o a su grupo. Los valores por defecto varan segn el tipo de objeto.
Para ilustrar el uso de los servicios de proteccin que proporciona Win32, se presenta en esta
seccin dos pequeos programas en lenguaje C que consultan y manipulan los descriptores de
seguridad de un objeto.
El Programa 9.3 lee los atributos de seguridad de un archivo. Para ello extrae primero la
longitud del descriptor de seguridad del archivo y luego el propio descriptor de seguridad, que
devuelve como salida de la funcin. Como ejercicio se sugiere al lector que modifique este progra
ma para extraer la ACL del archivo y cada una de sus entradas (ACEs).
El Programa 9.4 crea un descriptor de seguridad y le asigna los valores de proteccin por
defecto. Para ello extrae primero la longitud del descriptor de seguridad y del componente de la
ACL, los crea y posteriormente asigna valores. Se sugiere al lector que siga los comentarios del
programa como gua para comprender lo que hace.
Como ejercicio se sugiere al lector que modifique este programa para asignar permisos
espec ficos en el momento de la creacin del descriptor de seguridad. Estos permisos se pueden
pasar como parmetros del proceso.
La seguridad se incluy como parte de las especificaciones de diseo de Windows NT, lo que
permite lograr un nivel de seguridad C2 si se configura el sistema adecuadamente. El modelo de
seguridad incluye componentes para controlar quin accede a los objetos, qu accesos pueden
efectuar los usuarios sobre un objeto y qu eventos se auditan. Todos estos componentes juntos
componen el subsistema de seguridad de Windows NT.
Como se muestra en la Figura 9.20, el modelo de seguridad de Windows NT incluye los
siguientes componentes:
Procesos de logon, que muestran las ventanas de dilogo para que los usuarios puedan acce der
al sistema, piden el identificador del usuario, su palabra clave y su dominio.
Autoridad de seguridad local, que controla que el usuario tenga permiso para acceder al sistema.
Es el corazn del sistema porque gestiona la poltica local, los servicios de autenti cacin, poltica
de auditora y registro de eventos auditados.
Gestor de cuentas de usuario, que mantiene las base de datos de usuarios y grupos. Propor
ciona servicios de validacin de usuarios.
Monitor de referencia de seguridad, que controla los accesos de los usuarios a los objetos para
ver si tienen los permisos apropiados aplicando la poltica de seguridad y genera even tos para los
registros de auditora.
cada proceso que ejecuta en nombre del usuario tiene una copia de descriptor de seguridad del
usuario.
Cuando el usuario trata de acceder a un objeto con una mscara de proteccin, por
ejemplo, READ-WRITE, su SID se compara con los existentes en la ACL del objeto para verificar
que el usuario tiene permisos suficientes para efectuar la operacin de acceso. Para ello, el
Monitor de Referencia de Seguridad evala cada entrada de la ACL, denominada ACE (Access
Control Entry), de la siguiente manera:
Las utilidades de registro de eventos permiten recolectar informacin sobre los accesos de
los usuarios a los objetos y monitorizar eventos relacionados con el sistema de seguridad. El
registro permite identificar fallos de seguridad y determinar la extensin de los daos, si se han
producido. El nivel de auditora se puede configurar para ajustarlo a las necesidades de cada
instalacin.
9.10. KERBEROS
Kerberos [ 19871 es un sistema de seguridad para sistemas conectados en red, aunque se puede
aplicar a sistemas operativos convencionales, como Solaris y Windows 2000. Fue desarrolla do en
el Massachusetts Institute of Technology (MIT) a finales de los aos ochenta y se ha converti do en
un estndar defacto en sistemas operativos [ 1993]. Se basa en el uso de claves privadas,
protocolos simtricos de intercambio de claves y en la existencia de servidores de claves y tickets.
Cada usuario del sistema tiene su clave y el servidor de Kerberos usa dicha clave para codificar los
mensajes que enva a dicho usuario de forma que no puedan ser ledos por nadie ms.
Para proporcionar los servicios de autenticacin, Kerberos mantiene una base de datos
con sus clientes y sus respectivas claves privadas. La clave privada es un nmero muy grande que
slo conoce el servidor de claves de Kerberos y el cliente dueo de dicha clave. Si el cliente es un
usuario, dicha clave se almacena cifrada. Los servicios del sistema que requieren autenticacin, y
los clientes que quieren usar dichos servicios, deben registrarse en el sistema Kerberos. En ese
momento se establecen las claves privadas para cada uno de ellos. Puesto que Kerberos tiene las
claves de los usuarios, puede generar mensajes que convenzan a los mismos de que otro usuario
es quien dice ser. Se dice que Kerberos es un sistema confiable en el sentido en que los usuarios
creen que lo que dice Kerberos acerca de las identidades de otros usuarios es exacto. Para
incrementar la seguridad, el sistema genera tambin claves temporales o de sesin, que se dan
nicamente a los clientes que se quieren comunicar entre s. Dichas claves se usan para cifrar los
mensajes entre los dos clientes durante una sesin de trabajo.
Kerberos proporciona tres niveles de proteccin distintos:
Autenticacin de cada acceso. En este caso se comprueba que cada acceso es efectuado por
el usuario que inici la sesin. No se preocupa de ocultar el contenido de los mensajes, sino
de proporcionar mensajes seguros.
Autenticacin y ocultacin. En este caso se comprueban todos los accesos y se cifran los
mensajes con la clave de sesin de las dos partes en contacto proporcionando mensajes
privados.
Biblioteca de aplicacin. Interfaz entre las aplicaciones de los clientes y los servidores. Incluye
rutinas para crear autenticaciones, leerlas, generar mensajes seguros o privados,
etctera.
Biblioteca de cifrado. Incluye las rutinas para cifrar y descifrar. Se basa en el estndar DES y
proporciona varios mtodos alternativos de cifrado con caractersticas distintas de veloci dad y
seguridad (CBC, PCBC, etc.).
Sistema de gestin de base de datos. Mdulo reemplazable que proporciona los servicios de
bases de datos. Los servicios que necesita Kerberos son sencillos: por cada registro se guarda el
nombre del usuario, la clave privada y la fecha de expiracin de la misma. Adems puede existir
informacin adicional de los usuarios, tal como su nombre, telfono, etc. En este caso, la
informacin sensible se trata con medidas de seguridad mayores.
Servidor de registro, o mdulo de entrada, que proporciona la interfaz de cliente para acceder al
sistema. La parte del cliente se puede ejecutar en cualquier sistema, pero la parte
del servidor debe ejecutar en la mquina donde se ha instalado la base de datos de Kerberos.
El servidor de autenticacin ejecuta operaciones de slo lectura en la base de datos de
Kerberos para adquirir los datos de los usuarios. Adems genera claves de sesin y tickets, Puesto
que no modifica la base de datos puede ejecutar en cualquier sistema que tenga una copia de slo
lectura de la base de datos.
Existen adems programas de usuario que permiten entrar a Kerberos, cambiar una clave o
gestionar los tickets.
Los componentes que pueden escribir sobre la base de datos para generar registros o
modifi carlos slo pueden ejecutar en la misma mquina en la que est instalada la base de datos.
Dicha mquina debe estar instalada en un entorno seguro y ser confiable.
Lo ms complejo del diseo e implementacin de Kerberos son sus protocolos de
autentica. cin. Cuando un usuario pide un servicio, es necesario establecer su identidad. Para ello
es necesa rio presentar un ticket al servidor, junto con alguna prueba de que dicho ticket es legal y
de que no ha sido robado o falsificado. Como se puede ver en las Figuras 9.21 y 9.22, hay tres
fases en el proceso de autenticacin de Kerberos:
La credencial bsica en Kerberos es el ticket. Un ticket permite transmitir la identidad del dueo
del ticket de forma segura, adems de poder incluir informacin para identificar a los recep.
tores del mismo. Entre otras cosas incluyen el nombre del servidor, el del cliente, un sello temporal,
su duracin y una clave aleatoria de sesin. Toda esta informacin se cifra usando la clave del
servidor para el que se usa el ticket, lo que evita tener que comprobar si hay modificaciones del
ticket. Los tickets tienen una duracin temporal limitada, debiendo renovarse cuando expira.
Cuando un usUario quiere adquirir un ticket inicial (obtener credencial), debe acceder al
servi dor de autenticacin a travs de un proceso de login. Cuando introduce su nombre y clave se
codifican con la clave privada del cliente y se envan dichos datos al servidor de autenticacin, que
los contrasta con sus registros de la base de datos. Si todo es correcto, genera una clave aleatoria
para. esa sesin de trabajo y un ticket para que el servidor de tickets reconozca al usuario y le
conceda credenciales para servicios concretos cuando las pida. Para pedir credenciales para un
servicio concreto en un servidor, el usuario enva un mensaje al servidor de tickets (paso 1 de la
Figura 9.22). Este comunica con el servidor y el usuario y les enva el ticket concedido (pasos 2 y 3
de la Figura 9.22). A continuacin, el servidor se pone en contacto con el usuario para indicarle que
puede acceder a sus servicios usando dicho ticket (paso 4 de la Figura 9.22). Todos los mensajes
van codificados con las claves privadas del servidor o de la sesin correspondiente. Cada vez que
el usuario quiera acceder al servidor, debe presentar las credenciales concedidas para efectuar
esas operaciones.
Kerberos es un sistema ampliamente usado en sistemas operativos convencionales y
distribui dos. Sin embargo, no est exento de complicaciones y cuestiones pendientes de resolver
IlBellovin, 19911. Algunos de los problemas asociados con Kerberos son los siguientes:
Los protocolos de intercambio de tickets son complicados, lo que conlieva un tiempo consi
derable de ejecucin si se tiene en cuenta que hay que pedir un ticket para cada servicio y
servidor.
La seguridad de las bases de datos del servidor de autenticacin debe ser muy estricta para que
no haya accesos indebidos ni maliciosos. Este requisito se contradice con el rendimien to. Para
tratar de acercar ambas cuestiones, se replican las bases de datos con copias de slo lectura y
con acceso controlado por servidores de seguridad.
La duracin de los tickets supone tambin un compromiso entre seguridad y eficiencia. Por
seguridad, lo mejor sera usar un ticket para cada operacin. Por eficiencia, es mejor tener
tickets con una vida larga para evitar las operaciones de peticin de uno nuevo. Sin embargo, si el
ticket fuese usado de forma indebida, los daos seran mayores cuanto ms larga fuera la vida de
dicho ticket.
Es muy difcil garantizar la integridad del software que ejecuta en una computadora. La nica
solucin posible es dificultar la modificacin del software que se ejecuta en computa doras con
mltiples usuarios mediante la aplicacin de los controles descritos en este captulo.
Otro problema importante es la dificultad de delegar tareas entre servidores. Para conseguir esto,
habra que modificar mucho los protocolos de intercambio de tickets o compartir infor macin
sensible de las bases de datos.
A pesar de todo lo anterior, Kerberos es bien aceptado por los usuarios de un sistema de
computacin porque, si todo va bien, es casi totalmente transparente. Cuando accede al sistema,
el usuario ve una interfaz similar a la de un sistema convencional. Igualmente, las operaciones de
cam bio de palabra clave efectan de forma automtica los cambios pertinentes en los datos de
Kerberos. Slo cuando est dentro del sistema durante un tiempo mayor de lo que dura el ticket de
sesin (normalmente varias horas) el usuario observa la presencia de Kerberos, que le obliga a
adquirir un nuevo ticket de sesin. El trabajo del administrador del sistema, sin embargo, se
complica sustan cialmente. Debe efectuar todas las operaciones para dar de alta a nuevos
usuarios y servicios del sistema, replicar las bases de datos y asegurar que las mquinas que
ejecutan los componentes centrales de Kerberos son fsicamente seguras y confiables.
dominios de proteccin son las filas de la matriz y los U Los servicios de proteccin y seguridad de un sistema
objetos son las columnas de la misma. El elemento (i, j) varan dependiendo de que se usen ACL o capacidades.
expresa las operaciones que el dominio i puede eje cutar Adems, varan dependiendo de la complejidad del sis
sobre el objeto j. Estas matrices de proteccin suelen ser tema implementado.
muy grandes o muy dispersas, por lo que se U Los servicios de seguridad de POSIX usan el modelo
implementan como listas de control de acceso (ACL) o de ACL de UNIX directamente. Permiten manipular los
capacidades (capabilities). permisos de un objeto y la identidad y el grupo del due
U Una ACL es una lista de entradas asociadas a un o del objeto.
objeto que especifican qu operaciones puede hacer U Los servicios de seguridad de Windows NT usan un
cada do- modelo de ACL ms general y, por tanto, ms comple jo.
minio sobre ese objeto. Las ACL son sencillas de im Incluyen varias llamadas para manipular la ACL y
plementar en sistemas no distribuidos, pero tienden a sus entradas (ACE).
crecer mucho y pueden ser poco eficientes. Revocar to U Kerberos es un sistema de seguridad para sistemas
dos los permisos de acceso es fcil: basta con desconec co-
tar la ACL. nectados en red, aunque se puede aplicar a sistemas
U Una capacidad indica qu operaciones puede hacer operativos convencionales. Fue desarrollado en el Mas
un usuario sobre un objeto cuando pertenece a un sachusetts Institute of Technology (MIT) a finales de los
determi nado dominio. Cada usuario tendr una lista de aos ochenta y se ha convertido en un estndar de facto
capaci dades. Las capacidades complejas, pero se en sistemas operativos. Se basa en el uso de claves
prestan muy bien a sistemas distribuidos. Revocar todos privadas, protocolos simtricos de intercambio de cla ves
los permi sos de acceso puede ser complejo. y en la existencia de servidores de claves y tickets.
Para extender la visin introductoria sobre el tema se recomienda acudir a otros libros de sistemas
operativos tales como el de Deitel [ 1984], Krakowiak [ 1988], Tanenbaum [ 1997] y [ 1992],
Silberschatz [ 1998] o Stallings [ 1995]. Para tener una visin ms profunda del tema de seguridad
y proteccin se recomienda acudir a textos ms especficos, tales como [ PUTER, 1893b], [ 1982], [
1990], [ 19891 y [ 1997].
Los estudios bsicos sobre temas de seguridad y proteccin en sistemas operativos se llevaron a
cabo en la dcada de los setenta. Varios de estos estudios son importantes para entender el
problema y las soluciones propuestas. Popek [ 19741 estudi distintas estructuras de proteccin en
sistemas operativos. En [ 1976] se mostr el estado del arte del momento sobre estructuras que
permitan dar soporte de seguridad. En [ 19761 se repas la perspectiva de la seguridad de los
sistemas operativos existentes. En [ 1979] se hizo una exploracin muy completa de las posibles
vulneraciones de seguridad y de la forma de controlarlas.
Las cuestiones ms relevantes de diseo de sistemas seguros se estudian en [ 19731, [ TER,
1983a], [ 1988] y [ 1990]. Para aprender ms sobre la aplicacin de la criptografa al diseo de
sistemas seguros se puede consultar [ 1982] y [ 19821. Buenos estudios de penetra cin de
sistemas son los de [ 1976] para el VM/370 y [ 1974] para MVS.
Los problemas de integridad y disponibilidad de datos se estudian en [ 1991] y [ 19921.
Para estudios sobre seguridad en sistemas operativos especficos se pueden leer los textos de [
19851, [ 1986], [ 1990 [ 1993], [ 19911 y [ 19921, que estudian
el sistema operativo UNIX, los de [ 1999] y [ 1999] para LINUX y los de [
1994] y [ 19981 para Windows NT.
9.13. EJERCICIOS
Qu tipos de fallos de seguridad puede tener un Suponga que un empleado de una compaa
sistema de computacin? genera un cdigo malicioso que est
Cul es la diferencia entre los trminos transmitiendo infor macin no autorizada, como
seguridad y proteccin? por ejemplo el sueldo de los empleados, a intrusos
o espas. Cmo se
* Historia de Linux.
* Caractersticas y estructura de Linux.
* Gestin de procesos.
* Gestin de memoria.
* Entrada/salida.
* Sistema de archivos.
El origen de Linux se encuentra en el sistema operativo MINIX. MINIX fue desarrollado por Andrew
S. Tanenbaum con el objetivo de que sirviera de apoyo para la enseanza de sistemas operativos.
De hecho, en su clsico libro Operating Systems: Design and Implementation [Tanenbaum, 1987],
se utilizaba este sistema operativo para explicar los diferentes conceptos de esta materia,
incluyndose, adems, en un apndice un listado completo de su cdigo escrito en lenguaje C.
Adems de por su carcter pedaggico, MINIX se caracterizaba por tener una estructura
basada en un microkernel. El autor intentaba demostrar al crear MINIX que se poda construir un
sistema operativo ms sencillo y fiable, pero a la vez eficiente, usando este tipo de organizacin,
que era novedosa en aquel momento. Algunas otras caractersticas positivas de MINIX eran las
siguientes:
A pesar de estos defectos, MINIX atrajo la atencin de muchos usuarios de todo el mundo, que
usaban el grupo de noticias comp.os.minix como punto de encuentro. Algunos de estos usuarios se
ofrecan a mejorar partes del sistema o a incluir nuevas funciones al mismo. Sin embargo, el autor
siempre fue reacio a estas ofertas. Entre los interesados en MINIX se encontraba un estudiante
llamado Linus Torvalds, Fue en el ao 1990 cuando este estudiante envi un mensaje a este grupo
de noticias comentando que, por curiosidad y ganas de ampliar sus conocimientos, estaba
desarrollando un nuevo sistema operativo tomando como base MINIX. Se estaba produciendo el
humilde nacimiento de Linux. Cuya primera versin (enumerada como 0.01) vio la luz a mediados
del ao 1991.
Es importante recalcar que, en su concepcin inicial, Linux tomaba prestadas numerosas
caractersticas de MINIX (p. ej.: el sistema de archivos). De hecho, Linux se desarroll usando
corno plataforma de trabajo MINIX y las primeras versiones de Linux no eran autnomas sino que
tenan que arrancarse desde MINIX.
Sin embargo, a pesar de esta herencia inicial, MINIX y Linux son radicalmente diferentes. Por
un lado. Linux solventa muchas de las deficiencias de MINIX como, por ejemplo, la carencia de
memoria virtual. Estas mejoras permiten que se trate de un sistema adecuado para trabajar de
manera profesional, no limitndose su uso a un entorno acadmico. Pero la diferencia ms impor-
tante entre ellos est en su organizacin Interna. Mientras que MINIX tiene una estructura moderna
basada en un microkernel, Linux posee una estructura monoltica ms clsica. Este diseo
conservador tuvo como consecuencia que el autor de MINIX no diera el visto bueno a Linux ya que
consideraba que este sistema supona un paso atrs en la evolucin de los sistemas operativos.
Desde su lanzamiento pblico en 1991, Linux ha evolucionado e incorporado nuevas
caractersticas. Adems, se ha transportado a otros procesadores como SPARC, Alpha y MIPS. En
la actualidad es un sistema con unas caractersticas y prestaciones comparables a las de cualquier
sistema operativo comercial.
Puesto que en esta seccin se ha presentado la historia de Linux, parece el lugar
adecuado para explicar cual es el convenio usado para enunciar las sucesivas versiones del
sistema. El nmero de la versin contiene un nmero primario y uno secundario separados por un
punto p. ej.: versin 2.2). Un incremento en el nmero primario corresponde con una nueva versin
que incluye cambios significativos en el sistema. En el caso de una modificacin de menor
impacto, solo se modifica el nmero de versin secundario. Adems un nmero secundario de
versin que sea impar (como, por ejemplo la versin 2.1) indica que se trata de una versin
inestable en la que se han incluido nuevas caractersticas que todava hay que probar y depurar.
Evidentemente un usuario normal debera instalarse una versin con un nmero secundario par.
Linux es un sistema de tipo UNIX y, por tanto, posee las caractersticas tpicas de los sistemas
UNIX. Se trata de un sistema multiusuario y multitarea de propsito general. Algunas de sus
caractersticas especficas ms relevantes son las siguientes:
La gestin de procesos en Linux es bsicamente igual que en cualquier otra variedad de UNIX. Un
aspecto original de Linux es el servicio clone que es una extensin del clsico fork.
Este nuevo servicio permite crear un proceso que comparta con el padre su mapa de
memoria, sus rutinas de manejo de seales y sus descriptores de archivos. Aunque Linux no
implementa threads en el ncleo, se pueden construir bibliotecas de threads usando este nuevo
servicio.
En cuanto a la sincronizacin dentro del ncleo, siguiendo la tradicin de UNIX, Linux no
permite que haya llamadas concurrentes activas dentro del sistema operativo. As, si se produce un
evento que causa un cambio de proceso mientras se est ejecutando una llamada al sistema (p.
ej.: una interrupcin de reloj), el cambio se difiere hasta que la llamada termina o se bloquea.
Para evitar las condiciones de carrera entre la ejecucin de una llamada y el tratamiento de
una interrupcin, se prohben las interrupciones en pequeas zonas del cdigo del sistema.
Puesto que el cdigo de una rutina de interrupcin ejecuta con una prioridad alta
bloqueando el tratamiento de las interrupciones, es importante que estas rutinas sean muy cortas.
Para ayudar a lograr este objetivo, Linux ofrece un mecanismo que permite dividir las operaciones
asociadas a una interrupcin en dos partes:
La Figura 11.1 muestra cules son los niveles de prioridad de las diversas partes del
ncleo. Observe que slo se ejecutar una rutina de un determinado nivel si no est activa ninguna
rutina de un nivel superior.
En cuanto a la planificacin, Linux soporta tres clases de planificacin: un algoritmo de
tiempo compartido y dos algoritmos de planificacin de tiempo real que se corresponden con los
definidos por POSIX.
El servicio sched_setscheduler permite definir la clase de planificacin del proceso que la invoca.
Esta llamada slo puede hacerla un proceso privilegiado. Cada proceso de tiempo real tiene
asociada una prioridad y un tipo de planificacin que puede ser FIFO o Round-Robin. El
planificador selecciona en cada momento el proceso listo para ejecutar que tenga mayor prioridad.
Si el proceso es de tipo FIFO, seguir ejecutando hasta que se bloquee. Si es de tipo Round-
Robin, cuando termine su rodaja, el proceso pasar al final de la cola de procesos listos para
ejecutar de su misma prioridad.
Los procesos de tiempo compartido slo pueden ejecutar cuando no hay ningn proceso
de tiempo real listo para ejecutar. El algoritmo de planificacin para este tipo de procesos intenta
conjugar la prioridad del proceso con su perfil de ejecucin, favoreciendo a los procesos que
realizan ms operaciones de entrada/salida. A continuacin, se describe este algoritmo.
Todo proceso tiene asociada una prioridad base. Inicialmente la prioridad del proceso es
igual a su prioridad base. Cada vez que se produce una interrupcin de reloj se resta una unidad a
la prioridad del proceso que estaba ejecutando. El algoritmo de planificacin est basado en la
prioridad del proceso y tiene carcter exclusivo: el planificador elige el proceso listo para ejecutar
que tenga mayor prioridad.
Cuando se produce una situacin en la que todos los procesos listos para ejecutar tienen
una prioridad igual a cero (todos ellos han usado el procesador un tiempo suficiente para que su
prioridad haya cado a 0), se produce un reajuste de las prioridades de todos los procesos sea cual
sea su estado. La nueva prioridad se calcula dividiendo por 2 la actual y sumando la prioridad base
(prioridad = prioridad/2 + prioridad base). Observe que los procesos listos para ejecutar simple mente
recuperan su prioridad base ya que su prioridad actual es igual a 0. Sin embargo, los procesos
bloqueados obtienen una nueva prioridad mayor que la base puesto que su actual prioridad es
mayor que cero. Se trata de una frmula de tipo exponencial. Con ella, un proceso que estuviese
bloqueado mucho tiempo puede llegar a tener una prioridad con un valor del doble de la prioridad
base.
Linux tiene un sistema de memoria que incluye todas las caractersticas habituales en los sistemas
modernos. Estas caractersticas ya fueron discutidas en el captulo dedicado a este tema, por lo
que en esta seccin se presentan aquellos aspectos especficos de Linux:
11.5. ENTRADA/SALIDA
La entrada/salida en Linux es muy similar a la de cualquier otro sistema UNIX. Se distinguen, por
tanto, dos tipos de dispositivos: dispositivos de bloques y dispositivos de caracteres.
Como el resto de los sistemas UNIX, se utiliza una cache comn para todos los
dispositivos de bloques. El tamao de la cache es dinmico y crece de acuerdo a las necesidades
de memoria del resto del sistema. Para gestionarla se usa bsicamente una poltica de reemplazo
LRU. En las ltimas versiones esta cache trabaja coordinadamente con la utilizada por el gestor de
memoria.
En cuanto al acceso a los discos, se utiliza el algoritmo del ascensor con un nico sentido
de servicio.
Siguiendo el modelo de UNIX, en Linux los usuarios ven los dispositivos como archivos y
utilizan los servicios destinados a trabajar con archivos para acceder a los dispositivos.
La red, sin embargo, es un dispositivo que tiene un tratamiento un poco diferente. El
usuario no puede acceder a este dispositivo de la misma manera que a un archivo. La parte del
sistema operativo que trata la red est dividida en tres niveles:
En el nivel inferior est el manejador del dispositivo al que el usuario no puede acceder
directamente.
En el nivel intermedio est el software que implementa la pila de protocolos (p. ej.: TCP e
IP).
En el nivel superior est la interfaz del programador que corresponde con la de los sockets
definidos en el UNIX BSD.
Linux da soporte a una gran variedad de tipos de sistemas de archivos entre los que se incluyen
los distintos sistemas de archivos de Windows y de otros sistemas UNIX. Adems, cualquier
usuario puede programar un manejador de un nuevo tipo de sistema de archivos e incluirlo en el
sistema como un mdulo.
Esta coexistencia de distintos tipos de sistemas de archivos la posibilita el VFS (Virtual File
System, Sistema Virtual de Archivos), presente en la mayora de los sistemas UNIX actuales y
suficientemente analizado en el Captulo 8.
Aunque admite muy diferentes tipos de sistemas de archivos, Linux tiene su propio sistema
de archivos que se denomina ext2fs. Este sistema evolucion desde el sistema de archivos de
MINIX .Se le fueron aadiendo nuevas caractersticas al sistema de archivos de MINIX hasta llegar
al sistema extfs. Posteriormente se redise dando lugar al ext2fs actual. Se trata de un sistema
basado en el FFS (Fast File System, Sistema de Archivos Rpido) del UNIX BSD, que ya se
estudi adecuadamente en el Captulo 8.
Merece mencin aparte un tipo de sistema de archivos muy especial: el sistema de
archivos proc. Este sistema de archivos no tiene soporte en ningn dispositivo. Su objetivo es poner
a disposicin del usuario datos del estado del sistema en la forma de archivos. Esta idea no es
original de Linux ya que casi todos los sistemas UNIX la incluyen. Sin embargo, Linux se
caracteriza por ofrecer ms informacin del sistema que el resto de variedades de UNIX. En este
sistema de archivos se puede acceder a informacin general sobre caractersticas y estadsticas
del sistema, as como a informacin sobre los distintos procesos existentes.
La Figura 11.2 muestra cmo se relacionan las distintas partes del sistema de archivos.
El origen del Linux est en MINIX superior, que ejecuta con alta
que es un sistema operativo de prioridad, y una mitad inferior menos
carcter pedaggico basado en un prioritaria.
microkernel Linux soporta las clases de
Linux supera muchas de las planificacin de tiempo real definidas
limitaciones de MINIX y tiene una en POSIX.
organizacin monoltica ms La planificacin de procesos de
convencional. tiempo compartido intenta conjugar la
Linux comenz en 1991, como prioridad del proceso y su perfil de
proyecto personal de Linus Torvalds. ejecucin.
Gracias al auge de Internet, han La gestin de memoria en Linux
colaborado numerosas personas en incluye todas las caractersticas
su desarrollo. presentes en cualquier sistema
Proporciona una interfaz POSIX. operativo moderno.
Est diseado para facilitar su La entrada/salida es similar a la
transporte a distintos procesadores. existente en cualquier otro sistema
Puede ejecutar en mquinas de muy UNIX.
distintas prestaciones. Linux da soporte a una gran variedad
Da soporte a una gran variedad de ele tipos de sistemas de archivos
tipos de sistemas de archivos. gracias al VFS.
Proporciona soporte para un El sistema de archivos nativo de
esquema de multiproceso simtrico. Linux es ext2fs basado en el FFS.
La gestin de procesos en Linux es El sistema de archivos proc ofrece
muy similar a la realizada en otros mucha informacin sobre el propio
sistemas UNIX. sistema y los procesos existentes en
El ncleo de Linux no es reentrante. el mismo.
El tratamiento de una interrupcin
puede dividirse en una mitad
Algunos libros generales ele sistemas operativos incluyen un captulo dedicado a Linux Como
[Silberschatz, 1998]. Hay tambin libros dedicados exclusivamente a Linux como [Cornes. 1997],
que presenta con bastante detalle todas las caractersticas del sistema, o [Beck, 1998] que se
centra en los aspectos internos. Para comprender mejor Linux es interesante estudiar MINIX, el
sistema operativo que le sirvi como punto de partida. En [Tanenbaum, 1997] se presenta la
versin actual de MINIX incluyendo el listado completo de este sistema operativo.
12.1. INTRODUCCIN
Windows NT tiene un diseo moderno de tipo microncleo, con una pequea capa de ncleo que
da soporte a las restantes funciones del ejecutivo del sistema operativo. Dentro del ejecutivo
destaca la integracin del modelo de seguridad (nivel C2), de la gestin de red, de la existencia de
sistemas de archivos robustos y de la aplicacin exhaustiva del modelo orientado a objetos.
El diseo del sistema operativo Windows NT se hizo desde cero, pero, a pesar de ello, no
incluye muchas ideas nuevas, sino que surgi como el resultado de fundir ideas ya contrastadas en
otros sistemas operativos, como UNIX, VMS o MACH, y de la optimizacin de las mismas.
Adems, para mantener la compatibilidad con sistemas operativos anteriores de Microsoft, se
siguieron manteniendo algunas ideas existentes en MS-DOS y Windows 3.x. Por ello, los principios
de diseo fundamentales se parecen mucho a los de otros sistemas operativos:
Compatibilidad. Tanto con los sistemas anteriores (interfaz grfico y sistemas de archivos
FAT de Windows 3.x) como con otros sistemas operativos (OS/2, POSIX, etc.) y con
distintos entornos de red. La compatibilidad se logra mediante el uso de subsistemas que
emulan los servicios de los distintos sistemas operativos. Los emuladores son similares a
las mquinas virtuales de MVS.
Transportabilidad. Windows NT se dise para tener amplia difusin comercial, por lo que
se pens desde el principio en la posibilidad de transportarlo a distintos tipos de
computadoras con procesadores CISC (Intel) y RISC (MIPS, Digital Alpha, etc.). Para
facilitar el transporte, Windows NT se ha construido sobre una pequea capa de
abstraccin de hardware (HAL, Hardware Abstraction Layer) que proporciona toda la
funcionalidad dependiente del hardware al ncleo del sistema. Para transportar el sistema
operativo, slo es necesario adaptar el HAL a cada entorno hardware. Esta capa existe en
otros sistemas como MACH y MINIX, aunque no suele existir en sistemas monolticos
como UNIX y LINUX. Adems de la transportabilidad para el hardware, Windows NT
incluye facilidades para transportar las interfases a distintas lenguas mediante el uso del
estndar Unicode de ISO.
Los principios anteriores permitieron disear un sistema operativo con una arquitectura muy
moderna. Su uso se extendi rpidamente, sobrepasando el mbito de Windows 3.x que estaba
reducido a computadoras personales, para pasar a ser instalado en servidores medianos y
estaciones de trabajo.
Windows NT tiene una arquitectura por capas muy modular, en la que cada capa est compuesta
de varios mdulos relativamente simples y con una funcionalidad muy especfica.
Como se puede ver en la Figura 12.1, el sistema operativo est compuesto por las
siguientes capas:
Capa de abstraccin del hardware. Proporciona una interfaz virtual del hardware,
escondiendo las particularidades de cada entorno de ejecucin del sistema operativo.
Incluye la funcionalidad del hardware que necesita el resto del sistema y es el nico
mdulo que es necesario transportar cuando se cambia a otra plataforma hardware. Entre
sus funciones estn las interfases de los controladores de E/S, interfaz con memoria y
UCP, temporizadores del sistema y esconder los detalles del multiprocesamiento simtrico
al ncleo del sistema. Cuando se instala el sistema operativo, se elige uno u otro HAL en
funcin de la plataforma hardware.
Ncleo. Proporciona servicios y funcionalidades bsicas del sistema operativo tales como
gestin de excepciones hardware, control de procesos ligeros, sincronizacin, etc. Slo
incluye mecanismos, nunca polticas, aunque toma las decisiones para expulsar procesos
de memoria. Es pequeo (unos 60 KB), muy eficiente y altamente transportable (el 80 por
100 es independiente de la plataforma hardware). Usa memoria compartida para optimizar
las comunicaciones con otros mdulos del sistema, por lo que no sigue un diseo de
microncleo puro.
Ejecutivo. Incluye los mdulos que proporcionan los servicios del sistema operativo para
los distintos subsistemas de ejecucin. Tiene diseo orientado a objetos y, a su vez,
proporciona servicios orientados a objetos. Por ello entre sus componentes incluye un
gestor de objetos, adems de gestores para los sistemas de seguridad, procesos, memoria
virtual, etc. Su interfaz define la capa de servicios que el sistema operativo exporta a los
subsistemas externos al ncleo. Estos servicios son las interfases entre los subsistemas,
que se ejecutan en modo usuario, y el ncleo
Subsistemas de entorno de ejecucin. Proporcionan las llamadas al sistema operativo
que usan las aplicaciones de usuario, existiendo subsistemas compatibles con distintos
sistemas operativos (MS- DOS, OS/2, POSIX l, etc.). A diferencia de las capas anteriores,
sus componentes se ejecutan en mudo usuario. Sus servicios se pueden acceder a travs
de las bibliotecas de los compiladores.
El ncleo es la base de Windows NT ya que planifica las actividades, denominadas threads, de los
procesadores de la computadora. Al igual que en UNIX, el ncleo de Windows NT se ejecuta
siempre en modo seguro (modo ncleo) y no usa la memoria virtual (no paginable). El software del
ncleo no se puede expulsar de la UCP, y por tanto, no hay cambios de contexto durante su
ejecucin. En caso de que se ejecute en un multiprocesador se puede ejecutar simultneamente
en todos los procesadores.
El ncleo proporciona las siguientes funciones al resto del sistema:
El modelo de objetos est en la base de funcionamiento del ncleo, que proporciona dos tipos
de objetos bsicos:
Tabla de interrupciones (IDT, Interrupt Dispatch Table). Asocia las interrupciones con las
rutinas que las gestionan.
Tabla de descriptores de proceso (PCB. Process Control Blocks). Incluye apuntadores a
los manejadores de objetos tipo proceso. Hay una tabla por cada procesador del sistema.
Asociada a ellas hay una tabla de control de regiones de memoria, cuyas entradas apuntan
a las regiones de memoria donde estn las otras tablas con informacin relativa al proceso.
Cola de temporizadores. Lista global de temporizadores activos de todo el sistema. Se
mantiene en el ncleo.
Adems de estas estructuras se mantienen otras como las colas de dispositivos, las de
peticin de procesadores y recursos, etc.
La capa ms compleja del sistema operativo es el ejecutivo, un conjunto de servicios comunes que
pueden ser usados por todos los subsistemas de entorno de ejecucin existentes en Windows NT
a travs de la capa de servicios del sistema.
Cada grupo de servicios es manejado por uno de los siguientes componentes (Fig. 12.2):
Gestor de objetos.
Gestor de procesos.
Gestor de memoria virtual.
Monitor de seguridad.
Utilidad para llamadas a procedimientos locales.
Gestor de entrada/salida.
En esta seccin se estudian todos ellos, excepto el monitor de seguridad, al que se dedica
una seccin posterior.
Figura 12.2 Estructura del ejecutivo de Windows NT. (Fuente: Microsoft Windows T
ServerResource Kit, Copyright 2000 by Microsoft Corporation.)
Tipo de Objeto
que son instancias en tiempo de ejecucin de un tipo objeto particular que pueden ser manipuladas
por algn componente del sistema operativo. Un tipo objeto est compuesto por un tipo de datos
estructurado definido por el sistema y las operaciones que se pueden hacer sobre este tipo de
datos y un conjunto de atributos de datos para dichas operaciones.
La Figura 12.3 muestra la estructura de un objeto en Windows NT. Como puede verse,
todos los objetos tienen atributos comunes almacenados en la cabecera del objeto, tales como el
nombre, el manejador, la lista de manejadores de otros objetos a los que dan paso, el tipo objeto
con que estn relacionados y un contador de referencias al objeto. Adems, incluyen un cuerpo del
objeto en el que se almacena informacin especfica de cada objeto. Antes de poder usar un objeto
es necesario adquirir un manejador del mismo mediante operaciones especficas del sistema
operativo que se ejecutan a travs del gestor de objetos. El manejador de un objeto incluye
informacin de control y un puntero al objeto en s mismo.
Para poder identificar un objeto de forma inequvoca es necesario que cada objeto tenga
un nombre nico en todo el sistema. El gestor de objetos se encarga de gestionar el espacio global
de objetos con nombre (directorios, procesos, threads, puertos, archivos, semforos, etc.). El
espacio de nombres se modela como un sistema de archivos jerrquico, como el de la Figura 12.4.
Todos los objetos del sistema tienen una parte incluida en el ncleo, definida como un apuntador al
objeto correspondiente del ncleo. Esos objetos bsicos no pueden ser vistos por el usuario y no
tienen nombre lgico.
El gestor de procesos se encarga de gestionar dos tipos de objetos bsicos para el sistema
operativo:
Adems, gestiona las operaciones asociadas con ambos objetos (creacin, destruccin,
etc.) a travs del conjunto de servicios para procesos y threads existentes en cada subsistema de
entorno de ejecucin. Sin embargo, el gestor de procesos no impone ninguna jerarqua a los
mismos ni fuerza la existencia de una relacin padre-hijo, como ocurre en UNIX o LINUX.
La Figura 12.5 muestra el bloque descriptor de un proceso. Como se puede ver, los datos
de descripcin del proceso estn compuestos por dos estructuras de datos: descriptor en el
ejecutivo y descriptor en el ncleo. En la parte del ejecutivo, adems de la identificacin de
descriptor del ncleo, est la identificacin del proceso y de su padre, el estado del proceso, los
tiempos de creacin y terminacin, bloques del proceso, descriptor de seguridad, prioridad, etc. En
suma, toda la informacin del proceso que necesitan los otros componentes del ejecutivo y que, en
muchos casos, pueden acceder los usuarios a travs de los servicios del sistema. En la parte del
ncleo se encuentra la informacin relacionada con la planificacin (prioridad, rodaja, etc.) y con la
ejecucin del proceso (threads, tiempo de ejecucin de usuario y sistema, afinidad con el
procesador, etctera).
Los procesos y los threads se planifican de la misma manera: planificacin con expulsin y
rodaja de tiempo. De hecho, un proceso es visto como un thread especial. Cuando se crea un
objeto proceso se le asigna una prioridad determinada de entre la cuatro siguientes: Iddle, Normal,
High, Real-Time. Existen 32 niveles de prioridad, de los cuales los niveles 1 a 32 se dedican a los
procesos de tiempo real. Adems, el sistema operativo puede variar el nivel de prioridad mediante
calificaciones tales como normal, por debajo de lo normal o por encima de lo normal. Con esos
criterios el gestor de objetos consulta una tabla de prioridades y asigna la prioridad inicial al objeto.
Adems, cada objeto puede tener su propia rodaja de ejecucin, asignada cuando se crea el obje-
Directorio de pginas
Informacin de planificacin
Tiempo de sistema y usuario
Ejecutivo Lista de intercambio de pginas
Bloque de proceso del ncleo Lista de threads del ncleo
Identificador del proceso Spin Lock
Identificador del proceso padre Afinidad del procesador
Estado de terminacin Contador de pila del ncleo residente
Tiempos de creacin y terminacin Prioridad base del proceso
Bloque siguiente del proceso Rodaja de planificacin
Cuota Estado del proceso
Informacin de gestin de memoria Ncleo
Puerto de excepcin
Puerto de depuracin
Descriptor de seguridad primario
Bloque de entorno del proceso
Nombre archivo imagen
Direccin base de memoria
Clase de prioridad del proceso
Bloque de proceso Win32
to. La roda se indica en el descriptor del objeto como un valor de 6 bits, divididos en grupos de 2 de
la siguiente manera:
Bits 0 y 1. Modificaciones de la rodaja. Sirve para activar la ejecucin de threads en primer plano.
Bits 2 y 3. Rodaja de planificacin con valor variable o fijo.
Bits 4 y 5. Rodaja de planificacin corta o larga.
Con estos parmetros el sistema planifica los threads, pero no existe un planificador central
que est siempre activo, sino que las rutinas de planificacin son manejadores de eventos
disparados por los threads (bloqueo voluntario), los temporizadores (rodaja de planificacin) o
interrupciones (entrada/salida) del sistema.
ACLARACIN 12.1
Los bits que se usan para describir o cualificar la rodaja de planificacin se usan como mscaras
de bits en pares. El efecto de estas mscaras es complementario, lo que permite definir una
rodaja corta con valor variable o una rodaja corta con valor fijo. El valor de la rodaja vara
dependiendo de la versin del sistema operativo, siendo mayor en configuraciones para
servidores de datos o de proceso.
Windows NT proporciona un modelo de memoria virtual con paginacin por demanda y sin
preasignacin de espacio de intercambio. Cada proceso dispone de una capacidad de
direccionamiento de 4 GB (32 bits), de los cuales 2 GB son para el programa de usuario y 2 GB se
Los 10 bits siguientes indican la entrada de pgina dentro de la tabla de pginas seleccionada,
hasta un mximo de 1.024 pginas. Los 12 bits siguientes indican la posicin dentro de la pgina
virtual, cuto tamao es de 4 KB.
ACLARACIN 12.2
Este esquema es similar a la traduccin de direcciones de memoria con tres niveles que se
proponen en otras arquitecturas. Lo que vara es la denominacin del nivel superior (directorio,
nivel primario, etc.).
Cada proceso tiene un conjunto de pginas de trabajo en memoria, representado por una
lista de pginas que se define como su conjunto de trabajo. Adems de esta estructura de datos, el
gestor de memoria mantiene varias listas asociadas a la poltica de gestin:
Lista de pginas libres. Almacena las pginas libres, es decir, que han sido asignadas
alguna vez y liberadas posteriormente. Existen en el archivo de intercambio.
Lista de pginas a cero. Pginas sin iniciar. Cuando una pgina se referencia por primera
vez se asigna desde esta lista.
Lista de pginas modificadas. Pginas reemplazadas en memoria y cuyos contenidos
han sido modificados (escritos).
Lista de pginas en espera. Lista que aglutina pginas modificadas que todava no se
liberan para evitar sobrescribirlas de forma prematura.
La Figura 12.8 muestra la gestin de pginas de memoria en Windows NT. Cuando hay un
fallo de pgina en un proceso, el gestor de memoria aplica una poltica de reemplazo LRU sobre el
conjunto de trabajo del proceso. Si la pgina ha sido modificada, la almacena en la lista de pginas
modificadas (paso 1). Si no, pasa a la lista de pginas en espera (paso 2). En el caso de que haya
pginas modificadas, existe un thread escritor de pginas modificadas que las lee de la lista
anterior, las escribe y las pasa a la lista de pginas en espera (paso 3). En cualquiera de los dos
casos, cuando hace falta espacio o se cumple un determinado tiempo sin ser referenciadas, las
pginas de la lista en espera pasan a la lista de bloques libres (paso 4). A esta lista pueden llegar
tambin pginas cuando se libera un proceso o un conjunto de pginas de memoria de forma
explcita (paso 5). Si despus de pasar un cierto tiempo las pginas libres siguen sin ser usadas (o
si hay recoleccin de basura en memoria), el thread de pginas a cero libera los recursos de estas
pginas y las considera no asignadas (paso 7). Existen varias posibilidades para la pgina nueva
referenciada: estar en la lista de pginas modificadas o en espera, en cuyo caso se trae tal cual
(pasos 8 y 9); que se hubiera liberado anteriormente, en cuyo caso se traer de la lista de pginas
libres (paso 6); que sea la primera vez que se referencia, en cuyo caso se trae de la lista de
pginas a cero (paso 10).
PRESTACIONES 12.1
Los sistemas operativos con diseo por capas han tenido siempre fama de ser ms lentos que los
monolticos debido a la sobrecarga de tiempo que en las llamadas al sistema constituyen los
mensajes de unos niveles a otros. Para reducir esta sobrecarga, los sistemas operativos
comerciales cortocircuitan los niveles locales para proporcionar mecanismos de comunicacin
ms rpidos basados en el uso de memoria compartida.
Cada uno de los componentes anteriores se considera un objeto del sistema, por lo que es
muy sencillo crear el sistema de entrada/salida de forma dinmica, as como reemplazar
manejadores de archivos y dispositivos. Adems, para mantener la compatibilidad con aplicaciones
de l6 bits y permitir que piensen que tienen acceso directo a los puertos de entrada/salida, se
proporcionan manejadores virtuales para puertos serie, paralelos, ratn, teclado, etc.
La entrada/salida en Windows NT es inherentemente asncrona, aunque las aplicaciones
puedan pensar que es sncrona porque se bloquean los procesos que ejecutan tales instrucciones.
A partir del gestor de entrada/salida los manejadores se comunican intercambiando paquetes de
peticin de E/S (IRP, I/O Request Packets).
Estos paquetes describen las peticiones de E/S e incluyen, entre otras cosas, el tipo de operacin,
la direccin de memoria en el destino, la cantidad de datos a transferir o un apuntador al objeto
manejador que necesitan. Todas ellas se encolan en una lista global desde la cual se distribuyen
posteriormente a la lista particular de cada dispositivo, cuya gestin es guiada por eventos de
interrupcin. A partir de esta lista de peticiones, los manejadores de dispositivo acceden a cada
dispositivo a travs de las rutinas que proporciona Windows NT, rutinas con una interfaz comn
pero con un cuerpo distinto dependiendo de la plataforma hardware en que se haya instalado el
sistema. El procesador se ve como un dispositivo ms del sistema. La Figura 12.11 muestra una
traza de una peticin de E/S sncrona en Windows NT.
PRESTACIONES 12.2
Al igual que con la comunicacin, en el sistema de entrada/salida de Windows NT hay una forma
de saltarse los pasos que se muestran en la Figura 12.11 y acceder directamente a los
dispositivos. Se denomina E/S Rpida (Fast I/O).
El gestor de cache
Este componente es Fundamental para la optimizacin de la E/S del sistema operativo Windows
NT. Su misin es gestionar la cache de archivos de Windows NT, una cache nica en el mbito
del sistema y comn para todos los tipos de sistemas de archivos locales y remotos. Esta cache no
se gestiona sobre la base de bloques de archivos, sino mediante bloques virtuales, agrupaciones
de bloques de archivo de 256 KB que se proyectan en zonas de memoria virtual. Su tamao vara
dinmicamente en funcin de la memoria RAM disponible, siendo esta caracterstica controlada por
el gestor de memoria virtual. Con esta caracterstica, cada vez que se abre un objeto archivo se le
habilitan apuntadores a los bloques virtuales de la cache, lo que le permite trabajar con su propia
imagen de cache. Sin embargo, todas estas representaciones virtuales se proyectan sobre una
nica representacin de marcos de memoria fsica, a travs de los cuales se hace el acceso final a
los datos de un archivo.
La estructura de la cache se representa mediante varias estructuras de datos, como se
puede ver en la Figura 12.12. La primera es un vector que representa a los bloques virtuales en la
cache del sistema, denominado Direcciones virtuales de bloques de control (VACB, Virtual Address
Control Block). Representa el estado de las vistas de archivos en la cache del sistema que incluye
para cada VACB:
La segunda es una estructura que relaciona el objeto archivo con la cache, indicando qu
vistas del objeto estn presentes en la cache. Se denomina Apuntadores a secciones de objetos y
es una estructura del sistema a la que pueden apuntar varios objetos archivo, propiciando as el
uso compartido y coherente de las vistas. A travs de esta estructura, la tabla de objetos archivo en
el sistema enlaza con la cache.
La tercera estructura de datos es una lista doblemente encadenada que se denomina
Mapa compartido de cache. Cada entrada de esta lista muestra el mapa de un archivo cuyos datos
estn presentes en la cache. Para ello se incluyen en dichas entradas datos como un contador de
aperturas, el tamao del archivo o el conjunto de VACB del archivo presentes en la cache. A travs
de los VACB se enlaza con la primera estructura de datos.
Para la gestin de la cache descrita se aplica poltica de escritura retrasada perezosa y
semntica de coherencia tipo UNIX. La primera consiste en acumular los datos de escritura en
memoria hasta que son volcados a disco por un thread del sistema, denominado escritor perezoso,
de forma agrupada para reducir el nmero de operaciones de escritura. Este thread est controlado
por el gestor de memoria virtual, que lo arranca cuando necesita memoria, cuando el nmero de
pginas escritas sobrepasa un cierto nmero o de forma peridica cada segundo. En este ltimo
caso, se vuelcan a disco una cuarta parte de las pginas que han sido escritas. Cmo se calcula
este valor? Cuando arranca el sistema, en funcin de la memoria RAM disponible y de las opciones
de configuracin del sistema operativo (cache estndar, grande, servidor, etc.), se calcula un
umbral de escritura que sirve como referencia al gestor de memoria. La semntica de tipo UNIX
permite que cada proceso vea siempre la versin ms reciente de los datos. El gestor de memoria
virtual es el encargado de proporcionar esta semntica, para lo que mantiene siempre una nica
copia de los datos en memoria fsica a la que apuntan las tablas de pginas de los objetos que
comparten el archivo.
Las polticas anteriores son las que se instalan por defecto en el sistema. Sin embargo,
Windows NT es muy flexible y permite elegir para cada archivo desde una poltica de escritura
inmediata hasta no hacer uso de la cache, pasando por no volcar nunca los datos a disco.
Uno de los principales objetivos de diseo de Windows NT era su compatibilidad con entornos de
ejecucin provistos anteriormente por Microsoft (como MS-DOS o Windows 3.x) y con otras
interfases de sistemas operativos (como POSIX u OS/2). La solucin adoptada para proporcionar
esta compatibilidad fue el uso de entornos virtuales, implementados como procesos de Windows
NT que emulan el entorno de cada sistema operativo especfico. Estos componentes, que se
denominan subsistemas de entorno de ejecucin, se relacionan entre s y con el sistema como se
muestra en la Figura 12.13. Actualmente, Windows NT proporciona los siguientes entornos:
Subsistema OS/2.
Subsistema POSIX.
Subsistema Win32.
Mquinas virtuales para emular el entorno de MS-DOS y aplicaciones de Windows 3.x de
16 bits (Win16).
Subsistema de seguridad.
Como se puede ver, cada entorno es un proceso independiente que ejecuta en modo
usuario, por lo que su fallo no afectar a otros subsistemas o al sistema operativo. Todos ellos son
opcionales excepto el subsistema de Win32, que es la interfaz mnima que necesita el sistema
operativo para manejar teclado, ratn y pantalla.
El subsistema de Win32 es la interfase que controla toda la interaccin con los usuarios.
Entre sus funciones principales se encuentran la implementacin de colas de E/S para los
dispositivos que maneja el usuario y la creacin de objetos, para lo que interacciona con
Figura 12.13. Visin conceptual de los subsistemas de entorno de ejecucin. (Fuente: Microsoft
Windows NT ServerResource Kit, Copyright 2000 by Microsoft Corporation.)
prcticamente todos los componentes del ejecutivo de Windows NT. Los otros subsistemas
contactan con l para llevar a cabo las dos tareas anteriores. Cuando se crea un proceso se lo
indican al subsistema de Win32, que se encarga de contactar con el gestor de objetos para crear el
objeto de tipo proceso, con el gestor de procesos para crear el bloque descriptor del proceso, con
el gestor de memoria virtual para cargar el ejecutable, etc. Cuando se carga el ejecutable
comprueba a qu tipo de entorno de ejecucin pertenece y, si no est activo, lo arranca. Adems
contacta con las utilidades de llamadas a procedimiento lo local para crear los suplentes
necesarios para el proceso y con el gestor de E/S para habilitar puertos de comunicacin con dicho
proceso. Las aplicaciones de tipo Win32 disponen de una cola especfica para E/S asncrona,
mientras las de otros entornos se reconducen a travs de una nica cola por entorno.
ACLARACIN 12.3
Todas las llamadas al sistema mostradas en captulos anteriores, para el caso del sistema
operativo Windows NT, se refieren al subsistema de entorno de ejecucin de Win32. Sin embargo,
las llamadas de POSIX mostradas son perfectamente compatibles con el subsistema POSIX 1 que
incorpora Windows NT.
Windows NT permite la existencia de varios tipos sistemas de archivos, ya que su diseo modular
le capacita para incluir sin ningn problema todos los tipos de sistemas de archivos que desee el
usuario. El origen de los sistemas de archivos de Windows NT est en lograr la compatibilidad con
Estos sistemas de archivos usan la FAT (File Allocation Table) como medio para representar los
archivos. Cada archivo es una lista enlazada de bloques de la FAT, como se vio en el Captulo 8.
Los sistemas de archivos de este tipo se usan habitualmente a travs del subsistema de entorno
de MS-DOS y proporcionan direccionamiento con 16 bits, permitiendo particiones de hasta 32 MB.
Para incrementar su capacidad de direccionamiento se usan agrupaciones de bloques, como se vio
en el Captulo 8, y en la ltima versin de Windows NT se ha incluido el sistema de archivos FAT
para 32 bits.
La Figura 12.14 muestra la estructura de un sistema de archivos tipo FAT. En primer lugar
se encuentra el bloque de carga de la particin con los parmetros que le indican a la BIOS dnde
se encuentra el sistema operativo en caso de que sea una particin activa. A continuacin hay dos
copias de la informacin de la FAT. La segunda es redundante y se incluye para dotar con ms
tolerancia a fallos al sistema de archivos, ya que en caso de fallo de acceso a la FAT gran parte de
los archivos quedaran inaccesibles. El tamao que ocupa la FAT puede ser considerable. Para un
disco de 8 GB, usando direcciones de bloque de 32 bits y bloques de 4 KB, sera necesaria una
FAT de 8 MB. El tercer componente del sistema de archivos es el directorio raz, que incluye una
entrada de 32 bytes para cada directorio del sistema, a travs de la cual se puede acceder a
subdirectorios y archivos. En el Captulo 8 se coment en detalle el formato de esta entrada de
directorio. Los bloques restantes del sistema de archivos constituyen la denominada rea de datos
o de archivos, es decir, los bloques que contienen los datos de los archivos.
El sistema de archivos tipo FAT presente en Windows NT tiene varias mejoras respecto a
los que haba en MS-DOS y Windows 3.x:
La gran desventaja de esta solucin es que la FAT puede ocupar mucho espacio si el
dispositivo es grande. Ya hemos visto que un volumen de 8 GB, con 4 KB como tamao de bloque,
necesitara una FAT de 8 MB. Para buscar un bloque de un archivo muy disperso podra ser
necesario recorrer toda la FAT y, por tanto, tener que traer todos los bloque de la FAT a memoria.
Figura 12.14. Un sistema de archivos tipo FAT. (Fuente: Microsoft Windows NT ServerResource
Kit, Copyright 2000 by Microsoft Corporation.)
Los sistemas de archivos tipo FAT fueron diseados pensando en accesos secuenciales y en
volmenes pequeos. Con la incorporacin del entorno de OS/2 se vio que era necesario disponer
de un tipo de sistemas de archivos que pudiese gestionar volmenes ms grandes de forma ms
eficiente. Para lograr este objetivo, se disearon los Sistemas de archivos de alto rendimiento
(HPFS, High Performance File System).
Los HPFS tienen una estructura completamente distinta a la de la FAT (Fig. 12.15) ya que
el volumen se divide en bandas, cada una de las cuales tiene su propio mapa de bits junto a ella.
Cuando se da formato a un volumen, se reservan 18 sectores para el bloque de carga, el
superbloque y un bloque de repuesto, que sirve para duplicar el superbloque y aumentar la
tolerancia a fallos. A partir de estos bloques se colocan las bandas, definidas por espacios de 16
MB para datos y 2 KB para mapas de bits de la zona de datos adjunta. Los mapas de bits se
colocan a los extremos de las bandas, pero de Forma alternativa para permitir una zona de datos
contiguos de hasta 16 MB. Esta idea, muy similar a la de los grupos de cilindros del FFS de UNIX
(Captulo 8), permite reducir la zona de bsqueda de los archivos, pero presenta problemas de
fragmentacin de las bandas y de extensin de los archivos. Qu ocurre si un archivo no cabe en
una banda de 16 MB? La solucin de HPFS es buscarle un hueco adecuado, para lo que mantiene
listas de huecos en memoria.
Figura 12.15. Un sistema de archivos tipo HPFS. (Fuente: Microsoft Windows NT ServerResource
Kit, Copyright 2000 by Microsoft Corporation.)
Estas listas se elaboran cuando se abre el sistema de archivos y se mantienen actualizadas con
las operaciones de creacin y borrado de archivos.
El sistema de archivos tipo HPFS presente en Windows NT tiene varias mejoras respecto a
los sistemas de archivos de tipo FAT:
1. Fragmentacin externa, cuya incidencia depende del tamao de archivo de los usuarios y
de su disposicin en las bandas.
2. Asignacin de espacio usando sectores de disco como unidad de asignacin. Esto con
lleva que la mayora de los bloques lgicos se compondrn de varios sectores y que el
sistema de archivos se debe encargar de ocultar estos detalles. Por tanto, si se quiere
tener bloques mayores de un sector, o agrupaciones de sectores, es necesario gestionarlo
en la capa del gestor de archivos.
PRESTACIONES 12.3
Resolver la fragmentacin no es sencillo debido a que las polticas de asignacin que tratan de
llevar a cabo ajustes ptimos de huecos son muy lentas. La solucin ms plausible es ejecutar de
forma peridica algn thread de desfragmentacin del disco para compactar las bandas.
12.7.3. NTFS
Los dos sistemas de archivos anteriores tienen serias limitaciones si se quieren usar en grandes
instalaciones, donde es necesario tener archivos de gran capacidad y muy eficientes. NTFS (NT
File System) es el sistema de archivos ms moderno de Windows NT e incluye soluciones de
diseo nuevas, lo que permite resolver los inconvenientes de los sistemas anteriores y
proporcionar una combinacin de rendimiento, fiabilidad y compatibilidad ausente en sistemas
anteriores. Es el sistema de archivos asociado al subsistema de entorno de Win32.
Las principales caractersticas de diseo de NTFS son:
Operaciones de alto rendimiento sobre archivos y discos muy grandes. Usa agrupaciones
como unidad de asignacin y 64 bits para numerar los bloques o grupos.
Nuevas caractersticas de seguridad, incluyendo ACL sobre archivos individuales.
recuperacin de archivos, integridad de datos, etc. Toda la seguridad se gestiona a travs
del monitor de referencia de seguridad de Windows NT.
Implementacin de todos los componentes del volumen como objetos archivos (concepto
similar a UNIX) que tienen atributos de usuario y de sistema (nombre. tiempos. contenidos,
etctera).
Archivos con mltiples flujos de datos que pueden tener nombre (archivo: flujo) y ser
manipulados de forma totalmente independiente. Adems cada hijo tiene sus propios
atributos de tiempo, tamao, asignacin, etc. Esta caracterstica permite manejar como
nica unidad de datos relacionados (p. ej.: metadatos y datos) aunque estn en
dispositivos distintos.
Para satisfacer estos objetivos de diseo, el sistema de archivos y los archivos de NTFS
tienen una estructura muy distinta de tos de tipo FAT o HPFS. A continuacin se describen ambas
brevemente.
Un sistema de archivos de NTFS es una organizacin lgica que permite almacenar archivos de
tipo NTFS en un volumen de disco. Un volumen no es sino una forma de combinar mltiples
fragmentos de disco para formar una unidad lgica. En el caso de Windows NT, un volumen puede
tener hasta 32 extensiones, pertenecientes a uno o ms discos. Sobre estos volmenes se crea un
sistema de archivos de NTFS, cuya estructura (Fig. 12.16) se describe en un registro de un archivo
especial contenido al principio del volumen que se denomina MFT (Master File Table). Se puede
pues decir que el sistema de archivos de NTFS es nicamente un archivo, en el que los primeros
16 registros contienen informacin especial del sistema. A continuacin hay una copia de repuesto
del MFT, del cual hay otra copia redundante en el centro del volumen para incrementar la
tolerancia a fallos. En caso de volmenes extendidos a mltiples particiones o discos, estos datos
del MFT estn repetidos en todas las particiones para permitir interpretar el sistema de archivos
desde cualquiera de ellos.
Figura 12.16. Master File Table. (Fuente: Microsoft Windows NT ServerResource Kit, Copyright
2000 by Microsoft Corporation.)
A continuacin, hay dentro del MFT varios archivos de metadatos, que incluyen:
Registro dog), usado para almacenar todas las operaciones que afectan a los metadatos
del sistema de archivos. Bsicamente es un registro transaccional que usa el Log File
System para recuperar el sistema de archivos en caso de fallo.
Volumen, que incluye informacin de los atributos del volumen (nombre, versin, creador,
fechas, etc.).
Definicin de atributos, con los nombres de atributos y los valores definidos en el
volumen, as como definiciones de lo que significa cada atributo.
Directorio raz (\) del sistema de archivos, con informacin acerca de los archivos y
directorios que cuelgan directamente de la raz.
Mapa de bits del volumen, con un bit por cada grupo de bloques (cluster) que indica si
est libre o asignado a un archivo.
Carga, con el programa cargador para el volumen, en caso de que sea un dispositivo de
arranque. En otro caso existe igualmente, pero est vaco.
Grupos defectuosos (bad clusters), que contiene una lista de los bloques defectuosos y
su posicin en el volumen. Este archivo se genera cuando se da formato a la particin del
volumen o cuando se comprueba la situacin de la superficie del disco (p. ej.: con chkdsk).
Estos archivos estn ocultos y se denominan habitualmente archivos de sistema porque son
usados por el sistema de archivos para almacenar los metadatos y otros datos de gestin o control
del mismo.
A continuacin, desde el registro 17 en adelante, se incluyen los archivos y directorios de
usuario en el volumen. Para optimizar los accesos a disco se distingue en NTFS entre archivos y
directorios pequeos, existiendo dentro de la MFT un archivo para describir cada uno de estos
tipos, incluyendo una entrada distinta para cada extensin, en caso de que existan extensiones. La
razn para esta distincin es que un registro de MFT puede almacenar:
La Tabla 12.1 resume las caractersticas principales de los tres sistemas de archivos descritos y
existentes en la ltima versin de Windows NT.
La seguridad se incluy como parte de las especificaciones de diseo de Windows NT, lo que
permite lograr un nivel de seguridad C2 si se configura el sistema adecuadamente. El modelo de
seguridad incluye componentes para controlar quin accede a los objetos, qu accesos pueden
efectuar los usuarios sobre un objeto y qu eventos se auditan. Todos estos componentes juntos
forman el subsistema de seguridad de Windows NT. Varios componentes del cual se ejecutan en
modo ncleo para tener acceso a informacin interna de seguridad del sistema operativo de forma
controlada. Esta filosofa permite aplicar los mismos procedimientos de seguridad a todos los
objetos del sistema operativo.
Como se muestra en la Figura 12.17, el modelo de seguridad de Windows NT incluye los
siguientes componentes:
Procesos de logon, que muestran las ventanas de dilogo para que los usuarios puedan
acceder al sistema, piden el identificador del usuario, su palabra clave y su dominio.
Autoridad de seguridad local, que controla que el usuario tenga permiso para acceder al
sistema. Es el corazn del sistema porque gestiona la poltica local, los servicios de
autenticacin, poltica de auditoria y registro de eventos auditados.
Gestor de cuentas de usuario, que mantiene las base de datos de usuarios y grupos.
Proporciona servicios de validacin de usuarios.
Monitor de referencia de seguridad, que controla los accesos de los usuarios a los objetos
para ver si tienen los permisos apropiados aplicando la poltica de seguridad y genera
eventos para los registros de auditora. Estos registros permiten al administrador seguir la
pista a las acciones de los usuarios y detectar posibles violaciones de seguridad.
El modelo de seguridad mantiene informacin de seguridad para cada usuario, grupo y objeto
del sistema y proporciona control de acceso discrecional para todos los objetos. Puede identificar
accesos directos de un usuario y accesos indirectos a travs de procesos que ejecutan en
representacin del usuario. Permite a los usuarios asignar permisos a los objetos de forma
discrecional, pero si el usuario no asigna estos permisos, el subsistema de seguridad asigna
permisos de proteccin por defecto. Cada usuario se identifica en este sistema mediante un
identificador de seguridad nico (SID, Security ID) durante la vida del usuario dentro del sistema.
Cuando un usuario accede al sistema, la autoridad de seguridad local crea un descriptor de
seguridad para acceso, lo que incluye una identificacin de seguridad para el usuario y otra para
cada grupo al que pertenece el usuario. Adems, cada proceso que ejecuta en nombre del usuario
tiene una copia de descriptor de seguridad del usuario.
usuario que incluye su identificador de seguridad, los grupos a los que pertenece, sus privilegios,
grupo primario y enlace con su lista de control de acceso. Cuando el usuario quiere acceder al
sistema introduce su contrasea a travs de un proceso logon. Dicha contrasea se pasa al
subsistema de seguridad, que verifica la identidad del usuario y, en caso positivo, construye una
ficha de acceso para el usuario. Este objeto sirve como identificador oficial del proceso siempre
que el usuario intente acceder a un recurso a partir de ese instante. La Figura 12.18 resume los
atributos y servicios de este tipo de objeto, as como un ejemplo de icha de acceso en Windows
NT.
Habitualmente, cuando un usuario quiere acceder al sistema teclea CTRL-ALT-DEL. Esta
combinacin de teclas activa el proceso de logon, que presenta una pantalla o mensaje de entrada
(paso 1 de la Figura 12.19) que pide tres valores:
Si hay error al introducir la clave durante un cierto nmero de veces, definido por el
administrador del sistema, una medida habitual es bloquear la cuenta y notificar la situacin al
administrador de seguridad del sistema. En ambos casos se trata de evitar que los programas que
intentan adivinar las claves del sistema se puedan ejecutar de forma normal o que lo tengan que
hacer de forma tan lenta que tal deteccin sea inviable.
Tras capturar los datos del usuario, el proceso de logon (paso 2) se los enva al
subsistema de seguridad, que activa el paquete de autenticacin adecuado de entre los
existentes (pas 3). La misin de estos componentes es contrastar los datos de seguridad de los
usuarios con los existentes en la base de datos de seguridad (paso 4). En caso de usuarios
remotos es necesario contactar con el subsistema remoto adecuado. De cualquier forma, si los
datos son satisfactorios, el gestor de la base de datos de seguridad devuelve el SID del
usuario (paso 5). En caso contrario devuelve un error de validacin. Con estos datos, el paquete
de autenticacin crea un identificador de seguridad para la sesin y se lo pasa, junto con el SID,
al subsistema de seguridad (paso 6). ste comprueba que los datos sean vlidos, crea un
descriptor de acceso con los datos anteriores y se lo pasa al proceso de Iogon (paso 7). En
caso de error notifica el error al proceso de logon, y borra los datos de la sesin.
Por ltimo, el proceso de logon abre una ventana grfica en la que indica al usuario que el acceso
ha sido concedido, en cuyo caso arranca el Program Manager, o denegado.
Una vez identificado y autenticado el usuario, cada vez que intenta acceder a un objeto
protegido el Monitor de Referencia de Seguridad ejecuta procedimientos de validacin de acceso
en los que se comprueba si los permisos del usuario son suficientes para acceder al objeto. Estas
rutinas de validacin incluyen comprobaciones del descriptor de seguridad para comprobar la
identidad y de las entradas de la lista de control de accesos asociada al objeto para ver si tiene una
entrada (ACE, Access Control Entry) en la que permita al usuario efectuar la operacin solicitada.
Si la comprobacin no es satisfactoria, se deniega el acceso al objeto.
Todos los objetos de Windows NT tienen asignados descriptores de seguridad como parte de sus
fichas de acceso. La parte ms significativa de los descriptores de seguridad es la lista de control
de acceso. Normalmente, slo el dueo del objeto puede modificar los derechos de la ACL para
permitir o denegar el acceso al objeto. Cada entrada de la ACL contiene los descriptores de
seguridad de los distintos dominios del sistema y los derechos de uso del objeto. El criterio de
asignacin de derechos en la ACL de un objeto nuevo en Windows NT es el siguiente:
Estndar, que se aplican a todos los objetos (sincronizacin, dueo, escritura en ACL,
borrado, etc.).
Especficos, que slo se aplican a un tipo de objeto determinado. Por ejemplo, para un
objeto archivo, estos derechos incluyen permiso de lectura, de escritura, de ejecucin, para
aadir datos, etc.
Todos estos valores se rellenan cuando se crea un objeto con los valores que proporcione su
creador, con valores heredados de la clase del objeto o con unos valores por defecto del sistema.
Adems, se pueden modificar dinmicamente usando los servicios de seguridad de Win32.
El sistema operativo Windows NT incluye varios mecanismos para proporcionar tolerancia a fallos,
algunos de los cuales se han mencionado ya. Estos mecanismos permiten salvaguardar el estado
del sistema y de los datos para protegerlos ante fallos de dispositivos de almacenamiento.
Los principales mecanismos de tolerancia a fallos son:
Discos espejo.
Discos con reparto de datos cclico y paridad nivel RAID 5.
Duplicacin de discos.
Las utilidades para hacer copias de respaldo estn pensadas para los administradores de
sistema, ya que permiten hacer copias masivas de datos a cintas magnticas de forma muy
sencilla. Es similar a las utilidades de backup existentes en UNIX pero con una interfaz ms
amigable. Permiten hacer copias totales o parciales de volmenes o cuentas de usuario.
Para dotar con capacidades de recuperacin a los sistemas de archivos de Windows NT,
NTFS incluye procesamiento transaccional de las peticiones que afectan a los metadatos de los
sistemas de archivos. Con esta facilidad, todas las operaciones de este estilo se almacenan en un
registro dog) de forma que si el sistema falla se pueda volver a un estado coherente usando la
informacin de dicho registro. Este archivo de registro se gestiona mediante un conjunto de rutinas
internas al ejecutivo denominadas LFS dog File Services). Para asegurar la coherencia de los
sistemas de archivos se usan tcnicas de escritura cuidadosa con verificacin en el registro y en
los sistemas de archivos, de forma que las operaciones se reflejan primero en el registro y luego en
el sistema de archivos. Ambas operaciones se hacen primero en la cache, por lo que el gestor de
cache escribe inmediatamente los datos del registro a la zona del disco donde se guarda dicho
registro.
Los discos espejo son una tcnica de tolerancia a fallos muy popular y sencilla de
implementar. pero costosa y poco eficiente. Consiste en tener dos volmenes idnticos y actualizar
los datos de forma cuidadosa en ambos. Una escritura no se valida hasta que no se ha hecho en
los dos discos. Las lecturas, sin embargo, son vlidas desde cualquiera de ellos. Las
actualizaciones se mantienen coherentes en ambos discos de forma transparente al usuario.
La tcnica ms actual de tolerancia a fallos consiste en usar dispositivos tipo RAID 5 a
nivel software. Con esta tcnica se usa un conjunto de discos para almacenar la informacin de los
usuarios y la informacin de paridad del conjunto anterior como si fueran un nico disco lgico. Los
datos se reparten en grupos, cada uno de los cuales se escribe a un disco. Cuando se ha escrito
un bloque en cada disco, se calcula su paridad y se almacena en el disco siguiente (disk striping
with parity). Para que todos los datos de paridad no estn en el mismo disco, se almacenan de
forma cclica en discos distintos. Este mecanismo necesita un mnimo de tres discos y gestiona un
mximo de 32 discos, que pueden estar en el mismo controlador o en controladores distintos.
PRESTACIONES 12.4
La escritura de datos con paridad conlleva el coste del clculo de la misma, lo que puede ser
oneroso en caso de escrituras que no llenan todos los discos (escrituras pequeas). Por ello, este
mtodo se ajusta mejor a archivos con unidades de escritura grandes.
Los lectores interesados en saber ms sobre Windows NT y Windows 2000 disponen actualmente
de muy buena documentacin. En esta relacin de lecturas recomendadas se incluyen un conjunto
seleccionado de libros que permitirn al lector interesado profundizar en este tema.
Para ampliar conocimientos sobre la estructura general del sistema operativo, se
recomiendan los libros de Solomon [Solomon, 1998], Pearce [Pearce, 1977], Martnez [Martnez,
1999] y Custer [Custer, 1993].
Para profundizar ms en aspectos de sistemas de entrada/salida y dispositivos, se
recomiendan los libros de Baker [Baker, 1997] y Dekker [Dekker, 1999].
Para sistemas de archivos y directorios se puede acudir a los libros de Custer [Custer,
1995], Mitchell [Mitchell, 1977], Nagar [Nagar, 1977] y Lowe-Norris [Lowe-Norris, 2000].
Para aspectos concretos del sistema de seguridad se puede consultar el libro de lvens [lvens,
2000].
La programacin de aplicaciones sobre sistemas operativos supone conocer y usar las bibliotecas
con las llamadas al sistema operativo. Para hacer una aplicacin con llamadas al sistema operativo
es necesario indicar en los programas los archivos con:
La definicin de prototipos y tipos de datos, por ejemplo <windows.h>, para que puedan
compilarse los mdulos del programa, as como el directorio, o directorios, en que se
encuentran
Los archivos de bibliotecas del sistema que deben enlazarse con la aplicacin para crear
un archivo ejecutable, incluyendo el camino donde localizar dichas bibliotecas.
Las opciones de compilacin que deben activarse para compilar y enlazar la aplicacin.
El Listado B.1 contiene el makefile del programa Reloj, que especfica cmo construir el ejecutable
reloj. Por convencin, una especificacin de makefile se almacena tpicamente en un archivo
llamado Makefile o makefile. Para ejecutar el programa make y construir una aplicacin, slo
hay que teclear el mandato make dentro de un intrprete de mandatos (shell). El programa make
busca en el directorio actual un archivo llamado Makefile o makefile y lo procesa.
#
# Las siguientes lneas especifican que los archivos de C
# tendrn una extensin c.
.SUFFIXES:
.SUFFIXES:.c $(SUFFIXES)
CC = gcc
# Asignar a DIR_APOYO la ruta del directorio que contiene
# los directorios del material de apoyo.
# Las bibliotecas del sistema se incluyen por defecto.
DIR_APOYO = ./apoyo
#
# La variable CFLAGS especifica dnde encontrar
# los archivos a incluir desde el material de apoyo.
.c.o:
$(CC) $(CFLAGS -c $<
LDFLAGS = L$ d){DIR_APOYO)/lib
#
# La variable LIBS especifico al compilador qu bibliotecas
# de archivos objeto se deben usar para construir la aplicacin, adems
# de las del sistema.
#
LIBS = -lapoyo
#
# La variable OBJS especfica al compilador qu archivos
# objeto se deben crear para construir la aplicacin
reloj: $(OBJS)
$(CC) $(OBJS) $[LDFLAGS) $[LIBS) -o reloj
reloj.o: reloj.h
clock_task.o: reloj.h
hardware.o: reloj.h
Para compilar en UNIX O LINUX hay que ir aI directorio donde se encuentra el makefile de
la aplicacin y ejecutar el mandato make, como se muestra en la Figura 13.1.
SUFFIXES:
SUFFIXES: .c $(SUFFIXES)
Algunos lenguajes, por ejemplo C++, esperan archivos que tengan la extensin .cpp o .cc. Si
esto es lo que sucede, se debera cambiar el .c de la segunda lnea a .cpp o .cc, o aadir dichos
sufijos a la lnea de definicin. Todos los archivos de C proporcionados en este libro tienen la
extensin .c.
La siguiente lnea define el compilador que se debe usar para compilar los programas:
CC = gcc
En este ejemplo se asigna a la variable CC el nombre del mandato que corresponde con el
compilador de C que traduce el cdigo fuente. En este fragmento se le da el valor gcc que es el
compilador de GNU para el lenguaje C en UNIX y LINUX.
La lnea:
asigna la ruta que se corresponde con los directorios de inclusin y de la biblioteca del material de
apoyo para la construccin del programa reloj. Es siempre mejor usar variables relativas a la
situacin del programa a construir, porque as se puede instalar la aplicacin en distintos
directorios cada vez sin que haya que modificar el archivo makefile.
La lnea:
CFLAGS= -I $(DIR_APOYO)
establece una variable que informa al compilador de C dnde debe buscar los archivos de inclusin
del material de apoyo del usuario y los del sistema. Adems de buscar en este directorio, el
compilador siempre busca en los directorios del sistema, que suelen ser /usr/include y sus
subdirectorios.
De manera similar la asignacin siguiente:
define una variable que informa al cargador de UNIX, ld, dnde debe buscar los archivos de
biblioteca. Adems de buscar en este directorio, el compilador siempre busca en los directorios del
sistema, que suelen ser /usr/lib y sus subdirectorios.
La variable LIBS especifica al compilador qu bibliotecas de archivos objeto se deben usar
para construir la aplicacin.
LIBS= -lapoyo
.c.o:
$(CC) $ (CFLAGS) c $<
son una regla de dependencia implcita que especifica que un tipo de archivo se construye a partir
de otro y describe cmo rechazar su construccin. En este ejemplo, las lneas anteriores
especifican que los archivos .o se construyen a partir de los archivos .c mediante el compilador de
C.
La asignacin siguiente:
da valor a la variable OBJS con los nombres de los archivos objeto que forman la aplicacin. La
aplicacin reloj tiene tres mdulos objeto de aplicacin: reloj.o, clock_task.o y hardware.o. Para
una aplicacin diferente habra que modificar esta lnea para asignar a OBJS los mdulos objeto de
dicha aplicacin.
El siguiente conjunto de lneas es el corazn del ,makefile. Estas lneas son reglas de
dependencia que especifican Cmo construir la aplicacin. Por ejemplo, las siguientes lneas:
reloj: $(OBJS)
$(CC) $(OBJS) $(LDFLAGS) $(LIBS) -o reloj
del ,makefile de Reloj especifican que reloj depende de OBJS, que tiene el valor reloj.o,
clock_task.o y hardware.o. Adems depende de LIBS, que tiene el valor libapoyo.a. Si
cualquiera de estos archivos objeto es ms reciente que reloj, make ejecuta la lnea de mandato
que produce una nueva versin de reloj ms reciente que los archivos objeto. Si lodos los archivos
objeto son ms antiguos que reloj, significa que reloj est actualizado y, por lo tanto, no se necesita
realizar ninguna accin.
Despus de que se hayan construido todos los archivos objeto necesarios, su fecha de
actualizacin ser ms reciente que la de reloj, por lo que se ejecuta el mandato que construye
reloj.
La lista completa de opciones del programa make se puede obtener mediante el siguiente
mandato:
man make
Para ejecutar una aplicacin en UNIX basta con teclear el nombre de la aplicacin en el prompt del
intrprete de mandatos (Fig. B.2).
Existe en UNIX y LINUX una utilidad para la creacin y mantenimiento de bibliotecas de archivos.
Su principal uso es crear bibliotecas de objetos, es decir, agrupar un conjunto de objetos
relacionados dentro una entidad lgica que se puede usar como un elemento de compilacin.
En la lnea de compilacin se especifica la biblioteca (por convencin libnombre.a) en vez
de los objetos que hay dentro de ella. El enlazador extraer de la biblioteca los objetos que
contienen las variables y funciones requeridas y los insertar dentro del programa ejecutable o
incluir referencias dinmicas a dichos objetos.
Formato del mandato:
ar -tv /usr/lib/libc.a
Creacin de una biblioteca con objetos que manejan distintas estructuras de datos.
Creacin de la biblioteca con material de apoyo que incluye el objeto del programa que
simula el dispositivo reloj.
Hay dos formas posibles de compilar un programa que use una biblioteca: con nombre absoluto y
con nombre relativo. En este ltimo caso es necesario tener una variable de entorno para indicar
dnde est la biblioteca, como se ha hecho en el makefile anterior. A continuacin, se muestran
ejemplos de uso de ambas formas:
En todas las versiones del sistema operativo UNIX, incluyendo LINUX, existe un programa de
depuracin de programas. En el caso de LINUX existe un depurador denominado gdb. El
depurador permite que el usuario pueda controlar la ejecucin de un programa y observar su
comporta miento interno mientras ejecuta. Estos programas son muy tiles cuando se programa o
prueban aplicaciones, como las prcticas de alumnos. Su uso puede ahorrar mucho tiempo de
desarrollo y facilitar la tarea de los programadores.
Para poder depurar un programa, el compilador debe incluir informacin especial dentro del
mismo. Por ello, para poder depurar un programa compilado con el gcc, se debe compilar con la
opcin -g.
A continuacin se describen algunas de las Funciones de un depurador genrico:
gdb programa_ejecutable
En el caso del makefile del ejemplo se ha creado un ejecutable denominado reloj. Para
depurarlo habra que ejecutar el mandato:
gdb reloj
El primer paso para crear un archivo de proyecto para una aplicacin de Sistemas Operativos es
crear un espacio de trabajo y un proyecto, mediante el men: File ->New. Dentro de la caja de
dilogo New debe especificarse el tipo de aplicacin que se est construyendo. La eleccin
correcta depende de que la aplicacin requiera una consola. Cualquier aplicacin de Sistemas
Operativos c acepte entrada de teclado del usuario mediante el objeto de iostream cin o escriba
en la pantalla mediante el objeto de iostream cout requiere una consola. Para este tipo de
aplicacin de Sistemas Operativos la seleccin apropiada es Win32 Console Application. Si la
aplicacin no utiliza la biblioteca iostream, la seleccin apropiada es win32 Application.
El paso final es especificar la posicin del proyecto. En el ejemplo se quiere que el
proyecto resida en c:\jesus\docencia\sos2\apendice2\reloj, por lo que habr que navegar
hasta c:\jesus\docencia\sos2\apendice2\reloj y teclear reloj en el campo Project name:. Para
crear el proyecto se debe pulsar el botn OK.
Para compilar el archivo reloj.c slo hay que indicarlo en la opcin Build, que se muestra
en la Figura B.4.
Figura B.6. Caja de dilogo Insert Files into Project del Visual C++ de Microsoft
consigue mediante el mandato: Tools ->Options. Para ello se ejecuta el men Show directories
for-> Include files, y se teclea la ruta en la ventana Directories. En el ejemplo del reloj, esta ruta
es c:\jesus\docencia\sos2\apendice2\reloj.apoyo. El valor por defecto del campo Directorias indica
la posicin de los archivos de inclusin del sistema. La Figura B.7 muestra la caja de di Options
despus de que se ha aadido la entrada del directorio de inclusin del programa reloj. De igual
manera se puede definir el directorio para la biblioteca de apoyo, pero usando el men Show
directories for -> Libraries.
Para compilar y enlazar la aplicacin se usa el men: Build -> BuiId reloj.exe. Este
mandato hace que se compilen todos los mdulos que han cambiado desde la ltima compilacin y
que despus se enlacen todos los archivos objeto y las bibliotecas pedidas en una unidad
ejecutable. El ejecutable se escribe en el archivo reloj .exe puesto que se es el nombre del
proyecto.
Para ejecutar una aplicacin utilizando el C++ de Microsoft existen dos opciones:
Para ejecutar desde el entorno de Visual C++, lo nico que hay que hacer es ejecutar la
opcin: Build ->Execute reloj.exe Este mandato solicita al entorno que ejecute el archivo
reloj.exe usando para ello todos los recursos que sean necesarios. Si se usa entrada/salida por
consola, se abre una ventana consola. La Figura B.8 muestra la ventana Build y la opcin a usar
para ejecutar el archivo reloj .exe.
La otra opcin es ejecutar el programa desde una ventana consola o de MS-DOS, que se
puede crear activando el icono de MS-DOS en el men Inicio. Una vez en la ventana consola, se
debe cambiar el directorio a la posicin del ejecutable de la aplicacin y a continuacin ejecutar la
aplicacin tecleando su nombre.
Depurar una aplicacin utilizando el C++ de Microsoft, usando el entorno de Visual C++, es real
mente fcil. Hay dos opciones bsicas:
La primera es ms aconsejable, porque en este caso se puede estar seguro de que no hay
errores de en lazado.
Para ejecutar desde el entorno de Visual C++, lo nico que hay que hacer es ejecutar la opcin:
Build -> Start Debug. Este mandato solicita al entorno que ejecute el archivo reloj .exe de forma
controlada por el depurador (Fig. B.9). Cuando se ejecuta esta opcin, aparece una nueva ventana
que permite ejecutar el programa de forma continua (Go), ejecutar hasta donde est el cursor (Run
to cursor) o pararse en una llamada a funcin y saltar dentro del cdigo fuente de la misma (Step
into). Con estas tres llamadas bsicas se puede controlar la ejecucin del programa.- Los errores
salen en la pantalla de debajo del cdigo fuente, mientras que el flujo de ejecucin se controla en
esta ventana.
Las prcticas que se presentan en este apndice fueron diseadas como trabajos de laboratorio
para estudiantes de las asignaturas de Sistemas Operativos de la Universidad Politcnica de
Madrid y de la Universidad Carlos III de Madrid. Todas las prcticas se han desarrollado en uno u
otro entorno y fueron pensadas para ellos, por lo que es posible que existan todava en los
enunciados dependencias o referencias cercanas o derivadas de dichos en tornos. No obstante, se
ha hecho un importante esfuerzo para generalizar dichos enunciados. De forma que puedan
desarrollarse fcilmente sobre sistemas operativos de amplia difusin como Linux, UNIX o
Windows NT. De cualquier forma, es importante que los profesores que pretendan usar estos
trabajos de laboratorio revisen cuidadosamente cada uno de ellos y lleven a cabo una etapa previa
de adaptacin a sus entornos de prcticas. Esto evitar errores y confusin a los alumnos.
En casi todos los trabajos prcticos expuestos se hace referencia al material de apoyo
existente para las prcticas. Este material se puede conseguir en las pginas WWW del libro, cuya
referencia es: http://datsi.fi.upm.es/~ssoo-va y http://arcos.inf.uc3m.es/~ssoo-va
Los trabajos prcticos que se proponen en este apndice se describen brevemente a
continuacin:
En cuanto al lenguaje de programacin a utilizar para llevar a cabo los trabajos prcticos,
aunque se recomiendan los lenguajes C y C++, () es estrictamente necesario, ya que las prcticas
se pueden desarrollar en cualquier otro lenguaje. Es importante tener en cuenta que los materiales
de apoyo slo estn disponibles en lenguaje C.
El objetivo de esta prctica es familiarizarse con el intrprete de mandatos de UNIX que, adems
de ser la interfaz de usuario del sistema, ofrece una poderosa herramienta de programacin que
permite a los usuarios, tanto ordinarios como administradores, construir nuevos mandatos (shell-
scripts) sin tener que utilizar directamente los servicios proporcionados por el sistema operativo.
Un aspecto que conviene resaltar desde el principio es la dificultad de programacin en
este entorno. La sintaxis y el modelo de programacin son bastante inusuales, lo que hace un poco
difcil escribir los primeros programas. Sin embargo. El esfuerzo merece la pena puesto que
permite llegar a conocer mejor cmo funciona el sistema.
La prctica consiste en desarrollar un script denominado dirmix que lleve a cabo la unin del
contenido de un conjunto de directorios. El script recibir como argumentos:
Despus de la ejecucin de dirmix. En el directorio destino habr una copia de todos los
archivos (slo de los archivos, no de los directorios) de los directorios origen especificados,
teniendo en cuenta tambin los contenidos inicialmente existentes en el propio directorio destino.
Cada copia debe preservar las caractersticas del archivo original, tales como su propietario o las
fechas asociadas al mismo (mandato cp p). En el caso de que exista un archivo con el mismo
nombre en dos o ms de los directorios (incluyendo tambin el directorio destino), se aplicar el
criterio (le seleccin, que se recibe como primer argumento, para determinar cul (le ellos se copia
al directorio destino. De esta forma, el criterio de seleccin no est incluido en el script, sino que se
trata de un programa que ste recibe como argumento.
Como parte de la prctica se deber tambin construir un script. Denominado ms nuevo. Que
realice la seleccin teniendo en cuenta la fecha de ltima modificacin (le los archivos.
Descripcin de masnuevo
Este script recibir como argumentos los archivos a los archivos se pretende aplicar el criterio de
comparacin y escribir por su salida estndar cul ha sido el archivo elegido al aplicar el criterio
de seleccin correspondiente. El criterio consistir en seleccionar el archivo cuya fecha de ltima
modificacin sea ms reciente (una posible forma (le hacerlo es usando alguna (le las opciones del
mandato ls).
Descripcin de dirmix
Como se explic antes, despus de la ejecucin (le este mandato, en el directorio dir_dest deber
quedar tina copia de todos los archivos que haba inicialmente en cada dir_org junto con los que
haba en dir_dest habindose aplicado el mandato criterio para determinar cul debe copiarse en
caso de coincidencia de nombres.
El script dirmix deber:
C.1.5. Bibliografa
Esta prctica permite al alumno fan con los servicios para la gestin de procesos que
proporciona POSIX. Asimismo, se pretende que conozca cmo es el funcionamiento interno del un
intrprete de mandatos en UNIX/Linux.
Esta prctica cubre los objetivos de programacin de llamadas al sistema y del captulo de
procesos.
El alumno deber disear y codificar, en lenguaje C y sobre sistema operativo UNIX/Linux,
un programa que acte como intrprete de mandatos. El programa deber seguir estrictamente las
especificaciones y requisitos contenidos en este documento.
Con la realizacin de este programa el alumno adquirir valiosos conocimientos de
programacin en entorno POSIX. Tanto en el uso de las llamadas al sistema operativo (FORK,
EXEC, SIGNAL, PIPE, DUP, etc.), como en el manejo de herramientas como el visualizador de
pginas de manual man, el compilador de C gcc. el regenerador de programas make, etc.
Nota: Durante la lectura de este documento encontrar la notacin man -s# xxxxx. Que sugiere
usar el mandato man de UNIX/Linux para obtener informacin sobre la orden xxxxx de la seccin #.
Por favor, siga las recomendaciones.
Para obtener la lnea de mandatos tecleada por el usuario se recomienda proporcionar al alumno
una funcin obtain_order cuyo prototipo es el siguiente:
Para 1s -1 devuelve 2.
Para 1s | sort devuelve 3.
El argumento argvv permite tener acceso a todos los mandatos introducidos por el usuario.
Con el argumento f 11ev se pueden obtener los archivos utilizados en la redireccin:
Filev [0] apuntar al nombre del archivo a utilizar en la redireccin de entrada en caso de
que exista o NEJLL si no hay ninguno.
Filev [1] apuntar al nombre del archivo a utilizar en la redireccin (le salida en caso de que
exista o N U LL si no hay ninguno.
Filev [2] apuntar al nombre del archivo a utilizar en la redireccin (le la salida de error en
Caso de t exista o NULL S no hay ninguno.
Para desarrollar el minishell el alumno debe seguir una serie de pasos de tal forma que se
construyan el, minishell de forma incremental. En cada paso se aadir nueva funcionalidad sobre
el anterior.
1. Ejecucin de mandatos simples del tipo 1 s 1, who, etc. Para esta seccin deber usar
as llamadas al sistema fork, wait y execve.
cd [Cambia el directorio por defecto (man s2 chdir). Si aparece Directorio debe cambiar al
mismo. Si no aparece, cambia al directorio especificado en la variable de entorno HOME.
Presenta (por la salida estndar) como resultado el camino absoluto al directorio actual de
trabajo (man getcwd) con el formato: %s\n.
umask [Cambia la mscara de creacin de archivos (man s2 umask). Presenta (por la
salida estndar) como resultado el valor de la actual mscara con el formato: %o \n.
Adems, si aparece Valor (dado en octal, man strtol), cambia la mscara a dicho valor.
Para Facilitar la realizacin de esta prctica, se recomienda proporcionar a los alumnos un parser
que les evite tener que programar el suyo propio. Esto es importante, porque nuestra experiencia
nos dice que si no se proporciona dicho parser, los alumnos dedican la mayor parte del tiempo ha
programado y no se centran en los aspectos de sistemas operativos. En concreto, a nuestros
alumnos se les proporciona el siguiente cdigo de apoyo, que puede encontrarse en la pgina Web
del libro:
C.2.6. Bibliografa
Esta prctica permitir al alumno familiarizarse con los servicios que ofrece el estndar POSIX para
la gestin (le archivos y directorios.
Esta prctica cubre los conceptos del Captulo 8.
Programa copy
Programa mils
Si recibe la opcin a, mostrar todos los archivos, es decir, los ocultos y no ocultos.
Si se especifica la opcin -1, adems del nombre de cada archivo se imprimir en la misma
lnea algunos de sus atributos: su tipo (R para regular. 1) para directorio, C para un
dispositivo de caracteres, B para un dispositivo de bloques y F para un FIFO), el nmero
de enlaces, el tamao y la fecha del ltimo acceso. Para procesar este ltimo valor se
recomienda usar las funciones gmtime o localtime (se recomienda consultar el manual
interactivo del sistema para aclarar su uso: man gmtime o man localtime).
Se plantea una parte opcional que consiste en modificar el programa mil s anterior para que realice
un listado recursivo (opcin R) de todo el rbol de archivos y directorios que hay por debajo de
cada uno de los directorios que recibe como argumento.
Uno de los aspectos que hay que tener en cuenta a la hora de realizar el recorrido
recursivo es que se debe evitar atravesar los directorios. y . . presentes en todo directorio ya que
de hacerlo se entrara en un bucle infinito.
Para emular dentro de lo posible el comportamiento de este mandato en UNIX, el recorrido
del rbol se har como se describe a continuacin. No se realizarn las llamadas recursivas
correspondientes a los subdirectorios encontrados en un determinado directorio hasta que no se
haya tratado dicho directorio. Una posible forma de llevar a cabo este recorrido es utilizar una lista.
Cada vez que el programa encuentre un directorio, insertar su nombre en la lista. Cuando se haya
terminado de recorrer un determinado directorio, se comenzar con los directorios que se han
almacenado en la lista, cada uno de los cuales se recorrer a su vez de la forma descrita. A
continuacin se presenta un posible pseudo cdigo de dicho recorrido. Este pseudocdigo asume
la existencia de dos funciones, insertar y extraer. La primera introduce el nombre de un directorio
en la lista y la segunda lo extrae.
recorrido (root) {
para cada nodo que cuelgue directamente de roo {
visitar eL nodo;
if (nodo es un directorio)
insertar (nodo);
}
While (lista no sea vaca) {
extraer (&next)
recorrido(next)
}
}
Make file. Archivo fuente para la herramienta make. Con l Se Consigue la recopilacin
automtica de los archivos fuente cuando se modifiquen. Basta con ejecutar el mandato
make para que el programa se compile de forma automtica.
copia. Archivo fuente de C donde se incluir el programa copy.
mils.c. Archivo fuente de C donde se incluir el programa mus.
C.3.6. Bibliografa
En esta prctica se plantea como objetivo el manejo de las interrupciones del reloj de forma similar
a como lo hace un sistema operativo. Para ello se va a implementar un manejador de reloj. La
prctica se va a desarrollar sobre LINUX, lo que impone algunas restricciones, por lo que el
dispositivo reloj se va a simular con un proceso que emite seales peridicas, equivalentes a las
interrupciones del reloj real.
Sirve como trabajo prctico para el tema de entrada/salida.
La pieza esencial es el manejador de reloj que recibe las llamadas del manejador de
interrupcin y del programa de usuario, procesando las mismas de forma similar a como lo hace
LINUX. La idea fundamental de la prctica consiste en construir un manejador de reloj que permita
gestionar un reloj virtual en nuestra aplicacin y colas de temporizadores y ciclos. Cada
temporizador y ciclo puede tener asociado una funcin (especificable por el usuario), de forma que
cuando vence alguno de estos elementos se ejecuta la funcin asociada.
Cada vez q llega una interrupcin de reloj, se mira si tenemos un tick (unidad mnima) en el reloj de
nuestra aplicacin. En caso positivo, la rutina de tratamiento de interrupcin avisa al manejador de
reloj (CLOCK_TASK) y ste hace todo el proceso correspondiente a un tick de reloj.
La unidad mnima del reloj de la aplicacin (tick) no tiene por qu coincidir con la frecuencia
de las interrupciones del reloj hardware (18,7 mt, por segundo = aprox. 58 ms). Puede ser
cualquier mltiplo de ellas (en milisegundos), ajustable por el usuario mediante una operacin
(SET_TICK) Dicha unidad debe poder ser cambiada dinmicamente durante la ejecucin de la
aplicacin.
Adems el manejador de reloj tiene que permitir mantener un reloj virtual de la aplicacin.
Dicho reloj virtual se inicializar con el tiempo de la mquina cuando arranque la aplicacin y se
mantendr mediante los ticks del reloj fijado (horas, minutos y segundos). Este reloj permitir dos
operaciones: GET y SET Estas operaciones permiten cambiar la hora y leerla respectivamente.
Un aspecto que conviene destacar es que este reloj es relativo a la aplicacin y no tiene
por qu coincidir con el de la mquina.
Por ltimo, el manejador debe permitir poner, dentro de la aplicacin, Temporizadores y
ciclos (SET ALARM y SET_LOOP), asociando la ejecucin de una funcin al vencimiento de estos
eventos. El manejador debe mantener dos vectores estticos, con un mximo de diez elementos
cada uno, para mantener las direcciones de las lunciones asociadas a estos elementos (utilizar
punteros a funciones). Cuando se ponga un temporizador o ciclo, el manejador lo insertar en la
lista. Cada vez que venza un tick, debe mirar si alguno de estos elementos ha vencido y ejecutar la
funcin asociada. Adems, el manejador debe proporcionar dos funciones para eliminar
temporizadores (RESET_ALARM) y ciclos (RESET_LOOP) fijados anteriormente.
Mdulos de la prctica
La pieza clave de este mdulo es la rutina de tratamiento de interrupcin del reloj. Dicha rutina se
ejecuta cada vez que llega una interrupcin de reloj y debe llevar a cabo las siguientes acciones:
Adems de esta rutina, ste mdulo debe tener varias operaciones que permitan:
Este mdulo se encarga de hacer las operaciones propias de un manejador de reloj, excluyendo
las de planificacin.
La funcionalidad que debe admitir este mdulo es la siguiente:
Su Prototipo es similar a:
Esta funcin es similar a la principal de un manejador de LINUX, sin embargo, tiene dos
diferencias importantes:
No es un bucle infinito.
Usa paramatros de tipo message.
Los prototipos de las funciones que llevan a cabo las operaciones del manejador se describen
a continuacin:
int init_clock ()
int do_set_alarm (message *msg)
int do_reset_alarm (message *msg)
int do_set_loop (message *msg)
int. do_reset_ loop (message *msg)
int do_set_time (message *msg)
int do_get_time (message *msg)
int do_set_tick (message *msg)
mt do_clock_set_vect (message *msg)
int do_clock_tick (message *msg)
Esta funcin es llamada por el manejador de interrupcin cada vez que hay un tick de reloj
software.
Revisa las colas de ciclos y alarmas y ejecuta las funciones de los que hayan vencido,
pintando los resultados por pantalla.
Reactiva los ciclos vencidos.
Elimina las alarmas vencidas.
Actualiza la hora del reloj de la aplicacin (hora:minutos:segundos) y la escribe en la
esquina superior derecha de la pantalla.
El mdulo de prueba debe permitir acceder a la funcionalidad del manejador de reloj sin perder
precisin en el manejo de las alarmas, ciclos y hora relativa a la aplicacin (o la menos posible).
El esquema del programa de prueba es el siguiente:
Cuando se pone un ciclo o alarma hay que indicar una funcin para que se ejecute.
El alumno debe proporcionar cinco funciones de prueba, todas ellas con el mismo formato,
para que puedan ser ejecutadas en la aplicacin.
El formato de dichas funciones de prueba es el siguiente:
funcin_i () {
escribe (soy la funcin i \n);
escribe (hora del sistema)
}
En la Figura C.2 puede verse el flujo de llamadas entre los distintos mdulos del sistema.
Estructuras de datos
struct clock {
int hora;
int minutos;
int segundos;
}
struct message {
int caller; /* identificador del origen del mensaje*/
int operation; /* cdigo de operacin */
int duration; /* duracin del ciclo, alarma o tick del reloj */
void(*function) ( ) /* puntero a funcin asociada a alarma, ciclo o
interrupcin */
int id; /* identificador de alarma o ciclo fijado */
struct {
int free;
int ticks_left;
char *function;
} Temporizadores [MAXIMO_TEMPOLRALIZADORES]
struct {
int free;
int ticks_left;
char *function;
} Ciclos [MAXIMO_CICLOS]
Cada vez que se ejecute do_clock_tick, el manejador de reloj debe recorrer estos vectores
decrementando los ticks restantes de cada elemento (ticks_left). Si alguno llega a cero, el
manejador debe ejecutar su funcin asociada.
Se recomienda que el alumno entregue los siguientes archivos como solucin a esta prctica:
C.4.6. Bibliografa
En esta prctica se pretende que el alumno se familiarisara con los mecanismos de comunicacin
entre procesos, usando sockets como mecanismo de comunicacin. Adems. El alumno tendr
ocasin de experimentar con un sistema cliente-servidor.
Sirve como trabajo prctico para el tema de comunicacin y sincronizacin y el tema de
sistemas distribuidos.
Esta prctica permitir al alumno estudiar los mecanismos existentes en UNIX para comunicar
procesos con sockets y el concepto de relacin cliente-servidor.
La prctica consiste en el desarrollo de dos programas C que definen dos procesos
denomina dos csocket y ssocket respectivamente. El resultado de la ejecucin conjunta de ambos
procesos ser similar al obtenido mediante la ejecucin de la orden cat de UNIX, es decir,
visualizar el contenido de un archivo cuyo nombre se indica.
El proceso csocket lee el nombre del archivo por la (mitrada estndar (teclado) y se lo
enva al servidor por un socket de recepcin de mensajes del servidor, que se supone creado por
el servidor.
Si el envo es correcto, crea un socket para recibir y ejecuta un bucle de lectura del socket
y de escritura de lo ledo por la salida estndar (pantalla). Cuando el archivo est terminado, el
servidor le enva un cdigo de finalizacin.
El proceso ssocket crea un, socket de recepcin y recibe del cliente el nombre del archivo
a leer. Si la recepcin es correcta, abre el, socket (socket) del cliente y el archivo recibido (open) y
ejecuta un bucle de lectura del archivo (send/write) y enva (recv/read) por el socket del cliente
recibido como parmetro. Una vez ledo el archivo completo, cierra todos los archivos y
descriptores (close).
Para la comunicacin se usa una estructura de tipo mensaje. El uso de esta estructura
permite generalizar el modelo de comunicacin para su uso en un esquema cliente-servidor (le tipo
general. El servidor debe poder atender a cualquier cliente de forma secuencial. Para ello
supondremos que el servidor tiene una direccin de recepcin de mensajes conocida por todos los
clientes.
Puesto que el servidor debe conocer la identidad de la cola cliente donde debe responder,
usar una estructura mensaje como la siguiente:
typedef struct {
sockaddrin direccin; / direccin del emisor /
char datos datos que ha enviado */
unsigned mt longdat; /* longitud de datos vlidos dentro de datos /
unsigned mt orden; /* nmero de orden del mensaje /
}mensaje;
donde se incluye la direccin del cliente adonde debe enviarse la respuesta del servidor. Esta
modificacin permite al servidor atender peticiones de cualquier cliente que conozca su direccin y
a un mismo cliente recibir respuestas a sus mensajes por distintos sockets (uno por cada servicio).
Aunque existen distintos tipos de sockets (INET, UNIX, SNET,...), esta prctica se limitar
a los sockets de tipo INET y, dentro de ellos, a los sockets de tipo DATAGRAMA y STREAN.
Todas las llamadas al sistema devuelven un error en caso de ejecucin incorrecta. El
alumno debe controlar los posibles errores y mostrarlos por la salida de error.
Para construir un servidor similar a uno real de UNIX, en esta prctica se desarrollarn
varios apartados.
Para cada peticin de servicio, el servidor crea un proceso hijo al que le pasa el mensaje recibido
(Fig. C.3). Este es el responsable de ejecutar el servicio completo.
Para cada peticin de servicio, el servidor crea un PL al que le pasa el mensaje recibido. Este PL
es el responsable de ejecutar el servicio completo. El esquema es similar al de la Figura C.3. pero
en lugar de procesos convencionales se crean procesos ligeros usando threads de POSIX.
El mecanismo de comunicacin a utilizar en esta prctica son los sockets. Un socket (enchufe) es
un punto extremo de comunicacin, que permite comunicar dos procesos punto a punto. Estos
procesos pueden ejecutarse en la misma mquina o no. Permiten la utilizacin de protocolos de
red y de transporte para la comunicacin de procesos situados en distintos nodos. Esta
caracterstica hace que sean ms potentes que los pipes, y un mecanismo de comunicacin a
considerar en sistemas distribuidos.
Para trabajar con .sockets es siempre necesaria la existencia de extremos con direcciones
conocidas y que estos extremos se sincronicen adecuadamente, si bien la forma de sincronizacin
depende del tipo de socket.
Existen sockets de distintos tipos en un sistema UNIX, diferencindose cada tipo por la
semntica que proporcionan en el protocolo de comunicaciones. En esta prctica utilizaremos las
siguientes constantes:
Servicios de archivos
Los sockets se manejan en UNIX como descriptores de archivos, por lo que aceptan muchas llama
das de archivos como read. write, close o ioctl.
Servicios de sockets
Esta llamada asigna un nombre (una direccin) a un socket sin nombre, es decir, a uno
creado con socket. A partir de su ejecucin, se puede acceder a la direccin a travs del socket sin
especificar nada ms que el identificador del socket.
Acepta conexiones sobre un socket que ha sido previamente creado (socket), enlazado
(bind) a una direccin y que est a la escucha (listen). Esta llamada es bloqueante y extrae la
primera conexin que exista. Crea un nuevo socket conectado y devuelve su descriptor de archivo.
Intenta establecer una conexin con otro socket. Este ltimo debe estar ejecutando una
llama da accept. Generalmente slo se puede establecer una conexin de simultnea para SOCK
SIREAM y mltiples para SOCK_
Examina los descriptores de socket de readfds. writefdsn y exceptfds para ver si alguno
est lisio para leer, recibir o tiene alguna excepcin pendiente. El parmetro width es una mscara
de bits que indica los descriptores que deben ser muestreados.
int recvfrorn(int s, int len, int flag f ] struct sockdddr *fromm, Int *fromlen)
int send int s, char *buf, int len, int ilags)
Distintas llamadas de recepcin sobre sockets. recv slo puede usarse para sockets conecta dos.
Se lee sobre buf una longitud mxima len, con la operacin modificada por flags. Si to es no nulo,
se introduce en dicho parmetro los datos del origen del mensaje. Obteniendo su longitud en tolen.
int sendio(int s, mt len, int flags, struc sockaddr *io, int *io);
int send(int s, char *buf, int len, int flags)
Distintas llamadas de envo sobre sockets. send slo puede usarse para sockets
conectados. Se enva buf con una longitud mxima len, con la operacin modificada por flags. Si to
es no nulo, se introduce en dicho parmetro los datos del destino del mensaje, incluyendo su
longitud en iolen.
Para resolver la seccin que usa procesos ligeros, se recomienda al lector acudir al tema de
Procesos, donde se describen las llamadas al sistema para procesos ligeros, tales como
pihread_desiroy, pihread_yield, pthread sleep, etc.
Como material de apoyo se sugiere a los profesores proporcionar a los alumnos algn ejemplo de
programacin con sockets. Para ello se puede usar el libro de Stevens, Unix Network Programing
donde hay mltiples ejemplos.
Igualmente, se les puede proporcionar un ejemplo de programa que use las llamadas al
sistema
fork y exec.
Adems, se sugiere que para evitar una explosin de definiciones distintas se proporcione
un archivo, denominado Soc. . h, que, usando el lenguaje C, incluya las definiciones generales
para el desarrollo de la prctica.
C.5.7. Bibliografa
El objetivo de esta prctica es llegar a conocer los principales conceptos relacionados con la
gestin de procesos y la multiprogramacin. El trabajo va a consistir bsicamente en convertir un
sistema con monoprogramacin en uno multiprogramado.
La multiprogramacin y, en general, la concurrencia son probablemente los temas ms
importantes en la enseanza de los sistemas operativos, aunque tambin son los ms complejos
de entender. Es muy difcil conseguir comprender lo que ocurre cuando se estn ejecutando
concurrentemente varias actividades.
Esta dificultad se acenta notablemente cuando se est trabajando en el nivel ms bajo del
sistema operativo. Por un lado, en este nivel la mayora de los eventos son asncronos. Por otro, en
l existe una gran dificultad para la depuracin, dado el carcter no determinista del sistema y la
falta de herramientas de depuracin adecuadas.
Todas las consideraciones expuestas hasta ahora explican el motivo de que la
programacin de sistemas tenga una productividad tan baja y que los sistemas operativos tengan
mala fama debido a sus cadas y cuelgues imprevistos.
Por tanto, al enfrentarse con esta problemtica, es importante resaltar desde el principio las
dificultades que se encontrar para la realizacin de este proyecto prctico. Sin embargo, aunque
parezca un poco sorprendente, enfrentarse con esos problemas es a su vez un objetivo del mismo.
Por ltimo, hay que resaltar que en esta prctica se plasman muchos de los conceptos de
sistemas operativos relacionados con la concurrencia y la gestin de interrupciones tales como:
Uno de los problemas que surgen cuando se pretende hacer una prctica de este tipo es decidir en
qu entorno se lleva cabo.
La eleccin ms obvia es utilizar un sistema operativo real del que se dispongan las
fuentes (tales como MINIX o LINUX) y realizar modificaciones en el cdigo del mismo para incluir
nuevas funcionalidades. Este enfoque es el ms realista, pero, sin embargo, presenta algunos
problemas que dificultan considerablemente su aplicacin prctica.
El entorno de desarrollo de la prctica intenta imitar dentro (le lo que cabe el comportamiento y
estructura de un sistema real. En una primera aproximacin, en este entorno se pueden diferenciar
(res componentes principales:
A continuacin, se describe cada una de estas parles haciendo especial nfasis en el sistema
operativo.
De forma similar a lo que ocurre en un sistema real, en este entorno existe un programa de
arranque que se encarga de cargar el sistema operativo en memoria y pasar el control a su punto
de entrada inicial. Este procedimiento imita el modo de arranque de los sistemas operativos reales
que se realiza desde un programa cargador.
El programa cargador se encuentra en el subdirectorio boot y. en un alarde de originalidad,
se denomina boot. Para arrancar el sistema operativo, y con ello el entorno de la prctica, se debe
ejecutar dicho programa pasndole como argumento el nombre del archivo que contiene el sistema
operativo. As, suponiendo que el directorio actual corresponde con el subdirectorio boot y que el
sistema operativo est situado en el directorio kernel y se denomina minikernel, se debera
ejecutar: boot. . /kernel/minikernel. Observe que no es necesario ejecutar el programa de arranque
desde su directorio. As, si se est situado en el directorio base de la prctica, se podra usar el
siguiente mandato: boot/boot kernel/minikernel.
El minikernel
El cdigo del sistema operativo est organizado como un mdulo de apoyo (archivo apoyo o), del
que se proporciona nicamente su interfaz, y el mdulo que contiene la funcionalidad principal del
sistema operativo (archivo proc.c).
El mdulo de apoyo
El objetivo principal de este mdulo es simular el procesador y ofrecer servicios que permitan al
sistema operativo su manejo. Las principales caractersticas de este procesador son las siguientes:
Cuando se produce una interrupcin, sea del tipo que sea, el procesador realiza el
tratamiento habitual, esto es, almacenar el contador de programa y el registro de estado en
la pila, prohibir las interrupciones, elevar el nivel del procesador y cargar en el contador de
programa el valor almacenado en el vector correspondiente. Evidentemente, al tratarse de
operaciones realizadas l) el hardware, todas estas operaciones no son visibles al
programador del sistema operativo
La ejecucin en modo kernel de una instruccin de retorno de interrupcin restaurar el
nivel de procesador y el estado de las interrupciones previo. Observe que, ciado que se
pretende que el cdigo a desarrollar no incluya ensamblador, la ejecucin de esta
instruccin est incluida en uno de los servicios exportados por este mdulo.
Adems de funcionalidad relacionada con la simulacin del procesador, este mdulo tambin
incluye otras funciones de ms alto nivel que intentan facilitar la labor (le programacin del sistema
operativo. Por ejemplo, se ofrecen funciones relacionadas con la creacin del mapa de memoria de
cada proceso a partir del ejecutable. Con esto se pretende que el desarrollo se centre en los
aspectos relacionados con la gestin de procesos y no en otros como la gestin de memoria.
Las funciones ofrecidas por el modulo de apoyo se pueden clasificar en las siguientes
categoras:
El mdulo proc
ste es el mdulo que contiene la funcionalidad del sistema operativo. Su nombre viene a indicar
cul es la labor fundamental de este minisistema operativo: la gestin de procesos. Como parte
material de apoyo para la realizacin de la prctica se proporciona una versin de este mdulo que
incluye una funcionalidad bsica que corresponde con un sistema monoprogramado. Para ser ms
precisos, hay que aclarar que en este sistema inicial, aunque se puedan crear y cargar en memoria
mltiples programas, el proceso en ejecucin contina hasta que termina. Este sistema se deber
convertir en un sistema multiprogramado siguiendo las pautas que se detallan posteriormente.
Antes de pasar a revisar las caractersticas principales de esta versin inicial es
conveniente realizar algunas aclaraciones sobre el mismo:
Como se coment previamente, una vez que empieza a ejecutar un proceso, ste contina
hasta que termina. El estado del proceso ser en todo momento en ejecucin. No existe
ningn servicio que cause que el proceso pase a un estado bloqueado. Slo se invoca a la
rutina de cambio de contexto cuando el proceso termina, sea voluntaria o
involuntariamente. Observe que la rutina de interrupcin no cambia el estado de los
procesos.
No van a existir problemas de sincronizacin dentro del ncleo causados por la ejecucin
concurrente de varias llamadas al sistema ya que se trata de un sistema monoprogramado.
Segn se vaya incluyendo en el sistema la funcionalidad pedida, habr que analizar si
puede surgir este tipo de problemas.
Los problemas de sincronizacin dentro del ncleo entre una llamada al sistema y la rutina
de tratamiento de interrupcin van a ser relativamente simples, ya que en esta versin
inicial la rutina de interrupcin no realiza ninguna labor. Solamente es necesario asegurar
que mientras se est salvando o recuperando informacin de la pila, realizando un cambio
de contexto, o despus de liberar la pila del sistema del proceso, no se produzca una
interrupcin Y que la rutina de interrupcin tambin manipula esas estructuras de datos.
Para ello se prohibirn las interrupciones en la seccin de cdigo problemtica. Como se
coment para el caso anterior, segn se incluya nueva funcionalidad en la rutina de
interrupcin ser necesario revisar el sistema para comprobar si pueden surgir este tipo de
problemas.
Estructuras de datos (contenidas en proc.h). Este mdulo utiliza las siguientes variables
globales:
Iniciacin. Una vez cargado el sistema operativo, el programa cargador pasa control al
punto de entrada del mismo (en este caso a la funcin main de este mdulo). En este
momento,- el sistema inicia sus estructuras (le datos, los dispositivos hardware e instala
sus manejadores en la tabla de vectores. En ltimo lugar, crea el proceso inicial init y lo
activa pasndole el control. Observe que durante esta l las interrupciones estn inhibidas.
Sin embargo, cuan do se activa el proceso init restaurndose su contexto inicial, se
habilitan automticamente las interrupciones puesto que en dicho contexto inicial se ha
establecido previamente que esto sea as.
En la versin inicial, el cdigo de las tres llamadas ejecuta la mayora del tiempo con las
interrupciones habilitadas. Al ir aadiendo la funcionalidad pedida puede ser necesario revisar el
cdigo para aumentar la zona de cdigo que ejecuta con las interrupciones inhibidas.
En el subdirectorio usuario existe inicialmente un conjunto de programas de ejemplo que usan los
servicios del minikernel. De especial importancia es el programa init puesto que es el primer
programa que arranca el sistema operativo. En un sistema real este programa consulta archivos de
configuracin para arrancar otros programas que, por ejemplo, se encarguen de atender a los
usuarios (procesos de login). De manera relativamente similar, en este sistema este proceso har
el papel de lanzador de otros procesos, aunque en nuestro caso no se trata de procesos que
atiendan al usuario puesto que el Sistema no proporciona servicios para leer del terminal. Se
tratar simple mente de programas que realizan una determinada labor y terminan.
Adems del programa init, en este directorio existe un conjunto de programas que sirven
(le ejemplo del uso de las llamadas al sistema.
Como ocurre en un sistema real, los programas tienen acceso a las llamadas al sistema
como rutinas de biblioteca. Para ello, existe una biblioteca esttica denominada libserv. a que
contiene las funciones de interfaz para las llamadas. Esta biblioteca almacenada en el subdirectorio
usuario/lib est compuesta de dos mdulos:
serv. c. Contiene las rutinas de interfaz para las llamadas. Se apoya en una funcin de
nominada hacer_trap que es la que realmente ejecuta la instruccin (le llamada al sistema.
Para hacer accesible a los programas una nueva llamada, se deber modificar este archivo
para incluir la rutina de interfaz correspondiente.
misc.o. Contiene funciones de utilidad comO la definicin de la funcin printf del sistema
que, evidentemente, se apoya en la llamada al sistema escribir, de la misma manera que el
printf de UNIX se apoya en la llamada write.
Dado que parte de la labor de la prctica es incluir nuevas llamadas al sistema, se ha considerado
oportuno incluir en esta seccin los pasos tpicos que hay que llevar a cabo en este sistema para
hacerlo. Suponiendo que el nuevo servicio se denomina nueva, stos son los pasos a realizar:
Incluir en kernel /proc. c una rutina (que podra denominarse sis_nueva) con el cdigo de la
nueva llamada.
Incluir en tabla_servicios (archivo kernel/include/proc.h) la nueva llamada en la ltima
posicin de la tabla.
Modificar el archivo para incrementar el nmero de llamadas disponibles y asignar el
cdigo ms alto a la nueva llamada.
Una vez realizados los pasos anteriores, el sistema operativo ya incluira el nuevo servicio,
pero slo sera accesible desde los programas usando cdigo ensamblador. Por tanto, es
necesario modificar la biblioteca de servicios (archivo usuario/lib/serv.c) para que
proporcione la interfaz para el nuevo servicio. Se debera tambin modificar el archivo de
cabecera que incluyen los programas de usuario (usuario/ include / servicios. h) para que
dispongan del prototipo de la funcin de interfaz.
Por ltimo, hay que crear programas de prueba para este nuevo servicio y, evidentemente,
modificar init para que los invoque. Asimismo, se debera modificar el archivo Makefile para
facilitar la compilacin de este nuevo programa.
Como se coment previamente, la prctica va a consistir en modificar la versin inicial que se ci1trc
como material de apoyo para incluir nuevas funcionalidades y aadir multiprogramacin al mismo.
Se deben realizar tas siguientes modificaciones sobre la versin inicial del sistema:
Incluir una nueva llamada (obtener_id) que devuelva el identificador del proceso que la
invoca. Corno puede observarse, se trata de un servicio que realiza un trabajo muy
sencillo. Sin embargo, esta primera tarea servir para familiarizarse con el mecanismo que
se usa para incluir una nueva llamada al sistema. El prototipo de la funcin de interfaz
sera el siguiente:
int obtener_id_pr ().
Incluir una nueva llamada (int dormir (unsigned int segundos)) que permita que un proceso
pueda quedarse bloqueado un plazo de tiempo. El plazo se especifica en segundos corno
parmetro de la llamada. La inclusin de esta llamada significar que el sistema pasa a ser
multiprogramado ya que cuando un proceso la invoca pasa al estado bloqueado durante el
plazo especificado y se deber asignar el procesador al proceso elegido por el planificador.
Observe que en el sistema slo existirn cambios de contexto voluntarios y, por tanto,
sigue sin ser posible la existencia de llamadas al sistema concurrentes. Sin embargo. dado
que la rutina de interrupcin del reloj va a manipular listas de BCPs. es necesario revisar el
cdigo del sistema para detectar posibles problemas de sincronizacin en el manejo de
estas listas y solventarlos prohibiendo las interrupciones en los fragmentos de cdigo
correspondientes. Aunque se puede implementar esta llamada corno se considere
oportuno, a continuacin se sugieren algunas pautas:
Modificar el BCP para incluir algn campo relacionado con esta llamada.
Definir una lista de procesos esperando plazos.
Incluir la llamada que, entre otras labores, debe poner al proceso en estado bloqueado,
reajustar las listas de BCPs correspondientes y realizar el cambio de contexto.
Aadir a la rutina de interrupcin la deteccin de si se cumple el plazo de algn proceso
dormido. Si es as, debe cambiarle de estado (LISTO) y reajustar las listas
correspondientes.
Sustituir el algoritmo de planificacin FIFO por round-robin (el tamao de la rodaja es igual
a la constante TICKS_POR_RODAJA). Con la inclusin de este algoritmo aparecen
cambios de contexto involuntarios, lo que causa un gran impacto sobre los problemas de
sincroniza cin dentro del sistema al poderse ejecutar varias llamadas de forma
concurrente. Para sol ventar estos problemas, en la prctica se va a usar una solucin
similar a la utilizada en muchas implementaciones de UNIX: No permitir los cambios de
contexto mientras el proceso est ejecutando en modo sistema. A grandes rasgos, la
solucin planteada debe cubrir los siguientes aspectos:
En esta seccin se describe el rbol de archivos que corresponde con el entorno de desarrollo,
minikernel.
Makefile general del entorno. Invoca a los archivos Makefile de los subdirectorios
subyacentes.
boot. Este directorio est relacionado con la carga del sistema operativo. Contiene el pro
grama de arranque del sistema operativo.
kernel. Este directorio contiene todos los archivos necesarios para generar el sistema
operativo:
servicios. h. Archivo que contiene los prototipos de las funciones que sirven (le interfaz a
las llamadas al sistema. En l se debe incluir la interfaz a las nuevas llamadas.
lib. Este directorio contiene los programas que permite generar la biblioteca que utilizan los
programas de usuario. Su contenido es:
C.6.6. Bibliografa
Un sistema de archivos con bandas permite crear sistemas de archivos que ocupan varias
particiones. Su estructura distribuye los bloques de datos de forma cclica por los discos que con
forman la particin lgica, repartiendo la carga de forma equitativa. Para optimizar la eficiencia del
sistema de archivos se puede definir una unidad de almacenamiento en cada banda con un
tamao mayor que el del bloque del sistema de archivos. Esta unidad, denominada unidad de
distribucin (stripe unit), es la unidad de informacin que se escribe de forma consecutiva en cada
banda. Este valor cambia de un sistema, e incluso archivo, a otro, siendo 64 KB el valor por defecto
en Windows NT.
La Figura C.4 muestra la estructura de un sistema de archivos de bandas que ocupa cuatro
particiones.
Adems, este tipo de sistemas de archivos permite incrementar la fiabilidad del sistema de
archivos insertando bloques de paridad con informacin redundante. De esa forma, si falta un
dispositivo, se puede reconstruir la informacin mediante los bloques de los otros dispositivos y la
informacin de paridad. Adems, se puede hacer que la particin sea ms tolerante a fallos
distribuyendo tambin la informacin de la particin del sistema.
Un archivo con bandas queda definido por dos parmetros:
La forma de operar sobre un archivo con bandas es la siguiente. Cuando se va a leer del
archivo, se accede al subarchivo donde indica el puntero de posicin del FB. Sobre esa subunidad
se lee lo que reste de la unidad de reparto y luego se pasa a los siguientes subarchivos.
Evidentemente, si se leyera de varias subunidades se podra hacer en paralelo, pero teniendo en
cuenta que la modificacin del puntero de posicin ser la del puntero global.
En un objeto archivo se puede almacenar informacin de tipo muy distinto: cdigo fuente, pro
gramas objeto, bibliotecas, programas ejecutables, texto ASCII, agrupaciones de registros,
imgenes, sonidos, etc. Desde el punto de vista del sistema operativo, un archivo se caracteriza
por tener una serie de atributos. Dichos atributos varan de tinos sistemas operativos a otros, pero
todos ellos tienen una estructura interna que los describen. En nuestro caso, esa estructura se
denominar nodo_sfp y se muestra en la Figura C.5.
El nodo_sfp usado contiene la siguiente informacin:
Identificador nico: a nivel interno, el sistema operativo no usa el nombre para identificar a
los archivos, sino un identificador nico fijado con criterios internos al sistema operativo.
Este identificador suele ser un nmero y habitualmente es desconocido por los usuarios.
En el caso de la prctica ser un nmero entero que nunca decrece. Por tanto, hay que
tener un contador para asignar el nmero de nodo_sfp.
Identificador del proceso propietario y de su grupo. Son el pid y el gid del proceso creador.
Proteccin: informacin de control de acceso que define quin puede hacer qu sobre el
archivo, el dueo del archivo, su creador, etc.
Nombre: identificador del archivo en formato comprensible para el usuario. Definido por su
creador.
Nmero de subarchivos que componen el archivo con bandas. Definido por su creador.
Tamao de la unidad de distribucin, en bytes. Este dato indica la cantidad de datos
consecutiva que se escribe en cada subarchivo.
Tamao del archivo: nmero de bytes en el archivo.
Tiempos: de creacin y de ltima actualizacin. Esta informacin es muy til para
gestionar, monitorizar y proteger los sistemas de archivos.
Nmero de veces que el archivo ha sido abierto simultneamente. Es el nmero de
sesiones existentes sobre el archivo.
Para desacoplar a los procesos que usen la biblioteca de los descriptores internos de los archivos,
nodo_sfp, y para permitir que un archivo se pueda abrir varias veces sin que haya conflictos con
los accesos, se usar una tabla de descriptores de archivos como la que se muestra en la Figura
C.6.
La tabla tiene cuatro entradas:
Descriptor de archivo abierto. Es el que obtiene el proceso cuando ejecuta open. Este
descriptor es un nmero entero entre 0 y MAX_FD. Teniendo en cuenta que 0, 1 y 2 estn
reservados para la STDIN, STDOUT y STDERR como en UNIX.
Nmero de nodo sfp. Descriptor interno del archivo. Con este descriptor se pueden buscar
los metadatos del archivo en la tabla tnodos_sfp.
Puntero de posicin del archivo. Para esa sesin del archivo abierto incluye la posicin del
archivo sobre la que se ejecutan las operaciones de E/S.
Bandera de ocupado o libre. Est a O cuando est libre y a 1 cuando est ocupado.
Cuando se abre un archivo hay que entrar en la tabla y buscar el primer descriptor libre.
Esa entrada es la ocupada y su descriptor de archivo el devuelto. En la prctica, el nmero de fd
coincidir con su posicin en las filas de la tabla, El valor del puntero de posicin del archivo recin
abierto es cero. El valor del nodo_sfp se extrae del archivo de nodos_sfp, denominado nodos.sfp, y
se incluye en la columna correspondiente. Puesto que, como se ve en la figura, varias entradas de
esta tabla pueden apuntar al mismo nodo E p, ya que se puede abrir un archivo repetidamente sin
ningn problema.
Cuando se cierre un archivo hay que liberar la entrada del descriptor asociado al mismo y
se borran los contenidos de dicha entrada.
Estructuracin de la informacin
Con lo descrito hasta ahora, ya se puede explicar cmo y dnde debe quedar la informacin
resultante de la ejecucin de la prctica. Para simplificar la realizacin de la prctica, supondremos
que todos los archivos con bandas se crean dentro de un subdirectorio del directorio donde se
ejecuta la prctica, denominado sfp. Por tanto, todos los nombres de archivo con bandas deberan
empezar por /sfp/.
Dentro del directorio . /sfp estarn:
El archivo nodos. sfp. Todos los accesos a este archivo se hacen usando el tipo nodo_sfp
definido.
Los subarchivos resultantes de los archivos con bandas creados. Por tanto, cuando se
ejecute un mandato ls. /sfp de UNIX sobre ese directorio, se vern entradas del tipo
mi_fbandas_1 a mi_fbandas_n. No existir ninguna entrada de archivo con bandas, ya que
esta entelequia existe nicamente a nivel de biblioteca y de metadatos.
Para saber si las operaciones de archivos con bandas funcionan bien, bastar en muchos
casos con monitorizar el directorio /sfp.
Para construir un servidor de archivos similar a un servidor real, se recomienda desarrollar esta
prctica en varias etapas.
Primera etapa
En esta etapa, el alumno debe desarrollar una biblioteca de funciones para manipular los archivos
con bandas. En esta seccin se describe la funcionalidad de esta biblioteca, que debe incluir las
siguientes funciones para manejar este tipo de archivos:
Esta funcin crea el archivo, pero no lo abre. Para abrirlo es necesario hacer la
llamada que se describe a continuacin. El efecto de crear_sfp es la aparicin de un
archivo vaco con el nombre, protecciones, nmero de bandas y unidad de distribucin
definida en la llamada. Si el archivo ya existe, se trunca. dejndolo vaco de contenido.
Adems se crea el nodo_sfp y se incluye, relleno con los datos del archivo, en el archivo
nodos. sfp.
Esta llamada cierra el archivo con bandas y sus subarchivos asociados y decrementa
el contador de aperturas del nodo_sfp. Adems se libera su entrada de la tabla de
descriptores de archivos. Si el contador de aperturas del archivo es igual a cero, se elimina
el nodo_sfp del archivo de la tabla de nodo_sfp. Si el identificador de archivo pedido no
existe, debe devolver un error.
borrar_sfp. Borra un archivo con bandas. Su prototipo es:
Esta llamada comprueba si el archivo est abierto, devolviendo error en este caso. Si
el archivo no est abierto por ningn usuario, se borra el archivo con bandas y los
subarchivos que lo componen y se elimina su nodo_sfp del archivo nodos. sfp.
leer_sfp. Lee de un archivo con bandas a un buffer de memoria. El archivo debe estar
abierto. Su prototipo es:
Esta funcin devuelve la longitud de los datos ledos realmente, que ser siempre
menor o igual al tamao pedido. Si el archivo no est abierto, debe ciar un error. Si se
intenta leer ms all del fin de archivo, se deben devolver los datos existentes. l caso de
que no haya ninguno, se devuelve cero.
escribir_sfp. Escribe un buffer de memoria a un archivo con bandas. El archivo debe estar
abierto. Su prototipo es:
Segunda etapa
Adems de la biblioteca anterior, el alumno puede hacer los mandatos sfp_ls y sfp_cat para poder
consultar la informacin de dichos archivos.
sfp_ls. Permite ver los metadatos de los archivos con bandas que se han creado hasta el
momento, es decir, todos los existentes en el directorio . /sfp/. La informacin debe re
presentar al archivo con bandas y no a sus subarchivos. La informacin a mostrar por cada
archivo es: permisos, gid. uid, longitud, fecha de ltima escritura y nombre. Similar a un ls
1 de UNIX:
rw-r--r- 1 jcarrete 937 Sep 23 16:05 Makefile.
sfp_cat. Permite ver los datos de un archivo con bandas existente en el directorio. /sfp/ por
la salida estndar. El formato del mandato es sfp_cat - /sfp/nombre-archivo. Es similar al
mandato cat de UNIX.
Tercera etapa
Para la realizacin de esta prctica slo se deben usar llamadas, al sistema de archivos, tales
como read, write, close, 1seek, o ioctl.
Para obtener informacin ms detallada de estas llamadas se recomienda mirar la
bibliografa de la prctica y los manuales de la mquina para los mandatos de archivos (p. ej.: man
lseek).
C.7.6. Bibliografa
[ 1986] M. Accetta, R. Baron, D. Golub, R. Rashid, A. Tevanian y M. Young. Mach: A New Kernel
Foundation for UNIX Development. Proceedings Summer 1986. USENIX Conference, pgs. 93-
112, 1986
[ 19861 M. J. Bach. The Design of the Unix Operating Systems. Prentice-Hall, 1986.
[ 19981 M. Beck, N. Boheme, M. Dziadzka et al. Linux Kernel Internals, 2. edicin, Addison-Wesley,
1988.
ICorbato, 19621 F. Corbato, M. Merwin-Dagget y R. Dealey. A Experimental Time-Sharing System.
Proced dings of the 1962 Spring Joint Computer Conference, 1962.
[ 1997] C. Crowley. Operating Systems, A Design-Oriented Approach. Irwin-McGraw-Hill, 1997
[ 1994] H. M. Deitel y M. S. Kogan. The Design of OS/2. Prentice-Hall, 1994
[ 19681 E. W. Disjkstra. The Structure of THE Multiprogramming System. Communications of the
ACM, vol. 11, pgs. 341-346, mayo 1968.
[ 2000] L. D. Galli. Distributed Operating Systems: Concepts and Practice. Prentice-Hall, 2000.
[ 1998] J. M. Hart. Win32 System Programming. Addison-Wesley, 1998.
[ 1996] Information technology. Portable Operating System Interfac (POSIX). System Application
Pro gram Interface (API). IEEE Computer Society, 1996.
[ 1996] M. McKusick, K. Bostic, M. Karels y J. Quaterman. The Design and Implementation of the
4.4 BSD UNIX Operating System. Addison-Wesley, 1996
[ 1966] G. H. Mealey, B. 1. Witt y W. A. Clark. The Strucrural Structure of 05/360. IBM System
Journal, vol. 5, nm 1, 1966.
[ 1992] M. Milenkovic. Operating Systems: Concepts and Design. McGraw-Hill, 1992
[ 19901 S. J. Mullender, G. Van Rossum, A. S. Tanenbaum, R. Van Renesse y H. Van Staveren.
Amoeba: A Distributed Operating Systems for the ]990s. IEEE Computer, vol. 23, pgs. 44-53
mayo, 1990.
Captulo 3. Procesos
[ 1986] M. J. Bach. The Design of the UNIX Operating System. Prentice-Hall, 1986.
[ 19961 M. Beck, H. Bohme, M. Dziadzka, U. Kunitz, R. Magnus y D. Verwomer. Linux Kernel Inter
nais. Addison-Wesley, 1996.
[ 1969] L. A. Belady et al. An Anomaly in Space-Time Characteristics of Certain Programms Run
ning in a Paging Machine, Communications of the ACM, vol. 12, nm. 6, 1969.
[ 1993] H. Custer. Inside Windows/NT. Microsoft Press, 1993.
[ 1987] R. A. Gingeil et al. Shared Libraries in SunOS, Summer Conference Proceedings.
USENIX Association, 1987.
[ 19971 J. M. Hart. Win32 System Programming. Addison-Wesley, 1997.
[ 1965] K. C. Knowlton. A Fast Storage Allocator. Communications of ihe ACM, vol. 8, nm. 10,
1965.
[ 1987] M. Maekawa et al. Operating Systems: Advanced Concepts. Benjamin-Cummings, 1987. [
1996] M. K. McKusick, K. Bostic, M. J. Karels y J. 5. Quaterman. The Design and Implementa tion
of the 4.4 BSD Operating System. Addison-Wesley, 1996.
[ 19861 M. J. Bach. The Design of the Unix Operating System. Prentice-Hall 1986.
[ 19971 M. Beck et al. Linux Kernel Internais, 2. edicin. Addison-Wesley, 1997.
[ Ari, 19901 Ben Ari. Principies of Concurrent and Distributed Programming. Prentice-Hall, 1990
[ 1965] E. W. Dijkstra. Cooperating Sequential Processes. Technical Report EWD- 123, Technologi
cal University, Eindhoven, Holanda, 1965. Reimpreso en [ 1968], pgs. 43-112.
[ 1974j C. A. R. Hoare. Monitors: An Operating Systems Structuring Concept. Communications of
the ACM, vol. 17, nm 10, pgs. 549-557, octubre 1974.
[ 19801 B. Lampson y D. Redeil. Experience with Processes and Monitors in Mesa. Communica
tions of the ACM, febrero 1980.
[ 1996] M. K. McKusick, K. Bostic, M. J. Karels y J. S. Quaterman. The Design and impiementa tion
of the 4.4 BSD Operating System. Addison-Wesley, 1996
[ 19991 A. Silberschatz y J. Peterson. Operating Systems Concepts, 5 edicin, Addison-Wesley,
1999.
[ 1998] D. A. Solomon. Inside Windows NT, 2. edicin, Microsoft Press, 1998
[ 1998] W. Stallings. Operating Systems, Internais and Design Principies, edicin, Prentice-Hall,
1998.
Captulo 6. Interbloqueos
[ 1986] M. J. Bach. The Design of the Unix Operating System. Prentice-Hall, 1986.
[ 1971] E. G. Coffman, M. J. Elphick y A. Shoshani. System Deadlocks. Computing Surveys, vol. 3,
nm. 2, pgs. 67-78, junio 1971.
[ 19651 E. W. Dijkstra. Cooperating Sequentiai Processes. Technical Report EWD- 123, Technologi
cal University, Eindhoven, Holanda, 1965. Reimpreso en [ 1968], pgs. 43-112.
[ 1969] A. N. Habermann. Prevention of System Deadlocks. Communications of the ACM, vol. 12,
nm. 7, pgs. 373-377, julio 1969.
[ 1968] J. W. Havender. Avoiding Deadlocks in Multitasking Systems. IBM Systems Journal, vol. 7,
nm. 12, pgs. 74-84, 1968.
[ 19721 R. C. Holt. Sorne Deadiock Properties of Computer Systems. Computing Surveys, vol. 4,
nm. 3, pgs. 179-196, septiembre 1972.
[ 1973] J. H. Howard. Mixed Soiutionsfor the Deadiock Problem. Communications of the ACM, vol.
16, nm. 7, pgs. 427-430, julio 1973.
[ 19871 M. Maekawa, A. E. Oldehoeft y R. R. Oldehoeft. Operating Systems, Advanced Concepts.
The BenjaminlCummings Publishing Company, 1987.
[ 19961 M. K. McKusick, K. Bostic, M. J. Karels y J. S. Quaterman. The Design and Impiementa tion
of the 4.4 BSD Operating System. Addison-Wesley, 1996.
[ 19791 G. Newton. Deadiock Prevention, Detection and Resolution: An Annotated Bibiiography.
Operating Systems Review, vol. 13, nm. 2, pgs. 33-44, abril 1979.
[ 1999] A. Silberschatz y P. B. Galvin. Operating Systems Concepts, 5. edicin, Addison-Wes ley,
1999.
[ 1998] W. Stallings. Operating Systems, Internais and Design Principies, 3. edicin, Prentice-Hall,
1998.
Captulo 7. Entrada/salida
[ 19731 D. H. Abernathy et al. Survey of Design Goalsfor Operating Systems, Operating Systems.
Review, vol. 7, nm. 2, pgs. 29-48, abril 1973; OSR, vol. 7, nm. 3, pgs. 19-34, julio 1973; OSR,
vol. 8, nm. 1, pgs. 25-35, enero 1974.
[ 19951 5. Akyurek y K. Salem. Adaptive Biock Rearrangement. ACM Transactions on Computer
Systems, 13(2), pgs. 89-121, mayo 1995.
[ 19811 D. A. Anderson. Operating Systems. COMPUTER, vol. 14, nm. 6, pgs. 69-82, junio 1981.
[ 19961 M. Andrews. C++ Windows NT Programming, 735 pginas, M&T Press, 1996.
[ 1986] J. A. Anyanwu y L. F. Marshall. A Crash Resistant UNIX File System, Software - Practice
and experience, vol. 16, nm. 1, pgs. 107-118, febrero 1986.
[ 1990J American Telephone y Telegraph Company. UNIX System V release 4: programmers
guide:
POSIX conformance. Prentice-Hall, 1990.
[ 1986] M. J. Bach. The Design of the UNIX Operating System. Prentice-Hall, 1986.
Bailey, 1981] K. A. Bailey etal. UserDefined Files. Operating Systems Review, vol. 15, nm. 4,
pgs. 75-81, octubre 1981.
[ 1996] M. Beck, H. Bohme, M. Dziadzka, U. Kunitz, R. Magnus y D. Verwomer. Linux Kernel nter
nais. Addison-Wesley, 1996.
[ 1993] P. Biswas, K. K. Ramakrishnan y D. Towsley. Trace Driven Analysis of Wnte Caching
Policies for Disks. Proceedings of the 1993 ACM SIGMETRICS Conference on Measurement, and
Modeling of Computer Systems, pgs. 13-23, mayo 10-14, 1993.
[ 1995] T. Blackwell, J. Harris y M. Seltzer. Heuristic Cleaning Algorithms in Log-Structured File
Systems. Proceedings of the USENIX 1995 Technical Conference, pgs. 277-288, enero 16-20,
1995.
[ 1995] S. H. Bokhari. The Linux Operating System, Computer, vol. 28, nm. 8, pgs. 74-79, agosto
1995.
[ 19891 A. Braunstein, M. Riley y J. Wilkes. Improving the Efficiency of UNIX File Buffer Ca ches.
Proceedings of the Twelfth ACM Symposium on Operating Systems, Principies, pgs. 71-82, 1989.
[ 1989] R. Brent. Efflcient implementation of the First-Fit Strategy for Dynamic Storage Allocation.
ACM Transactions on Programming Languages and Sytems, julio 1989.
[ 19861 0. P. Brereton, Management of Replicated Files in a UNIX Environment, Software - Practice
and Experience, vol. 16, nm. 4, pgs. 771-780, agosto 1986.
[ 1969] N. Chapin. Common File Organization Techniques Compared. FJCC, vol. 35, pgs. 413-
422, 1969.
[ 1995] P. M. Chen y E. K. Lee. Striping in a RAID Level 5 Disk Array. Proceedings of the 1995
ACM SIGMETRICS Joint International Conference on Measurement and Modeling of Computer
Systems, pgs. 136-145, mayo 15-19, 1995.
[ 1988] K. Christian. The UNIX Operating System. Wiley-Interscience, 1988.
[ 19851 D. Davcev y W. A. Burkhard. Consistency and Recovery Control for Replicated Files.
Proceedings of the Tenth Sysposium on Operating Systems Principies, vol. 19, nm. 5, pgs. 87-
96, diciembre 1985.
[ 1995] W. Davy. Method for Eliminating File Fragmentation and Reducing Average, Seek Times in
a Magnetic Disk Media Environment. USENIX, 1995.
[ 1989] F. Douglis y J. Ousterhout. Log-Structured File Systems, Proceedings of the 34th COMP-
CON Conference, pgs. 124-129, febrero 1989.
[ 1987] M. J. Folk y B. Zoellick. File Structures. Addison-Wesley, 1987.
[ 1985] E. Foxley. UNIX for super-users. International Computer Science Series, pgs. 213,
Addison- Wesley, 1985.
[ 1996] A. Frish. Essential UNIX Administration, 2. edicin, OReilly, 1996.
[ 1994] B. Goodheart y J. Cox. The Magic Garden Explained: The Internais of UNIX System V
Release 4, an Open Systems Design, pgs. 664, Prentice-Hall, 1994.
[ 1991] A. Goscinski. Distributed Operating Systems: The Logical Design. Addison-Wesley, 1991.
[ 198 lj J. N. Gray. The Transaction Concept: Virtues and Limitations. Proceedings of the
internatio nal Conference on Very Large Data Bases, pgs. 144-154, 1981.
[ 1994] M. Abadi y R. Needham. Prudent Engineenng Practice for Cryptographic Protocols. Proc,
of the IEEE Symp. On Security and Privacy, pgs. 122-136, IEEE Computer Society Press, 1994.
[ 1973j D. 1-1. Abernathy et al. Survey of Design Goalsfor Operating Systems. Operating Systems
Review, vol. 7, nm. 2, pgs. 29-48, abril 1973; OSR, vol. 7, nm. 3, pgs. 19-34, julio 1973; OSR,
vol. 8, nm. 1, pgs. 25-35, enero 1974.
[ 1993] D. Arnold. UNIX Security. A Practical Tutorial. McGraw-Hill, 1993.
[ et al., 19761 C. R. Attanasion et al. Penetrating an Operating System: A Study of VM/370 Inte
grity, 113M Systems Journal, vol. 15, nm. 1, pgs. 102-116, 1976.
[ 1986] M. J. Bach. The Design of the UNIX System. Prentice-Hall, 1986.
[ 1994] M. Blaze. Key Management in an Encrypting File System. Proceedings of the USENIX
Summer 1994 Technical Conference, pgs. 27-35, junio 6-10, 1994.
[ 19831 D. Bell. Secure Computer Systems: a Retrospective. Proc. of the IEEE Symp. on
Security and Privacy, pgs. 161-162, IEEE Computer Society Press, 1993.
[ 1991] S. Bellovin y M. Merrit. Limitations of the Kerberos Authentication System. Proc, of the
Usenix Conference, pgs. 253-267, invierno 1991.
[ 1995] A. Berman, y. Bourassa y E. Selberg. TRON: Process-Specific File Protection for the UNIX
Operating System. Proceedings of the USENIX 1995 Technical Conference, pgs. 165-175, enero
16- 20, 1995.
[ 19891 D. Brewer y M. Nash. The Chinese Wall Security Policy. Proc, of the JEEE Symp. on
Securily and Privacy, pgs. 206-214, IEEE Computer Society Press, 1989.
[ 1994] Common Criteria Editorial Board. Common Criteriafor Information Technology Security Eva
luations, versin 0,6, abril 1994.
[ 1987] D. Clark y D. Wilson. A Comparison of Conimercial and Military Computer Security
Policies. Proc, of the IEEE Symp. on Securily and Privacy, pgs. 184-194, IEEE Computer Society
Press, 1987.
[ l983a] IEEE Computer. Special issue: Data Security in Computer Networks, IEEE Computer, vol.
16, nm. 2, febrero 1983.
[ l983b1 IEEE Computer. Speciai issue: Computer Security Technology, IEEE Computer, vol. 16,
nm. 7, julio 1983.
[ 19761 Computer Surveys. Special issue: Reliable Software II: Fault-Tolerant Software. Computer
Surveys, vol. 8, nm. 4, diciembre 1976.
[ 1992] D. Curry. UNIX System Security. A Guidefor Users and System Administrators. Addison-
Wes ley, 1992.
[ 1993] B. DeDecker. Unix Securily and Kerberos. Lecture Notes in Computer Science, vol. 741,
pgs. 257-274, 1993.
[ 1984] H. M. Deitel. An Introduction to Operating Systems. Addison-Wesley, 1984.
[ 19791 L. F. DeLashmutt. Steps toward a pro vably secure operating system. COMPCON, pgs.
40-43, verano 1979.
[ 1982] D. Denning. Cryptography and Data Security. Addison-Wesley, 1982.
[ 1990] D. Denning. Computers Under Attack. Addison-Wesley, 1990.
[ 19961 D. Denning y D. Branstad. A taxonomy of Key Escrow Encryption Systems. Communication
of the ACM, vol. 39 nm. 3, pgs. 34-40, marzo 1996.
[ 1990] D. Farmer y E. Spafford. The COPS Security Checker System. Proc, of the Usenix
Summer Conference, pgs. 165-170, 1990.
[ 1990] R. Farrow. UNIX System Security. How to Protect your Data and Prevent Intruders.
Addison- Wesley, 1990.
[ 1989] P. Fites et al. Control and Securily of Computer Information Systems. Computer Science
Press, 1989.
[ 1982] C. Foster. Cryptoanalysis for Microcomputers. Hayden Books, 1982.
[ 1991] 5. Garfinkel y G. Spafford. Practical UNIX Securily. OReilly & Associates, Inc., 1991.
[ 1997] S. Garfinkel y G. Spafford. Web Securily & Commerce. OReilly & Associates, Inc., 1997.
[ 1988] M. Gasser. Building a Secure System. Van Nostrand Reinhoid, 1988.
[ 1991] A. Goscinski. Distributed Operating Systems. Addison-Wesley Publishing Company, 1991.
[ 1968] R. Graham. Protection in an Information Processing Utility. Communications of the ACM,
vol. 11, nm. 5, pgs. 365-369, mayo 1968.
[ 1984] F. T. Grampp y R. H. Morris. UNIX Operating System Securiiy. BLTJ, vol. 63, nm. 8, parte
2, pgs. 1649-1672, octubre 1984.
[ 1985] M. Harrison. Theoreticai Issues Concerning Protection in Operating Systems. Advances in
Computers, vol. 24, pgs. 61-100, 1985.
[ 1990] L. Hoffman. Rogue Pro grams: Viruses, Wor,ns, Trojan Horses. Van Nostrand Reinhold,
1990.
[ 1978] A. K. Jones. Protection Mechanisms and the Enforcement of Security Policies. En E.
Bayer et al., eds. Operating Systems: An Advanced Course, pgs. 228-250, Springer-Verlag,
Berln, 1978.
[ 1984] P. Karger y A. Herbert. An Augmented Capability Architecture to Support Lattice Security.
Proc, of the IEEE Symp. Qn Security and Privacy, pgs. 2-12, IEEE Computer Society Press, 1984.
[ 1990] P. Karger et al. A VMM Security Kernel for the VAX Architecturex.. Proc, of the IEEE
Symp. on Securily and Privacy, pgs. 2-19, IEEE Computer Society Press, 1990.
[ 1988] S. Krakowiak. Principies of Operating Systems. MIT Press, 1988.
[ 1999] P. Lambert. Implementing Security on Linux. Journal of System Administration, vol. 8, nm.
lo, pgs. 67-70, octubre 1999.
[ 1981] L. Lamport. Password Authentication with Insecure Communication. Communications of the
ACM, vol. 24, nm. 11, pgs. 770-772, noviembre 1981.
[ 1974] B. Lampson. Protection. ACM Operating Systems Review, vol. 8, nm. 1, pgs. 18-24,
enero 1974
[ 19811 C. Landwher. Formal Models for Computer Security. Computer Surveys, vol. 13, nm. 3,
pgs. 247-278, septiembre 1981.
[ 19881 T. Lee. Using Mandatory Integrity to Enforce Commercial Security. Proc, of the IEEE
Symp. on Securiiy and Privacy, pgs. 140-146, IEEE Computer Society Press, 1988.
[ 1976] T. A. Linden. Operating System Structures to Support Security and Reliable Software.
Compu ting Surveys, vol. 8, nm. 4, pgs. 409-445, diciembre 1976.
[ 1989] M. Luby y C. Rackoff. A study of password security. Journal of Cryptology: the Journal of the
International Association for Cryptologic Research, vol. 1, nm. 3, pgs. 15 1-158, 1989.
[ 1991] T. Mayfield. Integrity in an Automated Information System. NCSC C Technical Report, pgs.
79-91, septiembre 1991.
[ 1974] W. S. McPhee. Operating System Integrity in OS/VS2. IBM Systems Journal, vol. 13, nm.
3, pgs. 230-252, 1974.
[ 19821 C. H. Meyer y 5. M. Matyas. Cryptography. John Wiley & Sons, Nueva York, 1982.
[ 19921 J. Millen. A resource Allocation Model for Denia! of Service. Proc. of the IEEE Symp. on
Security and Privacy, pgs. 137-147, IEEE Computer Society Press, 1992.
[ 1987] S. P. Miller, B. C. Neuman, J. 1. Schiller y J. H. Saltzer. Kerberos Authentication
andAuthoriza tion System. MIT Project Athena, Cambridge, Massachusetts, diciembre, 1987.
[ 1979] R. Monis y K. Thornpson. Password Securily: A Case History. Communications of the ACM,
vol. 22, nm. 11, pgs. 594-597, noviembre 1979.
[ 1982] R. H. Monis. Cryptographic Features of the UNIX Operating System. Cryptologia, vol. 6,
nm. 3, julio 1982.
[ 1986] S. J. Mullender y A. S. Tanenbaum. The Design of a Capabiliiy-Based Distributed Opera
ting System. IEEE Computer, vol. 29, nm. 4, pgs. 289-299, 1986.
[ 1990] M. Nash y K. Poland. Sorne Conundrurns Concerning Separation of Duty. Proc. of the
IEEE Symp. on Security and Privacy, pgs. 201-207, IEEE Cornputer Society Press, 1990.
[ 1977] National Bureau of Standards. Data Encryption Standard. FIPS Publication 46, enero 1977.
[ 1985] Nacional Computer Secunty Center. Orange Book, diciembre 1985.
[ 1990] P. Neurnann. Towards Standars and Criteria for Critical Computer Systems. Proc, of the
COMPASS Conference, 1990.
[ 19811 D. Parker. Computer Security Management. Reston Books, 1981.
[ 1997] C. P. Pfleeger. Security in Computing, 2. edicin. Prentice-Hall, 1997.
[ 19741 U. J. Popek. Protection Structures. IEEE Computer, vol. 7, nm. 6, pgs. 22-33, junio 1974.
[ 1979] G. J. Popek et al. UCLA data secure UNIX. NCC 1979, vol. 48, pgs. 355-364.
[ 1994] J. Richter. Advanced Windows NT. Microsoft Press, 1994.
[ 1978] R. L. Rivest eta!. On Digital Signatures and Public Key Cryptosystems. Cornmunications of
the ACM, vol. 2!, nm. 2, pgs. 120-126, febrero 1978.
[ 1969] R. F. Rosin. Supervisory and Monitor Systems. Computing Surveys, vol. 1, nm. 1, pgs.
37-54, marzo 1969.
[ 1979] L. H. Seawright y R. A. MacKinnon. VM/370 - a Study of Muftipliciiy & Usefu!ness. IBM
Systems Journal, vol. 18, nm. 1, pgs. 4-17, 1979.
[ 19961 B. Schneider. Applied Cryptography, 2. edicin, John Wiley & Sons, 1996.
[ 1949] C. Shannon. Communication Theory of Secrecy Systems. Bel! Systems Technical Journal,
vol. 28, pgs. 659-715, octubre 1949.
[ 1998] A. Silberschatz y P. B. Galvin. Operating System Concepts, edicin. Addison-Wesley, 1998.
[ 19941 G. Simmons. Cryptoana!isis and Protoco! Failures. Communications of the ACM, vol. 37,
nm. 1!, pgs. 54-64, noviembre 1994.
[ 1966] A. Sinkov. Elementary Cryptoana!isis: A Mathematical Approach. Math Association of Ame-
rica, 1996.
[ 1998] D. A. Solomon. Inside Windows NT, 2. edicin, Microsoft Press, 1998.
[ 1995] W. Stallings. Operating Systems, 2. edicin. Prentice-Hall, 1995.
[ 1999] M. Taber y R. Roger. Maximum Linux securily: a hackers guide toprotecting your Linux
server and network. Macmillan Computer Publishing, 1999.
[ 1992] A. 5. Tanenbaum. Modern Operating Systems. Prentice-Hall, 1992.
[ 1997] A. S. Tanenbaum y A. Woodhull. Operating Systems Design and Implementation, 2. edi
cin. Prentice-Hall, 1997.
[ Tassel, 1972] D. Van Tassel. Computer Securiiy Management. Prentice-Hall, 1972.
[ 1979] W. Ware. Security Contro!sfor Comp uter Systems. Rand Corp Technical Report R-609-1,
octu bre 1979.
[ 1984] W. Ware. Information System Securily and Privacy, Communications of the ACM, vol. 27,
nm. 4, pgs. 316-32!, abril 1984.
[ 1995] W. Ware. A Retrospective on the Criteria Movement. Proc, of the National Information
Systems Security Conference, pgs. 582-588, 1995.
[ 1992] D. A. Willcox y 5. R. Bunch. A Tool for Covert Storage Channel Analysis of the UNIX
Kernel. J5th Nationa! Computer Security Conference, pgs. 13-16, Baltimore Convention Center,
octubre 1992.
{Wilkes, 19821 M. Wilkes. Hardware Support for Memory Protection. ACM Symp. On
Architectural Sup portfor Programming Languages and Operating Systems, pgs. 107-1 16, 1982.
[ 18951 P. H. Wood y S. G. Kochan. UNIX System Securily. Hayden UNIX System Library, Hayden
Books, 1985.
[Accetta, 1986] M. Accetta, R. Baron. D. Golub, R. Rashid, A. Tevanian y M. Young. Mach: A New
Kernel Foundationfor UNIX Development. Proceedings Summer 1986. USENIX Conference, pgs.
93-112, 1986.
[ 1994] K. P. Birman y R. Van Renesse. Reliable Distributed Computing with the Isis Toolkit. Nueva
York: IEEE Computer Society Press, 1994.
[ 1996a] K. P. Birman y R. Van Renesse. Software for Re/jable Networks. Scientific American
274:5, pgs. 64-69, mayo 1996.
[ 1996b] K. P. Birman. Building Secure and Reliable Networks Applications. Manning Publications
Co, 1996.
[ 19841 A. D. Bine! y B. J. Nelson. Implementig Remote Procedure Ca/ls. ACM Transactons on
Com puter Systems, vol 2, pgs. 39-59, febrero 1984.
[ 20011 G. Coulouris, J. Dollimore y T. Kindberg. Distributed Systems. Concepts and Design, 3.
edicin, Addison-Wesley, 2001.
[ 1988] C. Fidge. Timestamps in Message-Passing Systems That Preserve the Partial Ordering.
Procee dings of the Eleventh Australian Computer Science Conference, 1988.
[ 20001 L. D. Galli. Distributed Operating Systems: Concepts and Practice. Prentice-Hall, 2000.
[ 1997] A. S. Grimshaw, Wm. A. Wulf y the Legion Team. The Legion Vision of a Wordwide Virtual
Computer. Communications of the ACM, 40(1), enero 1997.
[ 19991 Proceedings of the IEEE, marzo 1999. Nmero especial sobre Memoria compartida
distribuida. [ 19941 P. Jalote. Fault Tolerance in Distributed Systems. Prentice-Hall, 1994.
[ 19781 L. Lamport. Time, Clocks, and the Ordering of Events in a Distributed System. Communica
tions of the ACM 21:7, pgs. 558-565, abril 1978.
[ 19861 K. Li. Shared Virtual Memory on Loosely Coupled Multiprocessors. Tesis Doctoral,
Universidad de Yale, 1986.
[ 19891 F. Mattern. Tkime and Global States in Distributed Systems. Proceedings of the
International Workshop on Parallel and Distributed Algorithms. Amsterdam, 1989.
[ 1990] S. Mullender, G. Van Rossum, A. 5. Tanenbaum, R. Van Renesse y H. Van Staveren.
Amoeba: A Distributed Operating Systems for the 1990s. IEEE Computer, vol. 23, nm. 5 pgs. 44-
53, mayo 1990.
[ 1993] S. Mullender (Ed.). Distributed Systems, 2. edicin, ACM Press, Nueva York, 1993.
[ 1999] R. Orfali, D. Harkey y J. Edwards. Client/Server Survival Guide, 3. edicin, Wiley Computer
Publishing, 1999.
[ 19961 R. Otte, P. Patrick y M. Roy. Understanding CORBA. Prentice-Hall, 1996.
[ 19981 J. M. Protc, M. Tomasevic y V. Milutinovic. Distributed Shared Memory: Concepts and
Systems. IEEE Computer Society Press, Los Alamitos, California, 1998.
[ 19811 G. Ricart, A. K. Agrawala. An Optimal Algorithm for Mutual Exclusion in Computer
Networks. Communications of the ACM, vol. 24, pgs. 9-17, enero 1981.
[ 1988] M. Roizer, V. Abrossimov, F. Armand, 1. Boule, M. Gien, M. Guillemont, F. Herrmann, C.
Kaiser, P. Leonard, S. Langlois y W. Neuhauser. Chorus Distributed Operating System. Computing
Systems, vol. 1, pgs. 305-379, octubre 1988.
[ 1992] W. Rosenberry, D. Kenney y G. Fisher. Understanding DCE. OReilly, 1992.
[ 1999] W. Rubin, M. Brain y R. Rubin. Understanding DCOM. Prentice-Hall, 1999.
[ 20001 W. Stallings. Data and Computer Communications, 6. edicin. Prentice-Hall, 2000.
[ 1999] W. R. Stevens. UNIX Network Programming. Prentice-Hall, 1999.
[ 1995] A. S. Tanenbaum. Distributed Operating Systems. Prentice-Hall, 1995.
[ 1996] A. S. Tanenbaum. Computer IVetworks, edicin. Prentice-Hall, 1996.
[ 1996] M. Beck, H. Bohme, M. Dziadzka, U. Kunitz, R. Magnus y D. Verworner. Linux Kernel nter
nals. Addison-Wesley, 1996.
[ 19971 P. Comes. The Linux A-Z. Prentice-Hall, 1997.
[ 19981 A. Silberschatz y P. B. Galvin. Operating System Concepts, a edicin, Addison-Wesley,
1998.
[ 1987] A. S. Tanenbaum. Operating Systems: Design and implementation, . edicin. Prentice- Hall,
1987.
[ 1997] A. S. Tanenbaum y A. Woodhull. Opera:ing Systems: Design and Implementation, 2. edi
cin. Prentice-Hall, 1997.
[Baker, 1997] A. Baker. The Windows NT Device Driver Book: A Guide for Programmers, Prentice-
Hall,
1997.
[ 1993] H. Custer. Inside Windows NT, l. edicin, Microsoft Press, 1993.
[ 1995] H. Custer. Inside Windows NT File System, Microsoft Press, 1995.
IiDekker, 1999] E. N. Dekker y J. M. Newcomer. Developing Windows NT Device Drivers: A Pro
grammer s
Handbook. Addison-Wesley, 1999.
[ 2000] K. Ivens. Managing Windows NT Logons. OReilly & Associates, Inc., 2000.
[ 2000] A. G. Lowe-Norris. Windows 2000 Active Directory. OReilly, 2000.
[ 1999] J. M. Martnez Delgado y X. Martnez Balart. Windows NT 4.0 Server: Gua Avanzada.
Prentice-Hall, 1999.
1997] S. Mitchell. Inside the Windows 95 File System. OReilly & Associates, Inc., 1997
[ 1997] R. Nagar. Windows NT File System Internals: A Developers Guide. OReilly & Associates,
Inc.,
1997.
[ 1997] E. Pearce. Windows NT in a Nutshell: A Desktop Quick Reference for System
Administration.
OReilly & Associates, Inc., 1997.
[ 1998] D. A. Solomon. Inside Windows NT, 2. edicin, Microsoft Press, 1998.
Ncleo (kernel) del sistema Peor ajuste (worst-Jit), 185 LRU, 202
operativo, 34 Perifricos, 23-25 ptima, 201
Ncleo seguro, 514 perror, 119 reloj, 202
Nmero PIC (Position-Independent segunda oportunidad, 202
de subarchivos, 700 Code). de seguridad, 505
mgico, 424 Vase Cdigo independiente comercial, 507
Objeto de memoria, 178 de militar, 505
Objetos la posicin de seguridad militar, 505
de control, 623 pipe, 259 compartimento, 506
de planificacin, 623 Pirata, 501 dominancia en, 506
open, 259, 441 Pistas, 375 niveles de seguridad, 505
opendir, 452 Planificacin Polticas
OpenMutex, 300 de procesos distribuidos, 601 de actualizacin de cache,
OpenProcess, 146 en Windows NT, 626 605
OpenSemaphore, 295 Planificacin de procesos, de reemplazo de cache, 605
OpenThread, 153 102-109 de reparto de carga, 600
Operacin a corto plazo, 102 Prcticas de Sistemas
signal sobre un semforo, 237 a largo plazo, 102 Operativos, 669
wait sobre un semforo, 237 a medio plazo, 102 archivos con bandas, 699
Operaciones algoritmos de (vase comunicacin con sockets,
de un manejador de disco IDE algoritmos de 685
en planificacin) gestin de archivos, 677
LINUX, 381 en POSIX, 107 gestin de procesos, 673
sobre regiones, 182 en sistemas de tiempo real, manejo de interrupciones, 679
Orange Book, 524 106 programacin de scripts, 670
Ordenacin de eventos, 593 en Windows, 108 sistema multiprogramado, 690
OS/2, 43 Planificacin del disco, 382 Prediccin de interbloqueos,
OS/360, 69 poltica CSCAN, 383 337
Overlays, 172 poltica del ascensor, 382, 383 algoritmo del banquero, 341
Pgina, 188 poltica FCFS (First Come algoritmo para una
Paginacin, 17, 188-197 First representacin me diante un
por demanda, 199 Served), 382 grafo de recursos, 339
Pginas poltica LOOK, 383 algoritmos de prediccin, 339
de intercambio, 17 poltica SCAN, 383 estado seguro, 338
virtuales, 17 poltica SSF (Shortest Seek Prepaginacin, 200
Paquete, 564 First), 382 Prevencin de interbloqueos,
Particin, 459 Planificador, 82, 94, 102 334
activa, 378 Poltica espera circular, 337
de intercambio, 459 de actualizacin, 12 exclusin mutua, 334
raz, 459 de asignacin de marcos de retencin y espera, 335
Particiones extendidas, 459 pgina, sin expropiacin, 336
Paso de mensajes, 248 204-205 Primero que ajuste (first-fit),
almacenamiento, 250 asignacin dinmica 204-205 185
colas de mensajes, 249 asignacin fija, 204 Prioridad, 626
colas de mensajes POSIX, de asignacin de memoria, base, 615
274 170 Privilegios, 55
comunicacin cliente-servidor mejor ajuste (best-fit), 185 Problema de los lectores-
con peor ajuste (worst-fit), 185 escritores, 230
paso de mensajes, 252 primero que ajuste (first-fit), resolucin con mutex, 247
flujo de datos, 248 185 resolucin con semforos, 241
mailslots de Win32, 303 de escritura diferida, 483 Problema del productor-
nombrado, 249 de escritura en la cache de consumidor, 230
operacin send, 248 UNIX, 483 resolucin con colas de
productor-consumidor con de escritura inmediata, 482 mensajes
paso de de escritura retrasada, 483 POSIX, 277
mensajes, 251 de escritura retrasada resolucin con mutex y
puertos, 249 perezosa, 635 variables
secciones crticas con paso de de extraccin, 11 condicionales, 245
men sajes, 250 de ubicacin, 11 operacin receive, 248
sincronizacin, 250 de reemplazo, 11, 201-205
pause, 143 FIFO, 202